| 02:18 |
|
jeff_ joined #evergreen |
| 05:47 |
|
sandbergja joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:49 |
|
sandbergja joined #evergreen |
| 07:02 |
|
agoben_ joined #evergreen |
| 07:26 |
|
Dyrcona joined #evergreen |
| 15:09 |
|
sandbergja joined #evergreen |
| 15:09 |
sandbergja |
I really like the high contrast mode in KCLS's self-check. Nice work, berick! |
| 15:33 |
|
mmorgan1 joined #evergreen |
| 15:36 |
gmcharlt_ |
jeffdavis: If you happen to test the curbside pickup branch, one thing I'd be curious about is whether the barcode completion and opt-in work for you for the patron search on the schedule pickup table in the staff interface. (It should, but woud bear more testing.) |
| 15:37 |
pinesol |
[evergreen|Sam Link] LP1882937 Replace master/slave terminology - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=bc45adb> |
| 15:37 |
pinesol |
[evergreen|Mike Rylander] LP#1882937: Comment and dead-code cleanup - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3a2e51f> |
| 15:37 |
csharp |
slink++ |
| 15:37 |
jeffdavis |
gmcharlt_: thanks for mentioning - I think we're going to be testing it, will pay attention to those aspects |
| 15:38 |
|
gmcharlt_ joined #evergreen |
| 15:44 |
sandbergja |
slink++ |
| 15:44 |
sandbergja |
miker++ |
| 17:09 |
|
mmorgan1 left #evergreen |
| 17:48 |
jeffdavis |
another good one: no_tz.open-ils.storage.actor.user.crazy_search: prepare_cached(SELECT evergreen.unaccent_and_squash(?)) statement handle DBIx::ContextualFetch::st=HASH(0xf3767a8) still Active at /usr/local/share/perl/5.22.1/OpenILS/Application/Storage/Publisher/actor.pm line 627. |
| 18:00 |
|
sandbergja joined #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:19 |
|
mrisher_ joined #evergreen |
| 19:57 |
|
sandbergja joined #evergreen |
| 21:43 |
|
remingtron_ joined #evergreen |
| 00:11 |
|
sandbergja joined #evergreen |
| 05:31 |
|
Dyrcona joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:23 |
|
rjackson_isl_hom joined #evergreen |
| 07:38 |
|
agoben joined #evergreen |
| 07:51 |
|
rfrasur joined #evergreen |
| 16:54 |
Bmagic |
a great first day indeed! |
| 16:57 |
mmorgan |
What Bmagic said! |
| 16:58 |
jeff |
Do we know when recordings will be posted? |
| 17:00 |
rhamby_ |
jeff: in terms of the videos or videos with subtitles? |
| 17:01 |
rhamby_ |
I'm currently waiting to get the download links on the videos, I have the intro and keynote now. |
| 17:01 |
rhamby_ |
intro and keynote will probably go up as a single file tonight. |
| 17:02 |
rhamby_ |
the tracks I will probably get as a single file and I'll need a little time to split them (but not much) |
| 17:02 |
rhamby_ |
the subtitles will take more work and will probably trail behind |
| 17:03 |
rhamby_ |
we get the closed caption in a text format that is a bit messy, I wrote a script to convert them to youtube .scr format for subtitles but this will be it's beta test so how long it takes will be determined a bit by how well I've anticipated how messy the transcripts are |
| 17:05 |
rhamby_ |
looking over the keynote video I'll probably review and do trimming just to remove dead space from the front if nothing else |
| 17:07 |
rhamby_ |
that may be a longer answer than you wanted .... |
| 17:26 |
|
mmorgan left #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:30 |
|
mrisher joined #evergreen |
| 19:31 |
|
sandbergja joined #evergreen |
| 20:24 |
|
mrisher joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:51 |
|
rfrasur joined #evergreen |
| 07:12 |
|
agoben joined #evergreen |
| 07:15 |
|
rjackson_isl_hom joined #evergreen |
| 12:00 |
|
jihpringle joined #evergreen |
| 12:12 |
Bmagic |
All, I'm trouble shooting the presence of "Place Hold" in the OPAC. I've narrowed it down to the Apache ENV variable "physical_loc" - when it's set to "2" the "Place Hold" link is gone, When it's "3" - it's there. Found the function "global_record_copy_count" in biblio.pm where a SQL query figures out the counts |
| 12:16 |
Bmagic |
There is also a DB function: asset.record_has_holdable_copy - which takes the BIB ID and the context ORG unit. When I feed in "3", the function returns false, and when I feed "2" - it returns true. Which is opposite of the OPAC behavior. Not sure that this function is consulted for the OPAC, but it's curious none-the-less |
| 12:20 |
Bmagic |
All of the copies on my test bib are located beneath "2" - there are no copies for "3" or any org below "3". But "3" is the one that is working.... |
| 12:21 |
jihpringle |
Bmagic: sounds like https://bugs.launchpad.net/evergreen/+bug/1819956 |
| 12:21 |
pinesol |
Launchpad bug 1819956 in Evergreen "Place Hold Option Not Hidden In OPAC If Other Libraries Have Holdable Items" [Wishlist,Confirmed] |
| 12:23 |
Bmagic |
hmmm, this is different I think. The copies ARE holdable and OPAC visible |
| 16:22 |
|
sandbergja joined #evergreen |
| 16:43 |
|
Dyrcona joined #evergreen |
| 17:29 |
|
mmorgan1 left #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:20 |
|
Dyrcona joined #evergreen |
| 22:38 |
|
sandbergja joined #evergreen |
| 23:26 |
|
sandbergja joined #evergreen |
| 00:44 |
|
sandbergja joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:18 |
|
rjackson_isl_hom joined #evergreen |
| 07:53 |
|
rfrasur joined #evergreen |
| 08:13 |
|
remingtron__ joined #evergreen |
| 11:31 |
berick |
Bmagic: i'm just guessing. a lot of the supercat-ish URLs have a depth option |
| 12:04 |
jeffdavis |
<zurl>http://localhost/opac/extras/sru/SYSTEMNAME/holdings</zurl> works here, we don't do anything else to scope results that I know of |
| 12:16 |
|
jihpringle joined #evergreen |
| 12:28 |
Bmagic |
jeffdavis: using exactly that, I did a test query against the whole DB (Defined like this: <zurl>http://localhost/opac/extras/sru</zurl> ) - then did the exact same query against the SYSTEMNAME DB - with exactly the same result set. Furthermore, I grabbed the control number from the output and looked that bib up in the database, there were no holdings for my SYSTEMNAME on that bib |
| 12:33 |
jeffdavis |
Bmagic: does the Evergreen search string generated for your SYSTEMNAME search contain site:SYSTEMNAME as a search param? |
| 12:34 |
Bmagic |
would that be spit out STDOUT from simple2zoom? |
| 12:35 |
jeffdavis |
it would be in the EG logs |
| 12:42 |
jeffdavis |
If you take the same EG search string and run it directly (rather than via Z39.50/SRU), are the results scoped correctly? |
| 12:42 |
Bmagic |
openils.search.biblio.multiclass.query HASH(0x627b920), eg.title:"goblet of fire" && eg.author:rowling site:SYSTEMNAME, 1 |
| 12:42 |
Bmagic |
seems legit to me |
| 12:43 |
Bmagic |
using the http://www.loc.gov/z3950/test.html tool |
| 12:48 |
Bmagic |
that last "1" at the end is depth? |
| 12:55 |
Bmagic |
jeffdavis: I think the issue is that lookup tool |
| 12:55 |
Bmagic |
it must cache or something |
| 16:19 |
* mmorgan |
is wondering about applying a transit range of system to all the hold policies in the db.... |
| 16:19 |
jeff |
(wouldn't affect targeting / queue position, just trying to catch items on the pull list already for patrons who we know we're about to have come pick up soon) |
| 16:20 |
jeff |
mmorgan: if you update the policies, keep in mind that you'll also need to update and potentially retarget existing outstanding uncaptured holds. selection_ou and selection_depth are fields on the hold request. |
| 16:21 |
mmorgan |
jeff++ |
| 16:21 |
mmorgan |
I thought there must be a flaw in my logic :) |
| 16:55 |
mmorgan |
jeff: So I'm testing adding transit ranges to hold policies, and am not seeing that holds get a selection_depth. The transit range added to hold policies applies to holds placed prior to the rule change. |
| 16:56 |
mmorgan |
Is selection_depth only used set by boundaries? |
| 16:56 |
mmorgan |
s/used// |
| 16:57 |
jeff |
hard boundary is what ends up in selection_depth, i think. |
| 16:57 |
jeff |
i don't know if there are other circumstances where something else influences selection_depth |
| 16:57 |
mmorgan |
Ok, transit range in a hold policy looks to be consulted on the fly. |
| 17:19 |
mmorgan |
jeff++ |
| 17:19 |
|
mmorgan left #evergreen |
| 17:52 |
|
alynn26 joined #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:01 |
|
sandbergja joined #evergreen |
| 19:02 |
|
sandbergja joined #evergreen |
| 20:05 |
|
jvwoolf joined #evergreen |
| 05:57 |
|
miker joined #evergreen |
| 05:57 |
|
dbs joined #evergreen |
| 05:58 |
|
abneiman joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:17 |
|
rjackson_isl_hom joined #evergreen |
| 07:36 |
|
agoben joined #evergreen |
| 08:06 |
|
mantis joined #evergreen |
| 08:58 |
|
dbwells joined #evergreen |
| 09:00 |
csharp |
comcast-- |
| 09:00 |
csharp |
@hates |
| 09:00 |
pinesol |
csharp hates dojo_hold_policies_interface; SIP; when libraries purchase third party products without testing and blame Evergreen for it not working; reports; the fact that the Base Filters is unnecessarily greyed out when applying an Aggregate Filter and vice versa; evil; reports more; reports even moar; details; reports even more; the fact that the Base Filters is unnecessarily greyed out when applying an (2 more messages) |
| 09:00 |
csharp |
@more |
| 09:00 |
pinesol |
csharp: Aggregate Filter and vice versa even more; having to teach SIP2 client vendors about the SIP2 specification; troubleshooting reports; money reports; marc; reports even more than before; the EDI ruby bits; acquisitions; <quote>fun<unquote>; edi; sip2; sip too; sip two; acq; acq more; acq way more than before; omg I hate acq; omg I love acq; hate hate hate; comcast; action_triggers; javascript; action_triggers (1 more message) |
| 09:00 |
csharp |
@more |
| 09:16 |
Bmagic |
yes! Perfect |
| 09:16 |
rfrasur |
very concise! |
| 09:17 |
Dyrcona |
:) |
| 09:18 |
Bmagic |
Just tested - Pinesol's mind is compartmentalized between IRC channels |
| 09:18 |
rfrasur |
that makes sense |
| 09:18 |
Bmagic |
I was thinking it would be nice to have a private conversation with it, so we could work out what we wanted it to know without spamming channel |
| 09:19 |
rfrasur |
responsible ;) |
| 10:20 |
pinesol |
Dyrcona, tsbere, bshum, csharp, gmcharlt, yboston, kmlussier and gsams love git |
| 10:20 |
pinesol |
terran hates git |
| 10:22 |
berick |
@loves |
| 10:22 |
pinesol |
berick loves mosh; whitespace-as-syntax; digging around in Open-ILS/src/support-scripts/test-scripts and finding a 7 year old script that does exactly what I needed.; asciidoc; breakfast bourbon; and deleting things |
| 10:22 |
berick |
@hates |
| 10:22 |
pinesol |
berick: berick doesn't seem to hate anything. |
| 10:22 |
berick |
that's right |
| 15:55 |
abneiman |
dluch++ # sorry I missed the meeting |
| 17:30 |
|
mmorgan left #evergreen |
| 17:32 |
|
mmorgan joined #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:02 |
|
sandbergja joined #evergreen |
| 18:10 |
|
jvwoolf joined #evergreen |
| 18:36 |
|
jeffdavis_ joined #evergreen |
| 01:20 |
|
sandbergja joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 08:06 |
|
mantis joined #evergreen |
| 08:06 |
|
dbwells_ joined #evergreen |
| 08:09 |
|
rfrasur joined #evergreen |
| 12:26 |
csharp |
not sure if it fixes legacy TLS client access |
| 12:26 |
csharp |
(probably not) |
| 12:26 |
csharp |
still waiting to hear back from kenstir about whether it fixed an android app issue |
| 12:42 |
Dyrcona |
I'm going to test removing the AddTrust cert from the chain and see what happens. I'm told that just adding the SSL exception doesn't always work with XUL. Worked for me on Linux. |
| 12:51 |
|
khuckins joined #evergreen |
| 13:01 |
csharp |
"oh, by the way guys, we'll be migrating fully to the web client today!" |
| 13:03 |
Dyrcona |
:) |
| 15:26 |
|
jihpringle joined #evergreen |
| 15:38 |
|
mmorgan left #evergreen |
| 16:31 |
|
mantis left #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:27 |
|
sandbergja joined #evergreen |
| 20:28 |
|
jvwoolf joined #evergreen |
| 02:51 |
|
mrisher joined #evergreen |
| 02:54 |
|
mrisher joined #evergreen |
| 05:27 |
|
rjackson_isl_hom joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Failed configure CPAN <http://testing.evergreen-ils.org/~live//archive/2020-05/2020-05-27_04:00:07/test.3.html> |
| 07:18 |
|
rjackson_isl_hom joined #evergreen |
| 07:20 |
|
rfrasur joined #evergreen |
| 08:14 |
|
dbwells joined #evergreen |
| 08:35 |
Dyrcona |
At least, the backport to 3.2.10 seems to have done something. |
| 08:38 |
|
alynn26 joined #evergreen |
| 08:47 |
|
mmorgan joined #evergreen |
| 08:48 |
csharp |
Dyrcona: btw, I tested your no-Java branches on OpenSRF/Evergreen - I see no problems, but I would guess we want to be pretty coordinated about how we commit to master/release stuff |
| 08:52 |
Dyrcona |
csharp: It should wait until after 3.5 is released, or at least, it should not go into the 3.5 branch, not that Java works there. It hasn't worked in years. |
| 08:53 |
Dyrcona |
I'm looking into my earlier comment and I'm seeing strange stuff on my test VM. I'm going to have to find out what jamundson is looking at in production to see if something similar is going on. |
| 08:55 |
csharp |
Dyrcona: I looked on my master server and I don't have any selection lists to test but I didn't see problems with the UI loading or with PO items, etc. |
| 08:59 |
Dyrcona |
csharp: I reverted commits to the files in the picklist directory and it seems to be working, now. |
| 09:04 |
Dyrcona |
Could be a cache issue, too. It appeared fixed after I reverted changes and used the Chromium developer tools, and I have the tools set to disable cache. |
| 09:07 |
Dyrcona |
With or without changes, I get a bunch of these: VM1995:89 POST https://training.cwmars.org/osrf-http-translator net::ERR_INSUFFICIENT_RESOURCES |
| 11:54 |
bshum |
Every time we circle around to killing the target though, somebody decides to update the deps, so... :D |
| 11:55 |
bshum |
I think I got pretty close to figuring out how to get it working again, but got stuck on the HTTPS config parts, since it's different on Fedora vs. Ubuntu Apache |
| 11:58 |
bshum |
I'd only be wary against moving off of pinned Node versions because of potential dependency disruption. I think they tend to stay pretty safe along major versions, so maybe not as worrying |
| 11:59 |
Dyrcona |
So, reverting all of the ACQ changes from the jQuery bug fix makes no difference according to the person testing this. |
| 12:00 |
bshum |
This whole Node thing is so fickle :) |
| 12:00 |
|
mrisher joined #evergreen |
| 12:00 |
|
jihpringle joined #evergreen |
| 15:12 |
* mmorgan |
was looking at that, too. |
| 15:14 |
mmorgan |
So having separate event defs for different libraries would be the only way to break them up? Not a good solution for large consortia, though. |
| 15:17 |
Dyrcona |
mmorgan: Yes, that's where my thoughts are heading, though I'm a bit fuzzy on how to have the separate event definitions for each member library. |
| 15:20 |
* mmorgan |
has cloned the event owned by the consortium and changed owner to the ou for the member library. Testing this again to make sure it only creates events for the owner. |
| 15:21 |
Dyrcona |
mmorgan: I was about to look at that as a possibility. |
| 15:30 |
jeffdavis |
berick++ |
| 15:30 |
jeffdavis |
I can create a signoff branch but I wonder if it should be reviewed by someone more familiar with OpenSRF stuff than I am. |
| 17:12 |
mmorgan |
Heh. Just saw that pinesol helpfully supplied bug number seven. Obviously, that's not one I was referring, to :) |
| 17:13 |
|
mmorgan left #evergreen |
| 17:28 |
|
jihpringle joined #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:05 |
|
rjackson_isl_hom joined #evergreen |
| 18:08 |
|
jvwoolf joined #evergreen |
| 18:54 |
|
mrisher joined #evergreen |
| 04:22 |
|
dbwells_ joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:28 |
|
rjackson_isl_hom joined #evergreen |
| 07:20 |
|
rjackson_isl_hom joined #evergreen |
| 07:24 |
|
rfrasur joined #evergreen |
| 10:14 |
bshum |
Well, it sounded like dbwells had some thoughts about keeping it alive, but yeah I've been in favor of letting it die for now |
| 10:14 |
csharp |
didn't/doesn't Syrup use it? |
| 10:15 |
Dyrcona |
Reading dbwells comment, he's concerned about Syrup, and no, I don't think Syrup actually uses much (if any) of it. |
| 10:15 |
bshum |
20.04 definitely chokes on the existing packages and as testing goes, haven't built OpenSRF with python bindings at all forever |
| 10:16 |
Dyrcona |
It won't build on Ubuntu 16.04, either, but works on 18.04. |
| 10:16 |
Dyrcona |
Or, rather, it won't work on 16.04. |
| 10:17 |
Dyrcona |
Java's been dead for years.... bug 1827051 |
| 10:21 |
csharp |
Dyrcona: please - that sounds great |
| 10:22 |
csharp |
if someone gets the itch to implement Python3 later, more power to them :-) |
| 10:22 |
Dyrcona |
If someone wants to look at the Java bug in the meantime, that would be helpful. |
| 10:22 |
csharp |
if I get a moment today, I'll test both OpenSRF and EG |
| 10:22 |
Dyrcona |
csharp++ |
| 10:22 |
csharp |
lots of meetings today |
| 10:23 |
Dyrcona |
I think we should modernize our use of ejabberd before we try adding more language interfaces. |
| 16:06 |
|
jihpringle96 joined #evergreen |
| 17:17 |
|
mmorgan left #evergreen |
| 17:33 |
|
jvwoolf joined #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 01:06 |
|
JBoyer joined #evergreen |
| 01:49 |
|
JBoyer joined #evergreen |
| 04:22 |
|
dbwells joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:21 |
|
sandbergja joined #evergreen |
| 06:25 |
|
sandbergja joined #evergreen |
| 07:12 |
|
rfrasur joined #evergreen |
| 07:59 |
Dyrcona |
Pg11++ which is Pg12 and I'm trying that next. :) |
| 08:01 |
JBoyer |
Dyrcona++ |
| 08:01 |
JBoyer |
That sounds great |
| 08:04 |
Dyrcona |
I don't know what other surprises may await us in Pg12 or Pg11, but I think I'm going to switch my main development VM to used the Pg12 database if this test goes well. |
| 08:08 |
|
alynn26 joined #evergreen |
| 08:15 |
|
jvwoolf joined #evergreen |
| 08:22 |
|
mantis2 joined #evergreen |
| 17:01 |
|
rjackson_isl_hom joined #evergreen |
| 17:12 |
|
mmorgan left #evergreen |
| 17:33 |
|
Dyrcona joined #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:17 |
|
rjackson_isl_hom joined #evergreen |
| 18:52 |
|
rjackson_isl_hom joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:21 |
|
rjackson_isl_hom joined #evergreen |
| 07:32 |
|
Dyrcona joined #evergreen |
| 07:38 |
|
rfrasur joined #evergreen |
| 07:54 |
Dyrcona |
Been a while since I ran git pull: Your branch is behind 'origin/master' by 1764 commits, and can be fast-forwarded. |
| 08:30 |
|
alynn26 joined #evergreen |
| 08:31 |
Dyrcona |
csharp: It might interest you to know that I just got better profile numbers from a default installation of Pg10 with the same authority update on the same hardware than I got last Friday with a tuned Pg 9.6 database. I'm going to try Pg 11 and Pg 12 after restoring dumps to them. |
| 08:33 |
Dyrcona |
Granted, this is totally nonscientific testing. I'm just running the update, reverting it, and running the update again with plprofiler and looking at the output. I'm not doing enough trials nor averaging results. |
| 08:40 |
csharp |
thanks! I can do some experimentation too |
| 08:42 |
Dyrcona |
I'm restoring to Pg 11, now. My methodology is do the restore, then run the plprofiler as mentioned above. I'm trying not to use the db server for anything else in the meantime. |
| 08:42 |
Dyrcona |
The restore usually takes so long that I don't get around to running plprofiler until the next morning. |
| 17:14 |
jeff |
often our fallback is "your card number always works in place of your username if you've forgotten your username", but there are cases where that isn't as helpful. |
| 17:29 |
|
mmorgan left #evergreen |
| 18:00 |
|
sandbergja joined #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:31 |
|
sandbergja joined #evergreen |
| 19:51 |
|
sandbergja joined #evergreen |
| 20:23 |
|
sandbergja joined #evergreen |
| 01:44 |
|
alynn26_away joined #evergreen |
| 05:47 |
|
agoben joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:23 |
|
rjackson_isl_hom joined #evergreen |
| 07:25 |
|
Dyrcona joined #evergreen |
| 07:29 |
|
rfrasur joined #evergreen |
| 14:31 |
|
rfrasur joined #evergreen |
| 14:35 |
csharp |
Dyrcona: what version of PG? |
| 14:42 |
Dyrcona |
Pg 9.6 |
| 14:43 |
Dyrcona |
I also have 10, 11, and 12 on this server, but I'm only testing with 9.6. |
| 14:48 |
Dyrcona |
To install plprofile on other versions of Postgres, I'll need to checkout the source code for each version. |
| 15:55 |
JBoyer |
Dyrcona, In case you're interested the only package I had to remove to get Ubuntu to chill out about upgrading Postgres was postgresql-plperl-(vers). It wails about it because apparently that package must not properly work side-by-side with other versions and postgresql-* is in the "never remove these packages" list. Makes a Postgres version upgrade even more urgent once the system comes back up. :) |
| 15:56 |
Dyrcona |
JBoyer: Yes, that was the only one listed in the logs, but I deleted it and the main postgresql packages apparently. |
| 17:31 |
|
sandbergja joined #evergreen |
| 17:36 |
|
sandbergja joined #evergreen |
| 17:43 |
|
sandbergja joined #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 22:00 |
|
sandbergja joined #evergreen |
| 22:41 |
|
sandbergja joined #evergreen |
| 00:15 |
|
rjackson_isl_hom joined #evergreen |
| 00:22 |
|
dbwells joined #evergreen |
| 00:23 |
|
dbwells_ joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:19 |
|
rjackson_isl_hom joined #evergreen |
| 07:34 |
|
rfrasur joined #evergreen |
| 08:06 |
|
Dyrcona joined #evergreen |
| 14:00 |
|
sandbergja joined #evergreen |
| 14:02 |
jeffdavis |
berick: btw I applied your c-backlog-speedbump fix on our 3.5 server and it seems to have successfully prevented the log problem when we hit max_children today |
| 14:02 |
jeffdavis |
so thanks for that! :) |
| 14:03 |
berick |
jeffdavis: nice, thanks for testing |
| 14:05 |
|
sandbergja joined #evergreen |
| 14:59 |
|
miker joined #evergreen |
| 14:59 |
|
ericar joined #evergreen |
| 16:48 |
|
rjackson_isl_hom joined #evergreen |
| 17:14 |
|
mmorgan left #evergreen |
| 17:42 |
berick |
csharp++ |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:12 |
|
mantis1 joined #evergreen |
| 19:13 |
|
mantis1 left #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:20 |
|
rjackson_isl_hom joined #evergreen |
| 07:27 |
|
Dyrcona joined #evergreen |
| 07:48 |
|
rfrasur joined #evergreen |
| 10:31 |
|
dbwells joined #evergreen |
| 10:35 |
|
rfrasur joined #evergreen |
| 10:36 |
|
sandbergja joined #evergreen |
| 10:54 |
pinesol |
[evergreen|Bill Erickson] LP1837656 Org proximity admin disable org filter - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=07971c7> |
| 11:13 |
|
berick joined #evergreen |
| 12:04 |
|
jihpringle joined #evergreen |
| 12:09 |
mmorgan |
I'm trying to change a best hold selection sort order on a test system and it's not working. |
| 12:10 |
mmorgan |
We were using a sort order which always sent holds home, and I just changed it to Traditional, and it's still sending holds home. |
| 12:11 |
mmorgan |
I've restarted services, ran autogen, am I missing something? Traditional should capture a hold where an item lands, right? |
| 12:22 |
|
mantis2 joined #evergreen |
| 12:22 |
Dyrcona |
mmorgan: Have you run the hold targeter since making the change? |
| 12:23 |
|
sandbergja joined #evergreen |
| 12:24 |
mmorgan |
Dyrcona: I have manually retargeted the individual holds I'm testing, and confirmed that the non-owned item I'm checking is in the hold copy map for the hold at the pickup point. |
| 12:25 |
Dyrcona |
TBH, I don't know how that works any more. It's too complicated. |
| 12:26 |
mmorgan |
Agreed, it is complicated :) |
| 13:08 |
|
sandbergja joined #evergreen |
| 13:10 |
jeffdavis |
My test server with rel_3_5 and a few backports ran out of disk space due to 34159161 "Could not launch a new child" messages in the logs. |
| 13:11 |
Dyrcona |
jeffdavis: Yes, that happens. |
| 13:12 |
jeffdavis |
It didn't happen on a beta server with the same configuration. |
| 13:13 |
|
sandbergja joined #evergreen |
| 14:01 |
berick |
specifically regarding the log spewing, this should fix it. noting here in case this continues to be a thing. |
| 14:01 |
berick |
https://git.evergreen-ils.org/?p=working/OpenSRF.git;a=shortlog;h=refs/heads/user/berick/lpxxx-c-backlog-speedbump |
| 14:01 |
berick |
(though probably should fix it regardless) |
| 14:01 |
jeffdavis |
thanks Bill, we'll try that out |
| 14:05 |
jeffdavis |
FWIW, we have two test servers, upgrade1 (~3.5beta) and upgrade2 (~ current rel_3_5). They are configured pretty much identically, use the same db cluster, etc. upgrade1 has been in use for weeks without issues; upgrade2 ran into the max_children problem within a day or two of first use. |
| 14:05 |
Dyrcona |
I've seen the fine generator and/or hold targeter go ballistic when there's too much to do, like running the fine generator on old data when circulations haven't happened in a month, so there's a ton of overdue and lost stuff. I had that fill the disk on a training server. IIRC cstore messages like those. |
| 14:07 |
Dyrcona |
I may have mentioned it in here. I'm pretty sure that I did.... |
| 14:07 |
jeffdavis |
It could be just a transient usage or db issue, but given how similar the environments are, I am taking a look at the EG/OpenSRF code differences to see if there are any plausible causes there. We're upgrading this weekend so I want to know if the upgrade2 version has important bugs. :) |
| 15:46 |
jihpringle |
we're going to be coming up to this too soon so thanks sandbergja for asking the question and mmorgan for the answer :) |
| 16:14 |
sandbergja |
mmorgan++ |
| 16:34 |
sandbergja |
mmorgan: just to check, when you say they've fallen off the autorenewal train, does that mean that they just happen to have hit their limit of autorenewals? Or is there something specific about autorenewals that makes them fall off the train? |
| 16:38 |
mmorgan |
sandbergja: It relates to the processing delay in the autorenewal trigger, not the autorenew limit. Our items autorenew early in the morning the day they are due. |
| 16:38 |
mmorgan |
Because the item gets the due date of May 13 when it is autorenewed on May 13, it won't be picked up by the autorenew trigger that runs on May 14th. |
| 16:45 |
|
jihpringle joined #evergreen |
| 16:54 |
mmorgan |
Regarding my question earlier about best hold selection sort order. There was a hold policy affecting my test. Changing it to Traditional worked as expected. |
| 17:02 |
|
mmorgan left #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:06 |
|
drigney joined #evergreen |
| 18:24 |
|
rjackson_isl_hom joined #evergreen |
| 18:51 |
|
rjackson_isl_hom joined #evergreen |
| 06:00 |
|
rjackson_isl_hom joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:11 |
|
Dyrcona joined #evergreen |
| 07:16 |
|
rjackson_isl_hom joined #evergreen |
| 07:27 |
|
rfrasur joined #evergreen |
| 11:30 |
csharp |
my initial instinct says no, but the people who pushed for the fix probably want it sooner than 3.5 |
| 11:32 |
berick |
csharp: if it merges cleanly, i'd be in favor of merging |
| 11:32 |
jeffdavis |
+1 |
| 11:34 |
csharp |
10-4 |
| 11:35 |
csharp |
nope :-( |
| 11:36 |
csharp |
https://pastebin.com/Qm1dEVST |
| 11:37 |
csharp |
there are enough changes in the admin-page.component that I'm uncomfortable pushing it to 3.4 |
| 11:37 |
csharp |
I'll update the bug |
| 11:39 |
csharp |
as I said in my comment, if someone wants to resolve the conflicts, I'll be happy to test and signoff |
| 11:39 |
berick |
i'll push a fix |
| 11:39 |
berick |
well share a branch |
| 11:49 |
berick |
hm, it would mean untangling and backporting other stuff that the admin pages rely on |
| 16:46 |
|
rjackson_isl_hom joined #evergreen |
| 17:09 |
|
mmorgan left #evergreen |
| 17:27 |
|
jihpringle joined #evergreen |
| 18:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 20:57 |
|
sandbergja joined #evergreen |
| 22:45 |
|
sandbergja joined #evergreen |
| 23:52 |
|
sandbergja joined #evergreen |
| 04:57 |
|
mrisher joined #evergreen |
| 05:00 |
|
alynn26_away joined #evergreen |
| 05:19 |
|
AFloyd__ joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:19 |
|
rjackson_isl_hom joined #evergreen |
| 07:33 |
|
rfrasur joined #evergreen |
| 07:42 |
|
sandbergja joined #evergreen |
| 15:01 |
abneiman |
Bmagic: so, just the standard process? pullrequest, a couple signoffs, committer merge? |
| 15:01 |
Bmagic |
I believe so, yes |
| 15:02 |
dluch |
Can we make that happen? |
| 15:03 |
Bmagic |
the output of the Antora docs are online (linked above) - for anyone to test, for a sign off |
| 15:03 |
|
remingtron_ joined #evergreen |
| 15:04 |
dluch |
So, do we have a pullreequest already? |
| 15:04 |
Bmagic |
There are two seperate sets of concerns: merging this branch to master, setting up the new documentation to a server. I don't think they need to be closely linked |
| 15:04 |
dluch |
Just need testing and signoff? |
| 15:04 |
Bmagic |
seperate/separate |
| 15:05 |
dluch |
But we have the new docs server...did we not put Antora stuff there? |
| 15:05 |
Bmagic |
that's the way it is - but it has not been linked officially on the Evergreen page |
| 15:20 |
Bmagic |
@karma Bmagic |
| 15:20 |
pinesol |
Bmagic: Karma for "Bmagic" has been increased 7 times and decreased 0 times for a total karma of 7. |
| 15:20 |
Bmagic |
that proves it for sure - bmagic was raised (thank you rfrasur) - and it affected Bmagic |
| 15:21 |
rfrasur |
bmagic++ # for testing whether or not case sensitivity comes into karmic play. |
| 15:21 |
Bmagic |
:) |
| 15:21 |
Bmagic |
rfrasur++ |
| 15:22 |
rfrasur |
rfrasur-- # it's cool. my contributions today have been subpar |
| 17:06 |
|
alynn26_away joined #evergreen |
| 17:16 |
|
jvwoolf joined #evergreen |
| 17:27 |
|
rjackson_isl_hom joined #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 20:42 |
|
sandbergja joined #evergreen |
| 21:45 |
|
sandbergja_ joined #evergreen |
| 22:28 |
|
sandbergja joined #evergreen |
| 03:15 |
|
pastebot joined #evergreen |
| 03:15 |
|
jeff joined #evergreen |
| 03:29 |
|
mrisher joined #evergreen |
| 06:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:18 |
|
rfrasur joined #evergreen |
| 07:19 |
|
rjackson_isl_hom joined #evergreen |
| 08:15 |
|
Dyrcona joined #evergreen |
| 15:06 |
|
Topic for #evergreen is now Action Items from Last Meeting (Meeting topic: 2020-05-05 - Developer Meeting) |
| 15:07 |
Dyrcona |
#info csharp will arrange testing for sandbergja's fix to https://launchpad.net/bugs/1821094 on a realistic test server |
| 15:07 |
pinesol |
Launchpad bug 1821094 in Evergreen 3.3 "Item status refresh after editing can get confusingly slow" [Medium,Confirmed] |
| 15:07 |
csharp |
we installed the fix for bug 1821094 on a test server and one of our testers provided a comment on the bug |
| 15:08 |
csharp |
that's kind of where we left it as far as I'm aware |
| 15:08 |
sandbergja |
csharp++ |
| 15:08 |
Dyrcona |
So the action item is done. Is any more work required that merits a new action item? |
| 15:09 |
csharp |
I'll check on our end to see if they think the feature is ready |
| 15:46 |
Dyrcona |
Bmagic: If you want help with that, I'm sure we'll be able to make it happen. |
| 15:47 |
Bmagic |
cool, thanks for taking the time today to talk about that |
| 15:47 |
Dyrcona |
So, anything else for Evergreen releases? |
| 15:48 |
csharp |
Bmagic: looking forward to testing it out |
| 15:48 |
Bmagic |
csharp: feel free to click through what's there http://eg-docs.georgialibraries.org/prod/ |
| 15:49 |
csharp |
oh cool |
| 15:50 |
Dyrcona |
#topic New Business |
| 17:54 |
Bmagic |
I have a patch file for the target differing files - https://git-scm.com/docs/git-am doesn't seem to inform me how to make it patch *different* files |
| 17:55 |
Bmagic |
oh well - something for tomorrow - have a good evening Evergreen! |
| 18:00 |
berick |
Bmagic: oops, I mean 'git apply'. if the only difference is the path to the file, see the -p flag |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:05 |
|
sandbergja joined #evergreen |
| 18:37 |
|
sandbergja_ joined #evergreen |
| 20:14 |
|
sandbergja joined #evergreen |
