| 00:25 |
|
beanjammin joined #evergreen |
| 05:00 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-01-29T04:58:02,473540238-0500 -0> |
| 05:16 |
|
beanjammin joined #evergreen |
| 07:01 |
|
agoben joined #evergreen |
| 07:09 |
|
rjackson_isl joined #evergreen |
| 10:24 |
JBoyer |
I don't have a good feel for how much they're used, but I think the reason they're not enabled by default is (potential?) user confusion. The users that know what they are and are for like them a lot. |
| 10:25 |
JBoyer |
(Also, until very recently we didn't have a good way to distinguish DVD/BR and that would cause some unhappyness. And MR holds don't mesh with parts to my knowledge, so...) |
| 10:29 |
|
Dyrcona joined #evergreen |
| 10:30 |
phasefx_ |
I think this might be a heisenbug: http://testing.evergreen-ils.org/~live/test.42.html#2019-01-29T04:58:02,473540238-0500 |
| 10:32 |
JBoyer |
Dyrcona, I think the perl EDI pusher might help in that situation (since it doesn't bother with AT at all) but if it's not happening enough to warrant the switch that may not be much help. |
| 10:33 |
berick |
JBoyer: was going to say the same... |
| 10:33 |
Dyrcona |
JBoyer: Thanks. I have not looked into it that deeply, yet. As you said, it happens may be once/month, but sometimes twice in two weeks. |
| 10:34 |
berick |
*things like newlines |
| 10:39 |
|
nfBurton joined #evergreen |
| 11:09 |
JBoyer |
phasefx_, kind of a surprising one though. I'm not sure how that could change from one run to the next? |
| 11:11 |
phasefx_ |
JBoyer: not sure, but I saw it one my test system a lot when I was working on the QA scripts, but then it didn't happen on the one we use for the website, so I stopped worrying about it, until it reappeared today |
| 11:16 |
Dyrcona |
I've had tests sometimes fail, though it seems to b related to the order of running PgTAP and Perl tests, though not always reproducible. |
| 11:17 |
Dyrcona |
phasefx_: Guess we jumped the gun on Lp 1794588. We look forward to the revised branch later this week! |
| 11:17 |
pinesol |
Launchpad bug 1794588 in Evergreen 3.2 "Web client edit single call number changes all when multiple items attached" [Undecided,Confirmed] https://launchpad.net/bugs/1794588 |
| 11:17 |
|
beanjammin joined #evergreen |
| 16:15 |
miker |
abowling: for push, or even for pull? (assuming git@ repo syntax) |
| 16:15 |
miker |
(and, I'm assuming, for the working repo?) |
| 16:48 |
jeffdavis |
Does anyone around here have access to the NCIP v1 spec? I haven't been able to dig up a copy (best I can find is a DTD). |
| 17:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:10 |
|
mmorgan left #evergreen |
| 17:26 |
|
beanjammin joined #evergreen |
| 17:37 |
|
jvwoolf left #evergreen |
| 00:23 |
|
beanjammin joined #evergreen |
| 05:01 |
pinesol |
News from qatests: Failed Installing OpenSRF pre-requisites <http://testing.evergreen-ils.org/~live/test.7.html#2019-01-27T04:36:36,134655585-0500 -0> |
| 05:01 |
pinesol |
News from qatests: Failed Building OpenSRF <http://testing.evergreen-ils.org/~live/test.9.html#2019-01-27T04:36:36,145320458-0500 -2> |
| 05:01 |
pinesol |
News from qatests: Failed Running OpenSRF build tests <http://testing.evergreen-ils.org/~live/test.10.html#2019-01-27T04:36:36,155872803-0500 -4> |
| 05:01 |
pinesol |
News from qatests: Failed creating opensrf user and environment <http://testing.evergreen-ils.org/~live/test.12.html#2019-01-27T04:36:36,166398512-0500 -6> |
| 05:01 |
pinesol |
News from qatests: Failed configuring ejabberd <http://testing.evergreen-ils.org/~live/test.15.html#2019-01-27T04:36:36,176977598-0500 -8> |
| 05:01 |
pinesol |
News from qatests: Failed creating jabber users <http://testing.evergreen-ils.org/~live/test.16.html#2019-01-27T04:36:36,187453946-0500 -10> |
| 05:01 |
pinesol |
News from qatests: Failed configuring OpenSRF <http://testing.evergreen-ils.org/~live/test.17.html#2019-01-27T04:36:36,197942981-0500 -12> |
| 05:01 |
pinesol |
News from qatests: Failed start opensrf <http://testing.evergreen-ils.org/~live/test.18.html#2019-01-27T04:36:36,208465643-0500 -14> |
| 05:01 |
pinesol |
News from qatests: Failed stop opensrf <http://testing.evergreen-ils.org/~live/test.19.html#2019-01-27T04:36:36,219023235-0500 -16> |
| 05:01 |
pinesol |
News from qatests: Failed start opensrf <http://testing.evergreen-ils.org/~live/test.20.html#2019-01-27T04:36:36,229543507-0500 -18> |
| 05:01 |
pinesol |
News from qatests: Failed test opensrf <http://testing.evergreen-ils.org/~live/test.21.html#2019-01-27T04:36:36,240078227-0500 -20> |
| 05:01 |
pinesol |
News from qatests: Failed configuring websockets <http://testing.evergreen-ils.org/~live/test.22.html#2019-01-27T04:36:36,250624553-0500 -22> |
| 05:01 |
pinesol |
News from qatests: Failed stop opensrf <http://testing.evergreen-ils.org/~live/test.23.html#2019-01-27T04:36:36,261252502-0500 -24> |
| 05:01 |
pinesol |
News from qatests: Failed Installing Evergreen pre-requisites <http://testing.evergreen-ils.org/~live/test.26.html#2019-01-27T04:36:36,271800743-0500 -26> |
| 05:01 |
pinesol |
News from qatests: Failed Installing Angular web client <http://testing.evergreen-ils.org/~live/test.29.html#2019-01-27T04:36:36,282350977-0500 -28> |
| 05:01 |
pinesol |
News from qatests: Failed Building Evergreen <http://testing.evergreen-ils.org/~live/test.30.html#2019-01-27T04:36:36,292921177-0500 -30> |
| 05:01 |
pinesol |
News from qatests: Failed Running Evergreen tests <http://testing.evergreen-ils.org/~live/test.31.html#2019-01-27T04:36:36,303413681-0500 -32> |
| 05:01 |
pinesol |
News from qatests: Failed Installing Evergreen <http://testing.evergreen-ils.org/~live/test.32.html#2019-01-27T04:36:36,313932658-0500 -34> |
| 05:01 |
pinesol |
News from qatests: Failed Change File Ownership <http://testing.evergreen-ils.org/~live/test.33.html#2019-01-27T04:36:36,324429797-0500 -36> |
| 05:01 |
pinesol |
News from qatests: Failed Installing Dojo <http://testing.evergreen-ils.org/~live/test.35.html#2019-01-27T04:36:36,335032928-0500 -38> |
| 05:01 |
pinesol |
News from qatests: Failed configure apache <http://testing.evergreen-ils.org/~live/test.36.html#2019-01-27T04:36:36,345534813-0500 -40> |
| 05:01 |
pinesol |
News from qatests: Failed configure EG OpenSRF <http://testing.evergreen-ils.org/~live/test.37.html#2019-01-27T04:36:36,356033586-0500 -42> |
| 05:01 |
pinesol |
News from qatests: Failed configure EG Action/Trigger <http://testing.evergreen-ils.org/~live/test.38.html#2019-01-27T04:36:36,366494806-0500 -44> |
| 05:01 |
pinesol |
News from qatests: Failed Create Evergreen Database <http://testing.evergreen-ils.org/~live/test.41.html#2019-01-27T04:36:36,378341674-0500 -46> |
| 05:01 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-01-27T04:36:36,389221388-0500 -48> |
| 05:01 |
pinesol |
News from qatests: Failed start opensrf <http://testing.evergreen-ils.org/~live/test.43.html#2019-01-27T04:36:36,399678885-0500 -50> |
| 05:01 |
pinesol |
News from qatests: Failed Running autogen.sh <http://testing.evergreen-ils.org/~live/test.44.html#2019-01-27T04:36:36,410167249-0500 -52> |
| 05:01 |
pinesol |
News from qatests: Failed Restarting Apache <http://testing.evergreen-ils.org/~live/test.45.html#2019-01-27T04:36:36,420721842-0500 -54> |
| 05:01 |
pinesol |
News from qatests: Failed test EG opensrf <http://testing.evergreen-ils.org/~live/test.46.html#2019-01-27T04:36:36,431285564-0500 -56> |
| 05:01 |
pinesol |
News from qatests: Failed Running pgTAP live tests <http://testing.evergreen-ils.org/~live/test.47.html#2019-01-27T04:36:36,441802938-0500 -58> |
| 05:01 |
pinesol |
News from qatests: Failed Running settings-tester.pl <http://testing.evergreen-ils.org/~live/test.48.html#2019-01-27T04:36:36,452316792-0500 -60> |
| 05:01 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live/test.49.html#2019-01-27T04:36:36,462866936-0500 -62> |
| 05:01 |
pinesol |
News from qatests: Failed Gathering log summary <http://testing.evergreen-ils.org/~live/test.50.html#2019-01-27T04:36:36,473368748-0500 -64> |
| 05:01 |
pinesol |
News from qatests: Failed Log Output: config.log <http://testing.evergreen-ils.org/~live/test.51.html#2019-01-27T04:36:36,483854091-0500 -66> |
| 07:26 |
|
sandbergja joined #evergreen |
| 08:04 |
|
sandbergja joined #evergreen |
| 11:35 |
|
sandbergja joined #evergreen |
| 13:25 |
|
beanjammin joined #evergreen |
| 15:39 |
|
beanjammin joined #evergreen |
| 17:00 |
pinesol |
News from qatests: Failed Restarting Apache <http://testing.evergreen-ils.org/~live/test.45.html#2019-01-27T16:52:05,243690778-0500 -0> |
| 17:15 |
|
sandbergja joined #evergreen |
| 04:31 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:07 |
|
rjackson_isl joined #evergreen |
| 07:09 |
|
bdljohn joined #evergreen |
| 07:39 |
|
tlittle joined #evergreen |
| 15:13 |
jeff |
oh, and... |
| 15:13 |
jvwoolf |
Thank you, I would not have thought to look in the actor schema! |
| 15:13 |
jeff |
it's actor.search_filter_group, actor.search_filter_group_entry, and actor.search_query |
| 15:16 |
Dyrcona |
So, I'm seeing ingest being a lot slower on 3.2 than on a 3.0 database. I'm going to redo my "tests" next week and get some actual timings. Just thought I'd throw that out there. |
| 15:16 |
jeff |
also, if you're working with search filter groups that rely on "non-dynamic" filters like locations(), be aware of bug 1808055 |
| 15:17 |
pinesol |
Launchpad bug 1808055 in Evergreen "Search queries containing a filter in a subquery/group may drop the filter" [Undecided,New] https://launchpad.net/bugs/1808055 - Assigned to Mike Rylander (mrylander) |
| 15:20 |
miker |
Dyrcona: well, there are about 2x cmf's now, for display fields... |
| 15:21 |
Dyrcona |
I'm skipping the display fields in this test. I'm testing my branch for bug 1813172 by just doing a record attribute reingest. |
| 15:21 |
pinesol |
Launchpad bug 1813172 in Evergreen "Add option to specify metabib record attributes for reingest to pingest.pl" [Wishlist,New] https://launchpad.net/bugs/1813172 |
| 15:22 |
Dyrcona |
But, yeah, more fields makes a difference. |
| 15:41 |
jvwoolf |
jeff: Thanks for pointing out that bug. I think that may be our problem. We are relying on shelving location searches in our kidcat. |
| 15:48 |
jvwoolf |
jeff: Are you doing any workarounds in your catalog at this point? |
| 15:48 |
jeff |
jvwoolf: that is currenty broken. miker proposed a fix, but it didn't seem to work in our environment. i have not had/made time to investigate further. |
| 15:49 |
jeff |
jvwoolf: in the one place where we were using locations() in search filter groups, we expanded to use audience and added some additional item types, but it's an imperfect solution. i'd like to revisit or get additional eyes on the bug. |
| 15:49 |
miker |
I haven't had time to dig in either ... it seemed to work in my mock testing, but I'll have to look more |
| 15:50 |
jeff |
jvwoolf: sounds like you're the second person to hit it, though -- you could mark the bug Confirmed. :-) |
| 15:51 |
jeff |
and feel free to test the fix, if you're able and willing -- it's possible that my testing was flawed. |
| 15:51 |
jvwoolf |
For sure. Thanks, jeff |
| 15:51 |
miker |
+1 |
| 15:52 |
jeff |
jvwoolf++ miker++ |
| 15:52 |
jvwoolf |
jeff++ miker++ |
| 16:20 |
|
yboston joined #evergreen |
| 16:31 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:02 |
|
mmorgan left #evergreen |
| 17:09 |
|
jvwoolf left #evergreen |
| 17:35 |
|
bos20k joined #evergreen |
| 00:34 |
|
bshum joined #evergreen |
| 04:31 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:02 |
|
agoben joined #evergreen |
| 08:03 |
miker |
mmorgan: re deleting users in batch from a bucket, that behavior is intended and documented (in the specs, at least). it's to allow rolling back a batch action, and to provide a level of accident protection. |
| 08:04 |
miker |
also Bmagic -^ |
| 13:23 |
Dyrcona |
Hmm. Apparently not... |
| 13:24 |
Dyrcona |
At least not what I suspected. Seems normal. |
| 13:32 |
csharp |
we haven't noticed any trouble since upgrading to 3.2 over the weekend |
| 13:33 |
Dyrcona |
Yeah. I'm going to try doing Lp 1813172 and testing that on a db upgraded from 3.0 to 3.2. |
| 13:33 |
pinesol |
Launchpad bug 1813172 in Evergreen "Add option to specify metabib record attributes for reingest to pingest.pl" [Wishlist,New] https://launchpad.net/bugs/1813172 - Assigned to Jason Stephenson (jstephenson) |
| 13:42 |
|
yboston joined #evergreen |
| 13:49 |
eby |
question if there is anyone that knows offhand. I think i'm not getting my keywords right. From the code and documentation it seems that shelf hold expire dates are moved ahead if they fall on a closed date but not if there is a closed date between the dates, at least in our experience. |
| 14:17 |
Dyrcona |
Something in the logs that eby shared is highly relevant to something that I've been thinking about lately. |
| 14:17 |
eby |
2013 must have been a good thought year |
| 14:20 |
Dyrcona |
Next gen. and the future and all of that. :) |
| 14:23 |
Dyrcona |
Hmm.. Back to that potential bug in metabib.reingest_record_attributes....My test run of just doing that on a 3.0 database with pingest.pl has already processed the first 8 batches. On a 3.2 database, it still hasn't finished the first batch. I started the latter first. |
| 14:26 |
Dyrcona |
I wonder if specifying the pattr_list attribute can really slow things down. That bears looking into. |
| 14:32 |
Dyrcona |
It's now up to 12 batches done on the 3.0 database... |
| 14:33 |
Dyrcona |
Could just be the luck of the draw, but the 3.2 database has now finished 5 batches. |
| 16:13 |
jeff |
Dyrcona++ sandbergja++ csharp++ berick++ |
| 16:16 |
|
Dyrcona joined #evergreen |
| 16:21 |
|
seymour joined #evergreen |
| 16:31 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:18 |
|
mmorgan left #evergreen |
| 17:32 |
|
jvwoolf left #evergreen |
| 17:34 |
|
yboston joined #evergreen |
| 04:31 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:16 |
|
rjackson_isl joined #evergreen |
| 07:27 |
|
bdljohn joined #evergreen |
| 07:53 |
|
agoben joined #evergreen |
| 09:51 |
stephengwills |
for the record: just found this from Dan Wells: https://bugs.launchpad.net/evergreen/+bug/1053397 in 2014. some kind of memory error. |
| 09:51 |
pinesol |
Launchpad bug 1053397 in Evergreen "TPAC - Missing Meta-record Level Hold" [Wishlist,Fix released] |
| 10:06 |
|
jvwoolf1 joined #evergreen |
| 10:06 |
stephengwills |
yup…seg fault on 8G test server. will increase RAM and try again. |
| 10:12 |
miker |
csharp: re your log from last night, the cstore backends are timing out waiting for a request, which means that storage (the inner-most search stuff) is doing something for longer than 6 seconds ... cstore itself isn't timing out. it could very well be the container filter code... is that a big container? |
| 10:19 |
miker |
hrm... looking at the code, I don't like that theory anymore :( |
| 11:14 |
|
collum joined #evergreen |
| 12:03 |
pinesol |
[evergreen|Bill Erickson] LP#1808268 eg2 grid rename action disable option - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9776fd8> |
| 12:09 |
|
jihpringle joined #evergreen |
| 12:13 |
pinesol |
[evergreen|Bill Erickson] LP1808268 eg2 grid action disableOnRows sanity check - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=795c2f3> |
| 12:21 |
csharp |
miker: here's another example of something where cstore stops waiting: https://pastebin.com/2U201g0c |
| 12:22 |
csharp |
my next step is to kick up the loglevel on our test server to see what it shows, but I'm consumed with personal stuff today, so it will need to be later |
| 12:24 |
csharp |
stephengwills: make sure to rule out bug 1764542 |
| 12:24 |
pinesol |
Launchpad bug 1764542 in Evergreen "Incorrect format on config.metabib_field insert results in segmentation fault" [High,Fix released] https://launchpad.net/bugs/1764542 |
| 12:24 |
* csharp |
disappears again |
| 12:37 |
|
yboston joined #evergreen |
| 15:32 |
miker |
Stompro: just make sure your index normalizer has a position > 0 so that it doesn't change the displayed values |
| 15:33 |
miker |
if you go that route |
| 15:34 |
Stompro |
miker, are you a mind reader, i was just looking at that field. |
| 15:42 |
Stompro |
Hmm, i tried just simply substituting & for and in the normalizer, and that seems like it does it in my quick testing. Miker, is there a reason I need to map & to _and_ vs just to 'and'; |
| 15:43 |
Dyrcona |
tsqueries, maybe? |
| 15:43 |
Dyrcona |
but, maybe not. |
| 15:45 |
Stompro |
we already have a synonym for and -> &, so with that change both & and 'and" exist in the series_field_entry index_vector, but the series_field_entry value does now have and vs &. |
| 15:47 |
miker |
Stompro: no reason, really. does searching for & also work then? |
| 15:52 |
Stompro |
miker, it seems like it does, but it could just be filtering out the &, the results with or without the & included seem to work. It does change the relevance ranking for the couple that I've reindexed since making the change. |
| 15:52 |
|
yboston joined #evergreen |
| 15:56 |
Stompro |
When I remove the "&" in the series from one of the items I'm testing, that title still comes up for a search with or without '&' included, but not when 'and' is used. So I think the & is being ignored. |
| 15:57 |
Stompro |
Which is fine, I just want the 'and' searches to work. |
| 16:08 |
|
jamesrf joined #evergreen |
| 16:31 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 16:36 |
Stompro |
miker, hmm, searches with quotes around them, exact match, won't work with this method... |
| 16:38 |
Stompro |
The advanced search, exact match option does still work though. |
| 16:45 |
Bmagic |
Did I see a bug (can't find it now) that said that deleting patron using user buckets does NOT remove the patron data? |
| 04:31 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:51 |
|
agoben joined #evergreen |
| 06:55 |
|
JBoyer joined #evergreen |
| 07:07 |
|
rjackson_isl joined #evergreen |
| 10:01 |
|
Christineb joined #evergreen |
| 10:03 |
|
mmorgan1 joined #evergreen |
| 10:18 |
|
nfBurton joined #evergreen |
| 10:43 |
remingtron |
berick or others: do you have instructions on the minimum steps to test a new angular branch? |
| 10:44 |
remingtron |
I'm testing bug 1749475 and don't want to do the full install process |
| 10:44 |
berick |
remingtron: in the eg2 dir: npm run test |
| 10:44 |
pinesol |
Launchpad bug 1749475 in Evergreen "wishlist: Improved email and printing from the OPAC" [Wishlist,New] https://launchpad.net/bugs/1749475 |
| 10:45 |
remingtron |
sorry, I meant "install" the code into it's production location, not "run the tests" |
| 10:45 |
berick |
ah |
| 10:45 |
berick |
before 'make install', inside the eg2 directory: ng build --prod |
| 10:47 |
remingtron |
cool. Does configure or make do anything with the eg2 bits? |
| 12:20 |
pinesol |
[evergreen|Cesar Velez] LP#1727345 - fix bibsource when importing or overlaying - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=014b62e> |
| 12:21 |
rsulejmani |
berick: ok |
| 12:21 |
rsulejmani |
I just did the psql with -h host and it returned that the database evergreen does not exist |
| 12:22 |
berick |
rsulejmani: also, FWIW, I always install with -e use_pg_96=true. it should work either way, but I never install 9.5 so it gets less testing (though I think bshum uses 9.5) |
| 12:22 |
rsulejmani |
berick: ok will do the same thanks |
| 12:22 |
Dyrcona |
I use Pg 9.5 but don't use the ansible installer. |
| 12:23 |
Dyrcona |
rsulejmani: It sounds like the database creation step failed. I can help you with that manually if it fails the second time. I'm sure berick and others can help, too. ;) |
| 13:49 |
pinesol |
berick: Must be because I had the flu for Christmas. |
| 13:49 |
berick |
makes sense pinesol |
| 13:49 |
berick |
oh, now it's back |
| 13:52 |
csharp |
our lists (bookbags) are broken, resulting in an Internal Server Error page and I'm stumped about how to trace it |
| 13:53 |
csharp |
I can see the call in the osrfsys log, but nothing directly corresponds to that threadtrace in the error log |
| 13:54 |
csharp |
2019-01-22 13:53:56 brick04-head osrf_json_gw: [perl:error] [pid 31416] [client 127.0.0.1:50480] egweb: Context Loader error: Exception: OpenSRF::DomainObject::oilsMethodException 2019-01-22T13:53:56 OpenILS::WWW::EGWeb /usr/local/share/perl/5.22.1/OpenILS/WWW/EGWeb.pm:185 <500> No active transaction to roll back\n, referer: https://gapines.org/eg/opac/myopac/lists |
| 13:55 |
|
rsulejmani joined #evergreen |
| 13:56 |
csharp |
that's within the run_context_loader subroutine, and I'm not sure what that does |
| 13:58 |
|
khuckins joined #evergreen |
| 14:07 |
|
khuckins joined #evergreen |
| 14:12 |
csharp |
crazy thing is, test server running the same code is working fine |
| 14:15 |
Dyrcona |
csharp: What that code does is look up a Perl module in the directory or other config, use the module, then call it's load method. If that throws an error, it reports it. So, it looks like your context load module is failing. |
| 14:16 |
Dyrcona |
That looks like it would be EGCatLoader. |
| 14:17 |
Dyrcona |
The tricky part, now, is figuring what part of EGCatLoader. |
| 16:20 |
yboston |
If I only wanted subfield $a, then I could again just use the metabib.full_rec view, |
| 16:20 |
yboston |
but I end up with the correct 650 subfield $a for a particular bib, but if there are other subfields like $y in that same bib but for another 650 tag, then $y is incorrectly showing up with all the $a's |
| 16:22 |
pastebot |
"yboston" at 64.57.241.14 pasted "SQL to try to pull subjects from certain bibs" (60 lines) at http://paste.evergreen-ils.org/14388 |
| 16:31 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 16:31 |
rsulejmani |
berick: I'm testing something in the source code of the evergreen system and I was wondering since I updated and saved something how do I refresh the system so the changes can show |
| 16:32 |
yboston |
I am wondering if there is another view or table I should try to use to get the correct subject data, since I can trust the list of bibs I have. Alternatively, I can export all those bibs a use a MARC programming library to go through all the bibs and then output the 6xx fields |
| 16:40 |
berick |
rsulejmani: depends a lot on what you are changing |
| 16:41 |
berick |
you can always copy your files into place then restart the whole system, but there are usually much faster ways |
| 01:12 |
|
bdljohn joined #evergreen |
| 04:30 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:29 |
|
yar_ joined #evergreen |
| 07:01 |
|
agoben joined #evergreen |
| 07:08 |
|
rjackson_isl joined #evergreen |
| 08:36 |
JBoyer |
and finally records: delete from biblio.record_entry where id > 0; |
| 08:37 |
JBoyer |
(Normally you would want to use database transactions when using things like insert, update, or delete, but if you're trying to delete everything anyway it's not such a big deal.) |
| 08:37 |
JBoyer |
does that help? |
| 08:38 |
RMiller |
Testing it now! |
| 08:39 |
JBoyer |
Since I didn't know where you were comfort-wise I tried to make it easy to follow, hopefully that didn't come across condescending. :) |
| 08:39 |
RMiller |
I'm an English teacher fumbling around. You cannot condescend too low :) |
| 08:42 |
RMiller |
The first two returned "DELETE 0" pretty quickly, and the third one is... still... thinking... Does that sound normal? |
| 12:16 |
mmorgan |
We see log entries like this: 2019-01-18 11:02:24 brick2 open-ils.vandelay: [WARN:22569:Application.pm:624:1547827174572487] open-ils.vandelay.bib.process_spool: no mapping found for [0xCC] at position 5 in GarciÌ<U+0081>a Lorca, Federico,g0=ASCII_DEFAULT g1=EXTENDED_LATIN at /usr/share/perl5/MARC/Charset.pm line 308. |
| 12:16 |
mmorgan |
Anyone else seen something similar? |
| 12:26 |
|
sandbergja joined #evergreen |
| 12:27 |
sandbergja |
Bmagic: Our branch librarian is interested in testing your fix to bug #1741299 |
| 12:27 |
pinesol |
Launchpad bug 1741299 in Evergreen "DYMO LabelWriter 450 Turbo Hatch Label print fails with margin error" [Undecided,Confirmed] https://launchpad.net/bugs/1741299 - Assigned to Blake GH (bmagic) |
| 12:27 |
Bmagic |
great! |
| 12:27 |
sandbergja |
I'm not very familiar with Hatch, though. Would we need to use a test server with that Evergreen branch enabled? |
| 12:28 |
Bmagic |
the changes to Evergreen are very very small |
| 12:28 |
sandbergja |
And would we have to compile Hatch ourselves? And if so, can it co-exist with Hatch installed from the Chrome store? |
| 12:28 |
Bmagic |
you could edit the single tt2 file manually without having to merge the branch, etc |
| 14:03 |
jvwoolf |
JBoyer: Yes! |
| 14:08 |
JBoyer |
Ooh, the low-impact version would be a new view that only pulls things out of acn where label_class = dewey... Now I'm very interested in playing with this. |
| 14:16 |
|
beanjammin joined #evergreen |
| 14:24 |
csharp |
JBoyer++ |
| 14:25 |
csharp |
I'd be happy to work with you on that (or at least test whatever you come up with) after the dust settles from this weekend's upgrade |
| 14:31 |
JBoyer |
csharp++ |
| 14:31 |
JBoyer |
Good luck! We've been enjoying 3.2 so far. :) |
| 14:36 |
csharp |
thanks - all looks good |
| 15:43 |
miker |
mmorgan: that sounds a lot like (and, based on your error paste, looks like) badly encoded records. specifically, marc8 encoded records. is that possible? |
| 15:44 |
|
beanjammin joined #evergreen |
| 15:44 |
miker |
as in, the xml related code thinks its dealing with utf8 data, but it's marc8 |
| 16:30 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 16:34 |
|
yboston joined #evergreen |
| 16:42 |
bshum |
Happy Friday everyone, and good luck to all the upgrading Evergreeners this weekend :) |
| 16:42 |
bshum |
I'll be excited to see your shiny upgraded catalogs on Tuesday :) |
| 04:30 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:00 |
|
agoben joined #evergreen |
| 07:07 |
|
rjackson_isl joined #evergreen |
| 07:39 |
|
bdljohn joined #evergreen |
| 11:50 |
|
sandbergja joined #evergreen |
| 11:58 |
|
khuckins joined #evergreen |
| 12:07 |
|
jihpringle joined #evergreen |
| 12:13 |
JBoyer |
gmcharlt, depending on how far you've made it looking into bug 1805856 you might want to load the branch I referenced in the latest comment before testing further. |
| 12:13 |
pinesol |
Launchpad bug 1805856 in Evergreen "WebClient: would like certain results to open in a new tab" [High,Confirmed] https://launchpad.net/bugs/1805856 - Assigned to Galen Charlton (gmc) |
| 12:14 |
gmcharlt |
JBoyer: thanks for the heads-up |
| 12:15 |
sandbergja |
JBoyer: thanks for the testing and correction! |
| 12:15 |
sandbergja |
JBoyer++ |
| 12:15 |
JBoyer |
sandbergja++ |
| 12:15 |
JBoyer |
Thanks for putting it out there to test! |
| 12:23 |
mmorgan |
Just mentioning I added my signoff branch to bug 1806709 |
| 12:23 |
pinesol |
Launchpad bug 1806709 in Evergreen 3.2 "Add Billing History grid persist-key to server-side db settings" [High,Confirmed] https://launchpad.net/bugs/1806709 |
| 12:29 |
|
Christineb joined #evergreen |
| 13:58 |
csharp |
in this case I changed a digit of day phone and clicked Save |
| 13:58 |
Dyrcona |
Were you trying to change the usrname? |
| 13:58 |
csharp |
no |
| 13:58 |
berick |
if anyone wants to test/merge: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/patron-create-load-js-errors |
| 13:59 |
berick |
hm, no trouble saving modified patrons here |
| 13:59 |
berick |
in master |
| 14:00 |
csharp |
berick++ # your fix stopped the console errors - thanks |
| 14:02 |
Dyrcona |
csharp: Somehow, you're ending up in the code to create a new patron. |
| 14:02 |
JBoyer |
I was about to be confused as to how that usrname check could possibly work, but then I noticed that it's in _add_patron... So something about an isnew check (maybe not the ones berick fixed?) seems to be failing somewhere. |
| 16:30 |
Bmagic |
sheesh |
| 16:30 |
Bmagic |
it works as ejabberd |
| 16:30 |
bshum |
Well "sudo" doesn't come with Debian right? |
| 16:30 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 16:30 |
bshum |
You'd have to add sudo as a package prereq or something for the blind followers :) |
| 16:31 |
Dyrcona |
Um, I get sudo by default. |
| 16:31 |
bshum |
Maybe it's an old Debian problem |
| 01:25 |
|
beanjammin joined #evergreen |
| 04:30 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:56 |
|
agoben joined #evergreen |
| 07:11 |
|
rjackson_isl joined #evergreen |
| 07:49 |
|
bdljohn joined #evergreen |
| 12:25 |
|
yboston joined #evergreen |
| 13:01 |
|
bdljohn joined #evergreen |
| 13:08 |
|
khuckins joined #evergreen |
| 13:45 |
gmcharlt |
has anybody had an opportunity to test the OpenSRF 3.1 beta? |
| 14:01 |
Dyrcona |
No, but I've been using OpenSRF master for a while. |
| 14:02 |
Dyrcona |
including updating my VMs this week for some light weight work testing things for my conference presentation. |
| 14:09 |
JBoyer |
I was going to say no but upon actually bothering to look, I've been running master in production for a while now. Haven't given proper attention to any specific features beyond websocketd support though. |
| 14:15 |
|
yboston joined #evergreen |
| 14:30 |
|
khuckins_ joined #evergreen |
| 14:58 |
* berick |
thinks the answer is probably yet |
| 14:58 |
berick |
er, yes |
| 15:01 |
pinesol |
[evergreen|Cesar Velez] LP#1737800 - add delete action to pending patrons - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5d52073> |
| 15:03 |
phasefx |
gmcharlt: fwiw, 3.1 beta passed qa tests and my smoketest with a dev system |
| 15:26 |
Dyrcona |
I'll push bug 1801998 in the interest of getting it in before tomorrow's releases, if they're still on. Last that I heard they were, but haven't heard anything since last week. |
| 15:26 |
pinesol |
Launchpad bug 1801998 in Evergreen 3.2 "Deprecate Hatch storage for 3.2" [Medium,Confirmed] https://launchpad.net/bugs/1801998 |
| 15:29 |
pinesol |
[evergreen|Bill Erickson] LP#1801998 Deprecate Hatch for data storage - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ec3ce4b> |
| 15:33 |
Dyrcona |
It would be good if someone looked at bug 1803734 before tomorrow. |
| 15:33 |
pinesol |
Launchpad bug 1803734 in Evergreen 3.2 "edi_order_pusher.pl blindly pushes ancient orders" [Critical,Confirmed] https://launchpad.net/bugs/1803734 |
| 15:34 |
Dyrcona |
And bug 1806709 |
| 15:34 |
pinesol |
Launchpad bug 1806709 in Evergreen 3.2 "Add Billing History grid persist-key to server-side db settings" [High,Confirmed] https://launchpad.net/bugs/1806709 |
| 15:58 |
|
jvwoolf1 joined #evergreen |
| 16:06 |
|
khuckins__ joined #evergreen |
| 16:30 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 16:38 |
|
hbrennan joined #evergreen |
| 16:44 |
hbrennan |
bshum: FYI autogen didn't solve the "unclickable item barcode" issue :( |
| 16:44 |
hbrennan |
but diving in deep, there's a xul reference in there |
| 17:04 |
bshum |
Speaking from my own opinion, fixing webby issues in previous releases is a pain :) |
| 17:04 |
bshum |
Fixing them in current ones isn't much better either. |
| 17:05 |
bshum |
If it's not broken for others on 3.1 or 3.2, it's community-advisable to just say "plan your next upgrade" |
| 17:05 |
hbrennan |
We're building a test of 3.1.something this week |
| 17:05 |
hbrennan |
It's not even broken on 3.0.9, the closest I could survey |
| 17:06 |
hbrennan |
Literally no one has this issue, which is why I went in the direction that it must be us |
| 17:06 |
bshum |
Yeah :( |
| 17:06 |
bshum |
I hate it when that happens :) |
| 17:06 |
hbrennan |
Instead, it looks like it must be 3.0.5 |
| 17:07 |
hbrennan |
I'm too excitable. I should probably stop reading release notes. They promise so much fun and new. |
| 17:12 |
bshum |
New is always better. |
| 17:12 |
hbrennan |
Except when it's not. :) |
| 17:12 |
bshum |
When it was up to me, life on the bleeding edge was the only way to go |
| 17:12 |
|
mmorgan left #evergreen |
| 17:12 |
bshum |
But I was more in-tune with the development then |
| 17:12 |
bshum |
So it was easier to know where the mines were going to be |
| 17:13 |
bshum |
I don't get to test as much as I'd like to, now. |
| 17:13 |
hbrennan |
Well thankfully we can still run the xul client. Which is why this has been on my backburner for a while. |
| 17:13 |
hbrennan |
But now I'm leaving my position and need to push up web training |
| 17:13 |
bshum |
It makes me wonder if maybe it's a customization issue |
| 08:44 |
|
mmorgan joined #evergreen |
| 09:13 |
JBoyer |
Dyrcona, If you have a couple minutes for Overdrive API questions I have a couple. (Mostly what needed to be requested for CW/MARS' setup, not low level stuff) |
| 09:14 |
Dyrcona |
JBoyer: Go ahead. |
| 09:15 |
JBoyer |
I was looking at the APIs we have access to (LIB, META, AVAIL, and SRCH) and I have an updated and hand-tested api secret, but no part of the Ebook API displays anything in the logs. Did you request additional APIs or have to do anything special to get things working there? |
| 09:16 |
JBoyer |
(hand-tested as in I can throw the secret at curl and get an oauth bearer token back, I haven't done much else) |
| 09:17 |
Dyrcona |
Yes. Let me check. |
| 09:20 |
Dyrcona |
You need to have Client and Patron authenticaton API access. |
| 09:21 |
Dyrcona |
BTW, where do you see the list of APIs that you have access to? I'm not seeing that in the member center on the developers' site. |
| 12:47 |
Bmagic |
Since it's not officially recognized in LOC, it's the wild west, and you/catalogers can decide how to catalog playaways. Our catalogers decided it needed to have two 007's and some other stuff. Then you define that in the Evergreen ILS, call it playaway. Then create an icon for it with the same name |
| 12:48 |
Bmagic |
the icon/picture file needs to be located in the same folder as the rest of the picture files. The naming convention needs to match the name of the format (but all lowercase) as defined in the ILS |
| 12:49 |
Bmagic |
and finally.. reingest |
| 12:49 |
Bmagic |
you need only reingest a test record for troubleshooting before you go and reingest the whole database |
| 12:53 |
nfburton |
Would I be able to see your tree for the Format Icon? |
| 12:54 |
Bmagic |
yeah, let me see if I can get a screenshot |
| 12:54 |
nfburton |
Thanks |
| 13:12 |
nfburton |
Sounds good thanks |
| 13:18 |
|
yboston joined #evergreen |
| 14:31 |
|
jvwoolf joined #evergreen |
| 14:36 |
csharp |
khuckins_: we were just testing your fix for bug 1777677 and hit a snag - if I'm a non- |
| 14:36 |
pinesol |
Launchpad bug 1777677 in Evergreen "Test notification method" [Wishlist,New] https://launchpad.net/bugs/1777677 |
| 14:37 |
csharp |
"admin" user, I am prompted with a perm override box for OPAC_LOGIN even though my user has that perm at the proper level |
| 14:37 |
csharp |
gonna see if I can get that working, but wanted you to know (I also update the bug report) |
| 14:38 |
csharp |
s/update/updated/ |
| 14:50 |
Bmagic |
nfburton: it looks like the SMD stuff is stock in config.marc21_physical_characteristic_type_map |
| 15:02 |
jeff |
csharp: was the user you were testing as a user with super_user = true set? |
| 15:02 |
csharp |
I think I may have a handle on the problem. It's possible that the "home_ou" attribute is not being dereferenced "enough" (obviously not conversant in Perl to this level) |
| 15:02 |
jeff |
csharp: can you see what arguments were being passed to open-ils.actor.event.test_notification? |
| 15:02 |
csharp |
jeff: the original testers were superusers and that works perfectly |
| 15:03 |
jeff |
and once that's fixed, there's some other permissions-related flaws which would need to be addressed before that's tested and merged. |
| 15:03 |
csharp |
but a non-superuser with OPAC_LOGIN set still doesn't see it |
| 15:03 |
csharp |
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/Application/Actor.pm;h=f8aa7491bf1ff8d097229c484a26201b1a84c1b4;hb=refs/heads/user/khuckins/lp1777677-test-notification-method#l4231 |
| 15:04 |
csharp |
that's the sub it's using and I think $$args{home_ou}) on line 4241 is the problem |
| 15:04 |
jeff |
it's because a user with super_user = true (which should probably be deprecated) gets TRUE returned for permission checks on non-existent org unit contexts. |
| 15:04 |
csharp |
I'm not great at using Data::Dumper, but it comes back as Fieldmapper::actor::org_unit=ARRAY(0x5b40070) |
| 15:05 |
csharp |
ah - makes sense |
| 15:05 |
csharp |
er... |
| 15:05 |
jeff |
oh. |
| 15:06 |
csharp |
not showing the args in the console, no |
| 15:06 |
jeff |
is this in place on a test system i can log into, or would i need to install the branch to get that? |
| 15:06 |
JBoyer |
I would wonder how well it works if that line is just thrown away. I barely remember when a perms check came up for that and the question was basically "What's something that everybody has?" which to me sounds a lot like |
| 15:07 |
JBoyer |
"Maybe we don't need to gate this one" |
| 15:07 |
csharp |
jeff: let me fix the SSL cert on it and I'll let you it (it's a concerto server) |
| 15:13 |
khuckins |
home_ou is passed in for the sake of checking the permission, so if we drop the OPAC_LOGIN check, that should probably be dropped as well |
| 15:14 |
khuckins |
csharp++ jeff++ Drycona++ JBoyer++ |
| 15:14 |
Dyrcona |
khuckins: Any reason for checking for OPAC_LOGIN? |
| 15:15 |
jeff |
Just to be clear, the status of this is that it is not currently included in any released or reployed Evergreen install, other than perhaps a test install with either no live data or no ability for non-trusted individuals to log in? :-) |
| 15:16 |
* Dyrcona |
thinks its on our training server where we may have looked at it, but yeah. :) |
| 15:16 |
khuckins |
Early on on the lp ticket it was suggested to have a permissions check to avoid potential abuse, initially using the UPDATE_USER permission, then brought down to OPAC_LOGIN when realizing users should be using this as well as staff |
| 15:16 |
khuckins |
But in retrospect any user who's going to be able to access that API call would be logged in |
| 15:19 |
Dyrcona |
CStoreEditor->allowed could be made smarter, i.e. to check if it got an object or an int and then derefence the id if got an object. Some other places make similar checks. |
| 15:20 |
jeff |
and if my quick scan of the requirements is correct, you're going to want to checkauth, but then instead of just checking for OPAC_LOGIN or skipping a perm check, you'll want to verify that the user is the same as the target, OR if the user is different from the target, that the user has an appropriate staff permission at the right level. |
| 15:21 |
Dyrcona |
An "appropriate permission"... VIEW_USER perhaps? |
| 15:21 |
jeff |
the trouble with the code as currently written is that it permits any valid logged in user to send test notifications to anyone, just by supplying a value for "target" |
| 15:21 |
jeff |
Dyrcona: originally it was UPDATE_USER |
| 15:21 |
|
aabbee left #evergreen |
| 15:21 |
|
aabbee joined #evergreen |
| 15:22 |
Dyrcona |
Well, that makes sense if the test is done in conjunction with changing the notification method's value. |
| 15:22 |
Dyrcona |
jeff++ |
| 15:23 |
jeff |
Also, it allows a wider than intended array of events to be fired. |
| 15:24 |
jeff |
by passing arbitrary values as event_def_type -- though it looks like it will only pass an (arbitrary!) user object to $U->fire_object_event |
| 09:13 |
|
yboston joined #evergreen |
| 09:33 |
|
aabbee joined #evergreen |
| 09:48 |
|
dkyle1 joined #evergreen |
| 10:01 |
csharp |
miker: I'm looking to put your branch for bug 1749475 on our 3.2.2 test server... |
| 10:02 |
pinesol |
Launchpad bug 1749475 in Evergreen "wishlist: Improved email and printing from the OPAC" [Wishlist,New] https://launchpad.net/bugs/1749475 |
| 10:02 |
csharp |
my concern is the change to the eg2 stuff - will that require a rebuild of the ang6 stuff? |
| 10:02 |
csharp |
git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=f882dae5c875ce11f8cdeff046ddb1928af7c4fd is the commit in question for others possibly interested |
| 13:02 |
bshum |
If it's the latter, I agree with csharp that it doesn't seem any of the merged code seems to touch anything XUL related |
| 13:02 |
mmorgan |
csharp: Hmm. I'll look at that again, looked to my untrained eye like it was in the right places to apply to xul, too. |
| 13:02 |
* mmorgan |
thought it was using the TPAC place hold. |
| 13:02 |
bshum |
The XUL client has two place hold places if I remember right (and I might not, because it's been a few years) |
| 13:09 |
bshum |
Yeah the only place where "circ.staff_placed_holds_fallback_to_ws_ou" gets used is in that eframe.js from webstaff side. |
| 13:09 |
bshum |
I don't see it in the opac js file that was changed too |
| 13:09 |
bshum |
So that means it probably doesn't affect the behavior in TPAC place hold |
| 13:10 |
bshum |
Though now I'm not sure |
| 13:10 |
* bshum |
doesn't have any 3.1 systems to test with :D |
| 13:12 |
Dyrcona |
We reverted the patch that introduced the change in behavior to our XUL client when upgrading to 3.0. I'll see if I can find the commit. |
| 13:12 |
mmorgan |
We've been reverting the changes from bug 1167541 for the past couple releases, by just commenting out the changes to eframe.js and staff.js. But those changes have, well, changed. |
| 13:12 |
pinesol |
Launchpad bug 1167541 in Evergreen 2.11 "Pickup library defaults to Home OU of staff, instead of patron when placing holds" [Medium,Fix released] https://launchpad.net/bugs/1167541 |
| 00:06 |
|
jamesrf joined #evergreen |
| 04:30 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:01 |
|
agoben joined #evergreen |
| 07:06 |
|
rjackson_isl joined #evergreen |
| 07:25 |
|
dbwells_ joined #evergreen |
| 16:12 |
jeffdavis |
matching what's in the INSTALL doc though |
| 16:12 |
bshum |
Well the install doc was written with only 4GB of RAM in mind, for all of Evergreen+PG+Apache2 |
| 16:13 |
jeffdavis |
yeah I should probably experiment with those settings |
| 16:13 |
bshum |
It used to be higher, but then we found that certain test servers were dying due to lack of RAM :) |
| 16:15 |
Dyrcona |
We apparently go with the default from mpm_prefork.conf |
| 16:17 |
|
remingtron joined #evergreen |
| 16:18 |
Dyrcona |
So, maybe Bmagic needs another "brick?" |
| 16:30 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 16:48 |
|
remingtron joined #evergreen |
| 16:53 |
Bmagic |
Dyrcona: 6 bricks already. I think they are underutilized. 16GB memory, 4CPU, 8GB swap. I think they can go a bit higher on the apache workers. Like 200 |
| 16:57 |
berick |
Bmagic: how's the CPU load look on those? 120 active apache processes on 4CPUs seems like a lot |
| 00:11 |
|
Christineb joined #evergreen |
| 01:03 |
|
beanjammin joined #evergreen |
| 04:30 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:04 |
|
dkyle2 joined #evergreen |
| 06:34 |
|
jamesrf joined #evergreen |
| 07:06 |
|
rjackson_isl joined #evergreen |
| 10:38 |
|
jamesrf joined #evergreen |
| 10:40 |
Bmagic |
stephengwills: Chrome/Firefox both seem to work and work well. When it comes to the Hatch software, Chrome was* the only browser that had the Hatch extension, but now thanks to csharp and others, FF has it available in the add-on's store |
| 10:42 |
|
khuckins_ joined #evergreen |
| 10:42 |
stephengwills |
thanks…my tests seem to be working as well. I just wanted to double check. |
| 10:44 |
berick |
we officially support chrome and ff |
| 10:44 |
berick |
hatch still needs a little bit of love for FF, though - some pending LP's |
| 10:48 |
stephengwills |
i was just on a conf call where one of my LibDirs told the group not to ue firefox because it was unsupported. I didn’t want to jump in without this checkin. thanks all, as usual. ++ |
| 10:52 |
berick |
ideally, the other browsers will catch up, but yeah for now Chrome is the path of least resistence, but we also support FF |
| 10:57 |
* stephengwills |
puts up his thumb and pokes himself in the eye. |
| 11:03 |
Dyrcona |
Speaking of Google.... Do we have a community calendar with the EOL dates for the releases on it? |
| 11:26 |
Dyrcona |
berick++ for Lp 1810802. I swear I tested that, but guess I didn't. |
| 11:26 |
pinesol |
Launchpad bug 1810802 in Evergreen "Database org_top() function upgrade script errors" [High,New] https://launchpad.net/bugs/1810802 - Assigned to Jason Stephenson (jstephenson) |
| 11:31 |
pinesol |
[evergreen|Bill Erickson] LP1810802 org_top() SQL upgrade repairs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=eaca9cd> |
| 11:37 |
berick |
Dyrcona++ |
| 12:05 |
|
mmorgan joined #evergreen |
| 12:05 |
|
sandbergja joined #evergreen |
| 12:22 |
Dyrcona |
Speaking of db upgrades... It would be great if Lp 1806709 could go in before next week's update releases. |
| 12:22 |
pinesol |
Launchpad bug 1806709 in Evergreen 3.2 "Add Billing History grid persist-key to server-side db settings" [High,Confirmed] https://launchpad.net/bugs/1806709 |
| 12:37 |
|
khuckins_ joined #evergreen |
| 12:40 |
|
beanjammin joined #evergreen |
| 12:47 |
|
beanjammin joined #evergreen |
| 13:41 |
|
khuckins_ joined #evergreen |
| 15:13 |
|
khuckins joined #evergreen |
| 15:56 |
|
jvwoolf joined #evergreen |
| 16:30 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:11 |
|
mmorgan left #evergreen |
| 17:31 |
|
jvwoolf joined #evergreen |
| 22:36 |
|
beanjammin joined #evergreen |
| 04:30 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:48 |
|
JBoyer joined #evergreen |
| 06:55 |
|
agoben joined #evergreen |
| 07:10 |
|
rjackson_isl joined #evergreen |
| 12:53 |
jeff |
no, not generally useful. just sometimes handy. |
| 12:54 |
Dyrcona |
Though --app without a URL seems to behave better. I found that with a URL specified, Ctrl-t opened a new tab in a different window. |
| 12:55 |
Dyrcona |
I.E. not my --app window. |
| 12:55 |
* jeff |
nods |
| 12:55 |
jeff |
similar to opening an "external" link in the xul client opens in the "normal" browser. |
| 12:56 |
jeff |
unfortunately, when i tested a few minutes ago it also affected intentionally "open in new tab" links within the staff client when run with --app=url |
| 13:15 |
Bmagic_ |
Dyrcona: That invoicing issue from last week: it was a quantity mis-match! It would be great if the log message would say something (instead of nothing) |
| 13:28 |
|
khuckins joined #evergreen |
| 13:35 |
Dyrcona |
Bmagic_: That might be a good subject for a bug. |
| 13:37 |
|
khuckins_ joined #evergreen |
| 15:31 |
|
khuckins_ joined #evergreen |
| 16:18 |
Bmagic_ |
Dyrcona: bug 1810853 |
| 16:18 |
pinesol |
Launchpad bug 1810853 in Evergreen "Acquisitions EDI invoice creation needs better logging " [Undecided,New] https://launchpad.net/bugs/1810853 |
| 16:21 |
|
jamesrf joined #evergreen |
| 16:30 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:18 |
|
mmorgan left #evergreen |
| 18:26 |
|
beanjammin joined #evergreen |
| 15:10 |
phasefx |
welcome |
| 15:13 |
phasefx |
hrmm, so some instances of stretch seem to require use of /etc/init.d/ in places instead of systemctl :-/ |
| 15:14 |
berick |
phasefx: apache2ctl-websockets should work universally |
| 15:15 |
phasefx |
berick++ in this most recent case, it was ejabberd surprising me |
| 15:15 |
phasefx |
what do you guys think of this look/layout for the live tester? http://testing.evergreen-ils.org/~live/ |
| 15:16 |
bshum |
phasefx++ # neat :) |
| 15:16 |
phasefx |
will put a shortuct at the top to indicate/jump to the first failure |
| 15:17 |
bshum |
berick: phasefx: that step's in the OpenSRF readme right? It probably hasn't been touched since we introduced apache2-websocket |
| 15:18 |
phasefx |
will probably hyperlink to sections in the install instructions as well |
| 15:20 |
bshum |
Makes sense to update the instruction to be distro specific, if necessary. Or just use the one berick suggests. |
| 15:20 |
bshum |
That's assuming we keep it as option #1 over the new websocketd :D |
| 15:25 |
pinesol |
News from qatests: Failed configuring ejabberd <http://testing.evergreen-ils.org/~live/test.15.html#2019-01-03T15:08:51,961120528-0500 -0> |
| 15:25 |
pinesol |
News from qatests: Failed creating jabber users <http://testing.evergreen-ils.org/~live/test.16.html#2019-01-03T15:08:51,970774027-0500 -2> |
| 15:25 |
pinesol |
News from qatests: Failed start opensrf <http://testing.evergreen-ils.org/~live/test.18.html#2019-01-03T15:08:51,980501558-0500 -4> |
| 15:25 |
pinesol |
News from qatests: Failed start opensrf <http://testing.evergreen-ils.org/~live/test.20.html#2019-01-03T15:08:51,990116639-0500 -6> |
| 15:25 |
pinesol |
News from qatests: Failed test opensrf <http://testing.evergreen-ils.org/~live/test.21.html#2019-01-03T15:08:51,999747537-0500 -8> |
| 15:25 |
pinesol |
News from qatests: Failed configuring websockets <http://testing.evergreen-ils.org/~live/test.22.html#2019-01-03T15:08:52,009366939-0500 -10> |
| 15:38 |
blongwel |
In 3.1.7 with duplicate tcn (from 035) on import we are seeing long tcns generated with all isbns in the record. Is this expected behavior or a bug? |
| 15:55 |
pinesol |
News from qatests: Failed configuring websockets <http://testing.evergreen-ils.org/~live/test.22.html#2019-01-03T15:48:20,626585144-0500 -0> |
| 16:04 |
|
gsams_ joined #evergreen |
| 16:06 |
|
gsams_ joined #evergreen |
| 16:25 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 16:45 |
mmorgan |
Anybody getting reports from patrons using Comcast as an email provider that they are not getting their Evergreen notifications? |
| 16:45 |
csharp |
not here that I've heard |
| 16:46 |
mmorgan |
We're getting lots of reports, but see no problems in our email logs, and we've successfully seen messages delivered to staff members who have Comcast email. |
| 16:50 |
csharp |
email providers are getting stricter about enforcing that - but I would expect problems with Gmail and Yahoo too |
| 16:51 |
mmorgan |
We send through gmail and those logs indicate those messages are all being delivered to Comcast servers. We're only seeing the usual occasional bounce when a user doesn't exist. |
| 16:52 |
csharp |
yeah - the logs on your end will look fine - the receiving server accepts the mail in most cases, then trashes it on their end |
| 16:54 |
mmorgan |
Tests we've done work fine. Hold notifications, etc. appear in the Comcast inboxes of the patrons, who just happen to be staff members who tested with their Comcast email addresses. |
| 16:54 |
csharp |
oh - hmm |
| 16:55 |
mmorgan |
But we've had a large number of reports from patrons that they're not getting messages in the past two weeks. |
| 16:55 |
csharp |
we have a standard line of "all looks correct on our end - please contact your email provider" (sometimes including the log message on our end showing successful receipt |
| 07:12 |
|
rjackson_isl joined #evergreen |
| 09:24 |
|
stephengwills joined #evergreen |
| 10:57 |
|
jvwoolf joined #evergreen |
| 11:00 |
stephengwills |
Is it reasonable for me to upgrade EG database on a test server and copy the database to a production server and expect the prod version to attach to it and work properly? (as opposed to upgrading the prod database in place?) |
| 11:02 |
stephengwills |
i’m having profound index problems this morning and want to start by checking the basic premise of my workflow. |
| 11:08 |
|
khuckins joined #evergreen |
| 11:49 |
|
terran joined #evergreen |
| 11:54 |
bshum |
stephengwills: That makes sense to me. "Production" is basically whichever database you designate as the main one used by your Evergreen app servers. |
| 11:54 |
bshum |
It doesn't have to be the same actual database server, etc. |
| 11:55 |
bshum |
of course, once people start using said database, it'd be hard to go back and use another DB copy again |
| 11:55 |
bshum |
Meaning copying transactions, etc. between databases, I wouldn't advise that |
| 11:55 |
bshum |
But basically any app server, you can edit the opensrf.xml config to point at any database you want |
| 11:56 |
bshum |
In theory. :) |
| 11:57 |
bshum |
In the past, I've "upgraded" databases by building a whole fresh server and new PG version, and then took a db-dump copy of our prod database and restored it into the fresh system. |
| 11:57 |
bshum |
I just liked doing the dump/restore PG approach rather than doing in-place pg_upgrade. But to each their own. |
| 11:59 |
bshum |
Of course, your "test server" becoming the new production, you'll want to make sure the hardware is comparable, tuning is done, security in place, etc. |
| 11:59 |
bshum |
Good luck with everything. Be curious to hear how it all turns out later. :) |
| 13:08 |
|
hbrennan joined #evergreen |
| 14:18 |
stephengwills |
in 3.1.8 I imported a record via z39.50, added a 250 field and clicked save. There was no UX feedback that I was successful until I click on MARC View and saw that my 250 field has, indeed been added. is this a known problem? |
| 16:51 |
|
khuckins_ joined #evergreen |
