| Time |
Nick |
Message |
| 00:23 |
|
sandbergja joined #evergreen |
| 07:03 |
|
agoben joined #evergreen |
| 07:13 |
|
rjackson_isl joined #evergreen |
| 07:42 |
|
tlittle joined #evergreen |
| 08:25 |
|
tlittle joined #evergreen |
| 08:30 |
|
bos20k joined #evergreen |
| 08:33 |
|
bdljohn joined #evergreen |
| 08:35 |
|
Dyrcona joined #evergreen |
| 08:47 |
|
kmlussier joined #evergreen |
| 08:49 |
|
mmorgan joined #evergreen |
| 09:00 |
kmlussier |
Good morning #evergreen! Happy hump day! |
| 09:00 |
kmlussier |
@coffee [someone] |
| 09:00 |
* pinesol |
brews and pours a cup of Ethiopia Nekisse Espresso, and sends it sliding down the bar to gsams |
| 09:00 |
kmlussier |
@tea [someone] |
| 09:00 |
* pinesol |
brews and pours a pot of Golden Orchid, and sends it sliding down the bar to ejk (http://ratetea.com/tea/whispering-pines/golden-orchid/7244/) |
| 09:01 |
kmlussier |
@dessert [someone] |
| 09:01 |
* pinesol |
grabs some Shamrock Shakes for _bott_ |
| 09:03 |
_bott_ |
I do like the Shamrock Shake |
| 09:03 |
* kmlussier |
has never had a Shamrock Shake. :( |
| 09:04 |
Dyrcona |
Ah ha! That test that fails on 3.0.13 but succeded on master last night is broken on 3.0.13. It's looking for the wrong number. I guess I'll fix that. |
| 09:07 |
Bmagic |
Wrong number, please hang up and try again. If you feel that you have reached this recording in error...... |
| 09:13 |
Dyrcona |
tests+- |
| 09:14 |
JBoyer |
berick, kmlussier, re: copy notes post-3.1, in addition to skipping the migration script I went as far as putting the field back in the copy editor since we have so many libraries on both sides of the xul/web line. There are a large number of local commits I'm looking forward to throwing away once we upgrade next month... |
| 09:14 |
cesardv |
Bmagic: https://www.youtube.com/watch?v=NI_wyiY4vyk |
| 09:14 |
cesardv |
lol |
| 09:15 |
Bmagic |
haha! |
| 09:15 |
cesardv |
I guess youtube is working again... |
| 09:15 |
Dyrcona |
:) |
| 09:16 |
Bmagic |
cesardv: this is the one I was thinking of: https://www.youtube.com/watch?v=37aHq3WDe-w |
| 09:17 |
cesardv |
Bmagic: ah yeah, I've heard that variation before... |
| 09:17 |
Bmagic |
It's a bygone era |
| 09:29 |
JBoyer |
sooo, who has a test install of the latest 3.2? I'm getting failures to load item status with this error: vendor.bundle.js:6 TypeError: Cannot read property 'filter' of null at item.js 162 |
| 09:30 |
pinesol |
[evergreen|Dan Wells] LP#1796971 Wait for call number and copy before loading locations - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=193f06d> |
| 09:30 |
pinesol |
[evergreen|Dan Wells] LP#1796978 Realign working copy refresh with proper condition - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f64ec2e> |
| 09:30 |
JBoyer |
That line is filtering on copy alerts to only display the count of non-ack'd alerts attached to the item and it's failing for copies with and without alerts. |
| 09:35 |
JBoyer |
Ooops. never mind. local problem... |
| 09:40 |
JBoyer |
Apparently I have an older copy of fm_IDL.xml in Open-ILS/web/reports/ and it's not being overwritten by the updated version in Open-ILS/examples |
| 09:43 |
|
jvwoolf joined #evergreen |
| 09:52 |
agoben |
Flu shots on offer at the State House today if you wanted one |
| 09:54 |
agoben |
oops, sorry! |
| 09:58 |
Dyrcona |
Good to know. :) |
| 09:59 |
Bmagic |
What does it mean when OpenSRF::Transport /usr/local/share/perl/5.22.1/OpenSRF/Transport.pm:83 Session Error: router private.localhost/open-ils.serial IS NOT CONNECTED TO THE NETWORK!!! ? Ejabberd is messed up? Which config should I tweak do you think? |
| 10:00 |
Dyrcona |
Bmagic: First check that the router is running. Then check that opensrf_core.xml has the right hostname for the router, etc. |
| 10:01 |
Dyrcona |
And, I recently got this when there different ips configured for the hostname that the router was using in /etc/hosts. |
| 10:01 |
Bmagic |
if those were wrong, nothing would work. The brick runs fine for hours then suddenly that error |
| 10:02 |
Dyrcona |
See my previous comment. I had services start, but clients refuse to communicate with the /etc/hosts problem. |
| 10:02 |
Bmagic |
hmm, alright, double checking |
| 10:02 |
Dyrcona |
cesardv++ |
| 10:03 |
Dyrcona |
cesardv: One thing, when we push to master and rel_* branches we set the status to Fix Committed. We don't do Fix Releases until the tarball is rolled up and on the downloads site. |
| 10:05 |
kmlussier |
Dyrcona++ |
| 10:06 |
* csharp |
flies to Indy for free flu shots |
| 10:06 |
Dyrcona |
:) |
| 10:07 |
csharp |
I'll miss being back at good ol' Fort Harrison for the hackaway this year |
| 10:07 |
csharp |
glad it's close, but I get meals/lodging paid when we travel :-) |
| 10:08 |
Dyrcona |
Yeah, For Harrison is a nice venue. |
| 10:08 |
Dyrcona |
Fort Harrison, that is. |
| 10:08 |
csharp |
several Georgia state parks that would be a good venue, but none are super-close to Metro Atlanta |
| 10:09 |
Bmagic |
Dyrcona: /etc/hosts contains the standard 127.0.1.2 public.localhost public \n 127.0.1.3 private.localhost private. ; opensrf_core.xml only diffs from the example for the password lines |
| 10:10 |
Bmagic |
my working theory is the max_children numbers are too high in some of the service definitions for opensrf.xml. Would an insane number in there cause ejabberd to stop allowing connections? |
| 10:11 |
csharp |
Bmagic: check 'osrf_control --diagnostic' when it happens |
| 10:11 |
Dyrcona |
Bmagic: OK. When I had the problem, it was using $hostname.private and $hostname.public and I had 127. and other 192.168.1. entries for each. |
| 10:11 |
csharp |
also tailing the osrfwarn.log (assuming your logs are set up like ours are) |
| 10:11 |
Bmagic |
csharp: good question. I'll have to check next time |
| 10:12 |
csharp |
I usually have osrferror.log open in one console tab/window and osrfwarn.log in another |
| 10:13 |
Bmagic |
I believe those are thrown into the same log osrfsys.log ? |
| 10:13 |
csharp |
yeah |
| 10:13 |
Dyrcona |
Yeah, unless you do some fancy syslog configuration. |
| 10:13 |
Bmagic |
I suppose a grep would achieve the same thing in two windows? |
| 10:14 |
csharp |
yeah |
| 10:14 |
csharp |
how our logs are: https://docs.google.com/document/d/1BJ7kSr5LfPkxXRhcrYjNyPlbT9PlNFHg6zL-tyetnKA/edit |
| 10:17 |
Bmagic |
lots of warns right now but for all I know "open-ils.circ.title_hold.is_possible: Use of uninitialized value $depth in numeric eq (==) at /usr/local/share/perl/5.22.1/OpenILS/Application/Circ/Holds.pm line 2567" is "normal" |
| 10:25 |
|
beanjammin joined #evergreen |
| 10:35 |
|
bos20k_ joined #evergreen |
| 10:50 |
Dyrcona |
Bmagic: It may be normal, but it's noise that should be silenced. |
| 10:50 |
|
sandbergja joined #evergreen |
| 10:54 |
|
Christineb joined #evergreen |
| 10:58 |
|
jihpringle joined #evergreen |
| 11:09 |
* Dyrcona |
just updated https://wiki.evergreen-ils.org/doku.php?id=hack-a-way:hack-a-way-2018-agenda#discussion_topics for those going to the hack-away. |
| 11:11 |
|
bdljohn joined #evergreen |
| 11:13 |
|
yboston joined #evergreen |
| 11:34 |
bshum |
Dyrcona++ # good topics, I'm down for that stuff :) |
| 11:40 |
|
khuckins_ joined #evergreen |
| 12:20 |
|
sandbergja joined #evergreen |
| 12:24 |
|
khuckins joined #evergreen |
| 12:24 |
|
csharp joined #evergreen |
| 12:24 |
|
Bmagic joined #evergreen |
| 12:24 |
|
foobarrel joined #evergreen |
| 12:24 |
|
dluch joined #evergreen |
| 12:29 |
|
nfburton joined #evergreen |
| 12:39 |
|
beanjammin joined #evergreen |
| 13:00 |
|
yboston joined #evergreen |
| 13:18 |
nfburton |
I notice i can batch edit and add alerts/tags to copies but can't batch delete them through webby's buckets. Can I do it programatically? So far the only way I have done it is to remove them off each copy individually |
| 13:20 |
Dyrcona |
nfburton: Can copy alerts be removed in a batch from the XUL copy buckets? |
| 13:21 |
nfburton |
IDK we never used XUL. I just wanted to clarify that we are using webby |
| 13:22 |
Dyrcona |
Well, if you think you should be able to do that, make a bug on Lauchpad. Someone else can decide if it's a bug or a feature request. |
| 13:23 |
nfburton |
For sure, I didn't see a request on there and thought I may have a workaround til then. |
| 13:23 |
csharp |
Bmagic: seeing the same here |
| 13:25 |
csharp |
one of these days I'll feel able to commit (ha) to the job of release manager, but it is not this day |
| 13:28 |
bshum |
"Some are born great, some achieve greatness, and some have greatness thrust upon them." |
| 13:28 |
csharp |
ha! |
| 13:30 |
* Dyrcona |
is considering it. |
| 13:40 |
csharp |
Dyrcona++ |
| 13:41 |
jeffdavis |
I have added a 3.1 target for bug 1712854. It's already marked as Fix Released for 3.2 but needs to be backported. |
| 13:41 |
pinesol |
Launchpad bug 1712854 in Evergreen 3.1 "web client: Sorting for view record holds and holds shelf interfaces" [High,Confirmed] https://launchpad.net/bugs/1712854 |
| 13:41 |
kmlussier |
I still would love to see two people throwing their hats in the ring so that we could have a real vote on RM. |
| 13:42 |
kmlussier |
jeffdavis: My thinking on that bug when the code was first submitted was that the changes were extensive enough to qualify it as a new feature. |
| 13:43 |
kmlussier |
I was also concerned it would have the potential to introduce new bugs. |
| 14:02 |
jeffdavis |
kmlussier: I think Sitka's view is that the lack of sorting is a regression compared to the XUL client and that the hold shelf UI is pretty unusable without it. |
| 14:03 |
jeffdavis |
So I think we'd be inclined to fudge the bugfix/new feature distinction in the direction of calling it a bugfix. :) |
| 14:03 |
Dyrcona |
jeffdavis: Are you using it in production, yet? :) |
| 14:04 |
jeffdavis |
Not yet. We're already juggling a ton of backports, it's easier to justify ones that will eventually be in 3.1. |
| 14:05 |
|
bos20k joined #evergreen |
| 14:08 |
|
jvwoolf joined #evergreen |
| 14:08 |
kmlussier |
jeffdavis: I agree 100% that the inability to sort in those interfaces is a big problem. I wouldn't argue against it, but was just explaining reasons for not initially pushing for a backport. |
| 14:09 |
kmlussier |
There are a couple of known bugs that were caused by the code, and their targets would need to be updated as well if the code were backported. bug 1795906 is one. |
| 14:09 |
pinesol |
Launchpad bug 1795906 in Evergreen "Bring parity to the estimated queue position in OPAC and Record -> View Holds UIs" [Medium,New] https://launchpad.net/bugs/1795906 |
| 14:51 |
|
abowling joined #evergreen |
| 14:53 |
Dyrcona |
jeffdavis: Just run master. It isn't as scary as it sounds. :) |
| 14:53 |
jeffdavis |
heh |
| 14:56 |
|
khuckins_ joined #evergreen |
| 15:01 |
jeffdavis |
Dyrcona: the amount of testing we do before an upgrade means we usually only do one big upgrade per year - usually shortly after a major version release, at which point there's not much difference from master. Then we backport fixes as required. |
| 15:02 |
Dyrcona |
jeffdavis: Perfect candidate for running master in that case. |
| 15:02 |
jeffdavis |
This year with the switch to the web client we have more backports than usual. We did a minor upgrade from 3.1.0 to 3.1.4 and will probably do another minor release upgrade next month. |
| 15:02 |
Dyrcona |
We just upgraded from 3.0.8 to 3.0.12 and I installed the patches for 3.0.13 last night. |
| 15:06 |
jeffdavis |
There's a case to be made for us to upgrade to 3.2.1 instead of 3.1.7 in this case, but historically we've emphasized stability over up-to-date-ness. |
| 15:11 |
bshum |
Eh.... with the way the web client has been developed, I think being "up-to-date" is more important than any perceived concept of "stable" |
| 15:11 |
bshum |
But that's just my opinion. |
| 15:12 |
Dyrcona |
At least until it settles down. |
| 15:17 |
kmlussier |
I don't know. This particular bug is an exception to most of the bug fixes. I think we've been fairly open about backporting most. And there generally is more stability when you aren't adding new features into the mix. |
| 15:18 |
Dyrcona |
One person's feature is another person's bug....:) |
| 15:26 |
rhamby |
Dyronca: does that mean everything is both a feature and a bug? |
| 15:27 |
jeffdavis |
ha |
| 15:28 |
Dyrcona |
rhamby: Indeed. |
| 15:53 |
|
yboston joined #evergreen |
| 16:02 |
JBoyer |
Heisenberg's usability principle. |
| 16:05 |
|
khuckins joined #evergreen |
| 16:19 |
Bmagic |
What sort of values do you have for open-ils.storage? It sure seems that 10 is too low. Got some "no children available" - But for cstore we have 85 |
| 16:19 |
Dyrcona |
Shcrodinger's feature? |
| 16:20 |
Dyrcona |
Schrodinger's storage... Just a 'sec Bmagic. I'll share ours. |
| 16:21 |
Dyrcona |
Bmagic: 60 |
| 16:21 |
Bmagic |
web client seems to use these things much more than xul did |
| 16:22 |
Bmagic |
60 it is then! What do you hvae for cstore? |
| 16:22 |
Dyrcona |
It does. I made a list somewhere, but may not have kept it, of the changes that I noticed between xul and web client. |
| 16:23 |
Dyrcona |
I have 70 for cstore. |
| 16:23 |
Bmagic |
I win with 85 |
| 16:23 |
Dyrcona |
Note that we run 5 bricks with two drone servers for each, so those can go to double if necessary. |
| 16:23 |
berick |
@who has the most cstores |
| 16:23 |
pinesol |
Christineb has the most cstores. |
| 16:23 |
Bmagic |
how about url_verify |
| 16:24 |
Dyrcona |
I.E. the number is for each drone server, and I may have different numbers on the utility server. |
| 16:24 |
Dyrcona |
url_verify is 15. |
| 16:24 |
Bmagic |
yeah, I'm interested in the brick servers. Public facing |
| 16:25 |
Dyrcona |
Bmagic: Then you should double our numbers, but I don't think we usually get close to them. |
| 16:26 |
Bmagic |
Thanks, that is helpful. I am operating on the theory that the ejabberd service received too many requests due to these settings. (we have 6 bricks fluxuating up to 9 bricks to meet demand as average CPU increases) |
| 16:28 |
Bmagic |
Can I just ask about the other settings? I wonder if there is a grep command that would output them nice... |
| 16:28 |
Bmagic |
ejabberd is self contained per brick to be clear |
| 16:29 |
Dyrcona |
I've considered allowing my bricks to talk to each other and share drones. |
| 16:29 |
berick |
osrf_control -l --diagnostic # lists drone active/totals |
| 16:29 |
berick |
easy to share that way |
| 16:30 |
Dyrcona |
berick++ |
| 16:30 |
Dyrcona |
I was about to say that I don't think you'll get a usable output from grep, but awk or sed could do it. |
| 16:32 |
pastebot |
"Bmagic" at 64.57.241.14 pasted "open-ils settings" (29 lines) at http://paste.evergreen-ils.org/14230 |
| 16:32 |
Bmagic |
berick++ |
| 16:36 |
Dyrcona |
The web staff client also uses open-ils.pcrud a lot more than XUL does. |
| 16:36 |
Dyrcona |
I have to go, so I'll have a look at your paste later. |
| 16:39 |
|
dluch joined #evergreen |
| 16:44 |
pastebot |
"jeffdavis" at 64.57.241.14 pasted "Sitka drone counts" (29 lines) at http://paste.evergreen-ils.org/14231 |
| 16:45 |
jeffdavis |
^ on each of 3 app servers |
| 16:45 |
jeffdavis |
we definitely come up to the limit on some of those esp pcrud, also had to increase postgres max_connections to accommodate |
| 16:59 |
|
khuckins_ joined #evergreen |
| 17:04 |
|
jvwoolf left #evergreen |
| 17:16 |
|
mmorgan left #evergreen |
| 17:55 |
|
abowling left #evergreen |
| 19:35 |
|
yboston joined #evergreen |
| 19:43 |
|
yboston joined #evergreen |
| 21:29 |
|
Christineb joined #evergreen |
