| Time |
Nick |
Message |
| 05:11 |
|
eady joined #evergreen |
| 07:14 |
|
rjackson_isl joined #evergreen |
| 07:18 |
|
agoben joined #evergreen |
| 08:15 |
|
ericar joined #evergreen |
| 08:25 |
|
Dyrcona joined #evergreen |
| 08:26 |
|
Callender_ joined #evergreen |
| 08:34 |
|
mmorgan joined #evergreen |
| 08:59 |
|
jwoodard joined #evergreen |
| 09:13 |
|
yboston joined #evergreen |
| 09:17 |
|
maryj joined #evergreen |
| 09:31 |
|
mmorgan1 joined #evergreen |
| 09:50 |
|
maryj joined #evergreen |
| 09:58 |
|
jvwoolf joined #evergreen |
| 10:25 |
|
Callender joined #evergreen |
| 10:48 |
|
ericar joined #evergreen |
| 10:48 |
|
Christineb joined #evergreen |
| 10:57 |
|
gsams joined #evergreen |
| 11:17 |
|
mmorgan joined #evergreen |
| 11:43 |
|
brahmina joined #evergreen |
| 11:47 |
|
jihpringle joined #evergreen |
| 11:59 |
|
gvi joined #evergreen |
| 12:00 |
gvi |
I'm working on installing evergreen using http://docs.evergreen-ils.org/2.1/html/server_install.html. I think I'm not using the most up to date instructions 'cause I don't seem to be able to install on ubuntu trusty with those instructions. |
| 12:01 |
csharp |
gvi: what problems are you experiencing? |
| 12:02 |
gvi |
I'm trying to figure out how to get pgsql libdbi installed. The make -f Open-ILS... step doesn't like ubuntu-trusty as an osname |
| 12:03 |
gvi |
I think I have the latest source Evergreen-ILS-2.1.3a |
| 12:04 |
gvi |
So I thought I might have to install that ppa that was mentioned, but it doesnt' have a dist/trusty directory. |
| 12:04 |
csharp |
gvi: 2.1.3a? - that is very very old |
| 12:04 |
gvi |
Great. |
| 12:04 |
gvi |
Nuts. |
| 12:04 |
csharp |
gvi: currently supported releases: https://evergreen-ils.org/egdownloads/ |
| 12:05 |
gvi |
I guess I want 2.10.6 then? |
| 12:05 |
csharp |
gvi: yeah, that's the most recent |
| 12:06 |
gvi |
Thanks |
| 12:09 |
gvi |
I see what happened. The instructions on the page I was reading said to download that version, so I did. :) |
| 12:09 |
jeff |
yup, because it was the documentation for 2.1 -- it told you to download 2.1 :-) |
| 12:13 |
* tsbere |
wonders if we should be putting a big "THIS DOCUMENTATION REFERS TO AN OLDER VERSION OF EVERGREEN" warning on all the non-current server install doc pages |
| 12:29 |
gvi |
Am I going to have a problem installing the staff client on 16.04? |
| 12:31 |
Dyrcona |
gvi: that is really old an out of date. |
| 12:32 |
gvi |
16.04? |
| 12:32 |
Dyrcona |
gvi: No, I was responding to the 2.1.3. |
| 12:32 |
gvi |
Yes, I found that out. Thanks. |
| 12:32 |
Dyrcona |
If you're going to install 2.10.6 I recommend 14.04 for the server. |
| 12:32 |
gvi |
I've successfully compiled 2.10.6 thanks. |
| 12:33 |
Dyrcona |
The client should run on 16.04. I use it on 16.04. |
| 12:33 |
gvi |
The server is running 14.04 |
| 12:33 |
gvi |
OK thanks. |
| 12:34 |
Dyrcona |
Did you do the steps to build your own client? |
| 12:34 |
gvi |
Working on it. |
| 12:35 |
gvi |
I'm trying to figure out what exactly the STAFF_CLIENT_STAMP_ID=rel_name would look like right now. |
| 12:35 |
gvi |
I'm guessing 2.10.6. |
| 12:36 |
Dyrcona |
rel_2_10_6 |
| 12:36 |
gvi |
OK thanks. |
| 12:36 |
Dyrcona |
You can alternately do STAFF_CLIENT_VERSION=2.10.6 |
| 12:36 |
Dyrcona |
You'll end up with almost the same thing. |
| 12:37 |
|
bmills joined #evergreen |
| 12:38 |
|
rfrasur joined #evergreen |
| 12:40 |
|
brahmina joined #evergreen |
| 12:40 |
bshum |
gvi: You're following something like https://evergreen-ils.org/documentation/install/README_2_10.html#_installation_instructions right? Cause in the install instructions linked from the egdownloads page, all the version stamps should be explicitly defined in the instruction... |
| 12:47 |
gvi |
I am now. |
| 12:58 |
gvi |
OK https://<IP>/eg/opac/home give me a 500 error. I actually navigated to https://<IP>/ but it rewrote or otherwise redirected me to that address. |
| 12:58 |
gvi |
Nothing in the apache error.log |
| 12:59 |
jeff |
okay. |
| 12:59 |
jeff |
step 1: stop apache. |
| 12:59 |
gvi |
I must have missed a stip |
| 12:59 |
jeff |
step 2: check the state of opensrf services with something like osrf_control -l --diagnostic |
| 12:59 |
jeff |
(run as the opensrf user) |
| 13:00 |
jeff |
the -l means "localhost", which is what you'll use in a default install unless you went out of your way to do things differently. |
| 13:00 |
jeff |
if no opensrf services are running, then you'll want to start them. if some are running but things like storage/cstore are not, then they likely ran into trouble connecting to the database. |
| 13:00 |
gvi |
I see osrf isnt running. |
| 13:01 |
jeff |
did you get a dozen or so services, and none of them running? |
| 13:01 |
gvi |
Yes |
| 13:01 |
jeff |
(in the output of --diagnostic) |
| 13:01 |
jeff |
okay. try this, then repeat the diagnostic command: osrf_control -l --start-all |
| 13:01 |
jeff |
more services should be running than before. :-) |
| 13:02 |
gvi |
Yes much better |
| 13:03 |
gvi |
Oops, still getting 500 error however. I did restart apache |
| 13:03 |
jeff |
are all of the opensrf services now running as shown in osrf_control -l --diagnostic |
| 13:04 |
gvi |
Getting IS NOT CONNECTED TO THE NETWORK in osrfsys.log. |
| 13:05 |
gvi |
Let me get a second window as osrf user. |
| 13:06 |
gvi |
I have 7 services running. Two routers and 5 opensrf services. |
| 13:07 |
Dyrcona |
Diagnostic should tell you which are not running. |
| 13:07 |
jeff |
that's rather low. it is possible that you didn't update the opensrf config files with the Evergreen config (as opposed to the OpenSRF config) |
| 13:07 |
Dyrcona |
My guess is cstore and storage are not running and you should run eg_db_config with correct options. |
| 13:08 |
gvi |
math *2 persist settings and validator |
| 13:08 |
jeff |
gvi: if your diagnostic output does not include services like open-ils.actor and open-ils.cstore and open-ils.storage, then you're probably not running with the correct /openils/conf/opensrf_core.xml and /openils/conf/opensrf.xml |
| 13:08 |
Dyrcona |
jeff++ |
| 13:09 |
gvi |
OK I'll see if I can find where I went wrong. |
| 13:09 |
Dyrcona |
That's a common mistake. People don't notice that they have to copy the files again after installing Evergreen and edit them again. |
| 13:09 |
jeff |
gvi: this would be the point where you'd have put that in place: http://docs.evergreen-ils.org/2.10/_configure_opensrf_for_the_evergreen_application.html |
| 13:09 |
gvi |
So that's in the evergreen docs, not the opensrf docs? |
| 13:10 |
jeff |
gvi: right now, before changing config, you'll want to do osrf_control -l --stop-all |
| 13:10 |
Dyrcona |
Yes, in the Evergreen docs. |
| 13:10 |
gvi |
stopped |
| 13:10 |
Dyrcona |
Specifically in the README, and I recommend that you use the README from the tarball rather than anything online. |
| 13:11 |
Dyrcona |
The README should be up to date for the version that you are installing. |
| 13:11 |
jeff |
gvi: there's another quirk here -- since you probably ran the eg_db_config script before now, it would have tried to update the configuration file that you will now be replacing. |
| 13:12 |
gvi |
I don't have whatever software is necessary to display the README. It's in a format I'm not familiar with. |
| 13:13 |
jeff |
it should be a text file. |
| 13:13 |
Dyrcona |
It's plain text, but I'm about to share a link to the online version where you need to start over. |
| 13:13 |
Dyrcona |
https://evergreen-ils.org/documentation/install/README_2_10.html#_configure_opensrf_for_the_evergreen_application |
| 13:14 |
Dyrcona |
Any text editor, less or more should be able to read it. |
| 13:14 |
jeff |
with some special formatting that when interpreted by some software will enhance its display, but the text file itself should still be perfectly readable without that. |
| 13:15 |
gvi |
Jeff it is, but when it says "Skip this section" it's not obvious what a section is in the text file. It is in the html file. |
| 13:15 |
gvi |
Dyrcona: I'm there. |
| 13:16 |
gvi |
Thanks, Guy, let me hack away at this some more. |
| 13:18 |
Dyrcona |
gvi: The README uses asciidoc. The sections are more obvious in the HTML rendered from the aciidoc. |
| 13:19 |
Dyrcona |
jeff: heh. I should have read up a little. I stepped away from the computer for a moment. |
| 13:20 |
Dyrcona |
gvi: You might need to start over at section 9. |
| 13:21 |
gvi |
OK |
| 13:21 |
Dyrcona |
I see the "Skip this section..." is in section 8. |
| 13:21 |
Dyrcona |
I've done it so many times, I don't always refer to the documentation. |
| 13:21 |
gvi |
I think I did 9 right. |
| 13:22 |
Dyrcona |
OK. that's good. |
| 13:48 |
|
bmills1 joined #evergreen |
| 13:50 |
gvi |
11.2 port and dbname? |
| 13:55 |
gvi |
I'm a mysql guy, I don't know postgres. |
| 13:58 |
Bmagic |
Did MAX_HOLDS get deprecated? I don't see anywhere in the code where it gets used. |
| 14:02 |
jeff |
Bmagic: I believe the concept of max holds is still present. The config.hold_matrix_test.max_holds fail part is mapped to the MAX_HOLDS event in OpenILS::Utils::PermitHold |
| 14:03 |
Bmagic |
I found that line |
| 14:03 |
Bmagic |
But that is the only reference |
| 14:03 |
Bmagic |
There should be code that assigns that? |
| 14:03 |
jeff |
Bmagic: There was at least one "old way" of enforcing a limit on the number of outstanding holds a patron could have... that changed around the time in-db circ came about. |
| 14:04 |
jeff |
Bmagic: the table config.hold_matrix_matchpoint contains a max_holds column which is consulted by the action.hold_request_permit_test function, both of which are defined in Open-ILS/src/sql/Pg/110.hold_matrix.sql |
| 14:05 |
Bmagic |
I see |
| 14:05 |
Bmagic |
there's the glue |
| 14:05 |
jeff |
Bmagic: that function can return a fail_part of config.hold_matrix_test.max_holds, which is mapped to the MAX_HOLDS event in OpenILS::Utils::PermitHold::indb_hold_permit as defined in Open-ILS/src/perlmods/lib/OpenILS/Utils/PermitHold.pm |
| 14:06 |
Bmagic |
I was troubleshooting a hold error message "item is too new to transit this far" - which was thought to be the message when the patron had max holds - it must be a coincidence that the patron also had max holds |
| 14:09 |
jeff |
I experienced something similar the other day and had a note to look further: when at max holds and trying to request a hold where all otherwise-eligible items were age hold protected, I didn't receive an option to override the age hold protection (and place a hold that i'd have to wait longer for), and it wasn't clear that the reason I was not getting an option to override was because I was also at "max holds". |
| 14:09 |
jeff |
The situation where I was experiencing it was within our mobile app, so I'm not sure (without digging) if it was in that abstraction layer or an issue within the tpac itself. |
| 14:11 |
tsbere |
jeff: Part of the headache there is you get a failure reason set for *every copy*. Which set of reasons do you pass to the end user? |
| 14:11 |
tsbere |
I made it so that if age protection was the *only* reason on *any* copy then that information would be passed back up. But anything else is likely to get lost. |
| 14:12 |
gvi |
I'm at the point of testing the staff client. I've entered so many user names in the last few hours I don't know which one to use. |
| 14:13 |
tsbere |
gvi: You probably specified the username/password at the eg_db_config step. |
| 14:13 |
gvi |
OK thanks. |
| 14:14 |
gvi |
That was it. |
| 14:26 |
|
mcenter joined #evergreen |
| 14:27 |
mcenter |
is there a way for us to import book information to the catalog using ISBNs only? |
| 14:31 |
tsbere |
Z39.50 lookups? |
| 14:44 |
mcenter |
Perfect! Thank you |
| 14:45 |
mcenter |
Also, we are just starting to build our catalog and we need to add barcodes to our books.. is there a way to print those within evergreen |
| 14:50 |
|
annagoben joined #evergreen |
| 14:51 |
|
serflog joined #evergreen |
| 14:51 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged: http://irc.evergreen-ils.org/evergreen | Large pastes at http://paste.evergreen-ils.org |
| 14:52 |
tsbere |
mcenter: If you only have one of any given book right now you could cheat and use the ISBN as the barcode for the time being until you can get a supply of non-ISBN barcodes |
| 14:54 |
mcenter |
Ok. We have multiple copies of books but maybe we can work something out Thanks! |
| 14:55 |
|
gmcharlt joined #evergreen |
| 14:55 |
jeff |
I would recommend avoiding trying to repurpose the ISBN barcodes as library barcodes. We've never done it, so I can't say that this recommendation is from personal experience, but there are many potential pitfalls, despite it being technically possible. |
| 14:57 |
jeff |
we use 14 digit codabar barcodes with the 14th digit being a generated luhn/mod10 checkdigit, which is fairly standard for US library items. it might be worth inquiring with any surrounding libraries to see if there is any regional/statewide barcode prefix standard that you should consider reserving space within. |
| 14:57 |
|
dbs joined #evergreen |
| 14:58 |
jeff |
i do see a number of public school libraries that use different barcode schemes. |
| 14:59 |
|
gmcharlt joined #evergreen |
| 15:00 |
jeff |
hang in there, Atlanta Linode users. ;-) |
| 15:01 |
jeffdavis |
+1 to jeff's comment above about barcode standardization, it helps avoid future issues |
| 15:03 |
|
ericar joined #evergreen |
| 15:03 |
gsams |
We use 14 digit barcodes with our 4-digit state library ID embedded in the beginning |
| 15:04 |
gsams |
each one begins with 2 for patrons and 3 for items, then the 4 digit code |
| 15:05 |
gsams |
so each library has a different identifier in our consortium |
| 15:08 |
* tsbere |
is fairly certain that there was a group that kept those 4 digit codes as unique as possible in the past, given that he has seen the lists for several groups in different parts of the country without seeing overlap |
| 15:09 |
gsams |
Some of our libraries don't actually use their code, but that was only because they didn't overlap and rebarcoding so many items was not ideal. |
| 15:12 |
mmorgan |
http://www.ala.org/tools/bar-codes-libraries |
| 15:15 |
tsbere |
mmorgan: I suspect I keep dealing with groups that got their numbers from GEAC. |
| 15:15 |
mmorgan |
That's where (almost) all of our libraries got theirs. |
| 15:25 |
gsams |
I was slightly incorrect, we use the Federal-State Cooperative System ID |
| 15:25 |
|
bmills joined #evergreen |
| 15:36 |
|
jboyer-isl joined #evergreen |
| 15:47 |
JBoyer-DC |
@eightball Will I get this install finished before rush hour? |
| 15:47 |
pinesol_green |
JBoyer-DC: What are you asking me for? |
| 15:47 |
JBoyer-DC |
I'll take that as a no... |
| 15:47 |
rjackson_isl |
Boo |
| 15:57 |
|
jboyer-isl joined #evergreen |
| 16:15 |
Bmagic |
jeff: tsbere: so there is a bug here? When one of the copies is age protected on the bib, the error is "transit that far" |
| 16:16 |
tsbere |
Bmagic: It is likely that the *last* copy checked wasn't the age protected one, so who knows what is coming back....also, the age protected thing won't help if you have more than just age protection blocking |
| 16:16 |
tsbere |
Bmagic: For example, age protection *and* max holds doesn't trigger the code in question... |
| 16:19 |
Bmagic |
so if the local copy is checked out during the hold process, it's not considered as a part of the equation. Only the age protected items at other libraries are considered which are age protected. In addition, the patron has max holds. Therefore the system needs to display one or the other |
| 16:19 |
tsbere |
No, checked out copies are counted during hold placement. Not for the pull list, but for placement. |
| 16:21 |
tsbere |
As for "what to tell the user" - There is no good answer to that as each copy may have different reasons. Transit range, hold limits, holdable set to false in the matching rule, ratios triggering... |
| 16:22 |
Bmagic |
so, it cannot be improved? |
| 16:23 |
Dyrcona |
Well, you could return a list of all the considered copies and all of the failure reasons. The backend knows. It's a matter of percolating it up. :) |
| 16:23 |
Bmagic |
tsbere: "I made it so that if age protection was the *only* reason on *any* copy then that information would be passed back up." - do you have a branch on that? |
| 16:23 |
tsbere |
Bmagic: Er, "all supported releases", I think? |
| 16:24 |
tsbere |
That is an oldie |
| 16:24 |
Dyrcona |
Bmagic: I think something went in recently to improve the hold failure messages. |
| 16:24 |
Bmagic |
lol, we are on 2.9.1 and this issue arises |
| 16:32 |
Dyrcona |
Bmagic: Lp 1481441 might help. |
| 16:32 |
pinesol_green |
Launchpad bug 1481441 in Evergreen "action.hold_request_permit_test fail_parts can be confusing to end users" [Medium,Fix committed] https://launchpad.net/bugs/1481441 |
| 16:35 |
Bmagic |
thanks! |
| 16:39 |
jeff |
JBoyer: did you ever follow up on the idea mentioned here? https://bugs.launchpad.net/evergreen/+bug/1481441/comments/4 |
| 16:39 |
pinesol_green |
Launchpad bug 1481441 in Evergreen "action.hold_request_permit_test fail_parts can be confusing to end users" [Medium,Fix committed] |
| 16:44 |
Dyrcona |
phasefx: I'm going to open a new bug about https://bugs.launchpad.net/evergreen/+bug/1593815/comments/7 . It is happening to us. |
| 16:44 |
pinesol_green |
Launchpad bug 1593815 in Evergreen "The negative balance settings are being applied even if no existing setting, " [Undecided,New] |
| 16:45 |
phasefx |
Dyrcona: sounds good |
| 16:52 |
|
mcenter joined #evergreen |
| 16:52 |
|
TARA joined #evergreen |
| 17:02 |
Dyrcona |
phasefx: Lp 1618624 if you have anything to add. |
| 17:02 |
pinesol_green |
Launchpad bug 1618624 in Evergreen "Adjusting Bills to Zero Will Prematurely Close a Transaction" [Undecided,New] https://launchpad.net/bugs/1618624 |
| 17:05 |
phasefx |
Dyrcona++ it's no longer fresh in my mind |
| 17:06 |
dbwells |
Dyrcona++ |
| 17:06 |
Dyrcona |
I don't have a fix, or even an idea for a fix, yet. |
| 17:06 |
Dyrcona |
I can probably come up with a SQL to fix the circulations in the mean time. |
| 17:07 |
Dyrcona |
I'll take a stab at a fix in the coming days. |
| 17:07 |
|
mmorgan left #evergreen |
| 17:20 |
phasefx |
incidentally, it looks like live_t/purge-user-activity.pg is failing now |
| 17:21 |
phasefx |
and on the perl side, live_t/18-lp1592891_sip_standing_penalties.t |
| 17:21 |
phasefx |
actually, wrong test on that last one |
| 17:21 |
phasefx |
live_t/19-lp1306666-abort-transit-copy-status.t |
| 17:40 |
Dyrcona |
phasefx: If that last one is failing, I'm not sure why. I'd have to play with it some more. |
| 17:42 |
* Dyrcona |
sees about building a xenial vm from an ISO. It has been failing with vmbuilder since sudo was updated yesterday. |
| 17:45 |
* Dyrcona |
give vmbuilder one last shot. |
| 17:48 |
phasefx |
for that abort test, it's expecting Reshelving, and getting Canceled Transit. I haven't looked more closely than that. Maybe the behavior is correct and the test needs updating |
| 17:50 |
Dyrcona |
Ah, OK. I hadn't noticed that csharp's branch had gone in. |
| 17:50 |
Dyrcona |
I thought the tests were to be rewritten before that happened. |
| 17:51 |
Dyrcona |
I'll see if I can get around to fixing the tests by this weekend, but I can't promise much. |
| 17:56 |
Dyrcona |
And, yeah, vmbuilder is still choking on sudo. |
| 18:13 |
Dyrcona |
virt-manager is being a pain. I wish I could remember the options that I used for virt-install that last time. |
| 18:20 |
|
gmcharlt joined #evergreen |
| 18:32 |
|
TARA joined #evergreen |
| 19:02 |
|
_adb joined #evergreen |
| 20:23 |
|
gsams_ joined #evergreen |
| 20:25 |
|
gsams joined #evergreen |
| 21:03 |
|
_adb left #evergreen |
| 21:09 |
|
bmills joined #evergreen |
| 21:13 |
bmills |
anyone else having issues with docs.evergreen-ils.org ? |
| 21:23 |
csharp |
http://www.downforeveryoneorjustme.com/docs.evergreen-ils.org - down for me too |
| 22:16 |
jeff |
much (all?) of mohawk college seems to be down again. |
| 23:16 |
dbs |
Don't trust the Canadians. At least not the ones in Ontario. |
| 23:45 |
|
remingtron_ joined #evergreen |
