| 00:50 |
|
atlas___ joined #evergreen |
| 00:53 |
|
AliceR joined #evergreen |
| 00:55 |
|
atlas__ joined #evergreen |
| 05:33 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:23 |
|
b_bonner joined #evergreen |
| 07:23 |
|
mnsri_ joined #evergreen |
| 07:24 |
|
mtcarlson_away joined #evergreen |
| 11:25 |
kmlussier |
eeevil: Thanks for the background on the setting. It's helpful. |
| 11:25 |
eeevil |
good! :) (and I agree on the description change) |
| 11:26 |
|
vlewis joined #evergreen |
| 11:28 |
tsbere |
Looking at the reshelving complete code, I think the "fix" for allowing it to run mid-day and not screw things up may actually be a single line of code. <_< Not sure how to *test* it though. |
| 11:29 |
hopkinsju |
tsbere: Can you put your idea into a paste? We may be able to help test it. |
| 11:31 |
tsbere |
hopkinsju: I was thinking just drop it into a working branch you could cherry-pick from. |
| 11:31 |
tsbere |
(and attaching said branch to the launchpad bug) |
| 11:32 |
Bmagic |
tsbere: sounds good to me |
| 11:48 |
eeevil |
Able. Autocorrect... |
| 11:50 |
* tsbere |
watched locks with and without the status = 7 checks and didn't see any noticable difference in them, but didn't exactly do an overly complete job of watching either and wasn't on a production-level system data-wise |
| 11:51 |
dbwells |
bshum: I would typically branch rel_2_x_x from rel_2_x, do the release stuff, then forward-port the upgrade file back to rel_2_x and master (eventually). Then all the scripts are already in rel_2_x for the next point release. Does that answer your question? |
| 11:53 |
eeevil |
My bigger point is that the current reshelver has an intended purpose, and IMO we should consider that when looking for a solution that is outside that original intent. I'm 100% for code reuse, but I think this might be stretching it, in this specific case... But, testing will tell |
| 11:55 |
tsbere |
eeevil: I am all for "new code for the new intent" or even "more efficient/targeted code for this intent" (only doing short-term reshelving when open, for example) - I am also all for calling it a bug that the reshelving complete code can, regardless of when or how often it is run, change the status of something *not* in reshelving at update time. |
| 12:04 |
|
sal_ joined #evergreen |
| 12:05 |
eeevil |
fair enough. in practice, of course, it /only/ happens during open hours, but yes, it's a fair point |
| 13:07 |
gmcharlt |
RoganH: I recalled that we discussed this the other day... do you want to put it through its paces a bit before we make an announcement? |
| 13:08 |
RoganH |
Yeah, let me play with it for a couple of days. |
| 13:08 |
gmcharlt |
kmlussier: very creatively... http://evergreen-ils.org/jobs/ |
| 13:08 |
RoganH |
I'll do some test posts, deletions, etc... |
| 13:08 |
gmcharlt |
RoganH: it also exposes a jobs dashboard |
| 13:08 |
gmcharlt |
http://evergreen-ils.org/job-dashboard/ |
| 13:08 |
kmlussier |
When you've run it through its paces, I would like to share the link with OPW. As OPW sponsors, I think we get a benefit of having our jobs page listed on their site. |
| 13:11 |
RoganH |
shiny ball received |
| 13:11 |
gmcharlt |
RoganH++ |
| 13:12 |
kmlussier |
RoganH++ |
| 13:12 |
gmcharlt |
so, noting a couple action items for myself |
| 13:12 |
gmcharlt |
#action (carry-over) gmcharlt will coordinate/assist with dbs to move the planet |
| 13:12 |
gmcharlt |
#action gmcharlt with work with DIG to get a test VM for doc-building set up |
| 13:13 |
kmlussier |
gmcharlt++ |
| 13:13 |
RoganH |
gmcharlt++ |
| 13:13 |
gmcharlt |
next up, the FAQs... |
| 16:47 |
* berick |
recalls a recent conversation about that |
| 16:47 |
kmlussier |
Yup. http://markmail.org/message/jsrbhxlwr2dshglv |
| 16:49 |
|
nhilton_ joined #evergreen |
| 16:57 |
pinesol_green |
[evergreen|Bill Erickson] LP#1261486 Action/trigger aggregator script repairs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a7c3267> |
| 17:03 |
|
kmlussier left #evergreen |
| 17:04 |
|
kmlussier joined #evergreen |
| 17:16 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:45 |
gmcharlt |
dokuwiki updated to current stable version |
| 19:10 |
|
maggieWCL joined #evergreen |
| 19:13 |
|
kmlussier joined #evergreen |
| 01:46 |
|
jcamins joined #evergreen |
| 03:29 |
|
AliceR joined #evergreen |
| 03:49 |
|
AliceR joined #evergreen |
| 05:19 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:40 |
|
mtate joined #evergreen |
| 06:40 |
|
eeevil joined #evergreen |
| 07:10 |
|
Callender joined #evergreen |
| 09:05 |
aashita |
Hi Berick! |
| 09:05 |
aashita |
i Just want to know only Julia Lima has done editing of UI style guide |
| 09:24 |
|
RoganH joined #evergreen |
| 09:36 |
mrpeters |
trying to load the concerto, etc. data in 2.7 -- error that "env_create.sql" is missing. Is this a part of the test dataset that maybe got left out, or a missing dependency |
| 09:39 |
tsbere |
mrpeters: I see env_create.sql in what I believe to be the correct location |
| 09:40 |
mrpeters |
is that not /home/opensrf/Evergreen-ILS-2.7.0/Open-ILS/tests/datasets/sql ? |
| 09:40 |
* tsbere |
is also looking at master |
| 09:41 |
Dyrcona |
mrpeters: Is this from git or a tarball? |
| 09:41 |
mrpeters |
tarball |
| 09:43 |
Dyrcona |
"Someone" being bshum. ;) |
| 09:44 |
Dyrcona |
I checked rel_2_7 and tags/rel_2_7_0, and the file is in both branches where it should be. |
| 09:44 |
Dyrcona |
Just for the record. |
| 09:45 |
mrpeters |
/home/opensrf/Evergreen-ILS-2.7.0/Open-ILS/tests/datasets/sql is correct location, no? |
| 09:45 |
Dyrcona |
Yes, it is. |
| 09:45 |
Dyrcona |
jason jason:~/Src/Evergreen$ find ./ -name env_create.sql |
| 09:45 |
Dyrcona |
./Open-ILS/tests/datasets/sql/env_create.sql |
| 10:16 |
|
yboston joined #evergreen |
| 10:24 |
kmlussier |
dbs: I must have missed your comment in IRC regarding adding berick's script-based install to the README, but if you point me in the right direction, I can, at a minimum, add it to the OPW wiki page. |
| 10:25 |
kmlussier |
I'll even try to add it to the README if I get a minute to breathe. :) |
| 10:29 |
|
buzzy joined #evergreen |
| 10:31 |
mrpeters |
hmm, so the env_create is in the tarball, it's just looking for it in the cd, so you have to be in the tests/datasets/sql/ directory |
| 10:31 |
mrpeters |
my fault for the false alarm |
| 10:33 |
tsbere |
mrpeters: Are you loading the files manually, instead of with eg_db_config? |
| 10:33 |
mrpeters |
the test data? i just do psql evergreen < load_all.sql |
| 10:33 |
tsbere |
mrpeters: If you use the flags for eg_db_config it does the cd and such for you. |
| 10:33 |
mrpeters |
i just was supplying the full path to load_all.sql, not realizing i had to be in that directory |
| 10:34 |
mrpeters |
ah, interesting. didn't know you could use eg_db_config to load all of that test data |
| 10:36 |
tsbere |
mrpeters: --load-all-sample or --load-concerto-sample, I think. |
| 10:36 |
mrpeters |
awesome, good to know |
| 10:52 |
|
krvmga joined #evergreen |
| 11:18 |
mrpeters |
ok, carry on |
| 11:18 |
mrpeters |
just wanted to dispell your incorrect impression |
| 11:18 |
tsbere |
besides, if you screw up the install steps you may not realize you did so if the package has things in the right place and your install has them in the wrong one, then bash your head as to why your changes aren't working. |
| 11:18 |
mrpeters |
the packaged evergreen is a VERY good way for someone to quickly get a test system up and running as long as they understand basic IP addressing and know how to install linux packages |
| 11:20 |
mrpeters |
thats fine, if you dont see it fit for a developer don't use it, no big deal, just sharing the information that this is available to anyone, and the myth that it is "just for PINES" is completely false |
| 11:20 |
tsbere |
mrpeters: My assumption was "PINES has public non-customized and private customized package sets" - I never assumed the ones I could get at were customized for PINES. |
| 11:21 |
gmcharlt |
well, rather depends on what the ultimate purpose is - if you want a running EG instance to test or document, sure, try the packages |
| 11:21 |
gmcharlt |
if you are aiming to do *coding* ... at the moment, I don't see any responsible way around installing from a git clone if the end result is meant to be useful to a *coder* |
| 11:24 |
mrpeters |
that is fair |
| 11:25 |
Dyrcona |
And, what about production? Do you think that would work from a packaged version?\ |
| 11:25 |
Dyrcona |
Right now, Evergreen is very "old school" in how you install it. Not saying I have a problem with that, but that is not noob friendly. |
| 11:46 |
csharp |
there are some hard-coded assumptions/choices that we have to make for packaging, but we think they're sane and easily changed |
| 11:47 |
Dyrcona |
For us, we build directly from git, and make an integration branch. |
| 11:47 |
mrpeters |
built right from the same code we use to build up PINES |
| 11:47 |
Dyrcona |
We also have two developers with development and test servers, so we're doing integration on a fairly frequent basis. |
| 11:47 |
csharp |
however, (sorry mrpeters :-) ), I have to agree with others that building from source (either by hand or by script) is the best way to participate in community development |
| 11:47 |
Dyrcona |
Conflicts occur, but are often noticed and resolved quickly, and well before we go into production. |
| 11:48 |
mrpeters |
i agree for CODE development |
| 11:48 |
Dyrcona |
We also load onto the test server several weeks before we go live in production so members can have a go at finding things that might not be quite right. |
| 11:48 |
mrpeters |
but if you just want to quickly test out evergreen, man, its a fast way to do it |
| 11:49 |
csharp |
I completely agree that using our deb repo is the easiest way to get up and running on Ubuntu on the most current stable release |
| 11:50 |
mrpeters |
i just remember the days when we supplied virtual box images for people who just wanted to "test out" evergreen |
| 11:50 |
csharp |
but... it obviously comes with the same limitations as all the other methods people have discussed (preferences, best practices, etc. can vary widely) |
| 11:50 |
mrpeters |
and it was a nightmare, they were always outdated, nobody wanted to manage them, etc. |
| 11:50 |
mrpeters |
had i known about this repo back then, man the pain we could have avoided! |
| 17:49 |
berick |
Bmagic: that's probably it |
| 17:50 |
Bmagic |
You think it's possible that the update query from the reshelver could hit on rows that have their status=1 even though the query clearly is looking for 7? |
| 17:51 |
berick |
grr, i opened a LP ticket about this a really long time ago, now i can't find it |
| 17:51 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:51 |
berick |
https://bugs.launchpad.net/evergreen/+bug/1018011 |
| 17:51 |
pinesol_green |
Launchpad bug 1018011 in Evergreen 2.4 "Incorrect copy status caused by reshelving process colliding with item checkout" (affected: 4, heat: 20) [Medium,Confirmed] |
| 17:52 |
berick |
wow, for the first time ever, LP search worked better than google |
| 01:12 |
|
mnsri joined #evergreen |
| 02:42 |
|
shresh joined #evergreen |
| 03:33 |
|
RBecker joined #evergreen |
| 06:01 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:01 |
|
artunit_ joined #evergreen |
| 07:03 |
|
Callender joined #evergreen |
| 08:00 |
|
eeevil joined #evergreen |
| 11:31 |
pinesol_green |
Launchpad bug 1379824 in Evergreen "Make PermaCrud.js disconnect() actually disconnect" (affected: 1, heat: 6) [Medium,New] https://launchpad.net/bugs/1379824 |
| 11:33 |
yboston |
dbwells: nice! |
| 11:34 |
bshum |
Calling 0894 |
| 11:37 |
yboston |
dbwells: is there anything I can help with? do you need me to test the commit and sign it off? |
| 11:38 |
pinesol_green |
[evergreen|Chris Sharp] LP#1374551: Create index on money.billing.voider to speed user merge. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=44bca3b> |
| 11:38 |
pinesol_green |
[evergreen|Ben Shum] LP#1374551: Stamping upgrade script for new index on money.billing.voider - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=896dea5> |
| 11:38 |
dbwells |
yboston: testing and signoffs are always appreciated! |
| 11:50 |
bshum |
Hmm, California. |
| 11:55 |
|
ldwhalen joined #evergreen |
| 12:02 |
|
nhilton joined #evergreen |
| 13:35 |
bshum |
bmills: I just pushed the selfcheck timeout fix to the repos. Hopefully you can make use of that fix sometime. :) |
| 13:37 |
bmills |
bshum: thanks! |
| 13:38 |
bmills |
bshum++ |
| 13:39 |
bshum |
mmorgan++ # thanks for testing! |
| 13:39 |
bshum |
jboyer-isl++ # think check on the JavaScript. |
| 13:53 |
|
RBecker joined #evergreen |
| 14:07 |
mmorgan |
bshum++ # thanks for fixing :) |
| 14:09 |
|
RBecker joined #evergreen |
| 17:22 |
Bmagic |
bmills: I'm not going to be much help as our system is not currently using authority. I hope there is someone here with more expierence with the DB authority.normalize_heading. You could bring it to the email list and get more response. |
| 17:23 |
bmills |
Bmagic: thanks! |
| 17:42 |
|
bmills1 joined #evergreen |
| 17:43 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:44 |
|
nhilton_ joined #evergreen |
| 17:54 |
bbqben |
jihpringle: bring leftovers to the office next week? |
| 17:55 |
jihpringle |
bbqben: I wish, I'm going to family friends for dinner so I won't have leftovers :( |
| 20:07 |
bshum |
My experience thus far is primarily Debian/Ubuntu. |
| 20:08 |
atlas__ |
I figured I should have started with one of those since they are listed first in the instruction order |
| 20:08 |
atlas__ |
so when I try to start all the opensrf services I just get 'authentication failed' and its because ejabberd seems to be borked |
| 20:09 |
bshum |
atlas__: Fedora is one of the targets, but nobody actively uses Fedora in production for Evergreen (as far as I know) |
| 20:10 |
bshum |
I think it's mainly there cause there's a few Fedora enthusiasts among the developers :) |
| 20:10 |
bshum |
It's entirely possible that something needs more love with Fedora 20. Just a quick glance at the instructions for OpenSRF seem to me that they were written with Fedora 17+ in mind (which might also mean that they haven't been fully tested yet with 20) |
| 20:10 |
atlas__ |
what do people run in production |
| 20:11 |
bshum |
Yeah, the Fedora build slave at testing.evergreen-ils.org is only Fedora 18. |
| 20:11 |
bshum |
atlas__: Go for Debian or Ubuntu. |
| 20:11 |
bshum |
Presently, Debian Wheezy (7.0) or Ubuntu 12.04 server would be my best recommendations. |
| 20:12 |
bshum |
Ubuntu 14.04 support is still... being worked out. |
| 20:12 |
atlas__ |
any reason to do one over the other? i've got more experience with ubuntu, but yeah 14.04 would be a lot better |
| 20:13 |
atlas__ |
I'd rather Fedora (clearly!). But if Debian is what most use in production I could probably figure it out. |
| 20:13 |
bshum |
atlas__: I consider it to be a personal preference. I use Ubuntu 12.04 for our systems. |
| 22:31 |
bshum |
https://bugs.launchpad.net/opensrf/+bug/714694 like dollar signs, etc. |
| 22:31 |
pinesol_green |
Launchpad bug 714694 in OpenSRF "Passwords cannot contain certain special characters" (affected: 1, heat: 6) [Medium,Won't fix] |
| 22:31 |
atlas__ |
ba dum tish |
| 22:31 |
bshum |
You'll want to try something a little simpler for testing :) |
| 22:32 |
atlas__ |
can I just re-run these register commands to get new ejabbderctl passwords |
| 22:33 |
bshum |
I was just looking up how to change the passwords |
| 22:33 |
atlas__ |
thank you thank you |
| 22:33 |
bshum |
ejabberdctl man page, whee |
| 22:34 |
bshum |
So maybe something like |
| 22:34 |
bshum |
sudo ejabberdctl change-password opensrf private.localhost password |
| 22:34 |
bshum |
Repeat for all four users |
| 22:34 |
bshum |
But basically "ejabberdctl change-password <user> <hostname> <password>" |
| 22:35 |
bshum |
And then make sure you change up your opensrf_core.xml passwords to match it |
| 22:35 |
bshum |
And .srfsh.xml too |
| 22:35 |
bshum |
For purposes of getting going, I'd do something alphanumeric. |
| 22:35 |
bshum |
Or if it's purely a test system... *cough, cough* "password" is probably fine :) |
| 22:37 |
bshum |
Maybe we ought to consider putting a note on that in the OpenSRF README on how people should avoid certain special characters that are known to break things. |
| 22:37 |
* bshum |
adds reminder for his future self. |
| 22:40 |
|
atlas__ joined #evergreen |
| 22:43 |
|
buzzy joined #evergreen |
| 03:11 |
|
jventuro joined #evergreen |
| 05:17 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:41 |
|
sseng_ joined #evergreen |
| 07:06 |
|
Sato joined #evergreen |
| 07:32 |
|
rjackson-isl joined #evergreen |
| 09:48 |
|
sarabee joined #evergreen |
| 09:48 |
dbs |
Oh, I know Sid. |
| 09:49 |
dbs |
I'm still decrementing ubuntu because this problem has existed for a couple of years. |
| 09:51 |
csharp |
well, to be pedantic, the LTS releases sync with debian testing, so this is likely a problem that would exist in jessie too |
| 09:52 |
csharp |
unless it doesn't pass muster with Debian testers, that is |
| 10:01 |
|
RoganH joined #evergreen |
| 10:15 |
kmlussier |
Web client testing is also a good way to remember old bugs that I forgot to file in LP. |
| 10:42 |
|
ningalls joined #evergreen |
| 10:48 |
kmlussier |
I'm looking at the self-check docs at http://docs.evergreen-ils.org/2.7/_self_checkout.html#_configuring_self_check_behavior. For "Patron Login Timeout," it says not currently supported. Is that still true? |
| 10:48 |
bshum |
kmlussier: Right |
| 10:49 |
kmlussier |
Oh, wait. I see the bug report. |
| 10:49 |
bshum |
kmlussier: So there's a bug ticket for that and I wrote new code during the hackaway |
| 10:51 |
bshum |
I haven't decided if it's a "new feature" or a "bug fix" though. |
| 10:53 |
kmlussier |
I would think bug fix since there is an existing setting that doesn't work. |
| 10:53 |
* mmorgan |
agrees that it's a bug fix |
| 10:53 |
bshum |
Oh fun then. |
| 10:54 |
bshum |
Well if anyone feels brave to try :) |
| 10:54 |
bshum |
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/bshum/lp1306814-selfcheck-timeout |
| 10:54 |
bshum |
That's where I put the initial code I was poking at |
| 10:54 |
bshum |
I have to test it with an actual library setting configured. |
| 10:57 |
bshum |
I updated the bug report with a link to the code |
| 10:57 |
bshum |
And assigned targets as a bug fix. |
| 10:57 |
csharp |
heh - so it multiplies the patron timeout value by 1000? |
| 10:57 |
bshum |
Right, cause I think the setting is assigned as seconds |
| 10:57 |
bshum |
But the value is like milliseconds |
| 11:01 |
kmlussier |
bshum: But some of that was based on your custom 001 record attribute, right? |
| 11:01 |
bshum |
kmlussier: Correct, for us, abnormally large entries in our uncontrolled values table was causing slowdown, among other things. |
| 11:01 |
* kmlussier |
is looking at search performance on a system that doesn't have custom record attributes. |
| 11:01 |
bshum |
I'm finishing testing eeevil's fixes for that. |
| 11:02 |
bshum |
Define "slow" |
| 11:02 |
bshum |
Like have you guys turned on the debug timing and grabbed numbers on how things are? |
| 11:03 |
kmlussier |
This is a system where they timed searches on 2.5 and then timed then again after uprading the same system to 2.6. We're seeing numbers where the search took 3 seconds on 2.5 and is now taking 12-14 seconds. A big difference. |
| 11:03 |
kmlussier |
bshum: No, we haven't. |
| 11:04 |
|
DPearl joined #evergreen |
| 11:38 |
dbwells |
kmlussier: We didn't experience anything like the slowdowns shown in your chart. (great chart btw!) We also have a "normal" uncontrolled_record_attr_value table size (2551 rows). |
| 11:39 |
kmlussier |
dbwells: The credit for the great chart goes to tspindler. :) |
| 11:47 |
bshum |
csharp: Vacuuming the table didn't do anything for us, the new code helped :) |
| 11:50 |
Bmagic |
Im testing 2.7, right off the bat I don't see the secondary permission group UI in the staff client. Was there something I forgot to setup? |
| 11:51 |
kmlussier |
Bmagic: It should just display in the patron editor. And you need permission to see it. |
| 11:52 |
Bmagic |
kmlussier: huh, no magic trick? I am using an account with global everything |
| 11:54 |
bshum |
Hmm, it's working for me |
| 11:55 |
|
bkuhn joined #evergreen |
| 11:55 |
Bmagic |
I preformed an upgrade on an existing directory full of 2.6.1 code |
| 11:56 |
Bmagic |
aka /openils |
| 11:56 |
bshum |
Bmagic: That I don't know, all I know is that a clean install test server I was looking at seems fine. |
| 11:59 |
|
nhilton joined #evergreen |
| 11:59 |
|
ningalls joined #evergreen |
| 12:05 |
|
jihpringle joined #evergreen |
| 12:09 |
berick |
gmcharlt: were you able to make any headway w/ your nginx for websockets test? |
| 12:10 |
berick |
one of the OPW candidates cannot access webby... wondering if it's a port issue |
| 12:10 |
Bmagic |
bshum: I got it figured out, yay! |
| 12:10 |
gmcharlt |
berick: wouldn't surprise if it were; I expect to have tuits for that tomorrow |
| 12:10 |
kmlussier |
berick: We had a similar issue with another OPW candidate. We narrowed it down to the ports issue. |
| 16:11 |
bshum |
See, this bug.... |
| 16:11 |
bshum |
https://bugs.launchpad.net/opensrf/+bug/1369169 |
| 16:11 |
pinesol_green |
Launchpad bug 1369169 in OpenSRF "Add install instructions for websockets to README (and other cleanup)" (affected: 1, heat: 6) [Undecided,New] |
| 16:11 |
berick |
Bmagic: node, bower, etc. are only used for dependency retrieval and unit tests. it's not needed for running the browser client. |
| 16:12 |
bshum |
Bmagic: http://evergreen-ils.org/~bshum/OpenSRF-README.html#_optional_websockets_installation_instructions |
| 16:12 |
bshum |
That's a generated copy of the integrated steps |
| 16:12 |
Bmagic |
!! |
| 16:38 |
|
buzzy joined #evergreen |
| 17:15 |
|
mmorgan left #evergreen |
| 17:24 |
|
buzzy joined #evergreen |
| 17:49 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:51 |
bshum |
But gmcharlt, the quest_for_knowledge is over! |
| 17:51 |
bshum |
http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=988605ececad7850f2a7276b64a697b6b5c9ae31 |
| 17:51 |
pinesol_green |
[evergreen|Dan Wells] LP#1290496: The quest for knowledge is over - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=988605e> |
| 03:09 |
|
vanya joined #evergreen |
| 03:40 |
|
vanya joined #evergreen |
| 03:42 |
vanya |
I made some changes in the code while fixing a bug. Then I ran make and make install again to see if the modified code works. However, my apache crashed due to that. Can anyone tell me where I'm going wrong? |
| 05:53 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:32 |
|
kedmundson joined #evergreen |
| 07:50 |
|
collum joined #evergreen |
| 07:52 |
|
reach joined #evergreen |
| 09:47 |
|
kmlussier joined #evergreen |
| 10:11 |
|
yboston joined #evergreen |
| 10:28 |
|
Dyrcona joined #evergreen |
| 10:34 |
vanya |
Hello everyone. After I make changes in the code, I wanted to test it out. |
| 10:35 |
vanya |
I had downloaded the staff client and the server from the link given. |
| 10:37 |
vanya |
When I make the server again , the changes are not reflected on the client. I was wondering if someone could tell me how to build the client according to my changes. |
| 10:39 |
tsbere |
vanya: You may need to re-install the client if you aren't using automatic updates |
| 10:39 |
tsbere |
(especially if it is client-side code you are changing) |
| 10:42 |
|
mdriscoll1 joined #evergreen |
| 10:59 |
tsbere |
kmlussier: Heh, I was looking for that, then got distracted |
| 11:18 |
mmorgan |
Can someone confirm that the CIRC_OVERRIDE_DUE_DATE permission CANNOT be configured to prevent editing due dates on items owned by other org units? |
| 11:27 |
tsbere |
mmorgan: As I believe it is based on the library the circ is happening at, and not the item in any way, shape, or form, I think I can confirm that. |
| 11:30 |
mmorgan |
that's what my testing has shown. I was hoping that the depth of the permission might pertain to ownership, but that does not appear to be the case. |
| 11:32 |
tsbere |
mmorgan: Note that preventing the due date from being overridden would help with "you can't make it due later" but who is going to complain about someone trying to get an item to come back *sooner*? :P |
| 11:33 |
tsbere |
(outside of the person checking the item out, anyway) |
| 12:02 |
|
akilsdonk_ joined #evergreen |
| 15:02 |
kmlussier |
And welcome! |
| 15:03 |
jeff |
Yes, welcome! |
| 15:03 |
Dyrcona |
#info Jason Stephenson, MVLC |
| 15:03 |
jeff |
#topic Action items from last meeting |
| 15:03 |
jeff |
#info kmlussier and others to make time to test the latest branch (negative balances). |
| 15:03 |
jeff |
kmlussier: anything to report? |
| 15:04 |
|
mrpeters joined #evergreen |
| 15:04 |
kmlussier |
Yes, I've done more testing and reported my most recent feedback to the bug. |
| 15:04 |
kmlussier |
I thought I saw a new branch floating around during the hack-a-way. Is that something that's ready for testing? |
| 15:04 |
jeff |
excellent. related: |
| 15:04 |
jeff |
#info dbwells to work on display ideas for negative balance branch |
| 15:05 |
|
mnsri joined #evergreen |
| 15:05 |
dbwells |
It's blossomed into a few different branches. |
| 15:05 |
jeff |
(this may answer kmlussier's question, if not -- feel free to chime in regardless of the current bullet item) |
| 15:06 |
jeff |
dbwells: testing and eyeballs being needed, as always? |
| 15:06 |
dbwells |
The extra fine bug was actually related to a separate code branch for "new overdues for returned lost" stuff |
| 15:06 |
DPearl |
#info DPearl = Dan Pearl, C/W MARS |
| 15:06 |
dbwells |
That is it's own branch, courtesy of berick and eeevil |
| 15:08 |
dbwells |
Put me down as an action item to do just that. |
| 15:08 |
jeff |
dbwells++ thanks |
| 15:08 |
berick |
dbwells++ |
| 15:08 |
kmlussier |
I'll test anything dbwells puts out there. :) |
| 15:08 |
bshum |
dbwells++ |
| 15:08 |
kmlussier |
dbwells++ |
| 15:08 |
bshum |
kmlussier++ # testing too :) |
| 15:08 |
jeff |
#action dbwells to update Conditional Negative Balances bug 1198465 with links to new branches, etc. |
| 15:08 |
pinesol_green |
Launchpad bug 1198465 in Evergreen "Support for Conditional Negative Balances" (affected: 14, heat: 62) [Wishlist,Confirmed] https://launchpad.net/bugs/1198465 |
| 15:09 |
jeff |
kmlussier++ dbwells++ berick++ Dyrcona++ and probably more :-) |
| 15:09 |
jeff |
#info jeff and csharp to test websockets work by the end of this week. |
| 15:09 |
jeff |
That happened and/or didn't happen, but what did happen was (iirc): |
| 15:09 |
jeff |
#info gmcharlt to cut alpha of OpenSRF the middle of next week (week of Aug. 4th) |
| 15:10 |
bshum |
That did occur I think |
| 15:10 |
bshum |
Or at least, there's an OpenSRF 2.4 alpha around :) |
| 15:10 |
* jeff |
nods |
| 15:15 |
bshum |
There's a few things we have to put in there I think |
| 15:15 |
bshum |
And I need to revisit the updates I made to the main README for websocket steps. |
| 15:15 |
jeff |
bshum: currently, due to websockets and other things, Evergreen 2.7 does require OpenSRF 2.4 alpha, correct? Downloads page seems to confirm... |
| 15:15 |
bshum |
Generally speaking, yes. |
| 15:15 |
bshum |
I never tested it with anything less. |
| 15:15 |
bshum |
I think that's correct though. |
| 15:16 |
bshum |
It doesn't require websockets |
| 15:16 |
jeff |
bshum: anything specific that you/gmcharlt could use help/signoff with toward the goal of OpenSRF 2.4 making it to release? |
| 15:16 |
bshum |
But I think there were other changes. |
| 15:16 |
bshum |
Bug with branch is https://bugs.launchpad.net/opensrf/+bug/1369169 |
| 15:18 |
bshum |
Now that Dyrcona mentions it, the only reason to use OpenSRF 2.4 with Evergreen 2.7 is if you wanted websockets to play with the web based staff client. I think. |
| 15:18 |
ldw |
#info ldw is Liam Whalen Sitka |
| 15:18 |
jeff |
#topic Release info - Evergreen |
| 15:18 |
bshum |
I didn't personally test OpenSRF 2.3 stable with Evergreen 2.7 though to make sure that XUL stuff and catalog is still happy. |
| 15:18 |
jeff |
Evergreen 2.7 is released! Everyone's upgraded by now, right? |
| 15:18 |
* jeff |
ducks |
| 15:18 |
bshum |
If anyone wants to volunteer to try that, maybe that's worth it. |
| 15:18 |
bshum |
But really, getting 2.4 out the door is better anyways :D |
| 15:19 |
bshum |
jeff: Actually......! |
| 15:19 |
jeff |
#info Testing of Evergreen 2.7 with OpenSRF 2.3 would be appreciated -- pass feedback to bshum |
| 15:19 |
Dyrcona |
jeff: We're on 2.7alpha give or take a few later fixes. |
| 15:19 |
bshum |
We were going to upgrade to 2.7 a few days after I cut 2.7.0, but we were delayed a bit. We plan our upgrade to 2.7 this upcoming Saturday. |
| 15:19 |
jeff |
excellent. |
| 15:21 |
jeff |
#info bshum to push things to rel_2_7 in preparation for scheduled 2.7.1 maintenance release |
| 15:21 |
bshum |
If anyone else has any bug fixes with code that they want to see in 2.7.1, please feel free to target or put a pullrequest up. |
| 15:21 |
jeff |
#info bshum pulling updated translations for tpac (and other areas) into 2.7.1 |
| 15:22 |
bshum |
And if anyone has time to test and sign-off on them, that'd be great too :) |
| 15:22 |
jeff |
bshum: anything else for Evergreen release info/updates? |
| 15:22 |
bshum |
Nothing for me. I hope to keep 2.7 series happy and stable. |
| 15:22 |
jeff |
#info targeting, testing/signoff of bugs against 2.7.1 appreciated as always |
| 15:22 |
jeff |
bshum++ |
| 15:23 |
kmlussier |
bshum++ |
| 15:23 |
Dyrcona |
bshum++ |
| 15:23 |
jeff |
#topic New Business |
| 17:13 |
|
mdriscoll1 left #evergreen |
| 17:21 |
|
nhilton_ joined #evergreen |
| 17:23 |
|
StephenGWills left #evergreen |
| 17:35 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:41 |
|
dreuther_ joined #evergreen |
| 17:47 |
|
dreuther joined #evergreen |
| 17:49 |
|
nhilton joined #evergreen |
| 05:24 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:55 |
|
eeevil joined #evergreen |
| 07:56 |
|
Callender joined #evergreen |
| 07:56 |
|
phasefx joined #evergreen |
| 15:16 |
csharp |
okay, as the postgres user, do 'psql evergreen' and do 'select * from actor.org_unit;' |
| 15:16 |
csharp |
if you see data there, you created the database correctly |
| 15:19 |
csharp |
vanya: restarting the client after running autogen is a good plan |
| 15:19 |
vanya |
I don't see any specific data- as in- there are entries like "example branch 1" etc. |
| 15:26 |
vanya |
I tried creating the database again, it told me it was being used by 6 other sessions- evergreen, pearllu, tablefunc, xml2, hstore and intarray |
| 15:27 |
vanya |
Is there any particular command I can give to update database? |
| 15:28 |
vanya |
Also, I was wondering if you could tell me what all I need to restart if I make some changes in the code and want to test them? |
| 15:36 |
|
vrani_ joined #evergreen |
| 15:38 |
|
vrani joined #evergreen |
| 15:38 |
csharp |
vanya: seeing the example branches means you did that right - no need to recreate |
| 15:52 |
vanya |
"Successfully updated the organization proximity" |
| 16:06 |
Shilpa_ |
One quick question: I noticed that all the installaztion instructions are for Linux, is it possible to run Evergreen on a mac? |
| 16:08 |
Shilpa_ |
Or can you compile it from source on a mac? |
| 17:56 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 19:54 |
vanya |
Hello, I'm working on the file menu.js |
| 19:54 |
vanya |
Could anyone tell me what the variables usr_id, opac and bib_id represent? |
| 20:01 |
vanya |
Also, |
| 04:33 |
pinesol_green |
Launchpad bug 978040 in Evergreen "No result found search for patron by database id results in return to wrong interface" (affected: 1, heat: 6) [Low,Confirmed] https://launchpad.net/bugs/978040 |
| 04:40 |
vanya |
I have been trying to run the evergreen client, but when I enter hostname as "localhost", it gives me the status "500: Internal server error", and there is a warning that says "Workstation not yet configured for the specified server" |
| 04:40 |
vanya |
Can someone tell me what I'm doing wrong? |
| 05:10 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:49 |
csharp |
vanya: you should be able to see more details about the error in /openils/var/log/osrfsys.log (assuming you haven't changed anything about OpenSRF logging) |
| 07:58 |
|
eeevil joined #evergreen |
| 07:58 |
|
mtate joined #evergreen |
| 14:43 |
kmlussier |
phasefx: Thanks! |
| 14:44 |
phasefx |
you're welcome :) |
| 14:46 |
|
vlewis joined #evergreen |
| 14:55 |
kmlussier |
Something to ponder before I go back to web client testing. This record - https://bark.cwmars.org/eg/opac/record/948727 - is not retrieved in any keyword searches, either in the public catalog or staff client. |
| 14:56 |
kmlussier |
If it were just the public catalog, I would think it was a problem with subfield 9 or OPAC visibility. |
| 14:56 |
kmlussier |
We forced a reingest on the record, and it does have an entry in the metabib keyword table. |
| 14:56 |
kmlussier |
Is there anything else we should be looking at? |
| 14:57 |
|
jboyer-laptaupe joined #evergreen |
| 15:03 |
ldw |
kmlussier: It is not something I am working on currently. Please set it back to unassigned. It is still in my mind though, so I will get back to it. I will reassign myself when I am back on that job. |
| 15:03 |
kmlussier |
ldw: Thanks! |
| 15:52 |
jeff |
hey, that came up in private conversation the other day. |
| 15:52 |
* kmlussier |
googles recursive cte. :) |
| 15:52 |
jeff |
kmlussier++ for saving me from digging up the irc log for that time |
| 15:52 |
kmlussier |
Well, I just did some timed tests. |
| 15:53 |
kmlussier |
I used a 2.7 client on webby and then tried it in a browser. |
| 15:53 |
kmlussier |
The first load is very slow, in both, but it's a bit better in a web browser. |
| 15:53 |
kmlussier |
Then, in both environments, the load time improves. But I consistently found it took 4 seconds to load a patron in the editor in the xul client. It took 6 seconds in the browser. |
| 15:54 |
* kmlussier |
used an actual timer this time, not counting on her fingers. :) |
| 16:03 |
|
Canepa joined #evergreen |
| 16:04 |
kmlussier |
Anywho, I'll just re-state the concern I has back then about moving our libraries to something that is still loading slowly or, in this case, is loading a little more slowly. |
| 16:09 |
|
artunit joined #evergreen |
| 16:10 |
kmlussier |
Since it's Friday, I'll move on to happier performance-related topics. I'm guessing we no longer need the cap for patron search results because a) the user has the ability to select the option of up to 100 results b) we have paging and c) we won't kill the server by retrieving the 100 results that can be displayed on one screen? |
| 16:15 |
|
Canepa joined #evergreen |
| 16:15 |
dbs |
6 seconds? Good lord. |
| 16:16 |
* dbs |
doesn't have much more to contribute right now :( |
| 17:18 |
kmlussier |
Webby must have been updated while it was kicked. Awesome! I'm seeing a lot of fixes. :) |
| 17:20 |
jeff |
heh |
| 17:25 |
|
mmorgan left #evergreen |
| 17:42 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:51 |
tsbere |
jeff: On action.circulation, that can be much *less* useful when you are aging circs.....and as far as I know, "circulated an item" doesn't really show up anywhere else. For good reasons. |
| 18:09 |
|
Canepa joined #evergreen |
| 18:15 |
|
Canepa_ joined #evergreen |
| 04:50 |
|
geoffsams joined #evergreen |
| 05:33 |
|
vanya joined #evergreen |
| 05:46 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 08:10 |
|
eeevil joined #evergreen |
| 08:10 |
|
mtate joined #evergreen |
| 08:11 |
|
phasefx joined #evergreen |
| 11:04 |
berick |
kmlussier: too many ain't's and ya'll's, I assume ;) |
| 11:05 |
kmlussier |
berick: Ha! Given where I'm from, it's more likely that I wasn't using my r's. |
| 11:07 |
berick |
donde esta el coche? WHERE'S THE CAAAHHH |
| 11:07 |
* kmlussier |
chuckles |
| 11:07 |
kmlussier |
It's funny how much you learn about the existing client when testing the new client. I keep finding things that are missing, just to discover they never existed. |
| 11:08 |
* kmlussier |
should submit those reports anyway just to drive graced crazy. |
| 11:08 |
berick |
heh |
| 11:09 |
|
snigdha26 joined #evergreen |
| 11:34 |
* jeff |
grins |
| 14:18 |
yboston |
the date is fine for now |
| 14:18 |
remingtron |
#link http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=28a5085fd645c9470b852c9700661dbe4cbddf18 |
| 14:18 |
pinesol_green |
[evergreen|Remington Steed] Documentation: Upgrade instructions examples - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=28a5085> |
| 14:19 |
yboston |
I have never done an upgrade so I have not been able to help with testing those instructions so far. thanks rsoulliere and remingtron for working on this |
| 14:19 |
rsoulliere |
And here it is in the docs: http://docs.evergreen-ils.org/2.6/_upgrade_the_evergreen_database_schema.html |
| 14:19 |
yboston |
anything else to add or any questions from others? |
| 14:21 |
yboston |
OK, I will move on |
| 14:28 |
yboston |
kmlussier: very true |
| 14:28 |
remingtron |
oooooo, good point |
| 14:28 |
remingtron |
well, let's discuss that on the list |
| 14:29 |
kmlussier |
I know I'll be doing some documentation while testing, but I don't know how far I'll get. |
| 14:29 |
remingtron |
jihpringle volunteered to help with preview web client docs |
| 14:29 |
yboston |
who would like to follow up on the list to get ideas for how to tackle web client docs |
| 14:29 |
yboston |
? |
| 14:43 |
remingtron |
kmlussier: +1 to that! |
| 14:43 |
|
vrani_ joined #evergreen |
| 14:43 |
kmlussier |
stompro: One thing I was thinking is we could maybe tie it closely together with the Evergreen site. I think there is a FAQ plug-in for WordPress (can't recall if we're using it). |
| 14:43 |
yboston |
I agree with kbutler , we might want to rethink the overall organization, but it might require having another docs server set up to test out new re-orgs of the content for us to see, wihtout impacting the main docs server |
| 14:43 |
stompro |
kbutler, I've wondered why there are 3 sections on tpac and several sections on Acquisitions. A reorg would be good. |
| 14:44 |
jihpringle |
+1 to a reorg |
| 14:44 |
kmlussier |
stompro: That's partially due to the Evergreen in Action docs being added without replacing the existing docs. I think if those were more explicitly called out as being "Evergreen in Action" docs, it would make more sense to the user. |
| 14:52 |
remingtron |
yboston: yes |
| 14:52 |
yboston |
#action remingtron will create a wiki page to collect ideas for a docs re-org |
| 14:52 |
remingtron |
I think we should keep discussing snigdha26's ideas on that email thread |
| 14:53 |
yboston |
we talked about setting up a test server to be used for OPW purposes, and a few other experiments |
| 14:53 |
kmlussier |
snigdha26++ Thanks for the ideas! |
| 14:53 |
yboston |
I can assign that task to me and kmlussier ? is that OK? |
| 14:54 |
kmlussier |
Does it need to be assigned? snigdha26 already started the thread. People should feel free to continue offering feedback and ideas, I think. |
| 14:54 |
|
kakes_ joined #evergreen |
| 14:54 |
yboston |
did we want to focus on a couple of the ideas first liek the search changes or testing the addition of a (collapsible) TOC tot he pages? |
| 14:54 |
yboston |
kmlussier: I meant about following up with a docs test server |
| 14:55 |
kmlussier |
Oh, sorry. |
| 14:55 |
* kmlussier |
was confused. |
| 14:55 |
yboston |
BTW, the next meeting, Academics for Evergeen, will start in 5 minutes |
| 15:52 |
kmlussier |
I took yboston off that one since he volunteered for call number sorting |
| 15:52 |
kmlussier |
#action yboston to lead Call Number Sorting group |
| 15:52 |
kmlussier |
yboston: I think the group leaders should create their own wiki pages. |
| 15:52 |
Christineb |
I am available to test, etc... I cannot do code |
| 15:53 |
kmlussier |
Christineb: We're starting with building of specs, so that might be something to help with too. |
| 15:53 |
kakes_ |
lots of the survey respondents indicated they would help with specing and testing |
| 15:53 |
kmlussier |
Did I miss anything? |
| 15:53 |
Christineb |
kmlussier: ok I would like to help where I can |
| 15:54 |
kmlussier |
So the group leaders will be responsible for soliciting volunteers and starting to pull together needs/specs? Does that sound right? |
| 16:01 |
kmlussier |
yboston: Yes. |
| 16:02 |
eeevil |
kmlussier: it certainly could. it would make config simpler, certainly. no template full of xpath, etc |
| 16:02 |
eeevil |
just "here's your fields, put them where you like" |
| 16:02 |
kmlussier |
eeevil: And you have a new branch available for testing, right? |
| 16:03 |
eeevil |
I do. I confirmed that it rebases to master cleanly (as of the hackaway) |
| 16:03 |
eeevil |
sec... |
| 16:03 |
kmlussier |
eeevil: But it sounds like it still needs work? |
| 16:03 |
eeevil |
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp1251394-metabib-display-fields |
| 16:04 |
kmlussier |
eeevil: I'll try to take some time to look at it once I'm done with web client testing. |
| 16:04 |
kmlussier |
If I ever finish with web client testing, that is. |
| 16:04 |
eeevil |
well, it started before browse, and both display and facet fields could probably benefit from being folded into the same underlying storage |
| 16:05 |
eeevil |
to cut down on duplicate data, at least |
| 16:06 |
eeevil |
kmlussier: note, that branch /only/ provides the backend. the tpac loader (and friends) would need to be taught to pull the data and pass it to the templates |
| 17:07 |
csharp |
jeff++ # hahah |
| 17:15 |
|
sandbergja joined #evergreen |
| 17:19 |
|
mmorgan left #evergreen |
| 17:28 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:32 |
|
cherri joined #evergreen |
| 17:39 |
|
jeff_ joined #evergreen |
| 19:53 |
|
ldwhalen joined #evergreen |
| 12:50 |
|
jihpringle joined #evergreen |
| 12:53 |
eeevil |
bshum: https://bugs.launchpad.net/evergreen/+bug/1374091 updated |
| 12:53 |
pinesol_green |
Launchpad bug 1374091 in Evergreen master "unapi.bre and slow views" (affected: 1, heat: 6) [Undecided,New] |
| 12:55 |
bshum |
eeevil++ |
| 12:55 |
bshum |
I'll turn on metarecords in our test DB to look at that. We don't have them in production. |
| 12:59 |
eeevil |
bshum: note the change to the view, as well. that was force-pushed |
| 12:59 |
eeevil |
IOW, the first commit is different |
| 13:00 |
bshum |
eeevil: yep, already pushed that new commit to production |
| 16:55 |
jeff |
this agenda item says it'll be the default when 2.8 is released! [kidding! not official fact!] |
| 16:55 |
* jeff |
ducks |
| 16:55 |
RoganH |
Succeed or fail I'd rather learn from it while folks can fall back on the xul client. |
| 16:56 |
kmlussier |
The thing is, until people start using it at a live circ desk, we won't really know what all the bugs are, no matter how well we test it. |
| 16:56 |
bshum |
kmlussier: I'd be reluctant to call webby production ready till we've got more modules done for inter-related workflows. |
| 16:56 |
bshum |
Basic circ, sure. But people need to often do more. |
| 16:57 |
kmlussier |
bshum: Sure, but I can think of many libraries that have workstations that are primarily circ only. |
| 17:08 |
* bshum |
goes back to poking at his house of cards that he calls servers... |
| 17:32 |
jeffdavis |
jeff: FWIW, we still see staff client memory issues with the 2.6 client. |
| 17:34 |
jeffdavis |
I wrote up a survey last week to try and narrow down which usage patterns cause the biggest problems. |
| 17:35 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:48 |
|
wlayton joined #evergreen |
| 18:19 |
|
Canepa_ joined #evergreen |
| 18:35 |
csharp |
jeff: we have some libraries reporting the same thing about freezes/high RAM usage |
