| Time |
Nick |
Message |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:18 |
|
rjackson_isl joined #evergreen |
| 07:18 |
|
agoben joined #evergreen |
| 07:42 |
|
krvmga joined #evergreen |
| 08:05 |
|
JBoyer joined #evergreen |
| 08:06 |
|
ericar joined #evergreen |
| 08:15 |
|
remingtron joined #evergreen |
| 08:19 |
|
Dyrcona joined #evergreen |
| 08:45 |
|
mmorgan joined #evergreen |
| 09:08 |
|
rlefaive joined #evergreen |
| 09:15 |
|
bos20k joined #evergreen |
| 09:16 |
|
mrpeters joined #evergreen |
| 09:19 |
* jeff |
ponders upgrading to 2.10.4 just for fun |
| 09:27 |
|
yboston joined #evergreen |
| 09:29 |
|
kmlussier joined #evergreen |
| 09:29 |
* csharp |
submits feature request for "Upgrade Evergreen" button on the login page of the staff client |
| 09:30 |
kmlussier |
csharp++ |
| 09:33 |
|
terran joined #evergreen |
| 09:52 |
|
cfarley joined #evergreen |
| 09:53 |
jeff |
so who's upgrading this weekend? usually someone, it seems... PINES? :-) |
| 09:54 |
krvmga |
jeff: cwmars upgraded last weekend |
| 09:55 |
jeff |
oh? great! what did you upgrade to, and how'd it go? |
| 09:57 |
jeff |
2.9.5, it seems. |
| 10:02 |
|
bos20k joined #evergreen |
| 10:07 |
|
mmorgan1 joined #evergreen |
| 10:11 |
krvmga |
jeff: the upgrade went very well, i think |
| 10:12 |
krvmga |
the only real glitches were ones we made ourselves :) |
| 10:12 |
krvmga |
no glitches with evergreen |
| 10:19 |
kmlussier |
heh |
| 10:20 |
|
bos20k joined #evergreen |
| 11:19 |
|
mrpeters joined #evergreen |
| 11:38 |
|
brahmina joined #evergreen |
| 11:40 |
csharp |
jeff: NOOOOOOOOOOOOOOOOOOOOOO! er... I mean, nope, no upgrade this weekend :-P |
| 11:51 |
jeff |
i was very tempted when terran joined to go with "hi, terran! csharp was just telling us about the upcoming PINES upgrade to 2.10.4 this holiday weekend!" ;-) |
| 11:51 |
* csharp |
goes rogue and does it anyway |
| 11:51 |
jeff |
csharp: going with the experimental GPU-assisted records reingest, right? ;-) |
| 11:52 |
|
bmills joined #evergreen |
| 11:52 |
* csharp |
ports it all to Windows Server 2008 |
| 11:52 |
* terran |
has heart attack and dies |
| 11:53 |
bshum |
Windows_Server-- |
| 11:53 |
* bshum |
heartily spits on Windows Server anything |
| 12:02 |
|
bmills1 joined #evergreen |
| 12:06 |
|
mmorgan joined #evergreen |
| 12:16 |
|
jihpringle joined #evergreen |
| 12:33 |
Bmagic_ |
Can I get a poll what everyone's Apache MaxClients setting? We have 8 app servers with 150 clients max. |
| 12:34 |
jeff |
Hrm. Does anyone happen to have an archive of the content formerly available at http://blog.esilibrary.com/2013/10/15/hacking-away-a-web-based-staff-client/ ? Alas, archive.org has only crawled the 404 |
| 12:34 |
jeff |
ah, answering my own question -- i think the original post content can be found here: https://esilibrary.com/hacking-away-a-web-based-staff-client/#sthash.A8867Qfu.dpbs |
| 12:35 |
bshum |
jeff: Yeah I was about to say that if one were to remove the date stuff |
| 12:35 |
bshum |
:) |
| 12:43 |
bshum |
Bmagic_: 150 each? |
| 12:43 |
Bmagic_ |
yeah, we just saw a huge CPU spike on all of them all at once. LVS was reporting roughly 150 active connections on each app server during that lag |
| 12:43 |
bshum |
That sounds like the standard default option. |
| 12:44 |
Bmagic_ |
it is the default as per the install instructions |
| 12:44 |
bshum |
I don't think we varied ours much when we played. |
| 12:44 |
bshum |
That sort of thing has happened before, where we exhausted our apache max connections |
| 12:44 |
bshum |
Bad bots, or glitchy bug |
| 12:45 |
Bmagic_ |
right, it has been happening to us more and more lately |
| 12:45 |
Bmagic_ |
I am considerinng making that maxclients setting something higher, but then Im not sure, but I think we should also increase threads/spares/etc |
| 12:47 |
|
phasefx_ joined #evergreen |
| 12:47 |
|
miker joined #evergreen |
| 12:47 |
|
akilsdonk joined #evergreen |
| 12:48 |
bshum |
Did the logs show you anything interesting? Like X IP tried grabbing the same page search results or whatever 1000 times over? :) |
| 12:49 |
dbs |
"bad bots", heh |
| 12:49 |
|
jyorio joined #evergreen |
| 12:50 |
bshum |
It's almost always some chinese or russian web crawler. |
| 12:50 |
bshum |
:D |
| 12:51 |
Dyrcona |
Bmagic: We have maxrequestworkers set to 120 on our public brick. |
| 12:51 |
Dyrcona |
About the only time we hit that limit is when someone mashes the Enter key for 30 seconds when doing a search. |
| 12:52 |
Dyrcona |
The number of Apache processes running throughout the day varies a lot. |
| 12:52 |
Bmagic_ |
hmm, yeah, I figured it was bots but somehow we need to keep it from affecting the consortium |
| 12:54 |
Dyrcona |
We haven't had much trouble with bots lately, particularly since we split to a public and staff brick. |
| 12:55 |
Dyrcona |
The few times that Apache really goes nuts, it seems someone has dropped something on their keyboard. |
| 12:55 |
Dyrcona |
And, I chose the 120 number after lots of log diving and some testing. |
| 12:56 |
Dyrcona |
With our hardware configuration, even if we set to 150, 120 is about where performance really tanks. |
| 12:56 |
Dyrcona |
Like, "No, I'm not replying to your request for 5 minutes," kind of tanks. |
| 12:57 |
Dyrcona |
We typically don't exceed 100 at any given time anyway. |
| 12:59 |
|
barbara joined #evergreen |
| 13:04 |
|
jwoodard joined #evergreen |
| 13:04 |
|
graced joined #evergreen |
| 13:24 |
jeff |
well that's interesting. on a test VM that is often dormant for long periods of time, i have at least one apache process that doesn't serve requests. |
| 13:24 |
jeff |
if a request hits that child, the browser just sits until it times out. |
| 13:28 |
jeff |
sanity check: new feature merged to master in Feb of this year, I've found a bug in it. The feature has been included in a release of Evergreen. Sounds like the bug and fix is a new ticket, not a re-open of the original ticket. Am I correct? |
| 13:29 |
kmlussier |
jeff: Yes |
| 13:29 |
berick |
i'd say new ticket |
| 13:29 |
jeff |
thanks! kmlussier++ berick++ |
| 13:29 |
kmlussier |
The only time I would reopen an LP bug is if it's in master and not in a current release. |
| 13:33 |
jeff |
and jeffdavis++ for some confirmation of bug :-) |
| 13:40 |
jeff |
Is anyone here aware of anyone else running or near-term planning to upgrade to 2.10? |
| 13:42 |
kmlussier |
jeff: The only other site I know of is Sitka, but since jeffdavis confirmed your bug, I"m guessing you already knew that. |
| 13:44 |
jeffdavis |
jeff++ |
| 13:52 |
bcormack |
/msg NickServ identify admin123 |
| 13:54 |
|
rhamby joined #evergreen |
| 14:00 |
dbs |
jeff: we'll be upgrading to 2.10 in July-ish |
| 14:02 |
kmlussier |
csharp: Should bug 1077947 have a pullrequest tag? We had a Sandbox request for that one. |
| 14:02 |
pinesol_green |
Launchpad bug 1077947 in Evergreen ""ITEM_ON_HOLDS_SHELF" event message not specific enough for all use cases" [Wishlist,Triaged] https://launchpad.net/bugs/1077947 |
| 14:04 |
kmlussier |
And, wow, that bug is old! |
| 14:04 |
|
bos20k joined #evergreen |
| 14:05 |
kmlussier |
For some reason, Thunderbird has suddenly been marking a lot of my LP mail as junk. |
| 14:05 |
|
gsams_ joined #evergreen |
| 14:07 |
kmlussier |
And then another Sandbox was requested for bug 1189989, but based on gmcharlt's comments at the end, I'm thinking that the pullrequest tag should be removed and replaced with a needsrepatch tag. |
| 14:07 |
pinesol_green |
Launchpad bug 1189989 in Evergreen "Suspend Holds at time of placement" [Wishlist,Confirmed] https://launchpad.net/bugs/1189989 |
| 14:13 |
csharp |
kmlussier: wow - blast from the past! |
| 14:14 |
* csharp |
adds pullrequest tag |
| 14:14 |
* csharp |
high-fives his 38-year-old self |
| 14:18 |
|
_bott_ joined #evergreen |
| 14:18 |
|
ssieb joined #evergreen |
| 14:19 |
_bott_ |
Mentioned SuperCat to a new employee. He looked at me strange, then sent me this: http://pbs.twimg.com/media/BnXQFdZCMAAmw1H.jpg |
| 14:20 |
csharp |
_bott_++ |
| 14:22 |
kmlussier |
_bott_: Thank you! That made my day. |
| 14:22 |
kmlussier |
_bott_++ |
| 14:22 |
Dyrcona |
_bott_++ |
| 14:22 |
_bott_ |
I guess from the outside, that could conjure up something totally different |
| 14:26 |
gmcharlt |
_bott_++ |
| 14:37 |
graced |
_bott_++ |
| 14:41 |
Dyrcona |
Well, that was totally what I expected. :) |
| 14:42 |
Dyrcona |
So, I'm working on LP 1548993, and I wonder what people think about the status of the Show More/Fewer Details button surviving a change to advanced search or starting a new search? |
| 14:42 |
pinesol_green |
Launchpad bug 1548993 in Evergreen 2.9 "TPAC Show More/Fewer Details Button does not work with show_more_details.default set to true" [Undecided,Confirmed] https://launchpad.net/bugs/1548993 |
| 14:43 |
Dyrcona |
Right now, if switch to advanced search, choose refine my original search (which basically switches to advanced search), or click Another Search, the setting is essentially lost. |
| 14:44 |
Dyrcona |
It gets passed to advanced search, but is ignored. |
| 14:44 |
Dyrcona |
It gets cleared when Another Search is chosen, and I assume that is deliberate. |
| 14:45 |
Dyrcona |
I'm leaning toward having the user's choice remember across searches. |
| 14:45 |
jihpringle |
I think patrons would expect it to continue |
| 14:45 |
Dyrcona |
That's part of my reasoning. |
| 14:45 |
jihpringle |
especially since all the checkboxes persist until you uncheck them (limit to available, etc.) |
| 14:46 |
* kmlussier |
agrees with jihpringle and Dyrcona |
| 14:47 |
Dyrcona |
We were talking about it here, earlier and the consensus seemed to be to make it for the refine my original search, but it's actually easier and more consistent to fix it for all three. |
| 14:47 |
kmlussier |
Dyrcona: I'm okay with fixing it for all three. |
| 14:47 |
jihpringle |
I always vote for consistency :) |
| 14:48 |
Dyrcona |
I'll make it a separate commit in my branch so its easier to undo if someone strenuously objects later. |
| 14:48 |
kmlussier |
I can understand why "Another Search" clears out some search filters. Because it's saying that the search is starting from scratch. But I think the way the search results display is different. |
| 14:48 |
Dyrcona |
Thanks for the input. |
| 14:48 |
jihpringle |
np |
| 14:48 |
Dyrcona |
Yeah, I agree. If anyone disagrees, please speak up. |
| 14:48 |
jihpringle |
I agree with kmlussier |
| 14:49 |
kmlussier |
We are all very agreeable today. |
| 14:50 |
miker |
Dyrcona: I agree ... the user isn't changing the search with that, just the display options. so I think it should stick on Another Search |
| 14:55 |
terran |
Me too |
| 15:00 |
|
mrpeters left #evergreen |
| 15:08 |
|
bmills joined #evergreen |
| 15:17 |
|
abowling joined #evergreen |
| 15:31 |
|
mmorgan1 joined #evergreen |
| 15:37 |
|
bmills joined #evergreen |
| 15:39 |
|
abowling joined #evergreen |
| 15:56 |
|
abowling joined #evergreen |
| 15:57 |
|
mmorgan joined #evergreen |
| 16:01 |
|
bmills1 joined #evergreen |
| 16:04 |
|
rlefaive joined #evergreen |
| 16:12 |
ssieb |
I just installed an evergreen server version 2.10.3 and the client interface seems to be working fine. |
| 16:12 |
ssieb |
However, the staff client isn't working. |
| 16:12 |
ssieb |
When I try to login, it throws a javascript error: TypeError: g.my_libs_tree is null |
| 16:13 |
ssieb |
In the server logs I see: File does not exist: /openils/var/web/opac/common/js/en-US/OrgTree.js |
| 16:13 |
ssieb |
(and a few other files that don't exist) |
| 16:15 |
ssieb |
The staff client is 2.10.3 as well |
| 16:16 |
jeff |
ssieb: sounds like you have not yet run autogen.sh on the server. |
| 16:16 |
Dyrcona |
ssieb: You need to run a script on the server called autogen.sh |
| 16:16 |
Dyrcona |
:) |
| 16:16 |
JBoyer |
I just deleted my much too slowly typed response along the same lines. :) |
| 16:17 |
berick |
@band add Autogen Dogpile |
| 16:17 |
pinesol_green |
berick: Zoia knows how to make fusilli. |
| 16:18 |
Dyrcona |
pinesol_green: What happened to dogpile? |
| 16:18 |
pinesol_green |
Dyrcona: well, that's what you get for not being a shell script |
| 16:18 |
pinesol_green |
Dyrcona: I am only a bot, please don't think I'm intelligent :) |
| 16:18 |
|
bmills joined #evergreen |
| 16:19 |
ssieb |
jeff, Dyrcona: I did run that, but I'll try again |
| 16:20 |
ssieb |
hmm, looks like different output this time |
| 16:20 |
jeff |
ssieb: also, you'll want to make sure that your opensrf services started successfully before you run that command. |
| 16:20 |
ssieb |
yes, I did get those all working |
| 16:20 |
jeff |
good. |
| 16:21 |
jeff |
perhaps they were not fully started the first time you ran autogen.sh. either way, try the staff client again! |
| 16:21 |
ssieb |
yes, the staff client doesn't give that error now |
| 16:22 |
Dyrcona |
ssieb: It's a good idea to restart apache if you run autogen.sh while apache is also running. |
| 16:22 |
ssieb |
ok |
| 16:24 |
|
miker joined #evergreen |
| 16:24 |
|
akilsdonk joined #evergreen |
| 16:24 |
|
phasefx_ joined #evergreen |
| 16:26 |
* jeff |
prepares to run live tests |
| 16:26 |
|
jyorio joined #evergreen |
| 16:27 |
Stompro |
jeff - catching up, we are planning on moving to 2.10 by the end of june. |
| 16:27 |
jeff |
Stompro: great! |
| 16:27 |
jeff |
Stompro++ dbs++ |
| 16:28 |
|
_bott_ left #evergreen |
| 16:28 |
ssieb |
Is there a staff interface on the website or is it only the staff client? |
| 16:29 |
Dyrcona |
Looks like we'll be applying some patches to our 2.9 installation this weekend and changing an Apache configuration variable. |
| 16:29 |
Dyrcona |
ssieb: There is a web staff interface at https://hos.domain.tld/eg/staff/ |
| 16:30 |
Dyrcona |
substiute your fully qualified domain name for hos.domain.tld [pardon the typo] |
| 16:30 |
ssieb |
Dyrcona: thank you. What are your plans for the client because Mozilla is deprecating xulrunner? |
| 16:30 |
kmlussier |
ssieb: But the web staff interface isn't complete yet. |
| 16:30 |
Dyrcona |
ssieb: The plan is to replace it with the web client. |
| 16:30 |
jeff |
there are additional steps required to ensure that the web based staff client is installed and present -- those are outlined in the README, if you happened to skip them. |
| 16:30 |
ssieb |
ok, I'm just trying to find where to modify the organization structure |
| 16:30 |
jeff |
there's also a public instance here: https://webby.evergreencatalog.com/eg/staff/home -- username admin, password demo123 |
| 16:31 |
jeff |
and yes, for the time being you'll find that some interfaces only exist in the older client. |
| 16:31 |
ssieb |
I did see those instructions, it required nodejs setup if I remember correctly |
| 16:31 |
jeff |
ssieb: *nod* |
| 16:31 |
Dyrcona |
ssieb: Admin > Server Administration > Organizational Units |
| 16:32 |
jeff |
another recommendation, just based on common problems that i see people encounter: don't adjust the org unit types right out of the box. play around a bit first. :-) |
| 16:32 |
Dyrcona |
In the xulrunner staff client. |
| 16:32 |
ssieb |
ok, got it |
| 16:32 |
jeff |
org unit changes are one of those things that require an autogen.sh run after you've made the changes. |
| 16:33 |
ssieb |
ok, I'm just experimenting with the sample data before I reset it and put real data in |
| 16:33 |
jeff |
good luck, and enjoy! |
| 16:37 |
* jeff |
runs live tests |
| 16:38 |
Dyrcona |
jeff: Did you add any new tests, or you are just sanity checking? |
| 16:39 |
Stompro |
Is there any way to hide age protected items in the catalog, sort of like how 856 resources can be hidden? So users with a preferred lib/home lib that cannot request those items cannot see them? |
| 16:40 |
Dyrcona |
Stompro: I don't think so. |
| 16:42 |
ssieb |
I'm trying to set this up for a single school. The one important thing they need to do is print a list of all the checked out items at the end of the year. However, I don't see any way of getting that information from the staff client. |
| 16:43 |
kmlussier |
ssieb: You can generate a report. |
| 16:43 |
ssieb |
The software seems almost too big to use for a small library like this... But I had a hard time finding any other open source library management software. |
| 16:43 |
jeff |
ssieb: that's something you'd do by creating a custom report, either in the staff client reporter, or using an SQL reporting tool (which some libraries prefer, but obviously involves additional setup). |
| 16:44 |
jeff |
ssieb: did you come across Koha in your searching? https://koha-community.org/ |
| 16:44 |
kmlussier |
ssieb: Evergreen is big, but there are other single libraries that use it. There is also Koha, which is another open-source library system. |
| 16:44 |
kmlussier |
But jeff typed faster than me |
| 16:45 |
ssieb |
That was the other one I found, but this one used postgresql and Koha didn't seem obviously better in any way. :-) |
| 16:45 |
jeff |
Dyrcona: I am adding new tests supporting the fixes that I'm working on for a SIP-related issue with csp ignore_proximity |
| 16:46 |
jeff |
Dyrcona: Since it's something mostly unrelated to standing penalty ignore_proximity that broke, but that thing was not covered by tests and therefore was overlooked, I think I might just write a set of basic SIP tests. |
| 16:46 |
Stompro |
ssieb, how about a hosted service like librarything tinycat... I have no idea what it costs though. http://www.librarything.com/wiki/index.php/Using_LibraryThing_as_an_Integrated_Library_System |
| 16:46 |
ssieb |
jeff: what's the "staff client reporter"? Do you have any suggestions for a reporting tool? |
| 16:47 |
Dyrcona |
jeff: Did I break something in SIP with that feature? |
| 16:47 |
jeff |
Dyrcona: ...maybe... :-) |
| 16:47 |
Dyrcona |
:) |
| 16:47 |
ssieb |
Stompro: they are currently using an old version of Alexandria and it's either $500 to get the latest version or $500/year for hosted |
| 16:49 |
Stompro |
ssieb, interesting, thanks for the info. |
| 16:51 |
jihpringle |
ssieb: here are the docs on the reporter in the staff client - http://docs.evergreen-ils.org/2.10/_reports.html |
| 16:51 |
* Dyrcona |
tries to figure out why his phone's internal storage is full. |
| 16:52 |
* Dyrcona |
uninstalls two copies of Boopsie for Libraries. |
| 16:54 |
Dyrcona |
Well, well, AccuWeather has 41MB in the cache. That's almost as big as the app itself. |
| 16:57 |
jeff |
Dyrcona: you can clear all cached data from Settings -> Storage & USB -> Internal storage -> Cached data |
| 16:57 |
jeff |
(on Marshmallow, at least -- it's slightly different on other versions) |
| 16:57 |
jeff |
handy, vs going through each app and clearing caches. |
| 16:57 |
ssieb |
sorry, somehow I totally missed the menu entry labelled "Reports"! :-( |
| 16:59 |
Dyrcona |
"Miscellaneous files" is 6.54GB on the internal storage, and I thought I moved everything to the SD Card. :) |
| 17:01 |
terran |
Speaking of reports, I finally got around to creating a launchpad for Quick Reports... hopefully I set it up right: https://bugs.launchpad.net/egquickreports |
| 17:04 |
jeff |
terran++ |
| 17:06 |
|
rhamby joined #evergreen |
| 17:06 |
terran |
bmills++ for installing, testing, and bug-reporting :D |
| 17:07 |
Dyrcona |
Oh, well. Look at the time! |
| 17:07 |
Dyrcona |
Catch you all later. |
| 17:08 |
bmills |
terran++ |
| 17:12 |
ssieb |
oh, even better. I fixed the apache settings so that the index.xhtml file loads properly and there's a big reports icon there... :-/ |
| 17:13 |
ssieb |
except that clicking on it gives me: TypeError: xulG.url_prefix is not a function |
| 17:15 |
|
mmorgan left #evergreen |
| 17:15 |
ssieb |
never mind, reloading the client fixed it |
| 17:16 |
terran |
ssieb: you may also need the correct user permissions to create reports if you don't already have them |
| 17:16 |
terran |
ssieb: CREATE_REPORT_TEMPLATE, RUN_REPORTS, SHARE_REPORT_FOLDER, VIEW_REPORT_OUTPUT |
| 17:18 |
ssieb |
I'm using the egadmin user for now, so I would hope is has the right permissions. |
| 17:49 |
|
mceraso joined #evergreen |
| 19:52 |
|
bmills joined #evergreen |
| 22:31 |
|
bmills joined #evergreen |
| 22:32 |
|
dcook joined #evergreen |
| 23:32 |
|
bmills joined #evergreen |
