| 11:56 |
pinesol |
Launchpad bug 1923076 in Evergreen 3.6 "Incorrect typing when encoding some values as JSON" [Medium,Confirmed] |
| 11:57 |
Dyrcona |
Meahwhile...It's lunch time for me. |
| 12:08 |
|
jihpringle joined #evergreen |
| 12:38 |
Dyrcona |
So, I think I've come across one that I can't test on concerto, but I'm pretty sure it needs a patch: open-ils.circ.hold.clear_shelf.process |
| 12:51 |
miker |
Dyrcona++ |
| 12:58 |
Dyrcona |
miker: There are a couple that I'm sure don't need fixes, but I'm unsure about this one: Open-ILS/src/perlmods/lib/OpenILS/Application/Storage/Driver/Pg/storage.pm:401: return scalar(@fm_nodes); |
| 12:59 |
Dyrcona |
I had trouble find a context where it is used, so I moved on. |
| 14:37 |
Dyrcona |
I think we should ditch Perl, tbh. Seems like every few years we play whack-a-mole with nonsense like this. |
| 14:44 |
Dyrcona |
I'm testing Cpanel::JSON::XS on buster. Looks like all of the necessary changes are limited to 1 file. |
| 14:46 |
Dyrcona |
I still get some numbers that are strings, but the superpage size one is fixed. I'm gonna see if my tests pass. |
| 14:47 |
Dyrcona |
The tests that I have written pass with Cpanel::JSON::XS on the unpatched buster VM. I think switching to Cpanel::JSON::XS is easier than ditching Perl. |
| 14:49 |
Dyrcona |
So, looking at the output of these tests and some other calls, I'd say we have bigger problems than calling scalar on empty arrays and passing the results through JSON::XS. |
| 14:54 |
jeff |
Do you mean that you think Cpanel::JSON::XS fixes more things than we were focusing on? |
| 14:56 |
Dyrcona |
Yes, I do, but it still isn't perfect. I'm updating the bug. |
| 00:46 |
|
dbwells_ joined #evergreen |
| 03:05 |
|
dbwells joined #evergreen |
| 05:34 |
|
dbwells joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:25 |
|
rjackson_isl_hom joined #evergreen |
| 07:41 |
|
Dyrcona joined #evergreen |
| 07:42 |
Dyrcona |
typos-- |
| 10:50 |
Dyrcona |
I'm getting a numeric zero. |
| 10:58 |
jeff |
My understanding of why that is: the difference in behavior / characteristics is mostly in the Perl internals, which aren't available to Perl code. Things like Devel::Peek, B::*, and JSON::XS are perl extensions written in C which have access to the Perl API and can inspect the internals. JSON::XS uses this to try and treat simple scalar values correctly, but acknowledges that it's difficult. |
| 11:00 |
Dyrcona |
Yeah, well I was quickly getting into the elephant grass trying to chase a path through the Perl code itself. |
| 11:00 |
jeff |
In order to write a test case for my git bisect last night, I needed to redirect stderr to a string, so that when I called Devel::Peek::Dump() I could examine the output. |
| 11:01 |
Dyrcona |
So, when are we gonna ditch Perl? :P |
| 11:02 |
jeff |
Interesting. I don't think that the new value of scalar(my $lexical) is just any "0" with a string representation. That would be a SV = PV as shown with perl -MDevel::Peek -e '$str = "0"; Dump($str);' |
| 11:03 |
Dyrcona |
Admittedly, I need to get better at reading Devel::Peek output. |
| 11:06 |
* jeff |
nods |
| 11:07 |
jeff |
perlguts documents the various SV types |
| 11:08 |
Dyrcona |
On perl 5.26, it's PV = IV with or without my. |
| 11:09 |
jeff |
I think the first priority is to fix / work around the identified issues, then do a little looking to see if we have any other similar issues, and as/if time allows, gather some test cases and bring them to the attention of Perl hackers to see if this is something that needs any action on their part (fixing a bug, documenting the change in behavior, etc). |
| 11:09 |
Dyrcona |
perl -MDevel::Peek -e '@ar = (); $str = scalar @ar; Dump($str);' |
| 11:10 |
jeff |
There is a lot of elephant grass to go around. :-) |
| 11:11 |
Dyrcona |
And, I meant SV = IV when I typoed, PV = IV above, just for the logs. |
| 15:46 |
Dyrcona |
miker++ |
| 15:48 |
miker |
oh, I should mention, I also excluded all uses where the return value of scalar() was used inline with a numberish operator, like addition or multiplication, which forces numeric context and should be safe (per 0+ working) |
| 15:48 |
miker |
I basically limited the list to where it was not obviously safe |
| 15:59 |
JBoyer |
miker, I'm not so sure about your "I've excluded uses that are only used in truthiness tests..." from lp 1923076 , I got the impression that simply subjecting them to the testing might be enough to twiddle some bits in their storage and make them look string-y enough for JSON::XS. |
| 15:59 |
pinesol |
Launchpad bug 1923076 in Evergreen 3.6 "Incorrect typing when encoding some values as JSON" [Medium,Confirmed] https://launchpad.net/bugs/1923076 |
| 16:00 |
JBoyer |
Though I've mostly been at the edges of this discussion, if that's not what's actually happening that's great. |
| 16:00 |
miker |
JBoyer: oh, I mean like "if (scalar(@foo))" and the like |
| 16:07 |
gmcharlt |
as a general announcement: I'm planning on cutting 3.7-rc on Monday and the 3.7.0 release on Wednesday |
| 16:12 |
|
jvwoolf joined #evergreen |
| 16:26 |
|
akilsdonk_ joined #evergreen |
| 16:27 |
jeff |
miker: and just think, any times where we're testing an empty @lexical in a boolean context, it's ~314% faster because of the optimization present in Perl 5.28! |
| 16:32 |
|
mantis left #evergreen |
| 16:58 |
miker |
jeff++ |
| 17:17 |
|
mmorgan left #evergreen |
| 17:43 |
Dyrcona |
Correct > Fast. |
| 17:43 |
Dyrcona |
Perl-- |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:32 |
|
sandbergja joined #evergreen |
| 21:27 |
|
JBoyer joined #evergreen |
| 22:05 |
jeffdavis |
Lots of symspell-related deadlocks trying to import records in parallel on a 3.7 system |
| 00:00 |
|
sandbergja joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:18 |
|
rjackson_isl_hom joined #evergreen |
| 08:02 |
|
collum joined #evergreen |
| 08:29 |
|
mantis joined #evergreen |
| 11:51 |
|
jihpringle joined #evergreen |
| 11:56 |
|
dbwells joined #evergreen |
| 12:16 |
|
jamesrf joined #evergreen |
| 12:19 |
Dyrcona |
jeffdavis: Going to back to your thing with holds counts yesterday, it looks like the real culprit is open-ils.actor.user.hold_requests.count. I've only tested it on Perl 5.30 so far, and it returns the holds available count as a string. |
| 12:24 |
Dyrcona |
Seems bizarre that it would do that, though. The total field is returned as a number, and the way they're calculated *should* be functionally equivalent. |
| 12:24 |
Dyrcona |
I have a suspicion of how to fix it, though. |
| 12:25 |
jeffdavis |
I'm happy to test any ideas you might have. :) |
| 12:32 |
Dyrcona |
Hm... eg_db_config through some errors for me on Ubuntu 18.04. I need to check that before I can go on. |
| 12:35 |
Dyrcona |
OK. I have to install some prerequisites. |
| 12:43 |
Dyrcona |
In Perl 5.26 it's a number. That's really bizarre and must be some kind of Perl bug. |
| 12:43 |
|
dbwells joined #evergreen |
| 12:44 |
|
collum joined #evergreen |
| 12:50 |
Dyrcona |
And, it doesn't happen with a little Perl script intended to test the problem. so it's more complicated than it appears at first glance. |
| 12:54 |
Dyrcona |
So, my "fix" resolves it, but I think it's just patching over the real problem, which I suspect is buried in OpenSRF somewhere. I was not able to reproduce the behavior with a simple Perl script. |
| 12:55 |
Dyrcona |
We should have to go adding int() around all of our uses of scalar(@array)... |
| 12:56 |
Dyrcona |
s/should/shouldn't/ |
| 13:13 |
Dyrcona |
Might be it. I'll see if I can find where we use JSON to turn off allow_nonref. |
| 13:14 |
jeffdavis |
Seems like it might only be an issue where ready = 0? For a user with 1 or more holds ready, the result is an int rather than a string. |
| 13:15 |
Dyrcona |
I don't think that's it after reading the documentation, unless there's a bug with that setting. |
| 13:15 |
Dyrcona |
jeffdavis: I only tested with a handful of concerto patrons, none of whom turned out to have holds. |
| 13:16 |
jeff |
also interesting, https://metacpan.org/source/ISHIGAKI/JSON-4.03/Changes#L25 "allow PERL_JSON_PP_USE_B environmental variable to restore old number detection behavior for compatibility" |
| 13:17 |
Dyrcona |
We already turn allow_nonref on. |
| 13:17 |
jeff |
and: |
| 14:54 |
|
mantis joined #evergreen |
| 14:54 |
jeff |
I see a difference with Perl 5.32.1 with JSON::PP 4.04 vs JSON::XS 4.03. I see the documented behavior of scalars with a string context (where there's a PV and FLAGS includes PV/PVOK): the value is quoted. |
| 14:58 |
jeff |
Dyrcona: what version of JSON::XS are you running on your Ubuntu 18.04 system? |
| 15:02 |
Dyrcona |
jeff: This is Ubuntu 20.04 where I'm testing, the one that show the bug. |
| 15:02 |
jeff |
yep, got that. |
| 15:03 |
* jeff |
looks on packages.ubuntu.com |
| 15:03 |
Dyrcona |
Ubuntu 20.04 has 4.02 |
| 15:03 |
Dyrcona |
Ubuntu 18.04 has 3.02. |
| 15:04 |
Dyrcona |
I see the bug when I use srfsh to make the request, but trying to emulate what looks like the problematic code on 20.04 turns up nothing. |
| 15:04 |
Dyrcona |
I updated all packages before testing today. |
| 15:06 |
Dyrcona |
I have 5.32.1 on a FreeBSD server. |
| 15:07 |
pastebot |
"Dyrcona" at 168.25.130.30 pasted "Here's my latest test" (10 lines) at http://paste.evergreen-ils.org/10132 |
| 15:11 |
Dyrcona |
I get identical results on both Ubuntu servers with the above. I don't have Evergreen on the FreeBSD machine, so I won't test it there. |
| 15:12 |
Dyrcona |
Also, don't have JSON::XS on FreeBSD... |
| 15:12 |
Dyrcona |
I could install it, but this isn't a machine that I use for development. |
| 15:13 |
Dyrcona |
Maybe I should switch from ZZ Top to Jefferson Airplane.... :) |
| 15:15 |
mantis |
running 3.5.4 on a test server and images are failing to load in the catalog |
| 15:23 |
Dyrcona |
mantis: All images or just added content/book jackets? |
| 15:25 |
mantis |
content jackets |
| 15:26 |
mantis |
I'm not sure why that happened |
| 15:26 |
Dyrcona |
Did you configure the added content provider in opensrf.xml? |
| 15:26 |
Dyrcona |
I think that's where it goes.... |
| 15:36 |
jeff |
okay, I think I have a simple (yet still relevant) test that demonstrates a difference in behavior between Perl 5.26.3 and Perl 5.32.1, both with JSON::XS 4.03. I'm going to try and narrow down where it changes. |
| 15:38 |
Dyrcona |
jeff: Can you paste the test? I'd like to see it. |
| 15:38 |
mantis |
Dyrcona: thanks I'll take a look at it |
| 15:38 |
mantis |
Dyrcona++ |
| 15:39 |
|
mantis left #evergreen |
| 15:41 |
jeff |
here's the test and output under 5.26.3 and 5.32.1 so far, with some Devel::Peek Dump() output to help see where the flags are: https://gist.github.com/jeff/6ab1d188db2cd21ac1d45cf06544d7d2 |
| 15:42 |
jeff |
I'm installing 5.28 and 5.30 to help identify where the change was introduced. |
| 15:45 |
Dyrcona |
jeff: Interesting. My tests haven't done that. |
| 15:45 |
|
dbwells joined #evergreen |
| 15:48 |
miker |
oh, my, that's terrible if scalar() returns strings now |
| 15:49 |
jeff |
miker: not obvious in that simplified test, but it seems to only be when we have an empty array. |
| 15:50 |
Dyrcona |
Yeah, but I can't make it do that. jeff's test does for me, but my tests don't. |
| 15:53 |
jeff |
5.28.3 does it also. |
| 15:53 |
jeff |
updated gist with new output |
| 15:53 |
|
jihpringle joined #evergreen |
| 16:02 |
miker |
so do we just need to spell it 0+scalar(@bar) then? |
| 16:02 |
jeff |
> A new kind of magic scalar, called a "nonelem" scalar, has been introduced. It is stored in an array to denote a non-existent element, whenever such an element is accessed in a potential lvalue context. |
| 16:02 |
jeff |
but I'm not sold on that being related. |
| 16:04 |
miker |
changing jeff's test to that (cast to number by prepending 0+ ) "fixes" foo for me on 5.28 |
| 16:04 |
Dyrcona |
miker: int(scalar(...)) works, too. |
| 16:05 |
miker |
Dyrcona: yeah, either way ... s/scalar\(/0+scalar(/g in vim is easier though ;) |
| 16:06 |
Dyrcona |
What's weird is I'm not seeing it with the scripts that I pasted earlier. |
| 16:11 |
Dyrcona |
Also, looks like anyone using Debian Buster in production would see this, too. |
| 16:12 |
miker |
Dyrcona: I understand, I meant internal to opensrf perl code, not evergreen application code (looking for Worse Problems :) ) |
| 16:13 |
Dyrcona |
Right. |
| 16:16 |
jeff |
Dyrcona: that is interesting that your tests using OpenSRF libs aren't showing the problematic behavior. I modified one of your recent ones to use JSON::XS directly and it shows the same issue with the same versions (no surprise, since it's almost the same as one of my tests now): https://gist.github.com/jeff/a4fd184305f0a7870258040e3e3ce702 |
| 16:18 |
jeff |
"Various integer-returning ops are now more efficient in scalar/boolean context." |
| 16:18 |
jeff |
(also from perl5280delta) |
| 16:18 |
jeff |
"Converting a single-digit string to a number is now substantially faster." |
| 16:20 |
Dyrcona |
jeff: I didn't get it when I used the JSON::XS object interface, either. |
| 16:23 |
Dyrcona |
So, should we add this to Lp? |
| 16:24 |
miker |
jeff: "... faster, because it doesn't happen" ;) |
| 17:37 |
|
mmorgan left #evergreen |
| 17:46 |
jeffdavis |
Python 3 also makes installing translations "fun" on Ubuntu 20.04. |
| 17:46 |
jeffdavis |
Starting to wonder if we should stick with 18.04 for our upgrade. :( |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:42 |
|
sandbergja joined #evergreen |
| 19:45 |
|
dbwells joined #evergreen |
| 22:09 |
|
sandbergja joined #evergreen |
| 13:00 |
|
sandbergja joined #evergreen |
| 13:06 |
|
jamesrf joined #evergreen |
| 13:32 |
|
jihpringle joined #evergreen |
| 13:49 |
jeffdavis |
On my 3.7 beta test server, initial retrieval for any patron account results in a blank alert message - you get redirected to the Other tab with a STOP sign and the "Press a navigation button above (for example, Check Out) to clear this alert." message, but there is no alert. |
| 13:52 |
jeffdavis |
Test users are active, not expired/deleted/barred, card is active, no alert message, no standing penalties, no holds ready, no invalid addresses. Once the alert is cleared, it does not appear again for that patron. |
| 14:00 |
JBoyer |
jeffdavis, that sounds familiar. I've seen that happen when the number of holds available is formatted as a string rather than a number because 0 is false and "0" is true. |
| 14:00 |
JBoyer |
I thought there was a patch for that (unless this is a new instance of a similar issue) |
| 14:01 |
jeffdavis |
JBoyer++ |
| 14:47 |
|
dbwells joined #evergreen |
| 14:52 |
|
stephengwills joined #evergreen |
| 14:56 |
|
jihpringle joined #evergreen |
| 15:20 |
jeffdavis |
The test server where I'm seeing the issue is running Ubuntu 20.04. I tried installing the same OpenSRF/EG branches on an 18.04 server and cannot replicate the error there. |
| 15:21 |
jeffdavis |
(Perl v5.30.0 vs v5.26.1) |
| 15:22 |
|
jihpringle joined #evergreen |
| 15:29 |
rhamby |
r |
| 15:31 |
JBoyer |
No, I was definitely looking specifically at this ready_holds: "0" issue and more recently than that bug was last updated, but I'm having a hard time finding *where* I was looking at it. :( |
| 16:31 |
Dyrcona |
Oh well, time's up. I'll have a look tomorrow. I suspect it had more to do with Ubuntu 20.04 than the version of Evergreen. |
| 16:57 |
|
jvwoolf left #evergreen |
| 17:32 |
|
mmorgan left #evergreen |
| 18:00 |
pinesol |
News from qatests: Failed Installing Angular web client <http://testing.evergreen-ils.org/~live//archive/2021-04/2021-04-06_16:00:02/test.29.html> |
| 19:36 |
|
sandbergja joined #evergreen |
| 22:01 |
|
sandbergja joined #evergreen |
| 23:04 |
|
jamesrf joined #evergreen |
| 00:07 |
|
khuckins joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:37 |
|
jeff joined #evergreen |
| 07:15 |
|
khuckins joined #evergreen |
| 07:18 |
|
rjackson_isl_hom joined #evergreen |
| 09:09 |
|
alynn26 joined #evergreen |
| 09:15 |
|
jvwoolf joined #evergreen |
| 09:33 |
|
mmorgan1 joined #evergreen |
| 09:56 |
mantis1 |
A library staff member contacted me recently asking if we have a new feature. They are finding that when searching for a title after logged into the opac, they will get a "I have checked this out before" note in the results. I'm trying to replicate on my end but unsure what features need to be enabled to see this. I enabled circ history and checked out/in a few test items, searched for them, but won't find the note. |
| 10:09 |
collum |
mantis1 - There is a setting in the Library Settings Editor entitled "Tag Circulated Items in Results" that needs to be set to true, as well. |
| 10:26 |
mmorgan1 |
collum++ |
| 10:27 |
* mmorgan |
was looking for that but failed to find it :) |
| 11:39 |
mantis1 |
collum ++ |
| 11:49 |
Dyrcona |
collum++ |
| 12:24 |
|
jihpringle joined #evergreen |
| 13:25 |
jeffdavis |
Dyrcona: new fix incoming for that security bug, just testing now |
| 13:30 |
csharp |
jeffdavis++ |
| 13:31 |
Dyrcona |
jeffdavis++ |
| 13:57 |
miker |
jeffdavis: I have not had a chance to look at it in detail, but, I assume it does not break search result highlighting? |
| 16:32 |
|
Guest76203 joined #evergreen |
| 17:17 |
|
jvwoolf left #evergreen |
| 17:26 |
|
mmorgan left #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:39 |
|
khuckins joined #evergreen |
| 20:40 |
|
sandbergja joined #evergreen |
| 21:43 |
|
sandbergja joined #evergreen |
| 01:26 |
|
rjackson_isl_hom joined #evergreen |
| 02:16 |
|
khuckins joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 08:09 |
|
collum joined #evergreen |
| 08:33 |
|
mmorgan joined #evergreen |
| 09:24 |
|
dbwells joined #evergreen |
| 14:27 |
khuckins |
Does anyone know off the top of their head(or know where the docs exist for) how to enable outgoing email in Evergreen? I'm guessing it's somewhere in eg_vhost but not certain |
| 14:28 |
|
jvwoolf joined #evergreen |
| 14:30 |
Dyrcona |
khuckins: Depends. You want to set the return email address, or is email just not working at all? |
| 14:31 |
khuckins |
Dyrcona: email just not working at all - this is for the icelandic test server, so no need for a return address I would think |
| 14:32 |
Dyrcona |
If it's Debian or Ubuntu, you probably need to install and configure exim. |
| 14:32 |
khuckins |
Ah, I'll look into that, thanks! |
| 14:33 |
Dyrcona |
You can configure a different MTA, but exim is the default for Debian. |
| 15:44 |
rhamby |
terranm lp827356 you're running the upgrade script? |
| 15:50 |
Dyrcona |
The comment makes it look like the script was run twice. |
| 15:50 |
Dyrcona |
Or maybe the schema built from the branch and then the upgrade script run. |
| 15:52 |
rhamby |
yeah that was my thought |
| 15:53 |
rhamby |
I'm going to go back and test it as a fresh upgrade and building with it and I'll see if I can duplicate it |
| 15:53 |
rhamby |
either it ran twice somehow or the error isn't what it describes though usually postgres errors are at least close to the actual cause |
| 15:55 |
rhamby |
but it's late on a friday so who knows what chaos lurks waiting to be unleashed |
| 15:55 |
Dyrcona |
Yeahp. I was just about tot have a look on a test db upgraded to master, but the VPN keeps kicking me out today...... Chaos is already unleashed. |
| 15:55 |
terranm |
I use a script that Chris made for me that basically blows away the entire database and does a fresh install |
| 15:56 |
rhamby |
I'm building from git now so that will give me some indicator in a while |
| 15:57 |
|
mantis1 left #evergreen |
| 16:02 |
rhamby |
terranm: give me a few minutes and I'll push a fix on that branch |
| 16:03 |
terranm |
Cool beans |
| 16:03 |
Dyrcona |
rhamby++ terranm++ friday-- :) |
| 16:03 |
terranm |
I may not have time to test it until next week though |
| 16:03 |
rhamby |
yeah, that was less a bug and more a "rogan's fingers didn't do what they were supposed to at some point" |
| 16:04 |
terranm |
:) |
| 16:04 |
rhamby |
after ten years I think a few more days won't hurt :) |
| 17:30 |
|
mmorgan left #evergreen |
| 17:34 |
terranm |
You too! |
| 17:41 |
|
jvwoolf left #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:32 |
|
dbwells joined #evergreen |
| 20:29 |
|
sandbergja joined #evergreen |
| 21:37 |
|
sandbergja joined #evergreen |
| 02:08 |
|
malexander joined #evergreen |
| 04:46 |
|
khuckins joined #evergreen |
| 05:40 |
|
malexander joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:21 |
|
rjackson_isl_hom joined #evergreen |
| 08:26 |
|
mantis1 joined #evergreen |
| 08:47 |
|
alynn26 joined #evergreen |
| 10:22 |
tlittle |
I think the only place I've particularly noticed it is the Angular acq search |
| 10:22 |
Dyrcona |
Right. The syslog show a severe query error. I'm mixing terminology, sorry. |
| 10:23 |
tlittle |
*noticed empty searches go through, that is |
| 10:23 |
Dyrcona |
I can't seem to get to Angular acq search on my test vm. I'll look at production in a few minutes. Something else has come up. |
| 10:23 |
tlittle |
Good luck! :) |
| 10:58 |
csharp |
JBoyer++ |
| 10:58 |
csharp |
oh yeah - bugsquash week - I've been completely underwater and haven't been able to participate |
| 14:36 |
pinesol |
Launchpad bug 587028 in Evergreen "Inefficient asset.copy barcode index slows down circ transactions in pg 8.3" [High,Fix released] |
| 14:37 |
miker |
Dyrcona: are there generated queries that are including "not deleted"? (I haven't been following your details super close) |
| 14:37 |
Dyrcona |
miker: I don't think so. I use it a lot in my own queries, though. |
| 14:38 |
Dyrcona |
We do generate <> or !=, and that seems slower, but I haven't really tested the performance with any instrumentation. |
| 14:38 |
miker |
Dyrcona: fwiw, I use it a lot, too ... haven't noticed a problem, but, not using PG 12 yet, either |
| 14:39 |
Dyrcona |
I've been "testing" a lot on Pg 12 for the past year. |
| 14:48 |
gmcharlt |
Dyrcona: OK to push to master |
| 14:50 |
Dyrcona |
gmcharlt++ Thanks! |
| 14:58 |
|
miker joined #evergreen |
| 14:58 |
|
jweston joined #evergreen |
| 14:59 |
|
drigney joined #evergreen |
| 14:59 |
|
phasefx joined #evergreen |
| 14:59 |
Dyrcona |
Also, I've been using websocketd 0.4.1 with no issues on my test vms. |
| 14:59 |
|
abneiman joined #evergreen |
| 15:00 |
|
akilsdonk joined #evergreen |
| 15:05 |
|
sandbergja joined #evergreen |
| 17:11 |
miker |
"jub is whatever you need it to be" |
| 17:25 |
mmorgan |
Just Us Bugsquashers ;-) |
| 17:25 |
|
mmorgan left #evergreen |
| 17:25 |
terranm |
mmorgan++ |
| 17:30 |
terranm |
I've gotten to the point of my day where I can't even get vanilla master to install on my test server, so that seems like a good time to stop. |
| 17:33 |
|
nfBurton joined #evergreen |
| 17:37 |
|
jonadab joined #evergreen |
| 17:44 |
|
nfBurton joined #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:09 |
|
jihpringle joined #evergreen |
| 02:01 |
|
khuckins joined #evergreen |
| 06:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:22 |
|
khuckins_ joined #evergreen |
| 07:16 |
|
rjackson_isl_hom joined #evergreen |
| 08:28 |
|
mantis1 joined #evergreen |
| 12:31 |
|
Christineb joined #evergreen |
| 12:43 |
|
collum joined #evergreen |
| 14:02 |
|
sandbergja joined #evergreen |
| 14:05 |
terranm |
JBoyer: I'm trying to test the two LocalAdmin patches on pattypan, but neither of them are loading - can you verify? |
| 14:07 |
JBoyer |
terranm, will do. |
| 14:17 |
JBoyer |
terranm, both were applied; I rebuilt things just in case it helps. |
| 14:17 |
terranm |
Thanks, will check again in a moment |
| 14:23 |
|
dbwells joined #evergreen |
| 14:26 |
terranm |
Yeah, 1873322 isn't working for me - cleared cache and registered a brand new workstation but all the selectors are still defaulting to CONS |
| 14:27 |
JBoyer |
I'm curious if the home_ou is more important than it looks |
| 14:28 |
mmorgan |
terranm: JBoyer: I've gotten 1873322 working on a test server, at least logged in as admin |
| 14:28 |
* mmorgan |
was going to use that as an example at the newdevs meeting today. |
| 14:28 |
terranm |
Let me try on pattypan with another account |
| 14:32 |
JBoyer |
I just made admin's home ou BR1 and that didn't help either. Highly annoyed. |
| 14:32 |
JBoyer |
(with BR1 WS also) |
| 14:32 |
terranm |
I tried with a different staff account and it didn't work for that either |
| 14:32 |
mmorgan |
On my test server, the dropdown defaulted to the login workstation. |
| 14:33 |
terranm |
mmorgan++ |
| 14:33 |
terranm |
Could there be something else on pattypan that is conflicting with it? |
| 14:35 |
JBoyer |
I wouldn't think so; nothing else touches that file. :/ |
| 14:35 |
terranm |
mmorgan: since you have it working on yours and we'll be looking at it in the new devs group, I don't think there's worth spending more time on it on pattypan |
| 14:36 |
terranm |
I'll move on to testing 1844169 |
| 14:37 |
JBoyer |
I can try to get it working later unless one of you is signing off on it later today |
| 14:38 |
terranm |
We'll probably be able to sign off on 1873322 this afternoon |
| 14:39 |
JBoyer |
terranm++ |
| 14:40 |
JBoyer |
Well, maybe it's not missing... taking another look, but it's just not showing up. :/ |
| 14:45 |
terranm |
It looks like the local admin splash page update is in the patch |
| 14:47 |
JBoyer |
yeah, different format than I expected, but things just refuse to change. I threw away all of /openils/var/web/eg2/ and am building fresh because this isn't cool. |
| 14:51 |
Dyrcona |
Is the code full loaded on the test server? If its multiple commits, a commit or two may have been missed. |
| 14:52 |
JBoyer |
Checked both multiple times, 1 commit each. :/ |
| 14:53 |
JBoyer |
ok, here's something building eg2: ERROR in src/app/staff/admin/local/search-filter/query-dialog.component.ts:55:64 - error TS2367: This condition will always return 'true' since the types 'string' and 'number' have no overlap. |
| 14:53 |
JBoyer |
so I'm guessing it's dying after building part of the big pile of JS. |
| 17:11 |
|
dbwells joined #evergreen |
| 17:13 |
|
mmorgan left #evergreen |
| 17:20 |
|
dbwells joined #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:09 |
|
sandbergja joined #evergreen |
| 20:11 |
|
malexander joined #evergreen |
| 08:13 |
|
malexander joined #evergreen |
| 08:21 |
|
rfrasur joined #evergreen |
| 08:29 |
|
mmorgan joined #evergreen |
| 08:35 |
csharp |
miker: unfortunately, the sideloader consumed all available RAM and swap on the server and it locked up (64GB/8 core testing standalone DB server) |
| 08:35 |
csharp |
miker: last message from the script was Dictionary built in 9840 seconds, writing.. |
| 08:54 |
|
jvwoolf joined #evergreen |
| 09:04 |
miker |
csharp: that's ... very strange. once it starts writing the file, it should start /decreasing/ in ram use because it starts deleting keys from the huge hash. I have not seen any other behavior in my testing :( |
| 09:06 |
miker |
csharp: curious what version of perl is on that server... |
| 09:23 |
csharp |
miker: 5.26.1 |
| 09:23 |
csharp |
Ubuntu 18.04 |
| 09:27 |
miker |
I have 5.28 (kubuntu 19.10), though I certainly can't pin it on that with any confidence. I have an idea for a memory-related tweak, if you're willing to test again in a couple hours (meetings!). even if the release folken would rather not grant an indulgence, I'd appreciate having it ready to merge immediately after 3.7 is branched -- I'm tired of these bigger ones not getting in at the wire ;) |
| 09:27 |
csharp |
yes, totally willing to test |
| 09:31 |
Dyrcona |
Ubuntu 20.04 has Perl 5.30. I have an Ubuntu 20.04 dvelopment VM and DB server. The latter has 128GB of RAM. |
| 09:32 |
csharp |
our staging DB used to be a clone (specs-wise) of our prod DB, but in our new environment, we've been required to slim down our boxen based on usage |
| 09:33 |
csharp |
and that DB doesn't get a lot of day-to-day use |
| 09:33 |
Dyrcona |
My development DB server is an old mail server with 128GB of RAM and 8TB of disk space, so I run multiple versions of Pg with multiple copies of production data. |
| 09:34 |
|
dbwells joined #evergreen |
| 09:34 |
Dyrcona |
I'm trying to find the bug number in yesterday's log. |
| 09:35 |
miker |
csharp: fwiw, I suspect it's the number of suggestions on very short prefix keys, especially coming from the "keyword" data. there are runtime rules about what suggestions can be ignored, and I'm going to cull suggestions that wouldn't pass that test. the only way I can think of memory increasing during the write phase is if there are 10s of thousands of suggestions on a key (and even then, we should be talking MB, not GB, of RAM)... but we shall see |
| 09:36 |
Dyrcona |
OK. Got the branch. I'll take a look just to see how it works for us.We have 2.3 million not deleted bibs. |
| 09:41 |
Dyrcona |
Um. Is git.evergreen-ils.org down? |
| 09:44 |
csharp |
miker: If I can provide any data from my end, let me know |
| 13:09 |
|
khuckins joined #evergreen |
| 13:13 |
|
malexander joined #evergreen |
| 13:45 |
* gmcharlt |
claims 1254 |
| 13:56 |
pinesol |
Showing latest 5 of 8 commits to Evergreen... |
| 13:56 |
pinesol |
[evergreen|Mike Rylander] Provide two library groups for testing with Concerto - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2fcec1d> |
| 13:56 |
pinesol |
[evergreen|Mike Rylander] LP#1815815: Library Groups - limit copy table - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a9e0656> |
| 13:56 |
pinesol |
[evergreen|Mike Rylander] LP#1815815: Do not use depth when filtering copies for a library group - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=76f53ef> |
| 13:56 |
pinesol |
[evergreen|Galen Charlton] LP#1815815: add release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0bf0441> |
| 13:56 |
pinesol |
[evergreen|Galen Charlton] LP#1815815: stamp schema update - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e98a375> |
| 13:58 |
|
terranm joined #evergreen |
| 14:13 |
csharp |
miker: last line is: |
| 14:13 |
csharp |
yu20\N0{nyug2941756b}1{yu2}0\N0\N0\N |
| 17:00 |
Dyrcona |
Cheers, everyone! |
| 17:31 |
|
mmorgan left #evergreen |
| 17:33 |
|
sandbergja joined #evergreen |
| 18:00 |
pinesol |
News from qatests: Failed Create Evergreen Database <http://testing.evergreen-ils.org/~live//archive/2021-03/2021-03-11_16:00:05/test.41.html> |
| 18:10 |
miker |
I'm pushing a fix for that -^ |
| 18:16 |
pinesol |
[evergreen|Mike Rylander] Minor mis-merge for geosort, missing comma in INSERT VALUES list addition. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b3e6738> |
| 20:52 |
|
malexander joined #evergreen |
public.localhost seems to work