| 03:35 |
|
remingtron_ joined #evergreen |
| 03:56 |
|
acautley joined #evergreen |
| 04:59 |
|
acautley joined #evergreen |
| 05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 05:49 |
|
acautley joined #evergreen |
| 06:56 |
|
acautley joined #evergreen |
| 07:10 |
|
rjackson_isl joined #evergreen |
| 09:25 |
gmcharlt |
good morning |
| 09:26 |
csharp |
@coffee gmcharlt |
| 09:26 |
* pinesol_green |
brews and pours a cup of Sumatra Danau Toba, and sends it sliding down the bar to gmcharlt |
| 09:26 |
gmcharlt |
csharp++ |
| 09:27 |
gmcharlt |
so, general heads-up, I think master is in shape for the beta2 release, barring any last-minute updates to the draft release notes |
| 09:27 |
gmcharlt |
but given the spate of last-minute patches last night, would appreciate some testing on a fressh install, particularly on Jessie and Xenial, before we give the word to dbwells to start building |
| 09:28 |
* csharp |
volunteers |
| 09:28 |
gmcharlt |
I also call miker's and berick's attention to commit 474afc447 for more pairs of eyes |
| 09:28 |
pinesol_green |
gmcharlt: [evergreen|Galen Charlton] LP#1718301: catch it when multiple connection attempts fail - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=474afc4> |
| 10:35 |
|
kmlussier joined #evergreen |
| 11:45 |
gmcharlt |
opensrf 3.0.0-alpha is now available for download at https://evergreen-ils.org/opensrf-downloads/ |
| 11:45 |
gmcharlt |
no broader announcement just yet; plan to announce the same time as the beta2 |
| 11:49 |
* Dyrcona |
is struggling with vmbuilder to make fresh vms for testing. |
| 11:49 |
Dyrcona |
If it doesn't work this time, I'm going back to virtinstall and ISO images. |
| 11:50 |
* Dyrcona |
keeps hitting bugs that have solutions on Lp and each patch gets it that much closer to working.... |
| 11:50 |
Dyrcona |
And people think we're bad about keeping up with Lp..... |
| 13:44 |
pinesol_green |
[evergreen|Kathy Lussier] More release note edits for 3.0 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7960a55> |
| 13:44 |
pinesol_green |
[evergreen|Kathy Lussier] Docs: Add an entry for web staff client offline circ - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=33b6a01> |
| 13:46 |
|
rgagnon joined #evergreen |
| 13:52 |
gmcharlt |
csharp: does it abort the test, or just display? |
| 13:53 |
csharp |
gmcharlt: just displays |
| 13:54 |
|
tspindler joined #evergreen |
| 13:54 |
gmcharlt |
csharp: ok, that's benign, at least as far as the test suite is concerned |
| 13:54 |
csharp |
gmcharlt: ok - will move on |
| 13:55 |
|
yboston joined #evergreen |
| 13:56 |
bshum |
miker++ # i18n fixing |
| 14:37 |
gmcharlt |
#info The second beta release will come out today |
| 14:37 |
gmcharlt |
#info Important to emphasize that Evergreen 3.0 now requires OpenSRF 3.0, which has an alpha release today |
| 14:37 |
gmcharlt |
that's it unless there are questions for me |
| 14:38 |
terran |
We're starting training PINES staff on it next Monday so that they can do more testing and be fully prepared for our January upgrade. |
| 14:38 |
terran |
Everyone is very excited. |
| 14:38 |
tspindler |
terran++ |
| 14:38 |
tspindler |
we will be interested how it goes for PINES |
| 14:38 |
ScottThomas |
We also hope to upgrade asap. Looking at very early January |
| 16:33 |
gmcharlt |
AllYall++ |
| 16:41 |
abneiman |
gmcharlt++ |
| 16:43 |
|
mmorgan joined #evergreen |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:01 |
|
khuckins__ joined #evergreen |
| 17:03 |
csharp |
seeing some sporadic complaints of network errors and slow response times from catalogers on 2.12/OpenSRF 2.5.2 - anyone else? |
| 17:03 |
csharp |
I don't have many specifics |
| 00:06 |
pinesol_green |
[evergreen|Kathy Lussier] Docs: 2.11.9 release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=203dd19> |
| 00:06 |
pinesol_green |
[evergreen|Kathy Lussier] Docs: 2.12.6 Release Notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b38b3e5> |
| 00:24 |
|
acautley joined #evergreen |
| 01:46 |
|
acautley joined #evergreen |
| 02:55 |
|
acautley joined #evergreen |
| 03:49 |
|
acautley joined #evergreen |
| 04:37 |
|
Jillianne joined #evergreen |
| 04:58 |
|
acautley joined #evergreen |
| 05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 05:55 |
|
acautley joined #evergreen |
| 06:59 |
|
acautley joined #evergreen |
| 07:13 |
|
rjackson_isl joined #evergreen |
| 08:55 |
|
acautley joined #evergreen |
| 08:59 |
|
bos20k joined #evergreen |
| 09:10 |
|
kmlussier joined #evergreen |
| 09:12 |
bshum |
gmcharlt (and others): FYI, I'll angle to do another i18n POT and PO sync later tonight after today's work is done prior to 3.0-beta2 cutting (tomorrow?) |
| 09:14 |
|
Dyrcona joined #evergreen |
| 09:14 |
bshum |
Looking at LP translations, looks like Eva's finished translating for Czech all the latest strings we added for 3.0-beta1 for webstaff/db.seed so there's plenty to test and check out |
| 09:28 |
|
yboston joined #evergreen |
| 09:59 |
|
acautley joined #evergreen |
| 10:08 |
|
rlefaive_ joined #evergreen |
| 10:09 |
gmcharlt |
bshum: noted, and thanks |
| 10:09 |
kmlussier |
Oops. The 2nd time this week I forgot to vote. |
| 10:18 |
csharp |
miker: pretty sure at this point that RAM was part of (if not the cause of) the problem - thanks for the pointer! |
| 10:18 |
Stompro |
Beta2 tomorrow... I'm just finishing with a test database upgrade of beta1... sigh. |
| 10:18 |
csharp |
Stompro: right there with ya |
| 10:19 |
csharp |
JBoyer's disable ALL THE TRIGGERS! solution made mine pretty painless though after sifting out PINES database particularities |
| 10:20 |
Stompro |
No problems with a 2.10.6 -> 3.0.Beta1 database upgrade so far though, so that is good. Some parts take a long time on my non ssd test vm though. |
| 10:21 |
Stompro |
csharp, could you point me to more info on that? |
| 10:26 |
csharp |
Stompro: here's what I did http://git.evergreen-ils.org/?p=evergreen/pines.git;a=blobdiff;f=Open-ILS/src/sql/Pg/version-upgrade/2.12.5-3.0-beta1-upgrade-db.sql;h=3a4f54fecc0b4c37b627da2963fe1e50e259aa02;hp=0da18594c992f7050b0ea907600e318af117d6da;hb=99d5c1164f7180117760d48245db54a5a7bc0296;hpb=dfc8e3892d76af32162e1069c2c620139449ce2f |
| 10:28 |
Stompro |
csharp++ thanks |
| 10:36 |
kmlussier |
Recalculating fingerprints? |
| 10:38 |
Dyrcona |
Yeap. |
| 10:39 |
Dyrcona |
csharp++ # For the links.. |
| 10:40 |
Dyrcona |
I'm supposed to set up a 3.0 testing server, too, but I'm focusing on the upgrade, first. :) |
| 10:40 |
Dyrcona |
miker: Do you have any code for that set replication suggestion from last week? I might give that a go, though I said it made me uneasy. |
| 10:41 |
Dyrcona |
If not, I suppose I could figure it out. |
| 10:43 |
miker |
Dyrcona: it's basically just, "set session_replication_role to 'replica';" before the big update, and then "set session_replication_role to 'origin';" after |
| 10:44 |
Dyrcona |
miker: Thanks! I'll give that a whirl when do it the 3.0 upgrade on the testing server. |
| 10:44 |
pinesol_green |
[opensrf|Ben Shum] LP#1708048: Add support for Debian 9 Stretch - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=a85132e> |
| 10:44 |
miker |
awesome |
| 10:44 |
pinesol_green |
[opensrf|Jason Stephenson] LP#1708048: Fix ld problems by renaming libraries. - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=cace46d> |
| 11:35 |
gmcharlt |
tossing in bug 1715503 as ready for review and merging today |
| 11:35 |
pinesol_green |
Launchpad bug 1715503 in Evergreen "Complain if minimum Pg version for 3.0 is not met" [Medium,New] https://launchpad.net/bugs/1715503 |
| 11:40 |
|
rlefaive joined #evergreen |
| 12:46 |
bshum |
miker++ # I'll test your branch for bug 1717777 later tonight |
| 12:46 |
pinesol_green |
Launchpad bug 1717777 in Evergreen "Need to load all the PO files for a locale" [Undecided,Confirmed] https://launchpad.net/bugs/1717777 |
| 12:47 |
miker |
bshum++ # thanks |
| 12:47 |
bshum |
Fwiw, I also noticed that there could be differences in the various PO files too |
| 13:45 |
Dyrcona |
Wheezy is old and...wheezy...it should be replaced by Jessie. :) |
| 14:10 |
Dyrcona |
FYI: Master Evergreen seems to be broken on Debian 8 Jessie. |
| 14:11 |
Dyrcona |
karma:unit starts out with this warning: WARN [watcher]: Pattern "/home/opensrf/Evergreen/Open-ILS/web/js/ui/default/staff/node_modules/angular-sanitize/angular-sanitize.min.js" does not match any file. |
| 14:12 |
Dyrcona |
Then all following tests blow up with with various long messages. |
| 14:13 |
Dyrcona |
I'm testing a branch that has this commit as head: bed0acd1b197af590da729b6e1c29839580d1c5b |
| 14:13 |
Dyrcona |
Oh, right. It doesn't look at the working repository. |
| 14:14 |
Dyrcona |
I may have botched a prereq in the makefile, but I don't think so. |
| 14:14 |
Dyrcona |
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dyrcona/lp1718459-remove-debian7-wheezy |
| 15:22 |
bshum |
Dyrcona: Yep, if I yank out the prereqs for nodejs-legacy and npm for Jessie, and then install the NodeJS binary like we do for old-Wheezy, or Trusty, then run the usual npm install, grunt all is happy |
| 15:22 |
bshum |
So it is a problem with our package list and having old node on Jessie that's broken it for master |
| 15:23 |
gmcharlt |
and seems to have /just/ broken |
| 15:24 |
bshum |
I guess we should test it on Xenial where we also use the packaged nodejs and see if it's broken there too |
| 15:24 |
bshum |
gmcharlt: Extra fun! :) |
| 15:25 |
Dyrcona |
Yeah, we should test on Xenial and bug it, too. |
| 15:25 |
gmcharlt |
OK! fess up! who started using leftpad? ;) |
| 15:25 |
Dyrcona |
heh |
| 15:35 |
bshum |
Hmm, well the lovefield warning shows up in Xenial when doing the npm install |
| 16:07 |
pinesol_green |
[evergreen|Bill Erickson] LP#1718301 Offline db connections via promise - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b87a437> |
| 16:17 |
kmlussier |
berick++ |
| 16:29 |
* berick |
saw "leftpad", read it as "leafpad", started getting defensive |
| 17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:03 |
|
genpaku joined #evergreen |
| 17:06 |
|
mmorgan left #evergreen |
| 17:17 |
* gmcharlt |
claims 1076 in the name of ghosts that are tired of being invisible everywhere! |
| 18:08 |
csharp |
that was yesterday^^ again - same second |
| 18:21 |
|
acautley joined #evergreen |
| 18:39 |
|
Jillianne joined #evergreen |
| 18:40 |
bshum |
Bah |
| 18:40 |
bshum |
The xenial grunt test blows up on my latest VM rebuild test |
| 18:40 |
bshum |
So I guess that's all they wrote for that |
| 18:41 |
bshum |
I'll mock up my change branch for installing nodejs source and apply that in my test building |
| 18:44 |
bshum |
And in the meantime, while I wait for ansible to rebuild my test server (again), I'll go and make a bug for that change |
| 18:54 |
bshum |
Ho hum, might be a bigger problem than that.... sigh |
| 19:02 |
|
Dyrcona joined #evergreen |
| 19:02 |
bshum |
Well, clean repo copy, and still getting npm and dependency problems. Going to try nailing a copy of the errors this time around |
| 19:03 |
Dyrcona |
bshum: with the latest Node.js? |
| 19:04 |
bshum |
Dyrcona: Yep, I was getting failures, so I removed the legacy nodejs and npm from my xenial box and then tried using the latest NodeJS and it is still bombing on trying to grab all the stuff for web client |
| 19:04 |
bshum |
I'm not sure if it's NodeJS issues, or if it's changed that were merged last minute to master |
| 19:04 |
bshum |
Just to check |
| 19:04 |
Dyrcona |
OK. |
| 19:05 |
Dyrcona |
Do you have a branch with the changes, yet? |
| 19:05 |
Dyrcona |
It would make it easier for me to test, too. |
| 19:05 |
bshum |
For NodeJS? |
| 19:05 |
Dyrcona |
Yeah. |
| 19:05 |
bshum |
Yeah I was just adding the LP# and making the branch |
| 19:12 |
bshum |
Yep |
| 19:12 |
bshum |
Reverting b87a437825a531a3e6977d1e0b17e48d8f41f74a fixing my web client building |
| 19:12 |
pinesol_green |
bshum: [evergreen|Bill Erickson] LP#1718301 Offline db connections via promise - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b87a437> |
| 19:12 |
bshum |
So something in that new commit broke nodejs fresh setup |
| 19:14 |
bshum |
Maybe all those nodejs changes that recently happened are unhappy with the change, but whatever gmcharlt/miker had installed during their testing was fine. |
| 19:15 |
bshum |
Either way, that's definitely the source of my breakage once I backed that back out |
| 19:15 |
* bshum |
resumes building out his test server for i18n stuff |
| 19:16 |
Dyrcona |
bshum: You typoed the Lp number in your branch, you swapped the 4 and 5. I noticed, 'cause you have my bug number from today. :) |
| 19:16 |
bshum |
Oops |
| 19:17 |
bshum |
That always happens to me :( |
| 19:17 |
gmcharlt |
bshum: hmm, I'l look at it after dinner |
| 19:17 |
gmcharlt |
maybe (hopefully) just a matter of tweaking a test |
| 19:18 |
bshum |
Dyrcona: I can fix and force push a replacement |
| 19:18 |
Dyrcona |
bshum: It's just the branch name no big deal for now. |
| 19:18 |
bshum |
Dyrcona: Ah okay, yes, I see that now. Doh. |
| 19:18 |
Dyrcona |
The commit messages have the correct number. |
| 19:19 |
bshum |
gmcharlt: Sounds good, I'll keep testing other stuff around it for now. Reverting it locally till I know what to do about it :) |
| 19:19 |
* bshum |
waits for the LONG i18n dance on his test server to play out |
| 19:21 |
|
jihpringle joined #evergreen |
| 19:23 |
gmcharlt |
https://www.youtube.com/watch?v=sArAC2_ow2k |
| 19:23 |
bshum |
gmcharlt: That helps actually, thanks :) |
| 20:50 |
gmcharlt |
k, got a patch for you to look at in a minute |
| 20:50 |
bshum |
Working my way through a Stretch VM install :) |
| 20:50 |
Dyrcona |
I'm here also. |
| 20:56 |
bshum |
Fwiw, using "grunt all --force" let me proceed through the whole install even with the failed stuff. So it does appear to be the tests like you said |
| 20:56 |
bshum |
I havent' tried installing Hatch and trying out everything else though |
| 20:56 |
gmcharlt |
user/gmcharlt/lp1718301_lf_no_multi_connect |
| 20:57 |
Dyrcona |
Well, given the message that I got earlier, I assumed a --force would fail to work in the end. |
| 21:01 |
bshum |
gmcharlt: That patch worked for me |
| 21:22 |
gmcharlt |
if so, I can grab it |
| 21:22 |
bshum |
gmcharlt: Yep, it's in https://bugs.launchpad.net/evergreen/+bug/1718549 |
| 21:22 |
pinesol_green |
Launchpad bug 1718549 in Evergreen "install NodeJS from source for all supported distributions" [High,Triaged] |
| 21:22 |
bshum |
The thing I'm testing right now is whether you have to do something first to remove old npm and nodejs-legacy too |
| 21:22 |
bshum |
And I think you might |
| 21:23 |
bshum |
Cause when I run my patch through, it installs new nodejs and I get node --version = 6.11.3 as I expect, but still getting npm --version of 1.4.21 |
| 21:23 |
bshum |
So not sure it's not acting funny |
| 21:23 |
bshum |
But for fresh installs, should go perfectly |
| 21:24 |
bshum |
Oh, could just be my environment |
| 21:24 |
gmcharlt |
which npm |
| 21:25 |
bshum |
3.10.10 now showing |
| 21:25 |
bshum |
So that means it overwrites correctly with the installed source |
| 21:55 |
pinesol_green |
[evergreen|Ben Shum] Translation updates - newpot - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d019d22> |
| 21:55 |
pinesol_green |
[evergreen|Ben Shum] Translation updates - po files - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7a078f4> |
| 21:58 |
|
_bott_ joined #evergreen |
| 22:09 |
bshum |
Okay, xenial builds fine for me with the latest master as of all the POT/PO. I'll test further tomorrow. Thanks again gmcharlt for the patch |
| 22:09 |
bshum |
gmcharlt++ |
| 22:09 |
bshum |
Goodnight #evergreen :) |
| 22:17 |
gmcharlt |
https://evergreen-ils.org/evergreen-2-11-9-and-2-12-6-released/ |
| 22:17 |
gmcharlt |
Bmagic++ |
| 22:17 |
gmcharlt |
dbwells++ |
| 00:23 |
pinesol_green |
[evergreen|Jane Sandberg] Docs: TPAC bib_source variable - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9d163e4> |
| 05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:13 |
|
rkw joined #evergreen |
| 07:14 |
|
rjackson_isl joined #evergreen |
| 08:39 |
|
mmorgan joined #evergreen |
| 10:25 |
pinesol_green |
Launchpad bug 1712637 in Evergreen "Web Client: Default Hold Pickup Location Errors" [High,Confirmed] https://launchpad.net/bugs/1712637 |
| 10:29 |
kmlussier |
berick: In the hold pickup location selector? No. |
| 10:29 |
kmlussier |
I was about to build a new VM this morning and was going to include that branch. I can check again just to be sure. |
| 10:30 |
berick |
kmlussier: that would be appreciated. I'm not seeing what you are seeing. |
| 10:30 |
berick |
they are greyed out and un-select-able for me |
| 10:32 |
berick |
i just rebased to master and re-tested |
| 10:37 |
dbs |
berick: in terms of clearing cached proxy entries for given URIs, I started using the proxy_cache_bypass directive recently |
| 10:37 |
pinesol_green |
[evergreen|Jane Sandberg] Docs: adding the MARC Templates documentation back - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=899b6a5> |
| 10:37 |
pinesol_green |
[evergreen|Jane Sandberg] Docs reorg: splitting action/triggers into command-line and staff-client manuals - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=10c578a> |
| 10:43 |
dbs |
thank you https://serverfault.com/questions/493411/how-to-delete-single-nginx-cache-file for showing me the way :) |
| 10:45 |
|
mmorgan joined #evergreen |
| 10:51 |
berick |
i also had to find an example... docs are spare on that one. |
| 11:00 |
kmlussier |
berick: I don't know why it didn't work in my earlier test, but it's working for me now. I'll sign off and push it now. |
| 11:01 |
berick |
kmlussier++ |
| 11:21 |
|
ningalls joined #evergreen |
| 11:25 |
gmcharlt |
survey on what version number to use for the next major OpenSRF release https://gmcharlt.limequery.org/523355 |
| 13:42 |
csharp |
examples here (for the logs): http://gapines.org/eg/kpac/category?trail=30 |
| 13:43 |
* mmorgan |
remembers making buckets OPAC-able by doing what csharp said, changing btype AND public. But since both changes are required, the 'publicly visible' checkbox in the web client won't do the whole job. |
| 13:45 |
berick |
doesn't the pub checkbox in the web client determine if staff A can view a (staff) bucket created by staff B? or is that just permission-based? |
| 13:47 |
csharp |
for webstaff installation, is there anything wrong with having test/data/idl2js.pl use the installed versions of fm_IDL.xml and fm_IDL2js.xsl? since we install from debs, we're trying to work around needing the source tree installed |
| 13:47 |
csharp |
btw, what I'm suggesting *works*, I'm just wondering if there's a good reason not to do so by default or just instead |
| 13:52 |
berick |
csharp: it uses the source version so it's possible to build EG without installing it. |
| 13:53 |
kmlussier |
berick: Yeah, that's what I'm testing now. But I keep messing up my tests. |
| 13:56 |
csharp |
berick: ah |
| 13:59 |
kmlussier |
Yeah, I can retrieve somebody else's bucket by id whether it's publicly visible or not. |
| 14:01 |
kmlussier |
That's a copy bucket. I haven't tried it with a record bucket yet. |
| 14:37 |
kmlussier |
csharp: Too late! I've already tweeted about it. |
| 14:50 |
csharp |
crap |
| 14:51 |
csharp |
:-D |
| 15:18 |
pinesol_green |
[evergreen|Bill Erickson] LP#1537233 Copy bucket handles mis-scans, improve focus - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=40d8ce3> |
| 15:24 |
|
tlittle joined #evergreen |
| 15:50 |
|
jvwoolf left #evergreen |
| 16:39 |
|
jihpringle_ joined #evergreen |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:03 |
|
mmorgan left #evergreen |
| 17:07 |
|
acautley joined #evergreen |
| 17:09 |
|
khuckins joined #evergreen |
| 17:20 |
pinesol_green |
[evergreen|Ben Shum] LP#1717715: Fix typo in webstaff serials - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a7a98ff> |
| 17:26 |
|
Jillianne joined #evergreen |
| 18:01 |
|
tlittle left #evergreen |
| 18:27 |
|
acautley joined #evergreen |
| 05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:06 |
|
rjackson_isl joined #evergreen |
| 07:19 |
pinesol_green |
[evergreen|Galen Charlton] LP#1716486: fix hotkeys - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=bb85fcd> |
| 07:32 |
csharp |
@quote add * miker shakes fist at the heavens, "U T F EEEEEEIIIIIGGGGGHHHHTTTTT!" |
| 07:32 |
pinesol_green |
csharp: The operation succeeded. Quote #175 added. |
| 07:46 |
csharp |
@later tell RyanM see https://bugs.launchpad.net/evergreen/+bug/1541801 - should be fixed in the web client for 2.12 and newer (but not the XUL staff client) |
| 08:54 |
|
_adb joined #evergreen |
| 08:54 |
* csharp |
needs the fix, just wants to be sure we're on sure footing before experimenting too much |
| 08:57 |
Dyrcona |
csharp: I'm confident that gmcharlt's patch that I pushed last night fixes the problem. |
| 08:57 |
Dyrcona |
I'm going to build a new vm today to do some more testing. |
| 08:58 |
Dyrcona |
This is mainly 2.10.7 -> 2.12.5 upgrade testing, but this code will get another workout. |
| 08:59 |
Dyrcona |
I've got another machine that I'm supposed to install 3.0-beta onto, but I may just go with master. |
| 08:59 |
Dyrcona |
Until rel_3_0 is branched, that is. |
| 09:01 |
Dyrcona |
heh. It helps not to typo the db user name, huh? :) |
| 09:03 |
csharp |
Dyrcona: thanks ;-) |
| 09:04 |
Dyrcona |
Anyway, I think it is safe to apply the patch from last nigh if you've already installed OpenSRF 2.5.1. |
| 09:05 |
Dyrcona |
Oh, I can see it's going to be one of those typo kind of days. |
| 09:05 |
Dyrcona |
This is where testing with production data comes in handy. |
| 09:08 |
gmcharlt |
I am inclined to cut 2.5.2 now; the other changes can wait |
| 09:08 |
gmcharlt |
thoughts? |
| 09:09 |
|
bos20k joined #evergreen |
| 11:36 |
Bmagic |
Dyrcona++ |
| 11:36 |
Dyrcona |
I don't see anywhere that a SAN i put into an outgoing message. |
| 11:37 |
Dyrcona |
And yeah, right after that it looks up the address by SAN. ;) |
| 11:39 |
Dyrcona |
csharp: I haven't test a/t on 2.12. I probably should after making sure email goes nowhere. |
| 11:54 |
|
jvwoolf1 joined #evergreen |
| 11:57 |
|
sandbergja joined #evergreen |
| 11:58 |
csharp |
Dyrcona: A/T generally works - email notices are working fine - just the PO JEDI event with the undef variables that I'm trying to suss out |
| 13:24 |
Dyrcona |
Whee! tail -f /openils/var/log/osrfsys.log goes by too fast to follow. |
| 13:25 |
csharp |
berick: will do |
| 13:25 |
* berick |
always has to read "Fix for Web Client Copy Editor Fix" twice |
| 13:25 |
csharp |
I did verify that the template/environment/params have not changed between versions |
| 13:26 |
csharp |
but I haven't tested against stock yet |
| 13:26 |
Dyrcona |
csharp: You added lines to log the context, yeah? |
| 13:26 |
csharp |
yes |
| 13:27 |
kmlussier |
miker: mmorgan and I already verified the search slowness is still a problem on 2.5.1. Do you think 2.5.2 will make a difference? |
| 13:27 |
Dyrcona |
my events all went to invalid, but it could be because they are so old. |
| 13:28 |
miker |
kmlussier: that's what I want to test, yes. 2.5.1 has a bad bug, so an upgrade to the brand new 2.5.2 is indicated in any case |
| 13:28 |
Dyrcona |
I don't know enough about acq to setup an invoice to have a fresh one. |
| 13:28 |
csharp |
invalid probably means they aren't EDI vendors |
| 13:28 |
mmorgan |
miker: kmlussier: We slipped in the 2.5.2 fix this morning on our training server and still saw the issue. |
| 13:29 |
* csharp |
makes a sad face at mmorgan's last :-( |
| 13:29 |
csharp |
we're getting slow/timeout on searching too |
| 13:29 |
kmlussier |
Sure, I'll also update the OpenSRF on the test system I've been using just to be sure. |
| 13:29 |
* mmorgan |
forgot to supply same :-( |
| 13:30 |
* csharp |
was hoping the latest fixes would Just Work™ |
| 13:31 |
miker |
mmorgan: thanks, that's the confirmation I wanted. I just wanted to take something off the table to look at |
| 13:33 |
berick |
Dyrcona: to test the ACQ A/T stuff, i think all you need to do is activate a PO whose provider has an edi_default value |
| 13:33 |
berick |
the edi_account itself can be all dummy data |
| 13:33 |
csharp |
yeah |
| 13:34 |
Dyrcona |
berick: 1) I have no idea how to actually use acq. 2) I have 3-month old data that I can test with at the moment. |
| 13:34 |
Dyrcona |
I just make the dog food. I don't eat it. :) |
| 13:34 |
berick |
heh |
| 13:34 |
berick |
but it's delicious! |
| 13:35 |
berick |
TFW you remember you don't have to launch the XUL client |
| 13:35 |
csharp |
berick: did that earlier |
| 13:35 |
csharp |
"wait, why did I bother opening this?" |
| 13:36 |
berick |
:) gonna take some getting used to |
| 13:41 |
berick |
csharp: tested on master/master w/ stock data. had no problem generating JEDI. |
| 13:41 |
berick |
order had 1 LI and 25 copies, so not huge |
| 13:43 |
* berick |
is also using the large max_stanza_size, in case it's relevant |
| 13:49 |
csharp |
yeah our max_stanza_size is at 2000000 |
| 13:53 |
Dyrcona |
mine is the default 65536 |
| 13:53 |
Dyrcona |
Of course, my events failed to validate, so that's no helpful at this point. |
| 13:58 |
berick |
reminder to set an edi_default value on the provider after creating the edi_account. |
| 13:58 |
* berick |
got stuck on that |
| 14:03 |
* csharp |
just busted his test server by inserting the stock PO JEDI template into ALL THE EVENT DEFS |
| 14:04 |
csharp |
I was about to blow it away to start testing 3.0 anyway |
| 14:04 |
csharp |
and I did preserve the old defs, but I don't want to worry about spending the required time fixing it |
| 14:04 |
berick |
YOU GET EDI, AND YOU GET EDI |
| 14:04 |
berick |
noooooo |
| 14:05 |
csharp |
@oprah EDI |
| 16:48 |
Dyrcona |
Do it right, now, or pay for it later. |
| 16:48 |
Dyrcona |
Again, just a suggestion... :) |
| 17:00 |
miker |
parseFloat+printf (yes, we have a printf implementation stashed away somewhere in the code base) |
| 17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:02 |
|
mmorgan left #evergreen |
| 17:22 |
|
acautley joined #evergreen |
| 17:36 |
|
tlittle joined #evergreen |
| 17:42 |
pinesol_green |
[evergreen|Galen Charlton] LP#1708951: fix tabbing in webstaff catalog app for Firefox - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c43bc5b> |
| 18:00 |
|
kmlussier joined #evergreen |
| 19:17 |
|
Jillianne joined #evergreen |
| 20:29 |
|
tsbere joined #evergreen |
| 01:04 |
|
dbwells_ joined #evergreen |
| 01:05 |
|
remingtron_ joined #evergreen |
| 01:14 |
|
dbwells__ joined #evergreen |
| 05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:02 |
|
agoben joined #evergreen |
| 07:02 |
|
JBoyer joined #evergreen |
| 07:13 |
|
rjackson_isl joined #evergreen |
| 09:01 |
|
_adb joined #evergreen |
| 09:07 |
|
rlefaive_ joined #evergreen |
| 09:09 |
JBoyer |
mdriscoll, kmlussier, csharp: I noticed the talk about upgrade script 1057 in the logs, the real issue is the trigger that maintains the 901c subfield. It's causing every record in your entire db, deleted or not, to be parsed by the MARC::XML perl module and the 901 rebuilt. |
| 09:10 |
JBoyer |
If that winds up changing the marc field it will be reingested, but otherwise it's still just overly slow for no reason. For that script on my testing server I disabled all of the triggers and ignored the deleted records to get it down to somewhere between 30 and 90 mins. |
| 09:10 |
csharp |
JBoyer: oh - awesome |
| 09:11 |
mdriscoll |
JBoyer: I'll try that, thanks! |
| 09:12 |
kmlussier |
JBoyer++ |
| 10:59 |
* gmcharlt |
goes *poof* for a brief meeting |
| 11:00 |
bshum |
OpenSRF 3.0 sounds fun. +1 |
| 11:01 |
JBoyer |
and mdriscoll: if you left the maintain_control_numbers trigger enabled, it's doing essentially the same thing as maintain_901, meaning it will only take half as long as letting both run, but it will be a lot faster if you disable all of the triggers for the duration of that script. |
| 11:01 |
miker |
meh, WORKSFORME is psql test on 9.4. the complaints seem to be about pgadmin. but the script is editable, so... to each site, their own |
| 11:02 |
Dyrcona |
mdriscoll: You're using Pg 9.4, right? |
| 11:02 |
mdriscoll |
JBoyer: ok will do. I was trying to disable as little as possible to see how long it would take. |
| 11:03 |
mdriscoll |
Dyrcona: yes Pg 9.4. |
| 13:19 |
gmcharlt |
the bit of JavaScript mentioned on the Koha wiki page can be plopped into webstaff's base_js.tt2 and just work |
| 13:20 |
jeffdavis |
thx Dyrcona |
| 13:20 |
Dyrcona |
gmcharlt: That "feature" apparently hasn't made it into Firefox 55 on Linux, or it is not on by default. |
| 13:21 |
gmcharlt |
Dyrcona: yeah, they seem to be doing A/B testing during the release, so I think it is on for some |
| 13:23 |
kmlussier |
gmcharlt++ |
| 13:23 |
gmcharlt |
and for those institutions that manage their deployments of Firefox to library staff, there's this - https://support.mozilla.org/en-US/questions/1168009 |
| 13:48 |
* csharp |
switches gears back to other acq issue where A/T is crapping out on undefined values |
| 14:34 |
pinesol_green |
jeffdavis: [opensrf|Bill Erickson] LP#1697029 Log and exit on write to dead child - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=a9cd124> |
| 14:34 |
jeffdavis |
That reset gets rid of the fixes for bug 1709710 (plus a few other things). |
| 14:34 |
pinesol_green |
Launchpad bug 1709710 in Evergreen "Default ejabberd max_stanza_size can be exceeded when chunking (MARC)XML-heavy responses" [Undecided,Confirmed] https://launchpad.net/bugs/1709710 |
| 14:35 |
jeffdavis |
I'll test more when things are calmer here. |
| 14:38 |
Dyrcona |
jeffdavis: I may be able to set up a test of OpenSRF rel_2_5 and Evergreen 2.12. (I assume you have the issue with 2.12.) |
| 14:38 |
Dyrcona |
I only tested the changes with master OpenSRF and master Evergreen. |
| 14:38 |
jeffdavis |
yeah, we're on 2.12.1 with some backports |
| 14:39 |
Dyrcona |
Well, I'd recommend going all the way to 2.12.5, but I know that can be difficult (not technically, but politically). |
| 14:40 |
Dyrcona |
Since I was just working on documentation to prepare for our upgrade next month, maybe I should put that aside and build the test vm now..... |
| 14:40 |
Dyrcona |
jeffdavis: You say had trouble with workstation registration. Anything else that I could try to reproduce? |
| 14:41 |
jihpringle |
Drycona: stat cats for one of our sites disappeared in the copy editor as well |
| 14:42 |
Dyrcona |
jihpringle: Thanks. |
| 15:02 |
jeffdavis |
I can email you the scripts I used it you like |
| 15:02 |
jeffdavis |
*if |
| 15:02 |
Dyrcona |
That's OK. I think I know what I need to do. |
| 15:03 |
Dyrcona |
I'm going to test upgrading OpenSRF but leaving Evergreen untouched, first. |
| 15:05 |
abneiman |
anyone else getting timeout errors from docs.evergreenils.org? the main page loads but links into the docs themselves are timing out for me. |
| 15:05 |
|
mmorgan1 joined #evergreen |
| 15:08 |
berick |
abneiman: site doesn't load at all for me |
| 15:43 |
Dyrcona |
So, after that I get a different error message. I'll save those logs, too. |
| 15:52 |
Dyrcona |
Register workstation seems to work in the web staff client, btw. |
| 15:54 |
jihpringle |
Drycona: we could register workstations in the web client too |
| 15:55 |
Dyrcona |
I'll open a bug for now. I want to test with a clean installation tomorrow. |
| 16:02 |
* bshum |
grumbles as he makes himself a new Mac client |
| 16:10 |
Dyrcona |
jeffdavis jihpringle: bug 1717350 |
| 16:10 |
pinesol_green |
Launchpad bug 1717350 in Evergreen "Upgrading to OpenSRF 2.5.1 appears to break XUL 2.12.5" [Undecided,New] https://launchpad.net/bugs/1717350 |
| 16:20 |
jeffdavis |
followed by the usua "Request Completed Successfully" + request time |
| 16:20 |
jeffdavis |
*usual |
| 16:20 |
jeffdavis |
I need to step away for a bit, happy to try more stuff later on |
| 16:20 |
berick |
huh |
| 16:20 |
berick |
thanks |
| 16:21 |
berick |
just trying to boil it down to the simplest possible test case |
| 16:23 |
Dyrcona |
berick: FWIW the first request above gives the same message in the lp bug. |
| 16:25 |
Dyrcona |
And I get the osrfResultPartialComplete exception for the second, so same as jeffdavis, more or less. |
| 16:26 |
* Dyrcona |
calls it a day. |
| 16:48 |
gmcharlt |
berick: yeah, I was just about to reproduce it by expanding aou |
| 16:49 |
bshum |
New staff client, hmm... |
| 16:49 |
berick |
i tried installing rel_2_12 on top of osrf master and cannot reproduce, fwiw |
| 17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:04 |
|
khuckins__ joined #evergreen |
| 17:05 |
miker |
berick: can't reproduce in srfsh, you mean? |
| 17:06 |
berick |
miker: i couldn't reproduce locally in srfsh or xul |
| 17:39 |
dbwells |
gmcharlt's bug is the killer, but FWIW, I think we also have another issue with that loop. We're looping until num_bytes, but still chunking on chars. Since bytes >= chars, the effect will be possible empty responses at the end of the loop (rather than missing data, and depending on chunk boundary), so not the end of the world. If anyone agrees with this diagnosis, I can open a bug about it for a future fix. |
| 17:39 |
gmcharlt |
dbwells: I think it's worth exploring |
| 17:40 |
miker |
yeah, breaking when the substr is empty seems sane |
| 17:43 |
dbwells |
Okay, I will try to concoct a test case and go from there. I'm not very familiar with this layer, so should be interesting at least :) |
| 17:45 |
miker |
hrm... I wonder if the C version is at risk of spliting 2+ byte utf8 chars ... I suspect so. I'll make a note to look at that first thing tomorrow. |
| 17:46 |
* miker |
shakes fist at the heavens, "U T F EEEEEEIIIIIGGGGGHHHHTTTTT!" |
| 17:53 |
miker |
actually, nevermind. we \u-encode 2+ byte chars |
| 02:47 |
|
Jillianne joined #evergreen |
| 04:03 |
|
gsams joined #evergreen |
| 05:02 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:11 |
|
rjackson_isl joined #evergreen |
| 08:40 |
|
mmorgan joined #evergreen |
| 08:53 |
|
bos20k joined #evergreen |
| 09:03 |
|
mdriscoll joined #evergreen |
| 09:05 |
* csharp |
is about to test backporting non-Ruby EDI (bug 1373690) |
| 09:05 |
pinesol_green |
Launchpad bug 1373690 in Evergreen "Direct EDI generation for ACQ orders -- AKA kill ruby webrick" [Wishlist,Fix released] https://launchpad.net/bugs/1373690 |
| 09:06 |
csharp |
in part because, for whatever reason, A/T is breaking on creating JEDI |
| 09:07 |
|
_adb joined #evergreen |
| 09:36 |
|
jvwoolf joined #evergreen |
| 09:43 |
|
jvwoolf joined #evergreen |
| 09:48 |
|
kmlussier joined #evergreen |
| 09:55 |
berick |
csharp: i'm all ears! BTW, you probably saw this, but you have to enable direct generation for each edi_account now. |
| 09:56 |
berick |
so you can test by applying attrs while continuing traditional edi delivery |
| 09:59 |
csharp |
berick: good to know |
| 10:15 |
pinesol_green |
[evergreen|Galen Charlton] LP#1713160: fix crash viewing circ history in public catalog - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=461072d> |
| 10:21 |
|
mmorgan joined #evergreen |
| 13:04 |
csharp |
heh |
| 13:07 |
|
rlefaive joined #evergreen |
| 13:09 |
|
collum joined #evergreen |
| 13:12 |
roycroft |
hello, folks |
| 13:13 |
roycroft |
i'm curious - has there been any discussion of creating a virtual machine image of an evergreen platform for folks to use for testing/evaluation? |
| 13:13 |
roycroft |
i'm not complaining, but i've spent 3 hours doing an install so far, and i'm still working on the opensrf installation |
| 13:13 |
|
jihpringle_ joined #evergreen |
| 13:14 |
csharp |
roycroft: we used to have a couple out there, but not in years |
| 13:14 |
rhamby_ |
roycroft: there are a variety of ways to doing quick and dirty builds that are good for test systems but I wouldn't recommend them for production, I use an ansible script usually |
| 13:14 |
csharp |
it's a moving target and time-consuming to maintain :-/ |
| 13:14 |
roycroft |
i know that this is a vertical market app, and perhaps it's not evaluated as commonly as things like a cms |
| 13:14 |
roycroft |
so a vm image might not be as useful |
| 13:17 |
roycroft |
but if it's a slam dunk on jessie, perhaps i should go back and start over |
| 13:17 |
csharp |
oh - well, I would go with jessie or one of the Ubuntu LTS's |
| 13:17 |
roycroft |
i'm up to installing apache2-websockets |
| 13:18 |
berick |
roycroft: may be of interest: https://wiki.evergreen-ils.org/doku.php?id=server_installation:semi_automated |
| 13:18 |
berick |
i use the ansible installer (2nd from bottom) |
| 13:18 |
berick |
docker container is great for test machines too |
| 13:18 |
csharp |
roycroft: since it sounds like you're basically installing for evaluations, keep it simple and go with long-supported releases (jessie & Ubuntu 14.04) |
| 13:18 |
berick |
(when the build you want exists) |
| 13:23 |
roycroft |
yes, i'm beginning to think that would be a good idea |
| 15:07 |
berick |
so now you just have to keep trying over and over all day :) |
| 15:07 |
csharp |
ha! |
| 15:07 |
csharp |
yep |
| 15:23 |
mdriscoll |
I'm upgrading a test system to 3.0-beta1. The database has 2m bibs and 3m copies. The 2.12.5-3.0 upgrade script is taking a really long time (>24 hrs). |
| 15:23 |
mdriscoll |
The problem is with script 1057.schema.copy_vis_attr_cache.sql. I believe it is causing a reingest of every bib record. I'm wondering if there is a way around this. |
| 15:25 |
csharp |
d9fa69de |
| 15:25 |
pinesol_green |
csharp: [evergreen|Mike Rylander] LP#1698206: Eliminate Staged Search - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d9fa69d> |
| 15:25 |
kmlussier |
mdriscoll: I don't think it's reingesting bib records, but I can confirm it takes a very long time based on an upgrade on a much smaller database that I did yesterday. |
| 15:34 |
berick |
kmlussier: yeah that's what i'm thinking, after we get a usable set of seed data |
| 15:34 |
mdriscoll |
csharp: thanks! |
| 15:37 |
|
mmorgan1 joined #evergreen |
| 15:49 |
Dyrcona |
I will test that upgrade fairly soon on a relatively well-tuned server. |
| 15:57 |
csharp |
same here |
| 15:58 |
csharp |
PINES libs are super excited about the web client and we're starting trainings week after next |
| 16:00 |
berick |
we've started some high level review sessions here |
| 16:47 |
csharp |
ate a lot of those during my recent vegetarian period |
| 16:47 |
berick |
hah |
| 16:48 |
berick |
lot of dark adjectives |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:07 |
|
jvwoolf left #evergreen |
| 17:11 |
|
mmorgan left #evergreen |
| 19:53 |
|
khuckins joined #evergreen |
| 03:50 |
|
HTTP_____GK1wmSU joined #evergreen |
| 03:53 |
|
HTTP_____GK1wmSU left #evergreen |
| 05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:02 |
|
kmlussier joined #evergreen |
| 07:17 |
|
rjackson_isl joined #evergreen |
| 07:43 |
|
Dyrcona joined #evergreen |
| 15:01 |
|
Jillianne joined #evergreen |
| 15:03 |
|
mmorgan1 joined #evergreen |
| 15:17 |
* berick |
has also had the missing cursor issue |
| 15:25 |
Dyrcona |
One of the negative balance live tests fails for me on Concerto. It's test 90. |
| 15:26 |
Dyrcona |
Also, I think we have two live tests with the same number again. |
| 15:26 |
Dyrcona |
Yeah, two 24s. |
| 15:30 |
bshum |
And two 20s |
| 15:31 |
Dyrcona |
you're right. I missed the 2 20s. |
| 15:32 |
Dyrcona |
It's not a big deal, but what's the point of numbering them. |
| 15:32 |
bshum |
Isn't that some tests have to run sequentially? |
| 15:33 |
Dyrcona |
Could be that. |
| 15:33 |
Dyrcona |
I'm just saying if we duplicate numbers, then why number them? ;) |
| 15:34 |
Dyrcona |
Anyway, I did login and do a search prior to running prove, so I've reloaded a fresh db and will try again. |
| 15:34 |
Dyrcona |
I also ran make check, but that doesn't do the live tests. |
| 15:34 |
bshum |
That's probably a good idea. I think login could goof something up like if you register a workstation ahead of whatever they add during the test |
| 15:36 |
Dyrcona |
It passed this time. |
| 15:36 |
berick |
the live tests have chaotic consequences. until we have a system that does a full data rollback (a la pgtap) with each test we have to guarantee an order. |
| 15:37 |
Dyrcona |
I know that. I'm being rhetorical, sort of... :) |
| 15:37 |
bshum |
So... branch needed to rename the tests in a proper order? :D |
| 15:37 |
Dyrcona |
Guess someone (me) should open a LP bug to renumber them. |
| 15:38 |
berick |
Dyrcona: ah, i'm being too literal |
| 15:38 |
Dyrcona |
Or, bshum can open it. That works for me. :) |
| 15:41 |
Dyrcona |
Anyway, Evergreen now runs on Debian 9. bshum++ |
| 15:41 |
berick |
woot |
| 15:42 |
Dyrcona |
I should make sure the lib naming changes don't break anywhere else, but it shouldn't. |
| 15:42 |
bshum |
Yeah I'll test the new commit too for Debian 9 but also apply it on my next Ubuntu 16 test build just in case |
| 15:42 |
bshum |
Dyrcona++ |
| 15:43 |
bshum |
Maybe those changes will help get it working for Fedora again, hehe :) |
| 15:43 |
Dyrcona |
Shouldn't hurt. |
| 15:43 |
Dyrcona |
It's always better not to fight the tools. |
| 15:43 |
roycroft |
hello, folks |
| 16:06 |
Dyrcona |
roycroft: You'll need to convert the CSV to MARC. |
| 16:06 |
roycroft |
there's a library system that covers most of eastern oregon (i'm in western oregon) who use evergreen, and folks seem to think it's a really nice package, which is what got me looking at it in the first place |
| 16:06 |
roycroft |
so csv to incomplete marc, and then evergreen can get the full marc records? |
| 16:06 |
Dyrcona |
Also, if you want to test on stretch use the branches on the bug I referenced earlier. |
| 16:07 |
roycroft |
ok, i'll do that |
| 16:07 |
gmcharlt |
yeah, Evergreen doesn't have a direct script to batch-import records from a Z39.50 source, but here's another tool that can do it: http://marcedit.reeset.net/batch-marc-record-retrieval-using-z39-50 |
| 16:07 |
Dyrcona |
They're basically the beta for 3.0. |
| 16:32 |
Dyrcona |
Mr. Kent seems much happier, now. |
| 16:36 |
miker |
Dyrcona: confirmed, yes it's fine |
| 16:37 |
Dyrcona |
miker: Thanks. That's what I thought and what it looks like from here. ;) |
| 16:38 |
* Dyrcona |
actually makes a note to that when updating the data for the training and testing servers.....Typing it in will help me remember. |
| 16:39 |
* Dyrcona |
imagines 62 zombie Supermen running around Gotham or whatever city Superman supposedly lives in. |
| 16:41 |
gmcharlt |
clark-kent.pl ought to change its process name to 'Bizarro' just before terminating |
| 16:55 |
Dyrcona |
I noticed that Clark still doesn't daemonize properly. It writes messages to the console, still. |
| 16:56 |
* Dyrcona |
search for a LP bug on that. |
| 17:02 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:03 |
kmlussier |
abneiman: The silent failure bug you just filed, is that the import marc permission or the create or update marc permission? |
| 17:04 |
* kmlussier |
is wondering if it's the same as bug 1693580 or something different. |
| 17:04 |
pinesol_green |
Launchpad bug 1693580 in Evergreen "web client: attempting to update a MARC record without required permissions fails without feedback to the user" [Undecided,New] https://launchpad.net/bugs/1693580 |
| 19:48 |
|
_adb1 joined #evergreen |
| 19:48 |
|
pastebot0 joined #evergreen |
| 19:54 |
|
berick joined #evergreen |
| 20:37 |
bshum |
berick: I added a couple tweaks for the ansible installer here: http://git.evergreen-ils.org/?p=working/random.git;a=shortlog;h=refs/heads/collab/bshum/ansible-installer-ubuntu-16.04 |
| 20:37 |
bshum |
berick: It changes the ejabberd config back to default max_stanza_size and adds the rpaf apache module install for nginx |
| 20:38 |
bshum |
I used it to test a clean installation using the Debian9 changes from Dyrcona for libaries. Looks like everything works with the changes. |
| 21:12 |
|
jvwoolf joined #evergreen |
| 21:22 |
|
jvwoolf joined #evergreen |
| 21:31 |
|
jvwoolf left #evergreen |
| 05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:26 |
|
barbara joined #evergreen |
| 06:33 |
|
barbara_ joined #evergreen |
| 13:31 |
|
Dyrcona joined #evergreen |
| 13:53 |
Dyrcona |
@monologue |
| 13:53 |
pinesol_green |
Dyrcona: Your current monologue is at least 21 lines long. |
| 14:05 |
Dyrcona |
Well, my search for keyword mozart is still broken. |
| 14:15 |
Dyrcona |
So, a 2 core vm with 4GB of RAM is no longer enough to test Evergreen....Just my opinion based on today's frustrations. |
| 14:19 |
bshum |
Hmmm, crazy |
| 14:21 |
Dyrcona |
I keyword search for mozart and get a cstore time out in the logs. |
| 14:21 |
Dyrcona |
harry potter on the other hand comes back almost instantly with the 1 record. |
| 14:26 |
Dyrcona |
I'm working on code to place multiple holds for a single title. |
| 14:26 |
Dyrcona |
Everything works so far except for actually placing the multiple holds. It's still only placing 1. |
| 14:27 |
Dyrcona |
oops. last two lines are in the wrong tab, but it's no secret what I'm working on. :) |
| 14:32 |
Dyrcona |
The tests work, so the backend changes are "correct." I'm stuck on getting the places hold logic in EGCatloader to pass the message correctly. |
| 16:05 |
Dyrcona |
Well, search is still messed up on my vm, even after a fresh db reload and the git clean -xfd and a rebuild. |
| 16:06 |
Dyrcona |
I've tried mozart and brahms and they don't return anything with an occasional Internal server error from a cstore timeout. |
| 16:06 |
Dyrcona |
harry potter with just 1 record comes right back, though. |
| 16:06 |
Dyrcona |
Guess I'll blow this vm out, too. :( |
| 16:07 |
Dyrcona |
I did figure out my issue with placing multiple holds. I've got more work to do, and I may possibly rearrange the code that I've written. |
| 17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 19:45 |
pinesol_green |
[evergreen|Jillianne Presley] Docs reorg: adding acquisitions manual - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a1c75a7> |
| 20:32 |
|
Jillianne joined #evergreen |
| 21:37 |
|
Badman240 joined #evergreen |
| 21:38 |
Badman240 |
Hey guys, I'm really new to ILS software and was planning to use it for a library of about ~1000 books for my sunday school |
