| 09:02 |
|
dguarrac joined #evergreen |
| 09:14 |
|
mantis1 joined #evergreen |
| 09:16 |
Dyrcona |
I've noticed that with psql 16, \df+ <function> no longer shows the function definition. |
| 09:22 |
Dyrcona |
I had to use \ef <function> to open it in a test editor, which gives you the SQL used to create the function. |
| 09:24 |
Dyrcona |
Interesting... psql 10 gives an error when doing \df+ on a pg 15 database. I wonder if \df+ from psql 16 works on a Pg 16 database. It probably does. |
| 09:25 |
* Dyrcona |
loads a dump into pg 16 to see what happens. |
| 09:26 |
Dyrcona |
Heh... "Talk Soup" by Weird Al just started playing.... :) |
| 09:26 |
mantis1 |
talksoup++ |
| 09:27 |
Dyrcona |
"Listen to me! Listen to me! Listen to me!" :P |
| 09:30 |
* Dyrcona |
updates a script for pg 16 on the test db server. |
| 09:32 |
Dyrcona |
Whee! Just copy, paste, and edit 3 lines. |
| 09:35 |
JBoyer |
Dyrcona, so long as you specify enough params to uniq-ify it, \sf should show you the function source |
| 09:35 |
JBoyer |
(similar to \df+ I mean) |
| 09:35 |
Dyrcona |
JBoyer: OK. I was going to check with psql 16 on a pg 16 database because I think its an issue client server mismatch and not a change in features. |
| 09:36 |
JBoyer |
Oh, I see what you mean. Yeah, the queries backing that feature may have changed / broken / been removed in psql 16. |
| 09:36 |
Dyrcona |
Now that I have used it, I think I prefer \ef, at least when I'm running psql locally and talking to a remote server. |
| 09:37 |
Dyrcona |
I also plan to finally get around to adding Pg 16 support for Evergreen, so this will be a good first test. |
| 09:43 |
Dyrcona |
I suppose it is a good sign that pg_restore has not produced any output to the screen. |
| 09:43 |
|
smayo joined #evergreen |
| 09:51 |
|
BDorsey_ joined #evergreen |
| 12:28 |
|
jvwoolf joined #evergreen |
| 12:55 |
|
sleary joined #evergreen |
| 13:28 |
|
smayo joined #evergreen |
| 13:38 |
csharp_ |
Dyrcona: I tested out all but one of the LP scripts you shared and with a couple of Python 3-ish changes, they appear to work |
| 13:39 |
csharp_ |
the release.py one is untested since it appears to make changes and I wanted to get my head around it first |
| 13:39 |
csharp_ |
smayo may do some work on things too - we're still in research mode to make sense of the release process |
| 13:47 |
|
jvwoolf joined #evergreen |
| 13:58 |
|
dguarrac_ joined #evergreen |
| 14:11 |
|
mdriscoll joined #evergreen |
| 14:20 |
|
mdriscoll joined #evergreen |
| 14:25 |
mdriscoll |
I want to copy some patrons from a production system to a test system and I need their password to work. I have the password hash but not sure how to do the insert so the password works and isn't set to literally 'd41d8cd98f00b...' Any ideas? |
| 14:31 |
|
mdriscoll joined #evergreen |
| 14:34 |
jeff |
mdriscoll: that looks like the start of the md5 hash of an empty string. you'll probably want to take a look at the actor.passwd table. |
| 14:36 |
jeff |
mdriscoll: if you copy a user's row from actor.usr and actor.passwd (and actor.usr_address, actor.card, etc), then the copied user on the test system should end up with the same password as on the source system. |
| 14:39 |
mdriscoll |
jeff: thanks. I think actor.passwd is the part I was missing. |
| 14:41 |
jeff |
mdriscoll: depending on how empty your test system db is, you may need to worry about conflicts, renumbering ids, etc. Even if you don't, consider that if you manually insert ID values, you'll want to either bump sequences or know that eventually you'll run into an error when some future insert gets that manually-inserted value from its default sequence. |
| 14:42 |
jeff |
(depending on what kind of a test system this is, and how long it will be around, and other things, you may not care) |
| 14:48 |
mdriscoll |
jeff: I'm altering a script I use for loading patrons where I usually set the password and let the database trigger crypt the plain text. I let the database create the new ids but duly noted about bumping sequences. |
| 15:01 |
|
mmorgan1 joined #evergreen |
| 15:10 |
|
smayo joined #evergreen |
| 10:00 |
|
jvwoolf joined #evergreen |
| 10:00 |
|
sleary joined #evergreen |
| 10:12 |
|
sandbergja joined #evergreen |
| 10:16 |
csharp_ |
Bmagic> Dyrcona: Just testing my tarball, and I got this while building the old concerto set: psql:assets_concerto.sql:58: ERROR: update or delete on table "record_entry" violates foreign key constraint "browse_entry_def_map_source_fkey" on table "browse_entry_def_map" |
| 10:16 |
csharp_ |
terranm saw that same error yesterday - currently trying to reproduce it |
| 10:18 |
csharp_ |
and.... no, I can't reproduce it on 3.12.0 |
| 10:18 |
csharp_ |
(from git, not tarball, if that matters) |
| 10:21 |
Bmagic |
csharp_++ |
| 10:22 |
Bmagic |
I don't think the build process messes with the concerto set, but, of course, the base schema build is there in the rel_11 branch. I would think that if there was an issue with the schema, the enhanced concerto would have the problem too |
| 10:36 |
|
redavis_reboot joined #evergreen |
| 16:22 |
adam_reid |
ok, thats fair, so does Evergreen need to be aware of the page earlier in the process? |
| 16:22 |
jeff |
just the tt2 bits, or Evergreen variables/functions also? |
| 16:23 |
jeff |
do you have the tt2 source somewhere? that would answer some of the questions. it sounds like public data? |
| 16:23 |
adam_reid |
I'm not 100% the difference, I think just the tt2 bits |
| 16:24 |
adam_reid |
no source anywhere yet, to test the idea I basically just made a blank test page, I assumed it would resolve but didn't expect to be asked to login by default |
| 16:24 |
jeff |
which path did you put it at? |
| 16:25 |
adam_reid |
at the time /openils/var/templates_custom/opac/test.tt2 |
| 16:26 |
adam_reid |
I figured if the simple test worked I would start to see what was possible, the page was essentially blank, once logged in everything worked fine, pulled in a few carousels and they worked |
| 16:26 |
adam_reid |
just didn't want users to need to log in |
| 16:30 |
terranm |
I'm not 100% certain, but you may need to add it into EGCatLoader.pm to route |
| 16:31 |
terranm |
Example - https://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=fc361eeb6759c7af074b14f8faa9b9c4d37bbb77 |
| 16:34 |
adam_reid |
interesting... right, seems that addition would've required a similar setup, looks like a great place to start looking, THANKS terranm |
| 16:39 |
jeff |
depending on your needs, you can drop a tt2 file in a place outside of the opac dir, like (using your example above) /openils/var/templates_custom/local/test.tt2 |
| 16:40 |
jeff |
(without needing to define a route, etc) |
| 16:41 |
terranm |
jeff++ |
| 16:44 |
* JBoyer |
Eg tarballs rebuilt, uploaded, and updated. |
| 16:44 |
adam_reid |
interesting, thanks jeff. I'll play around with that too! |
| 09:26 |
Dyrcona |
sandbergja++ |
| 09:28 |
* Dyrcona |
ponders how much the PHP Evergreen objects should resemble their Perl counterparts.... There are two ways I could implement property access, and one is similar to the Perl way, the other is more like public property access. I could do both. |
| 09:30 |
jmurray-isl |
For some reason, the concept of "PHP Evergreen objects" leaves a bad taste. |
| 09:32 |
Dyrcona |
jmurray-isl: I have reasons for implementing Evergreen client code with PHP, mainly to do with testing Aspen code changes. I'm going a bit farther than I might actually need to go and implementing actual classes for a client, fieldmapper, requests, objects, and probably another to represent class metadata. |
| 09:38 |
pinesol |
News from commits: Docs: release notes for 3.11.2 <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=82d206eebd22b89a9ea002cb58188adf1c84169d> |
| 09:39 |
jmurray-isl |
Dyrcona: I get it. It's mostly just the principle for me. |
| 09:41 |
Dyrcona |
jmurray-isl++ |
| 09:46 |
jmurray-isl |
Indeed. |
| 09:47 |
Dyrcona |
CLI programming in PHP is a different thing, and it's easier/better in some ways. |
| 09:48 |
jmurray-isl |
Agreed. My initial work with VuFind was pre-Zend. The cli harvest scripts were much easier to troubleshoot. |
| 09:51 |
Dyrcona |
I kind of like using the interactive mode (aka REPL) for testing code. The only problem is having to restart when I change a class definition. (In Lisp, I can just reload the file and it will replace the existing code definitions.) |
| 09:54 |
sandbergja |
Dyrcona: 3.10.4 release notes pushed |
| 09:56 |
Dyrcona |
sandbergja++ |
| 09:56 |
mmorgan |
sandbergja++ |
| 11:28 |
Dyrcona |
Looks like just --disabled-password. |
| 11:28 |
|
mantis1 joined #evergreen |
| 11:30 |
Dyrcona |
yeah, i know... I should script this with ansible. |
| 11:40 |
kmlussier |
Dyrcona: On the other hand, it's always good to have an opportunity to test the steps in the README. |
| 11:46 |
Dyrcona |
Oof. have to start over. I started installing prerequisites for the wrong branch. |
| 11:53 |
Dyrcona |
Maybe another burrito will help? |
| 11:58 |
|
jihpringle joined #evergreen |
| 14:08 |
pinesol |
News from commits: Docs: final updates to 3.12 release notes <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=807fb5cf59f4ba65a4d668cfbf87627fbf36ebb9> |
| 14:10 |
|
jvwoolf joined #evergreen |
| 14:14 |
jmurray-isl |
win 2 |
| 14:16 |
Dyrcona |
Live tests are failing. Guess I'll need to figure out what I did wrong. |
| 14:18 |
Dyrcona |
heh. --load-all-sample might help. :) |
| 14:23 |
Dyrcona |
yeah, that's much better. |
| 14:33 |
|
jihpringle joined #evergreen |
| 16:09 |
pinesol |
News from commits: LP2046362 Button type for staff portal catalog search <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=533b9e5bcc11dc99bd5a0d1393bb8a46934c7d18> |
| 16:09 |
pinesol |
News from commits: Forward port 3.10.3 to 3.10.4 db upgrade script <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=b6d73efaac01e2604d6871d1bcf704b4fcb41f14> |
| 16:18 |
|
smayo joined #evergreen |
| 16:20 |
Bmagic |
Dyrcona: Just testing my tarball, and I got this while building the old concerto set: psql:assets_concerto.sql:58: ERROR: update or delete on table "record_entry" violates foreign key constraint "browse_entry_def_map_source_fkey" on table "browse_entry_def_map" |
| 16:21 |
Bmagic |
oops, Dyrcona's not here |
| 16:27 |
Bmagic |
enhanced concerto loaded ok though |
| 16:27 |
Bmagic |
not sure if that's "ok" but I've put the tarball on the web server (I think that the concerto issue isn't related to the tarball) |
| 10:19 |
berick |
sandbergja: branch updated. thanks for the heads up. |
| 10:19 |
sandbergja |
Thanks, berick! |
| 10:20 |
|
collum joined #evergreen |
| 10:27 |
Dyrcona |
I sometimes think our triggers are out of hand. I'm updating tcn_source on 10,000 bib records and according to ps it's using 16GB of RAM and 88% of a CPU on my test database. |
| 10:27 |
Dyrcona |
I'm pretty sure it's mostly being used by the maintain 901 trigger, which is actually why I am doing this. |
| 10:32 |
Dyrcona |
I wonder if using a transaction and deferring all triggers would help with the speed of this? |
| 10:36 |
Dyrcona |
Actually, it's probably smple rec and some of the other triggers, too. I'm not sure I want to disable simple rec in a transaction. I'll have to investigate the triggers a bit more. |
| 10:40 |
pinesol |
News from commits: LP1850473 (follow-up): Update DOM selector in nightwatch test <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=bddc372d27e4ac9298ef6d265534c3b14529b2a2> |
| 10:41 |
Dyrcona |
No, I don't want to disable any triggers. It would lead to locking and possible dead locks. Setting session replication role is overkill since it disables all triggers. |
| 10:45 |
Dyrcona |
Looks like the ingest triggers are getting fired, too, but they.... Oh wait. The marc changes.... |
| 10:53 |
Dyrcona |
Trying different batch sizes, with a limit on a subquery, It did 10 in 5 seconds 100 in 26 seconds and 1000 took 4 minutes 23 seconds and used a lot more memory. |
| 13:27 |
Dyrcona |
--csv option to psql doesn't properly quote strings apparently. |
| 13:28 |
Dyrcona |
ha! I'm not paying enough attention. LibreOffice had a "from row" 1322 still set on the CSV import from the other day. |
| 13:30 |
Dyrcona |
The delete was attempted multiple times. |
| 13:59 |
csharp_ |
Dyrcona: waiting can be just waiting - becomes a deadlock when two processes start waiting on each other |
| 14:00 |
csharp_ |
but seems like a matter of time - I'm nervously watching a very slow parallel reingest on a test server and many of the PG procs are in "waiting" state |
| 14:01 |
csharp_ |
reingest began ~11:30 a.m. yesterday - a little over half done per the batch count |
| 14:07 |
Dyrcona |
csharp_: My case was nearly catastrophic. Cascading deadlocks stemming from a process trying to delete a staff account with thousands of owned records. It was acquisitions account. The person doing the delete tried it at least 3 more times after the first timed out in the client. |
| 14:10 |
Dyrcona |
This sort of thing used to happen so much in Horizon with Sybase, that I made a little GUI in Java to show me the deadlocked processes. From that I could identify the most likely culprit process. I could then click its row in the table, type Ctrl-k and that would send the Sybase equivalent of pg_cancel_backend. Every now and then, I consider adapting that to PostgreSQL and Evergreen. |
| 14:13 |
Dyrcona |
Looks like someone was also loading MARC order records at the same time. I may have clobbered their backend process, not sure. I tried to only cancel the delete_usr queries. |
| 14:23 |
Dyrcona |
Speaking of long-running processes my update of tcn_source on 530,105 bibs where it is '' has been running for 1day, 5 hours, and 27 minutes at this point. |
| 14:25 |
Dyrcona |
Fortunately, that is on a test system, or I'd have probably had to cancel it for deadlocks. |
| 14:29 |
|
smayo joined #evergreen |
| 14:58 |
|
jonadab joined #evergreen |
| 15:01 |
csharp_ |
Dyrcona: holy moly |
| 09:22 |
|
Dyrcona joined #evergreen |
| 09:39 |
Dyrcona |
due_date: "3812-01-17 23:59:59-05" Sure, that's plausible. |
| 09:40 |
mmorgan |
:) |
| 09:41 |
Dyrcona |
And, it looks like a test or someone was messing with due dates. It was checked in in 2018. |
| 09:41 |
mmorgan |
Or a barcode got scanned into the due date field? |
| 09:42 |
Dyrcona |
mmorgan: That might be a possibility. 38120 looks like a valid item barcode prefix for Massachusetts. |
| 09:43 |
Dyrcona |
I think I need to do something more sophisticated than just select max(due_date) from action.circulation; :) |
| 09:43 |
Bmagic |
jeffdavis: are you working on SSO for Evergreen staff client? |
| 09:44 |
Dyrcona |
I'm looking for things I can renew in my test database with a script to try out the osrf-gateway-v1. |
| 09:44 |
Dyrcona |
I can wait until next week. The data should be refreshed on Sunday. |
| 09:51 |
Dyrcona |
Think I'll give it a shot anyway. |
| 10:03 |
Dyrcona |
Hm. Left joins with a where clause on "right_table.columns is null" seem to be a lot faster in Pg 15 than in Pg 10. |
| 11:14 |
csharp_ |
eeevil: yeah, I didn't consider FTPS in my branch |
| 11:14 |
csharp_ |
eeevil: yeah, that's a mistake - shouldn't have removed libnet-ssh-perl |
| 11:14 |
eeevil |
well, yes, but just on the SFTP addition, it removes (it looks like) SSH support |
| 11:14 |
csharp_ |
sorry libnet-ssh2-perl |
| 11:15 |
csharp_ |
I removed it in the makefiles but still call it in the perl - that would have been caught in the fleetingist of testing |
| 11:15 |
eeevil |
right, it might still get installed as a dep, which would be fine |
| 11:15 |
csharp_ |
yeah |
| 11:16 |
eeevil |
but, it looks like pure ssh2 support gets broken |
| 11:20 |
Dyrcona |
Net::STFP::Foreign does not use libnet-ssh-perl unles you tell it to. That's actually the point of Net::SFTP::Foreign. It defaults to using the sftp client on the host. |
| 11:21 |
* Dyrcona |
uses Net::SFTP::Foreign in several utility scripts. |
| 11:22 |
Dyrcona |
berick++ jeff++ Thanks for the answers. I thought I was missing a couple. |
| 11:23 |
Dyrcona |
I have another question, but I'll check the code, too. I think it's possible to login with user id and not barcode or username, right? I'm working on a program to test OPAC renewals through osrf-gateway-v1, in case anyone missed it. |
| 11:23 |
csharp_ |
eeevil: are you looking at the latest I pushed? I see the sub delete with } elsif ($self->type eq "SFTP") { |
| 11:23 |
csharp_ |
or maybe I'm misunderstanding... |
| 11:24 |
Dyrcona |
FTPS.... Ugh. Someone actually uses that? |
| 11:34 |
csharp_ |
jeez, y'all |
| 11:34 |
csharp_ |
don't you know libraries are still excited about Web 2.0? |
| 11:34 |
eeevil |
"upload your EDI messages to the blockchain and..." |
| 11:35 |
csharp_ |
eeevil++ |
| 11:37 |
csharp_ |
eeevil: with my code in place, tlittle and I were able to push files to a PINES-owned SFTP server - that's all the testing we've done |
| 11:38 |
csharp_ |
tlittle has asked Ingram for a test account to push prod files to but that request appears to have flummoxed them |
| 11:39 |
eeevil |
csharp_++ |
| 11:39 |
eeevil |
tlittle++ |
| 11:44 |
eeevil |
it certainly looks like it will work. though, to retain SSH/SCP support, the DESTROY sub should simply add an sftp->disconnect in addition to the ssh2->disconnect. other than that, maybe the need to implement delete_sftp, I don't see any obvious problems |
| 12:48 |
sandbergja |
I spent an embarassing amount of time troubleshooting why every request I made to the open-ils.serials service returned an error. Fun fact: the service is actually called open-ils-serial. |
| 12:49 |
sandbergja |
^ open-ils.serial, rather |
| 12:52 |
|
mantis1 joined #evergreen |
| 13:03 |
jeffdavis |
abneiman: thanks for the reminder about the DYM-related search slowness bug - our testing results weren't as definitive as I would like but I believe the fix works, I'll make a signoff branch and update 2038472 |
| 13:04 |
jeffdavis |
I guess there's already a signoff branch, I'll just add a signoff via LP |
| 13:07 |
|
Stompro joined #evergreen |
| 13:08 |
abneiman |
jeffdavis++ |
| 13:08 |
abneiman |
thank you! |
| 13:15 |
jeffdavis |
More specifically, our test environment remained somewhat slow after applying the fix, but I believe the remaining slowness was for other reasons. We decided not to enable DYM so we effectively stopped testing the fix at a certain point; it's possible that it introduces other issues, but no point in delaying the fix over such hypotheticals. |
| 13:16 |
jeffdavis |
"other reasons" = slower hardware + that unrelated bug that required disabling a PG "optimization" |
| 13:41 |
Dyrcona |
jeffdavis: I have not experienced the issue that "requires" disabling jit. |
| 13:42 |
Dyrcona |
I'm using Pg 15 for quite a bit of testing. Of course, the VPN to where that server is just went down, so..... |
| 13:42 |
jeffdavis |
required it on our test server, that is - we haven't seen it in production |
| 13:43 |
Dyrcona |
I was in the middle of installing updates.... I'll have to check when I get access again. I might have disabled JIT after you reported the issue, but I also wanted to test your queries with JIT enabled. |
| 13:44 |
pinesol |
News from commits: LP#2038472: stamp DB update <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=10527ec78952a27d447f675a93d13e2846fa7ae6> |
| 13:44 |
pinesol |
News from commits: LP#2038472: Revive DYM optimizations <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=7f72e22bc23ae887fefd98074a7415e852fcb4c0> |
| 13:44 |
Dyrcona |
I knew that I should have just started my test program in a tmux session and installed updates after. |
| 13:45 |
Dyrcona |
The test was not related to JIT, but to checking in and deleting copies from a spreadsheet. |
| 13:51 |
Dyrcona |
VPN is definitely down. Wonder if the site also lost Internet? |
| 13:53 |
Dyrcona |
I suppose I could test the changes to command line options on a local vm. |
| 14:11 |
|
jihpringle joined #evergreen |
| 14:12 |
Dyrcona |
Well, that looks like it will work. Guess I can test it on the training server. |
| 14:16 |
csharp_ |
@decide open-ils.serial or open-ils.cereal |
| 14:16 |
pinesol |
csharp_: go with open-ils.cereal |
| 14:16 |
csharp_ |
a nutritious part of this complete breakfast! |
| 12:12 |
Dyrcona |
That's at 11:24 EST. :) |
| 12:13 |
Dyrcona |
I've already done this for a set of records that evergreen-universe-rs doesn't like. |
| 12:13 |
berick |
oh, gotcha |
| 12:15 |
Dyrcona |
I think I'll put this down for now and work on a program to convert some marcxml to binary marc to see if CPAN's RT will let me upload that. I get a 403 when I try to upload the marcxml examples from the Rust test. |
| 12:15 |
Dyrcona |
"That should only take half an hour," he said knowing it was very likely to be a lie. |
| 12:16 |
Dyrcona |
Also, mexican_coca-cola++ It tastes so much better with cane sugar than with HFCS. |
| 12:22 |
Dyrcona |
What? libmarc-perl does not install MARC::File and friends? I thought that it did. |
| 12:35 |
Dyrcona |
I'm just full of complaints today, aren't I? |
| 12:44 |
Bmagic |
you? never! |
| 12:44 |
Dyrcona |
I'm installing MARC::File::XML with cpan set to local::lib, and there sure are a lot of prerequisites. |
| 12:50 |
Dyrcona |
Failed 11/11 test programs. 3/5 subtests failed. |
| 12:50 |
Dyrcona |
Right. I'll just run it on a server where this is already installed. |
| 12:51 |
Dyrcona |
And, I'll wipe out the stuff that CPAN installed locally. |
| 13:08 |
Dyrcona |
Looks like I may have to reboot. I just swapped monitors and the laptop doesn't see the new one. |
| 13:33 |
Dyrcona |
Apparently, all of the software in the world has chosen this week to hate me: https://rt.cpan.org/Ticket/Display.html?id=150348&results=a5d68555ff4b4354e65ce6ec51f76634 # Read to the bottom... |
| 13:37 |
Dyrcona |
gmcharlt: RT on CPAN is apparently broken for uploads at the moment. I've tried 3 times to add a file of records to that ticket above. |
| 13:39 |
Dyrcona |
Stompro++ I'll give MARC::Lint a whirl. |
| 13:57 |
Dyrcona |
Stompro: It looks like MARC::Lint may help. I'm running a test program already. |
| 13:59 |
Stompro |
I wonder if it will be too verbose, or if you can pick out the bigger issues. I'm curious how it performs also? |
| 13:59 |
Dyrcona |
And, maybe not so much: is_valid_checksum: Didn't get object! at /usr/share/perl5/Business/ISBN.pm line 481, <DATA> line 244. |
| 13:59 |
Dyrcona |
Well, it gets totally clobbered by our data after bib id 233519. |
| 14:58 |
Dyrcona |
Google sheets is 10 million cells, roughly speaking. Maximum column is zzz (or 18.278). I only have 2 columns. |
| 15:00 |
Dyrcona |
LibreOffice Calc has a limit of 1,024 columns per row. Maximum number of rows is just over 1 billion. I hope I don't have to worry about the 32,767 characters per cell limit. |
| 15:01 |
Dyrcona |
So as long as we stick with Google Sheets and LibreOffice, we should be OK. I doubt that I'll hit 10 million cells. It may go over 1 million rows. |
| 15:01 |
Dyrcona |
Right, enough blather. I'll test the version that writes the CSV files. |
| 15:03 |
* Dyrcona |
tries hot swapping monitors again. If I disappear, I had to reboot. |
| 15:10 |
Dyrcona |
Well, looks like I have to reboot. |
| 15:16 |
|
Dyrcona joined #evergreen |
| 10:27 |
pinesol |
News from commits: DOCS: LP#1871211 Follow-up eg_vhost.conf <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=ded2dd7815a9d3bcf0305c1b55dd53ee3f7ae4f4> |
| 10:27 |
Dyrcona |
It probably should. |
| 10:29 |
|
sandbergja joined #evergreen |
| 10:30 |
sandbergja |
Dyrcona++ # thanks for taking a look at that live test |
| 10:32 |
berick |
sandbergja++ # branches, redis, and more! |
| 10:32 |
Bmagic |
sandbergja, abneiman, terranm, colum : Would you mind if I back ported this Docs commit to rel_3_12? ded2dd7815a9d3bcf0305c1b55dd53ee3f7ae4f4 |
| 10:33 |
sandbergja |
+1 from me |
| 11:18 |
berick |
hm, i thought we did decide to make it default for post-3.12 main. |
| 11:18 |
berick |
i could be misremembering |
| 11:19 |
berick |
in part, i think, since it would only affect new installs |
| 11:20 |
eeevil |
I thought we'd agreed that we should see what things look like after some more testing and review. |
| 11:20 |
Dyrcona |
I'm not sure what we agreed at this point. Maybe we should have that discussion on the list? |
| 11:20 |
eeevil |
where will there be more new installs than for the purpose of dev, though? |
| 11:21 |
Dyrcona |
The dev meeting is also today. |
| 11:37 |
eeevil |
since I came to complain ;) , I'm happy to pick them into main. are there objections? |
| 11:38 |
eeevil |
man... my fingers are not moving in the right order today. rel_3_12 |
| 11:41 |
eeevil |
it's close to lunch time, so I'll leave the question open for a while. but, ping Dyrcona and sandbergja (in particular) |
| 11:52 |
csharp_ |
eeevil: I'm good for what my opinion is worth |
| 11:55 |
csharp_ |
I've lightly tested it on my puny server |
| 11:55 |
csharp_ |
@band add Irregular Expressions |
| 11:55 |
pinesol |
csharp_: Band 'Irregular Expressions' added to list |
| 12:02 |
sleary |
can I still target bug fixes to 3.12 or is that bad manners at this point? |
| 12:03 |
eeevil |
csharp_: it's worth One Full Commit Bit, as it happens, sir! |
| 15:04 |
Bmagic |
no problem, carrying forward |
| 15:04 |
Bmagic |
#action mmorgan will explore moving LP stats to community site and automating same |
| 15:04 |
Bmagic |
#info sandbergja will write tutorial: "Do a database call (Galen’s cat counter)"#info sandbergja will write tutorial: "Do a database call (Galen’s cat counter)" |
| 15:04 |
Bmagic |
#info sandbergja will go over the Nightwatch test reorg with folks at the Monday at 2pm ET meeting or another time as available |
| 15:05 |
Bmagic |
go ahead sandbergja |
| 15:05 |
sandbergja |
kinda fidddling with my partial draft for the tutorial |
| 15:05 |
sandbergja |
probably need to check back with me next time :-) |
| 15:05 |
Bmagic |
no problem |
| 15:05 |
sleary |
sandbergja I looked at what you sent me a while back and it's looking great |
| 15:05 |
sandbergja |
we didn't get around to moving the nightwatch tests, but we got them working! |
| 15:05 |
sandbergja |
sleary++ # thanks for the review! |
| 15:05 |
terranm |
sandbergja++ |
| 15:05 |
Bmagic |
#action sandbergja will write tutorial: "Do a database call (Galen’s cat counter)" |
| 15:05 |
smayo |
sandbergja++ |
| 15:33 |
Bmagic |
sandbergja++ sleary++ |
| 15:33 |
sleary |
sandbergja++ # thanks for staying on top of linting! |
| 15:33 |
Bmagic |
thanks again sandbergja! next.... |
| 15:33 |
Bmagic |
#topic New Business - Test failures, including at least one critical regression (bug 2043437) - Jane |
| 15:33 |
pinesol |
Launchpad bug 2043437 in Evergreen "Three test failures on rel_3_12 and main" [Critical,New] https://launchpad.net/bugs/2043437 |
| 15:34 |
Bmagic |
#link https://bugs.launchpad.net/evergreen/+bug/2043437 |
| 15:34 |
sandbergja |
oh god, I have a bunch in a row :-D |
| 15:34 |
Bmagic |
yes, yes you do |
| 15:34 |
sandbergja |
we have 3 failing tests, one of which points to a major problem |
| 15:34 |
sandbergja |
tests++ # catching that before we released it to users! |
| 15:35 |
sandbergja |
specifically, the holdings view doesn't load (maybe just a missing import or something) |
| 15:35 |
terranm |
sandbergja++ tests++ |
| 15:35 |
sandbergja |
I feel pretty strongly we should take care of those before building a beta. |
| 15:35 |
mmorgan |
+1 |
| 15:37 |
Dyrcona |
When I said that I don't know how to fix the syntax error, I should have said that it's not obvious to me what's wrong. |
| 15:37 |
Bmagic |
the course reserves issue is fine because the test is bad, so we're looking at the holdingsView.spec.ts issue, and the query issue |
| 15:37 |
sleary |
we should fix the bad test since the problem is obvious, but yes |
| 15:38 |
Bmagic |
agreed on fixing the test. Should each of the three things be it's own bug so folks can claim them? |
| 15:38 |
Dyrcona |
Well, we could use a collab branch to avoid separate bugs, but I'll let the consensus decide. |
| 15:40 |
Bmagic |
I assume this pause is because everyone is reading the bug |
| 15:40 |
sandbergja |
:-) |
| 15:41 |
Bmagic |
Dyrcona: that query works on two of my test systems |
| 15:42 |
Dyrcona |
Bmagic: It blew up for me on a 3.12 vm with stock concerto and Pg 15. I tried the function by itself with different parameters. |
| 15:43 |
Bmagic |
Just the query? Not integrated in Evergreen? |
| 15:43 |
Dyrcona |
Different parameters, I mean interger array and string that should have matched. |
| 15:43 |
Dyrcona |
Just the function by itself, as well as the query I pasted. |
| 15:43 |
Dyrcona |
The query comes from the error output of the test. |
| 15:44 |
JBoyer |
Fun thing: it worked for me on eg3.11 / pg15 and broke on 3.11 / pg14. |
| 15:44 |
Bmagic |
ok, yes, it breaks on newer versions of the database |
| 15:44 |
Bmagic |
bugsquash machine throws the error |
| 15:46 |
Bmagic |
let's move this to post-meeting |
| 15:46 |
Dyrcona |
JBoyer: Gotcha. |
| 15:46 |
JBoyer |
Bmagic, +1 |
| 15:47 |
Bmagic |
#topic New Business - How can we get computers running our tests regularly again? - Jane |
| 15:47 |
eeevil |
I'll also look at the search one, later |
| 15:47 |
sandbergja |
#info for anybody wanting to run the tests, or try it out: https://wiki.evergreen-ils.org/doku.php?id=dev:contributing:qa#types_of_tests |
| 15:47 |
Bmagic |
sandbergja++ |
| 15:47 |
mmorgan |
sandbergja++ |
| 15:48 |
sandbergja |
I am just feeling fired up about tests, and wanted to see if there's capacity for getting buildbot running them automatically for us, or some new solution |
| 15:48 |
Bmagic |
sandbergja: where's the buildbot now? (I've never known where that lives and who's in charge of it) |
| 15:49 |
shulabear |
sandbergja++ |
| 15:49 |
sandbergja |
no clue. Was it an EOLI server? |
| 15:52 |
sandbergja |
the ng lint always passes, for reasons mentioned above hahaha |
| 15:52 |
Bmagic |
haha |
| 15:52 |
Bmagic |
not sure if we've arrived at anything I can put down as action |
| 15:53 |
sandbergja |
I can investigate getting more tests into gh actions, if there aren't concerns with tying ourselves more to that platform |
| 15:53 |
Bmagic |
#action sandbergja will investigate getting more tests into gh actions |
| 15:53 |
JBoyer |
It doesn't have to be the projects definitive home to provide a useful function, even if temporarily, |
| 15:54 |
Bmagic |
almost out of time |
| 15:54 |
Bmagic |
#topic Keep an eye out for Angular 17 / Bootstrap 5.3 upgrade blockers and note them on bug 2043490 - Stephanie |
| 15:54 |
pinesol |
Launchpad bug 2043490 in Evergreen "Angular 17 + Bootstrap 5.3 Upgrade" [Wishlist,New] https://launchpad.net/bugs/2043490 |
| 15:54 |
kmlussier |
sandbergja++ tests++ |
| 15:54 |
JBoyer |
(so long as it's still easy to run tests locally) |
| 15:54 |
Bmagic |
#link https://bugs.launchpad.net/evergreen/+bug/2043490 |
| 15:54 |
Bmagic |
sleary: go for it |
| 15:55 |
eeevil |
#info I've requested we keep XMPP as the default OpenSRF transport in EG main for the time being. There's no redis release of OpenSRF yet, so support is only in a side branch, and having redis be the default will make dev (especially backport-focused dev, like bug fixes) more painful because you can't just switch branches and test the code. Also, I'm not convinced that it's deeply understood by more folks than berick, and that puts a lot of pressure |
| 15:55 |
eeevil |
on him to Fix All The Things if Things need Fixing. I'm asking here for any strong objections to applying the 2 existing commits that will make that so, as it is now for rel_3_12. Barring any, I'll pick those commits into main and life will be a little simpler for all the not-testing-redis cases, for now. |
| 15:56 |
eeevil |
(separately, I think I know where the search test failure is coming from, and I'll poke at it early tomorrow) |
| 15:57 |
Bmagic |
eeevil: and when we've all installed and tested redis, then make it default? |
| 15:58 |
eeevil |
Bmagic: well, and when more-than-Bill can help work on it, ideally, but yes. "when it and we are ready" |
| 15:58 |
eeevil |
it's not something we should force Right Now, IMNSHO. but, hopefully, soon |
| 15:58 |
eeevil |
for a definition of soon somewhere between "months" and "geologic time" |
| 16:06 |
|
jihpringle joined #evergreen |
| 16:06 |
shulabear |
bmagic++ |
| 16:10 |
Bmagic |
Dycona: that's strange. Worked for me on 3.9.1 and 3.11.1, but not busquash main |
| 16:11 |
Dyrcona |
Bmagic: Are you talking about the function itself or the search test? I suspect the function has been broken since 0940, but doesn't look like it is used much. |
| 16:12 |
Bmagic |
copy/paste the query I mean |
| 16:13 |
Dyrcona |
I get a syntax error any time/any where I run the function. |
| 16:14 |
JBoyer |
yeah, query_int_wrapper does so little I'm surprised we even have it (syntax escaping simplicity if I had to guess) but sometimes passing '()' as the second param is accepted and sometimes it's a syntax error, which is weird. |
| 16:20 |
Dyrcona |
select query_int_wrapper(vlist, '()') from metabib.record_attr_vector_list where source =2; <- Blows up for me, even though record 2 is in metabib.record_attr_vector_list |
| 16:20 |
Dyrcona |
Can we just replace it with the code from the function? |
| 16:22 |
Dyrcona |
select vlist @@ '()'::query_int from metabib.record_attr_vector_list where source = 2; Also produces a syntax error at the text value '() |
| 16:23 |
eeevil |
I wish I weren't orange right now ... TL;DR: no, we can't (without testing that we don't need it anymore -- and there were reasons) |
| 16:24 |
Dyrcona |
eeevil: It's used in only 1 place AFAICT. |
| 16:24 |
Dyrcona |
I've tried a few variations: '{}' also fails but null works. |
| 16:25 |
eeevil |
Dyrcona: yes, and that 1 place is important. more later, though |
| 16:45 |
eeevil |
I'm transforming back into pure eeevil, leaving my pumpkin state behind! |
| 16:45 |
eeevil |
and, https://bugs.launchpad.net/evergreen/+bug/1438136/comments/12 |
| 16:45 |
pinesol |
Launchpad bug 1438136 in Evergreen 2.8 "OPAC searching significantly slowed by adding format filters" [High,Fix released] |
| 16:45 |
eeevil |
that's why we have query_int_wrapper, and what we need to test before we stop trying to use it. |
| 16:45 |
eeevil |
HOWERVER |
| 16:46 |
eeevil |
that's not the problem here, regardless. the problem here is that we should never be sending an effectively-empty query_int (that is, and int array query "thing") to the database |
| 16:47 |
eeevil |
that clause is a question of the data, but the question being asked is empty in this case. we need to elide the clause altogether |
| 16:48 |
eeevil |
which we normally do (you don't always see a query_int clause either direct or via query_int_wrapper), but something is convincing us to generate an empty query_int at the perl level |
| 16:49 |
eeevil |
I suspect an interaction with the new on_reserve() filter, but mostly because it's new and not because I can point to a problem with it |
| 16:54 |
Dyrcona |
Well, that's somewhere to start. I was thinking of resorting to git bisect. I can take a look tomorrow morning, probably. |
| 16:55 |
Dyrcona |
Anyway.... I'll turn into a pumpkin now..... |
| 17:11 |
|
kmlussier left #evergreen |
