| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:50 |
rjackson_isl_hom |
csharp nothing stuck out |
| 07:58 |
rjackson_isl_hom |
after our upgrade to 3.4.4 the actor.usr_delete function has become corrupted. There are two entries attempting to set guardian to null so function fails always. |
| 07:59 |
rjackson_isl_hom |
two questions for the community: where do I find the function definitions that should be in place |
| 11:03 |
berick |
mmorgan: yeah, i wonder if a setting somewhere is not stored correctly, like a default pickup lib user setting |
| 11:03 |
berick |
"\"171\"" is still valid JSON, so the DB would accept it |
| 11:03 |
Dyrcona |
Yeah, I was about to suggest it might be a user setting. |
| 11:04 |
csharp |
mmorgan: that was my first thought, but I stopped when it wasn't the OU setting - I'll dig in that direction |
| 11:05 |
csharp |
well, I should have mentioned that we're testing the fix to bug 1889128 on *top* of 3.6.1 |
| 11:05 |
pinesol |
Launchpad bug 1889128 in Evergreen "Angular Staff Catalog: Place Another Hold & Multi-Holds" [High,Confirmed] https://launchpad.net/bugs/1889128 |
| 11:07 |
Dyrcona |
csharp: You removed the sticker, opened the seal, and voided the warranty. :) |
| 11:07 |
csharp |
Dyrcona++ |
| 11:13 |
berick |
mmorgan: was just checking... |
| 11:14 |
berick |
well my branch may have missed it too |
| 11:14 |
berick |
mmorgan: hm, no, the patch is there in your s/o branch |
| 11:15 |
mmorgan |
I did my testing on terranm's server, and it worked well there. |
| 11:15 |
berick |
but it has a different LP number so csharp may have missed it |
| 11:16 |
csharp |
oh - yeah - that's it |
| 11:16 |
csharp |
I didn't realize they were all of a piece because of the different LP numbers |
| 12:08 |
|
Jp joined #evergreen |
| 12:28 |
Jp |
. |
| 13:15 |
|
sandbergja joined #evergreen |
| 14:21 |
csharp |
we're seeing the same kind of actor drone exhaustion that Dyrcona and jeffdavis have previously reported |
| 14:21 |
csharp |
I'll see if I can test berick's fix for bug 1896285 |
| 14:21 |
pinesol |
Launchpad bug 1896285 in Evergreen "Use batch methods for multi-row grid actions" [Medium,Confirmed] https://launchpad.net/bugs/1896285 |
| 14:23 |
jeffdavis |
^ should mention I re-tested those fixes, one seemed to work the second time around but I still saw drone exhaustion on the other test case. I need to revisit and properly report results. |
| 14:44 |
pinesol |
[evergreen|Chris Sharp] Forward-port 3.4.4-3.4.5 version upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a76b279> |
| 14:46 |
pinesol |
[evergreen|Chris Sharp] Forward-port 3.5.1-3.5.2 version upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f7fe764> |
| 14:52 |
pinesol |
[evergreen|Jason Boyer] Forward-port 3.6.1 upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0297d91> |
| 17:02 |
|
mmorgan left #evergreen |
| 17:30 |
|
jeffdavis joined #evergreen |
| 17:30 |
|
Cocopuff2018 joined #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:39 |
|
Cocopuff2018 joined #evergreen |
| 05:54 |
|
rjackson_isl_hom joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:48 |
|
collum joined #evergreen |
| 08:04 |
|
Dyrcona joined #evergreen |
| 08:23 |
|
rfrasur joined #evergreen |
| 11:21 |
|
Cocopuff2018 joined #evergreen |
| 11:24 |
|
rjackson_isl_hom joined #evergreen |
| 12:11 |
mmorgan |
Can a partial cut command be included in a print template? One of our libraries wants to create a 2-part receipt. |
| 12:16 |
jeff |
many variables there. the most likely route to success will be to see what font your printer considers its "control font", and what character in that font signals a partial cut. |
| 12:16 |
jeff |
i haven't tested that enough to know if any of the ways Evergreen currently prints present a particular challenge to that approach. |
| 12:16 |
|
jihpringle joined #evergreen |
| 12:26 |
|
sandbergja joined #evergreen |
| 12:41 |
|
collum joined #evergreen |
| 14:05 |
Dyrcona |
Nope. Still broken. |
| 14:08 |
csharp |
maybe private browsing is not storing some sort of cookie or something? |
| 14:09 |
|
sandbergja joined #evergreen |
| 14:09 |
jeff |
Dyrcona: do you have a test url you can share here or via msg? |
| 14:10 |
jeff |
I wonder if something's tripping up Enhanced Tracking Protection in Firefox. |
| 14:10 |
Dyrcona |
jeff: You can't access it without a firewall. Also, I need to retest the bug. |
| 14:10 |
Dyrcona |
s/firewall/vpn/ |
| 14:11 |
Dyrcona |
Or, rather, a vpn for the cw mars firewall. |
| 14:11 |
JBoyer |
I'm guessing Private mode doesn't allow access to shared workers or databases. FYI, I can see this problem on demo.evergreencatalog.com |
| 14:11 |
JBoyer |
so there's a pretty available test site |
| 14:11 |
Dyrcona |
It looks like something like that, yeah. |
| 14:11 |
jeff |
oh, workstation registration... i was trying patron self-reg. reading comprehension failure, sorry. |
| 14:12 |
JBoyer |
Well, I guess if I read it a little closer it looks like shared workers are allowed, because they're complaining about not being able to get lovefield working. :) |
| 15:54 |
JBoyer |
Ah, I'll check that one out, much better than opening dev tools and then right-clicking reload which is what I normally end up doing. |
| 15:54 |
|
sandbergja joined #evergreen |
| 16:14 |
|
Cocopuff2018 joined #evergreen |
| 16:50 |
mmorgan |
JBoyer: Dyrcona: I'm testing this Chrome plugin to do the cache clearing and have had success: https://chrome.google.com/webstore/detail/hard-refresh/ichmdelihgokllcnibkcpciljnggojkj |
| 17:10 |
|
mmorgan left #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 20:16 |
|
sandbergja joined #evergreen |
| 21:35 |
|
sandbergja joined #evergreen |
| 21:49 |
|
rjackson_isl_hom joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:17 |
|
rjackson_isl_hom joined #evergreen |
| 08:01 |
|
Dyrcona joined #evergreen |
| 08:10 |
|
mantis2 joined #evergreen |
| 08:41 |
mmorgan |
:) |
| 08:41 |
Dyrcona |
I suppose I could delete some of these. I guess I kept them thinking that I might either need them again or want to look at them for some reason. |
| 08:45 |
Dyrcona |
Some of them look like I was just playing around with command or functions. |
| 08:49 |
Dyrcona |
Yeah, experiments, tests, one shots, and things that I used to years ago, but are no longer needed. |
| 08:58 |
Dyrcona |
I could organize this particular set of files a bit better. I'm finding some things that will be useful for our next upgrade, I guess because I wrote them for a previous upgrade. |
| 09:07 |
csharp |
Dyrcona: yeah, I have a lot of those fix-and-forget scripts that I've kept around too |
| 09:07 |
csharp |
I try to name them something that I might have a chance of remembering later |
| 14:47 |
Dyrcona |
Is the first one you've installed with Ubuntu 18.04? If so, it could be that previous versions of the XPath software were not enforcing that rule. |
| 15:34 |
Bmagic |
that sounds more like the cause |
| 15:40 |
|
mantis2 left #evergreen |
| 16:16 |
mmorgan |
I have a test server running (finally!) and am testing making changes to Angular files. I'm not seeing my changes in the web client. |
| 16:17 |
mmorgan |
I make a change, do the ng build --prod to compile, but I'm missing the step(s) to get the compiled files where they belong. |
| 16:17 |
berick |
mmorgan: copy them to /openils/var/web/eg2/en-US/ |
| 16:18 |
berick |
and copy them from your checkout at Open-ILS/web/eg2/en-US/ |
| 16:18 |
mmorgan |
berick: Just copy them? Thought I had tried that, but will try again. |
| 16:19 |
berick |
yeah, should be fine to just copy them over |
| 16:21 |
mmorgan |
berick: Do services need restarting after the copy? |
| 16:21 |
berick |
mmorgan: nope, but a browser cache clear or hard refresh likely will be |
| 16:22 |
mmorgan |
Ok, good to know. Giving it a try. |
| 16:29 |
mmorgan |
Hmm. Not seeing the changes. Using bug 1855761 to test. Still seeing the typo 'Succeessfully' |
| 16:29 |
pinesol |
Launchpad bug 1855761 in Evergreen "Typo when creating new carousel mapping" [Low,Confirmed] https://launchpad.net/bugs/1855761 |
| 16:29 |
|
sandbergja joined #evergreen |
| 16:44 |
mmorgan |
Oh. 'Succeessfully' appears in other files, too. I do see a result from my changes, though, so |
| 17:53 |
|
mantis2 joined #evergreen |
| 17:53 |
|
mantis2 left #evergreen |
| 17:56 |
|
mmorgan left #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:06 |
jeffdavis |
200 max children for open-ils.actor, "no children available" starting at 14:03:15.146000, no sudden spike in open-ils.actor calls beforehand and only 269 such calls in the 10 mins leading up to it |
| 18:08 |
jeffdavis |
lots of open-ils.actor NOT CONNECTED TO THE NETWORK errors immediately afterward, starting at 14:03:15.435596 (almost exactly 0.3s after the first "no children available" error), which seems like a consequence of no children available |
| 18:12 |
jeffdavis |
actor drone count was 21/200 at 14:03:04 and 200/200 at 14:03:19 |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:34 |
|
rjackson_isl_hom joined #evergreen |
| 08:03 |
|
rfrasur joined #evergreen |
| 08:07 |
|
mantis2 joined #evergreen |
| 08:08 |
Dyrcona |
Umm... Why are columns out of order in a table after a pg restore? |
| 08:09 |
Dyrcona |
Maybe I should ask in #postgresql? |
| 08:11 |
Dyrcona |
So, in a Pg 12 database restored from a 9.6 dump, the hold and cancel_time fields in action.hold_transit_copy are swapped compared to the order that they had in the source database. |
| 08:12 |
Dyrcona |
This makes testing my update script impossible. |
| 08:13 |
Dyrcona |
Grr... I'll have to ask in #postgresql. I can't have this happening. |
| 08:18 |
csharp |
I'm under the impression that column order is not static unless you ask for it in a select, but I haven't investigated that recently |
| 08:19 |
Dyrcona |
I suspect it has something to do with the inheritance on action.transit_copy, too. |
| 08:32 |
Dyrcona |
Oh! It'd different on my 9.6 database that was pg_restore'd.... So, it must be the inheritance. I suspect that cancel_time was added later. |
| 08:35 |
Dyrcona |
So table order doesn't matter, until it does. :) |
| 08:35 |
|
mmorgan joined #evergreen |
| 08:35 |
Dyrcona |
I'll have to run this script live without testing it, or I could add a rollback just to check the syntax. |
| 08:37 |
csharp |
https://stackoverflow.com/a/285740/1692794 - I learned that you can see the order in pg_attribute.attnum but also learned that changing that is a pain |
| 08:40 |
Dyrcona |
csharp: That's interesting, but the order of the columns in the destination table hasn't changed, so I'll just select the columns in that order, and I should be good to go. |
| 08:45 |
Dyrcona |
I think I'm leaning toward joining the camp of "table inheritance considered harmful." |
| 16:59 |
|
JBoyer joined #evergreen |
| 17:16 |
|
mmorgan left #evergreen |
| 17:49 |
|
rjackson_isl_hom joined #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:42 |
|
Cocopuff2018 joined #evergreen |
| 19:04 |
|
sandbergja joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:13 |
|
rjackson_isl_hom joined #evergreen |
| 08:12 |
|
collum joined #evergreen |
| 08:16 |
|
collum_ joined #evergreen |
| 08:31 |
|
mmorgan joined #evergreen |
| 09:29 |
|
mantis2 joined #evergreen |
| 09:50 |
|
rlefaive joined #evergreen |
| 10:18 |
jeff |
Looking at hold policy, there doesn't seem to be a way to limit the number of holds on items of a given circ modifier... you can say "if you're placing a hold on KIT you can only have X hold requests total", but it's not "you can only have X other KIT hold requests"... I wonder if any of the bib-level tests do better. |
| 10:19 |
jeff |
(it's tricky of course, because 1) it's holds and 2) your other title holds may be a mix of KIT and something-else in terms of eligible copies for each hold) |
| 10:22 |
csharp |
I guess we need the equivalent of circ limit sets for holds? |
| 10:23 |
csharp |
reworking holds policies should be on the Big Board so we can enable things like fallthrough too |
| 10:24 |
jeff |
capturing items that the patron can't actually check out is also annoying, but we're discussed that here before. :-) |
| 15:36 |
jeffdavis |
I see the default install location for simple2zoom has changed from /usr/bin to /usr/local/bin in Ubuntu 18.04 |
| 15:38 |
|
mantis2 left #evergreen |
| 15:54 |
|
sandbergja joined #evergreen |
| 16:58 |
mmorgan |
berick: Just wanted to report that I had to comment out the npm run test to get the ansible script to complete in my VirtualBox VM. Evergreen appears to be running, but I can't connect to it from my browser. Will quit while ahead and revisit next week. |
| 16:58 |
|
rlefaive joined #evergreen |
| 16:59 |
|
Cocopuff2018 joined #evergreen |
| 17:04 |
|
mmorgan left #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:15 |
|
rlefaive joined #evergreen |
| 20:16 |
|
Cocopuff2018 joined #evergreen |
| 21:20 |
|
rlefaive joined #evergreen |
| 00:35 |
|
sandbergja joined #evergreen |
| 01:00 |
|
sandbergja joined #evergreen |
| 04:52 |
|
khuckins joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:18 |
|
rjackson_isl_hom joined #evergreen |
| 08:03 |
|
collum joined #evergreen |
| 08:10 |
|
mmorgan joined #evergreen |
| 09:54 |
csharp |
based on a discussion here, we did combine our KPAC customizations into a megacommit, but that was better than the sprawl that was there before |
| 09:55 |
csharp |
the principle I try to work from is thinking of a "feature" (or fix) as a unit |
| 09:58 |
Dyrcona |
csharp: Yes, I try to do that, and then a year or two later, everything gets squashed into 1 megacommit. :) |
| 09:59 |
Dyrcona |
Right now, I'm deciding between making a branch for one of my test VMs with modifications from the production configuration or just use a sed script. I'm leaning toward a branch. |
| 10:01 |
Dyrcona |
What I should probably do at this point is split the configuration changes, i.e. those touching Open-ILS/examples from the custom code, i.e. just about everything else. |
| 10:03 |
Dyrcona |
I used to maintain separate branches for configuration vs. custom templates and code modifications, then it all ended up in one branch, and over time the commits got squashed and squashed again until it all ended up in 1 commit. |
| 10:04 |
csharp |
THERE CAN BE ONLY ONE (commit) |
| 11:03 |
Dyrcona |
Y'know, now would also be a good time to convert our logos from JPEG to PNG. |
| 11:13 |
csharp |
yeah, releases are Wednesday if you're around - if not, no big |
| 11:20 |
Dyrcona |
OK. We'll see how things go. |
| 11:20 |
JBoyer |
Speaking of releases... lp 1904220 is a very simple thing to test |
| 11:20 |
pinesol |
Launchpad bug 1904220 in Evergreen 3.5 "determine_booking_status in OpenILS::Application::Circ::Circulate breaks when changing router names" [Medium,New] https://launchpad.net/bugs/1904220 |
| 11:49 |
Dyrcona |
Also, sed++ imagemagick++ |
| 12:08 |
|
Christineb joined #evergreen |
| 17:37 |
|
mmorgan left #evergreen |
| 17:42 |
Bmagic |
mmorgan++ |
| 17:42 |
Bmagic |
csharp++ |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:51 |
|
sandbergja joined #evergreen |
| 20:48 |
|
sandbergja joined #evergreen |
| 21:34 |
|
sandbergja joined #evergreen |
| 03:04 |
|
Hello joined #evergreen |
| 03:04 |
|
Hello left #evergreen |
| 05:25 |
|
troy__ joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:19 |
|
rjackson_isl_hom joined #evergreen |
| 08:36 |
|
mmorgan joined #evergreen |
| 08:45 |
|
Dyrcona joined #evergreen |
| 10:48 |
Dyrcona |
That's how I interpreted jeff's comment about it being "accidental" yesterday. |
| 10:49 |
mmorgan |
The "accident", seamless capture of equivalent copies, is a much preferred behavior. Without the op-capture, staff members find it hugely time consuming to match barcodes, and frustrating to not be able to fill a hold when they can't find the exact copy. |
| 10:49 |
Dyrcona |
One person's bug is another's feature. :) |
| 10:51 |
miker |
confirmed that there are significant performance implications. I can see a way to make it work, maybe, but lots of testing on various sized data sets would be needed ... the change is small in lines of code (probably 2) but big in terms of potential impact |
| 10:53 |
miker |
mmorgan: I can absolutely understand that! the baseline expectations today are much different than 2004 ... op-capture /at all/ was unthinkably magical back then (to staff used to ... a certain proprietary ILS) :) |
| 10:56 |
csharp |
also, PINES was in the middle of courier paralysis at the time that feature was added (if I know my history) |
| 10:57 |
csharp |
after the courier delays were improved, the need for stalling disappeared (we just this summer turned it off) |
| 10:59 |
mmorgan |
And now we have COVID quarantines, causing long delays with items needing to travel to fill holds, so we just recently turned it on, never having used it before :) |
| 11:01 |
* mmorgan |
is happy to open a bug, and would be happy to test 2-ish lines of code on a large data set :) |
| 11:02 |
csharp |
yeah, some of the courier delays have definitely returned |
| 11:03 |
Dyrcona |
csharp: While you're here, can I ask a couple of questions about Quipu? |
| 11:08 |
|
stompro_ joined #evergreen |
| 11:16 |
miker |
mmorgan: having looked, it's going to be a lot more than 2 lines ;) |
| 11:21 |
miker |
the main problem is, when you're capturing holds you're not saying "here's a hold, capture any copy at this location" you're saying "here's a copy, give me holds it could fill in proximity order". when stalling is enabled what you're really saying is "the PL-to-copy proximity must be 0". the current copy part is separate. here's what the code does: |
| 11:22 |
miker |
1) first look for holds that target the copy in hand. hold onto that list for later |
| 11:23 |
miker |
2) sort holds the copy in hand could fill by "best-ness" per best-hold-sort-order and proximity adjustment rules |
| 11:23 |
miker |
3) run the permit tests on the "best" ordered holds, and return the first permitted |
| 11:25 |
miker |
4) if no "best" ordered holds passed the permit tests, look at that first directly-targetted, stashed list and run the permit tests on those, returning the first that passes |
| 11:29 |
mmorgan |
Hmm. More -ish, than 2, then ;-) |
| 11:29 |
miker |
and (2) is where we run into problems. we're sorting holds-for-this-copy, and stalling specifically says "only look at holds for this copy where the proximity is 0". The directly-targeted hold test comes later and, again, is only about this copy in hand. |
| 11:30 |
|
stompro__ joined #evergreen |
| 11:30 |
miker |
(note, there are some short cuts / optimizations in the actual code -- we merge the lists, we don't do 2 separate loops -- but that's just code ordering stuff) |
| 11:33 |
mmorgan |
Maybe 0) could identify equivalent copies and proceed to 1) for that set of copies? Just brainstorming... |
| 11:33 |
miker |
we never actually see the desired hold in either list, because ALL the info we have is 1) the copy in hand 2) the stalling interval for this location. everything else is derived. adjacent copies are never seen because we're never looking from the point of view of the /holds/ on the pull list, we're looking from the point of view of the copy in hand |
| 11:33 |
|
stompro_ joined #evergreen |
| 14:06 |
jeffdavis |
strongly considering ripping out the level 0 version on prod servers, this problem is not going away |
| 14:08 |
Dyrcona |
We made it stop by deleting a closed date that was causing the problem. It seems to happen when it latches onto a closed date as an open date or something. |
| 14:09 |
Dyrcona |
I'm not sure how to explain it, really. |
| 14:10 |
Dyrcona |
One thing I noted in testing is that it didn't matter if it was a multi-day closing or a single day closing that fell on the particular date. |
| 14:11 |
jeffdavis |
hm, noticing that the apparent problem libraries have no open hours at all in actor.hours_of_operation |
| 14:12 |
Dyrcona |
jeffdavis: That's one thing that will do it. In our case it was a library open only 1 day/week. |
| 14:13 |
jeffdavis |
These libraries are doing circs but have no open hours, seems like that is going to be a problem for setting a due date. |
| 15:13 |
sandbergja |
make -f Makefile.install fossa? |
| 15:13 |
Dyrcona |
:) |
| 15:14 |
Dyrcona |
So, I guess the question is when to merge the branches and fork the rel_3_3 and rel_3_7 branches, and maybe we don't need an answer today. |
| 15:14 |
JBoyer |
Looks like some more testing is needed to get those branches in, but that should easily be achievable by the ~3.7 timefram.e |
| 15:15 |
JBoyer |
"Looks like" meaning they're not all signed off yet, but I imagine they'll be no trouble. |
| 15:15 |
gmcharlt |
yeah, and easy enough to get OpenSRF 3.3 out the door sooner than EG 3.7 |
| 15:16 |
JBoyer |
#agreed The removal of Python and Java will be a part of the 3.3 OpenSRF and 3.7 Evergreen releases |
| 15:16 |
Dyrcona |
I think it's worth mentioning again that if you test the Focal Fossa branches, you are effectively testing all 3, since the Focal branches depend on the Python and Java branches. |
| 15:16 |
abowling |
#info abowling = Adam Bowling, Emerald Data Networks |
| 15:17 |
JBoyer |
Do all 3 need to be applied manually or does the fossa branch basically include the others? |
| 15:17 |
* JBoyer |
goes to look after lazygoogling |
| 15:18 |
Dyrcona |
JBoyer: The Fossa branch includes the other two, yes. |
| 15:18 |
JBoyer |
Excellent, ok. So easy to test then. |
| 15:18 |
berick |
good summary http://list.evergreen-ils.org/pipermail/evergreen-dev/2020-October/000053.html |
| 15:19 |
JBoyer |
berick++ |
| 15:19 |
JBoyer |
ok, hopefully some Ubuntu VMs will be spun up and those branches taken for a spin. Any further OpenSRF discussion? |
| 15:30 |
JBoyer |
Does anyone have any further information to bring to the table re: Pg10+ ? |
| 15:30 |
JBoyer |
I know there are a couple production upgrades in the planning phases, but haven't heard anything else. |
| 15:31 |
csharp |
we won't be moving to it until late winter/early spring at this point |
| 15:31 |
Dyrcona |
We're sticking with 9.6 for now. I have a test server with 9.6 through 12 installed. |
| 15:31 |
csharp |
Dyrcona++ # pioneering |
| 15:31 |
Dyrcona |
Um, 9.6 through 13, now. I installed 13 last month. |
| 15:32 |
Dyrcona |
I'm not sure how we should go about benchmarking things, but I can say that performance seems to change quite a bit on 12 versus 9.6 and 10. |
| 15:33 |
JBoyer |
odd benchmarking aside, you haven't noticed anything like the changes in Pg10 where things we were doing in 9.6 and below would just blow up anywhere, correct? |
| 15:34 |
Dyrcona |
Not so far. It looks like we've caught those. I haven't seen anything just blow up on 12, either, and I've been using it as my main test db. |
| 15:34 |
JBoyer |
That's promising. |
| 15:35 |
|
jihpringle joined #evergreen |
| 15:36 |
JBoyer |
Ok. If there's no more discussion to be had about Pg10 I feel like we've already covered the Fossa / -Python / -Java discussions, does anyone have any new business that didn't hit the agenda? |
| 17:03 |
Bmagic |
found this in the logs: Not changing edi_account because we found (2) matching vendacct(s), one of which being on the edi_account we already had |
| 17:03 |
Bmagic |
followed by: changing edi_account from 104 to 103 based on vendacct 'xxxxxx' (2 match(es)) - there we go! That's the smoking gun |
| 17:05 |
|
mmorgan left #evergreen |
| 18:13 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:23 |
|
jihpringle joined #evergreen |
| 18:46 |
devted |
Closed Dates Editor question: question: Is it normal to see past emergency closings with unprocessed portions in the Closed Dates Editor? (ie, 1/34 holds) |
| 18:47 |
devted |
Closed Dates Editor question #2: Also, is it normal to see past emergency closings with 0/0 processed portions in the Closed Dates Editor? |
