| 12:52 |
Dyrcona |
Doesn't xact_begin start a new session if there isn't one? Could the session have gone away, but the drone not know it? |
| 12:56 |
berick |
Dyrcona: that's what i'm thinking. the session timed out while compiling the template, it then tried to send a BEGIN on a disconnected session. |
| 12:57 |
Bmagic |
it almost has to be |
| 12:57 |
berick |
and it didn't know it was disconnected because no recv() / queue_wait calls occurred before the "am I still connected" test in editor's xact_begin() sub. |
| 12:57 |
Dyrcona |
I'd still check the database logs for anything weird around that time. |
| 12:58 |
Bmagic |
db logs don't have anything interesting around that time |
| 12:58 |
Bmagic |
lots of " WARNING: there is no transaction in progress" |
| 14:25 |
berick |
oddly it tries to create the transaction after it's compiled the template. "trigger: writing 3273 bytes to template output" happens after template compilation. |
| 14:26 |
berick |
then cstore sends a bunch of stuff back after the begin. that part I don't get. |
| 14:43 |
Dyrcona |
Eighteen commits rebased down to 1, and I'm ready to share the code... |
| 15:04 |
Dyrcona |
I suppose we have functional tests for the staff client that can be run. I guess I should learn how those work. |
| 15:11 |
* eeevil |
reads up and sees Bmagic's adventure... ah yes, a Very Expensive Template Output (esp a grouped set of expensive events) could take longer than the session keepalive time (configured in opensrf.xml, per service) and it does look like that. the fast fix is to increase the keepalive time. I know of EG instances that have in the past had a timeout of 12s (slower hardware, and before some code changes lowered the timeout risk), but I don't see |
| 15:11 |
* eeevil |
any currently. if it's right at the edge of the time limit, that'd give breathing room to figure out where we need to insert more interaction and avoid that particular session timeout in A/T land. |
| 15:19 |
Bmagic |
eeevil++ berick++ Dyrcona++ mmorgan++ # thanks for the ideas. timeout 6 > 12 seems easy enough. What's the drawback? Tying up more Drones, and running up against max_children? |
| 09:43 |
berick |
Dyrcona: i've had similar thoughts lately re: merging opensrf because of this project. there's quite a bit of duplicated effort. |
| 09:43 |
berick |
Dyrcona: yes, those are the correct branches. |
| 09:43 |
Dyrcona |
berick: Thanks. |
| 09:44 |
berick |
Dyrcona++ # testing |
| 10:04 |
|
sleary joined #evergreen |
| 10:33 |
* Dyrcona |
hasn't done much today. I've been mucking about with UNIX account configuration. |
| 10:40 |
StomproJ |
oclc-- |
| 13:47 |
Dyrcona |
berick: For practicing rust locally would your recommend installing the rust-all apt package or going with rustup? |
| 13:48 |
Dyrcona |
s/your/you/ |
| 13:48 |
berick |
Dyrcona: either works. i've mostly used rust-all. |
| 13:49 |
Dyrcona |
Ok. I was thinking of going with rustup on my laptop for newer features, etc. I installed rust-all on the Ubuntu 22 vm where I'm testing redis. I'll give universe-rs a whirl later. |
| 13:50 |
Dyrcona |
I'm rerunning the perl live tests because I forgot to start apache2, so the tests that depended on Apache failed... |
| 13:51 |
Dyrcona |
Looks good so far |
| 14:23 |
Dyrcona |
I notice that gmcharlt is (righly) concerned about the universe-rs pulling in 167 crates. However, npm pulls in almost 1390 packages in Open-ILS/src/eg2. That should be a concern, too, no? |
| 14:23 |
Dyrcona |
Where are my fingers today?.... Must Typoday.... |
| 10:20 |
Dyrcona |
That's much safer than setting a flag in actor.usr. |
| 10:21 |
Dyrcona |
My second promised email about our rusty future might go into some detail about issues I have with the current staff client, but I might save that for yet another email. |
| 10:21 |
Dyrcona |
I have examples of bad API design and even worse use or bypassing of existing API. |
| 10:22 |
berick |
we have exactly 2 accounts w/ superuser. one for logging in/testing/etc and one a backend utility account. not following the use case where a standard human person would get superuser. |
| 10:24 |
jeff |
seconding deprecation and possibly eventual removal of actor.usr.superuser, if only for simplicity and for the sake of having permissions in fewer places. |
| 10:24 |
Dyrcona |
berick: Doesn't matter if you don't get it. Doesn't mean it's wrong. When someone is on the phone wanting something fixed, that permission comes in handy. |
| 10:25 |
jeff |
and yes, both EVERYTHING and superuser should be rarely handed out / relied upon. |
| 10:34 |
jeff |
csharp_: that "unless" bit around the check_perms call is because check_perms returns undef on success. if the return value is truthy, it means that the user doesn't have the perm. it's... perhaps less than intuitive. |
| 10:35 |
csharp_ |
jeff: ah - out of context it was really throwing me |
| 10:35 |
Dyrcona |
Another unpopular opinion: I think we should ditch Perl for the back end (other than utility scripts). |
| 10:36 |
jeff |
Dyrcona: I don't object to PL/pgSQL functions being used to test "does this user have this perm at X location" and such. It seems efficient and not an egregious "that doesn't BELONG in the database!" kind of thing. |
| 10:36 |
csharp_ |
Dyrcona: preview of your "rusty" email? :-) |
| 10:36 |
Dyrcona |
csharp_: yes, but I'll have to write it. It might take me a few more days. |
| 10:38 |
|
kworstell_isl joined #evergreen |
| 11:04 |
mmorgan |
Cool! |
| 11:04 |
Dyrcona |
Yeah, thanks. |
| 11:05 |
mantis1 |
Dyrcona++ |
| 11:07 |
gmcharlt |
Dyrcona== |
| 11:07 |
gmcharlt |
er |
| 11:08 |
gmcharlt |
Dyrcona++ |
| 11:14 |
gmcharlt |
if you give a mouse a cookie^W^W^W^W GitHub Actions a commit... |
| 11:14 |
gmcharlt |
anyway, the GitHub-based automatic tests are now happy again |
| 11:14 |
pinesol |
News from commits: fix title of 3.11.0 release notes <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=8c52cb5dfef7485f4bec742c2a431c35b39d6c58> |
| 11:15 |
pinesol |
News from commits: LP#2023582 - 3.11.0 release notes - remove redundant section <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=ba9550376925919ddab361b4b9f918fd8f5b66f7> |
| 11:15 |
pinesol |
News from commits: LP#2023582: Update RELEASE_NOTES_3_11.adoc - formatting fixes <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=500b04d7a729d30bc87b66aafe53d52220163256> |
| 11:28 |
|
Christineb_ joined #evergreen |
| 12:51 |
|
jvwoolf joined #evergreen |
| 13:13 |
|
dmoore joined #evergreen |
| 13:45 |
jvwoolf |
Anybody have an issue with Perl modules not getting installed correctly with 3.9.3? |
| 13:45 |
jvwoolf |
We've installed it a few times over the past few weeks (including for our production system) but seem to be having issues with the install on 2 different test servers today. |
| 13:58 |
JBoyer |
jvwoolf, any OS upgrades in the mix there? |
| 13:59 |
JBoyer |
(Like 20.04 -> 22.04, not 20.04.9 -> 20.04.10) |
| 14:13 |
jeff |
jvwoolf: can you say more about what the issues/symptoms are? are there errors at "make install" time, or something else? |
| 15:10 |
jvwoolf |
I know I did everything right this time on the server I'm working on and I'm getting the same error on make check |
| 15:11 |
jvwoolf |
@bartender mantis1 |
| 15:11 |
* pinesol |
fills a pint glass with Ommegang Witte, and sends it sliding down the bar to mantis1 (http://beeradvocate.com/beer/profile/42/16506/) |
| 15:13 |
jeff |
Above the "Test Summary Report" should be a collection of more specific/detailed error messages. Often times I like to start with the first one, though it's not guaranteed to be the clue that leads to a solution. :-) |
| 15:14 |
Dyrcona |
jvwoolf: Is this a virtual machine? |
| 15:15 |
jvwoolf |
Dyrcona: Yes |
| 15:16 |
|
mantis1 left #evergreen |
| 15:17 |
Dyrcona |
I'd destroy it and start over. The output from your find commands suggests that it has been upgraded from Ubuntu 16 to 18 to 20. |
| 15:19 |
jvwoolf |
Dyrcona: That's the case with all of our test VMs at this point |
| 15:20 |
jvwoolf |
This is the only one that's decided to be a PITA |
| 15:25 |
Dyrcona |
Try this one: find /usr -name Logger.pm |
| 15:28 |
* Dyrcona |
was just wondering why my database was missing indexes, and then realized I was checking the wrong schema. |
| 15:28 |
Dyrcona |
No asset.copy indexes in the actor schema! |
| 15:29 |
jeff |
based on that output, my next suggestion would be perl -c /usr/local/share/perl/5.30.0/OpenSRF/Utils/Logger.pm |
| 15:30 |
Dyrcona |
Yeahp. What jeff said. |
| 15:30 |
Dyrcona |
Probably a busted module somewhere. |
| 15:32 |
jeff |
(but I also think we may be using the output of paste gKQdDQSz ("the start error") to debug a different machine, so that may not be helpful.) |
| 15:33 |
jeff |
the errors from "make check" that occurred before the Test Summary Report are my best suggestion at the moment. |
| 15:33 |
jvwoolf |
jeff: Yes, sorry for the noise on that one |
| 15:33 |
jvwoolf |
It was just a coincidence that they were both getting Perl-related errors at the same time |
| 15:34 |
jvwoolf |
/usr/local/share/perl/5.30.0/OpenSRF/Utils/Logger.pm syntax OK |
| 16:42 |
pinesol |
Launchpad bug 1904737 in Evergreen "Flag/setting for Items with Specific Statuses to Display on Holds Pull List" [Wishlist,In progress] https://launchpad.net/bugs/1904737 - Assigned to Jason Stephenson (jstephenson) |
| 16:43 |
Dyrcona |
I think I'll see what happens with the current query using that index and dropping the cp_available... index. |
| 16:43 |
Dyrcona |
I'll bet it's faster. |
| 16:47 |
Dyrcona |
Yeah... On my test system performance is comparable to the modified query and just slightly faster than the previous cp_available_by_circ_lib_idx. Going to modify the queries to include "deleted is false" to force the is false index to be used. Maybe drop the circ with status code index, too. |
| 16:49 |
Dyrcona |
Heh. It's using both indexes when they are there. |
| 16:49 |
Dyrcona |
oops. It's the index on serial.unit that I'm seeing... |
| 16:53 |
Dyrcona |
To be fair, I should probably loop these variations thousands of times and average them out, and they will likely all be comparable, i.e. within a fraction of a second of each other. |
| 09:07 |
|
Dyrcona joined #evergreen |
| 09:09 |
|
Christineb joined #evergreen |
| 09:23 |
|
mantis1 joined #evergreen |
| 09:24 |
mantis1 |
Found this error when running autoreconf -i for our 3.11.0 test server install |
| 09:24 |
mantis1 |
autoreconf: automake failed with exit status: 1 |
| 09:24 |
mantis1 |
I think this was related to a makefile when I saw it before, but it's been some time |
| 09:32 |
gmcharlt |
mantis1: what Linux distribution? |
| 09:40 |
pinesol |
News from commits: LP2019735 Fix Bootstrap5 checkbox borders <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=e62173478e9e509f3f8c225b4ea262e0ffb18dfa> |
| 09:41 |
mantis1 |
gmcharlt: I figured it out |
| 10:11 |
pinesol |
News from commits: LP#1996818 Issues Placing Holds from the Patron Record <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=2a2af7843d2db0440ffb3b0fe4c59e3157af35f9> |
| 10:11 |
Dyrcona |
That might have been the problem. Whenever you do a major version upgrade of Evergreen, it's best to delete the node files in /usr/local/ and to do a `git clean -x -f -d` in your local Evergreen repository to remove any old files. |
| 10:14 |
mantis1 |
Dyrcona: I have the code prep and scripts done. Is it possible to run these now or does it need to be done at a specific time during the code prep? |
| 10:16 |
Dyrcona |
mantis1: They should be done before you do anything else. You will probably be OK, because we don't change Node versions that often. I do the git clean -x -f -d from time to time to clean things up on my dev systems particularly if I'm switching release versions or about to test big changes, |
| 10:18 |
Dyrcona |
I've had weird issues after doing an installation that going back and doing the node deletion or a git clean and reinstalling has fixed. |
| 10:54 |
Dyrcona |
@blame Apple |
| 10:54 |
pinesol |
Dyrcona: Apple is really just another name for autogen |
| 15:05 |
berick |
Dyrcona++ |
| 15:05 |
Bmagic |
#info RUST timeline |
| 15:05 |
Bmagic |
berick: I threw this on the agenda because it was bare. Feel free to tell me to move on |
| 15:06 |
berick |
well... |
| 15:06 |
berick |
not much so say on the Rust side at this point. kind of waiting/hoping others will get interested and join the momentum |
| 15:06 |
berick |
i did at this https://github.com/kcls/evergreen-universe-rs/blob/main/PRIMER.md |
| 15:06 |
berick |
tiny primer |
| 15:07 |
berick |
i think the bigger question now is more about the Redis stuff, which has been decoupled from Rust now |
| 15:07 |
berick |
and is ready for wider testing |
| 15:07 |
Dyrcona |
berick++ |
| 15:07 |
Bmagic |
oh! berick++ |
| 15:07 |
Dyrcona |
I'll take a look. |
| 15:16 |
berick |
so, it's a long game |
| 15:17 |
jeffdavis |
kind of works as a roadmap though - there's some time to get up to speed on Rust while Redis dev continues, then ramp up with Rust once the Redis stuff is in main? |
| 15:18 |
berick |
jeffdavis: yeah, pretty much |
| 15:18 |
Bmagic |
I'm sure more discussions will be had, we can table it. Good to know that berick has Redis up for testing sans Rust! |
| 15:18 |
Bmagic |
berick++ # for good measure |
| 15:18 |
jeffdavis |
yeah, really excited for Redis and hoping the Rust interest takes off |
| 15:18 |
JBoyer |
berick++ |
| 15:31 |
jeff |
i've no strong opinion either way on one-channel or many-channels, but support having a list of "official" project channels and making logs more readily available for those channels. |
| 15:32 |
Bmagic |
hmmm, it's public as far as I know. The security stuff wouldn't be there (correct me if I'm wrong releaseers) |
| 15:33 |
Dyrcona |
It's public, but it is not logged by the bots. |
| 15:33 |
jeff |
sleary: I think the reason you can't see the channel in your IRC client is the same reason you wouldn't be able to see this channel if you weren't already in it: the channels are +s ("secret") to avoid being listed in the commands that spam bots use, etc. Something we did long ago, and could test removing if folk think +s is causing more trouble than its worth. |
| 15:33 |
Bmagic |
I mean, the chatter is public |
| 15:34 |
jeff |
I mention the above because I'm happy to be the one to set up logging / join the bots / list the channels on the wiki or web page / toggle channel modes as needed / etc. |
| 15:34 |
Bmagic |
so, shall we remove it? |
| 16:16 |
Dyrcona |
It might be a while before others see the change. |
| 16:19 |
|
sleary_ joined #evergreen |
| 16:51 |
jeff |
gmcharlt: in a recent comment on bug 1483496 you mentioned "evergreen.change_db_setting() will be removed shortly" -- I'm wondering if there's additional context to that? I've no objection, just curiosity. |
| 16:51 |
pinesol |
Launchpad bug 1483496 in Evergreen "evergreen.change_db_setting needs test" [Undecided,Won't fix] https://launchpad.net/bugs/1483496 |
| 16:52 |
gmcharlt |
jeff: a pending security fix |
| 16:52 |
jeff |
ah. :-) |
| 17:02 |
|
mmorgan left #evergreen |
| 08:04 |
|
BDorsey joined #evergreen |
| 08:09 |
|
rfrasur joined #evergreen |
| 08:10 |
|
PhilMakesStuff joined #evergreen |
| 08:11 |
PhilMakesStuff |
This is a test message to see if I am posting in the correct channel |
| 08:12 |
PhilMakesStuff |
Quick question: I was wondering if evergreen has a Voluntary Product Accessibility Template (VPAT)? |
| 08:13 |
PhilMakesStuff |
We will need this in order for our organization to use Evergreen |
| 08:23 |
JBoyer |
Hi PhilMakesStuff , that sounds familiar but you may have more luck getting responses on the Evergreen general email lists as IRC activity is pretty irregular. |
| 16:00 |
javier_guel |
great thanks, i will try |
| 16:44 |
|
dmoore_doppel joined #evergreen |
| 16:59 |
|
mmorgan left #evergreen |
| 17:31 |
dmoore |
hey all - any thoughts on this API note published on EBSCO's Novelist page - https://connect.ebsco.com/s/article/Setting-up-On-The-Shelf?language=en_US |
| 17:32 |
dmoore |
"Note: There is an Evergreen API that supports automatic harvesting of your collection. However, we were unable to obtain a complete harvest for any customers during the testing of this functionality, as Evergreen’s Web Services API was not built for such a wide-scale application. We discourage Evergreen customers from utilizing this feature for collection harvesting." |
| 17:32 |
csharp_ |
dmoore: we don't use it in PINES, but anecdotally, I've heard from sites who do that the harvesting can eat into available server resources |
| 17:33 |
berick |
hah, yeah, IIRC, they were madly spewing api calls |
| 17:33 |
csharp_ |
dmoore: we sent a monthly upload to NoveList so they can reference it offline |
| 08:06 |
|
ahazaril joined #evergreen |
| 08:50 |
ahazaril |
Hi! I'm trying to do Batch MARC Import in Evergreen 3.11 RC on my test server |
| 08:51 |
ahazaril |
but it seems error like this: |
| 08:51 |
ahazaril |
ERROR TypeError: r.id is not a function |
| 08:51 |
ahazaril |
at Object.next (5959.1f96455ba4311aeb.js:1:14565) |
| 08:51 |
ahazaril |
at De.next (main.a07a83aabf044c34.js:3:39334) |
| 08:51 |
ahazaril |
at Re._next (main.a07a83aabf044c34.js:3:39003) |
| 08:51 |
ahazaril |
at Re.next (main.a07a83aabf044c34.js:3:38689) |
| 08:51 |
ahazaril |
at x.dispatchResponse (main.a07a83aabf044c34.js:3:14786) |
| 08:51 |
ahazaril |
at OpenSRF.Request.onresponse (main.a07a83aabf044c34.js:3:14057) |
| 08:51 |
ahazaril |
at OpenSRF.Stack.handle_message (opensrf.js:748:28) |
| 08:51 |
ahazaril |
at OpenSRF.Stack.push (opensrf.js:693:23) |
| 08:51 |
ahazaril |
at OpenSRF.websocketConnection.onmessage (opensrf.js:388:23) |
| 08:51 |
ahazaril |
at socket.onmessage [as __zone_symbol__ON_PROPERTYmessage] (opensrf_ws.j |
| 08:51 |
ahazaril |
Vandelay file uploaded OK with key f114583e2c27f43954f487556c7816fe |
| 09:09 |
|
ahazaril joined #evergreen |
| 11:45 |
jeffdavis |
ahazaril: those look like errors in the browser console, are there any related error messages in the server logs? |
| 12:07 |
ahazaril |
which log file i need to view jeffdavis? |
| 12:33 |
ahazaril |
hahaha its ok, i forgot also to report a bug in Launchpad before |
| 12:34 |
jeffdavis |
I've reported it now, bug 2021402 |
| 12:34 |
pinesol |
Launchpad bug 2021402 in Evergreen "Default Vandelay import folder is not readable by opensrf" [Undecided,New] https://launchpad.net/bugs/2021402 |
| 12:36 |
jeffdavis |
Hope the rest of your testing goes well! :) |
| 12:36 |
ahazaril |
tq so much pinesol! |
| 12:36 |
ahazaril |
tq jeffdavis! |
| 07:58 |
|
collum joined #evergreen |
| 08:10 |
|
BDorsey joined #evergreen |
| 08:11 |
|
rfrasur joined #evergreen |
| 08:16 |
JBoyer |
Evergreen 3.11.0-rc1 is up and announced. To testing! |
| 09:12 |
|
mmorgan joined #evergreen |
| 09:27 |
JBoyer |
Bmagic, are you involved in the docs auto-build for docs.evergreen-ils.org/eg/ ? It looks like it was unhappy with something recently and all of the docs are gone. |
| 09:29 |
JBoyer |
Ooor, since it's CNAME'd to a gpls system, csharp_ ? |
| 10:08 |
JBoyer |
I also mean they may be things that we need to document (ha...) about how best to do formatting on this or that page level, etc. I did some experimenting to try to silence the "level 0 blah blah book" error that latency.adoc is throwing and apparently could not make the thing happy. |
| 10:09 |
JBoyer |
Though it occurs to me it may have tried building multiple versions even though I was in the rel_3_11 branch and I was only looking at 1 copy (and not committing the changes...) |
| 10:09 |
JBoyer |
I need to re-familiarize myself with the whole process apparently. :) |
| 10:49 |
jvwoolf |
TIL that if you set the intenal flag ingest.force_on_same_marc to true your metarecords seem to remap themselves without kicking off pingest.pl |
| 10:50 |
jvwoolf |
The bad part is that I accidentally set the flag to true in production instead of a test system like I had intended.:-D |
| 10:50 |
jvwoolf |
Doesn't seem like anything bad happened luckily. |
| 10:52 |
jvwoolf |
Does anybody know how to check on whether whatever it's doing in the background is done? |
| 10:56 |
Dyrcona |
jvwoolf: Your foreground update doesn't finish unti its done, I think. |
| 10:59 |
Dyrcona |
That is, the triggers don't run in the background. |
| 11:00 |
jvwoolf |
Dyrcona++ |
| 10:07 |
|
dguarrac joined #evergreen |
| 10:18 |
|
mantis1 joined #evergreen |
| 11:12 |
gmcharlt |
updated the wiki to the latest stable version of Dokuwiki |
| 11:13 |
tlittle |
gmcharlt++ |
| 11:34 |
|
ACSpike joined #evergreen |
| 11:34 |
|
ACSpike joined #evergreen |
| 11:35 |
tlittle |
Reports don't appear to be running on my test server, and I'm not sure what else to check as to why. I've already restarted everything on this list: https://wiki.evergreen-ils.org/doku.php?id=newdevs:restarting |
| 11:36 |
tlittle |
Any ideas what else I should try? |
| 11:37 |
gmcharlt |
tlittle: if Clark is running (ps -ef | grep -i Clark), it's possible that Clark things that there's a report still running |
| 11:37 |
ACSpike |
Is Hatch specific to Evergreen? Could it be used by other web apps? |
| 11:37 |
gmcharlt |
if so, SELECT * FROM reporter.currenly_running would show one or more rows |
| 11:29 |
csharp_ |
yeah, that was last Tuesday - Wednesday was fun |
| 11:42 |
|
ariez_hazaril joined #evergreen |
| 11:43 |
ariez_hazaril |
hi everyone! I wanna ask something. Can Evergreen ILS port we change from 80 to 8080? i manage to change the port, but the eg_vhost still listen to port 80. thanks |
| 11:57 |
jeff |
ariez_hazaril: in theory, it could be. it's not a common configuration, and may not be well tested. I don't think we have specific documentation on how to do it, and I'm not personally in a position to help troubleshoot your attempt. Out of curiosity, what are you trying to do? |
| 11:58 |
ariez_hazaril |
Hi jeff, im trying to change opac port from 80 to 8080 as i need to use port 80 for something else |
| 12:08 |
|
Christineb joined #evergreen |
| 12:25 |
|
genpaku joined #evergreen |
| 11:21 |
sandbergja |
Dyrcona++ |
| 12:14 |
|
jihpringle joined #evergreen |
| 12:24 |
|
kmlussier joined #evergreen |
| 12:28 |
terranm |
When refreshing a test server, it's really helpful to log into the correct one. |
| 12:39 |
Dyrcona |
terranm++ |
| 12:40 |
Dyrcona |
sandbergja++ |
| 12:40 |
Dyrcona |
It looks like we'll have point releases next week, and there is a high likelihood of there being one or more security patches in the releases. |
| 12:46 |
csharp_ |
for when you do an OS upgrade and it breaks NPM all to hell: https://pastebin.com/aWcn6jkC |
| 12:46 |
csharp_ |
(thanks to gmcharlt for the kernel of this back at the 2019 hackaway) |
| 12:57 |
Dyrcona |
csharp_++ I have a less comprehensive version of that, but I think I'll steal yours. |
| 12:57 |
Dyrcona |
I find it useful sometimes to wipe out Node and reinstall it when switching branches on a test VM. |
| 13:01 |
csharp_ |
I may variable-ize the Evergreen source dir name to allow for non-Git or alternate repo usage |
| 13:03 |
csharp_ |
updated the paste with that change |
| 13:05 |
Dyrcona |
csharp_: Good idea. You might want to add this for bootstrap OPAC: rm -rf $INSTALL_DIR/var/web/opac/deps/node_modules |
| 13:09 |
csharp_ |
-ohs*t |
| 13:10 |
berick |
hah |
| 13:11 |
Dyrcona |
:) |
| 13:13 |
* Dyrcona |
tries the script out on a test vm, because I was just about to install Lp1947898 for testing with rel_3_10. |
| 13:13 |
Dyrcona |
Lp 1947898 |
| 13:13 |
pinesol |
Launchpad bug 1947898 in Evergreen "Enhanced MARC importer script electronic_marc_import.pl" [Wishlist,Confirmed] https://launchpad.net/bugs/1947898 - Assigned to Jason Stephenson (jstephenson) |
| 13:36 |
csharp_ |
updated the paste with the bootstrap addition |
| 07:10 |
|
kworstell_isl joined #evergreen |
| 07:29 |
gmcharlt |
I have pushed the bootstrap 5 + angular15 branch that berick, sleary, and sandbergja have been working on to master |
| 07:30 |
gmcharlt |
the BS5 upgrade in particular introduces a number of changes to how Bootstrap CSS classes work, so if you run into trouble when reviewing Angular changes that predate this morning, please be aware (and don't hesitate to ask for help, especially if you have an opportunity to bug berick and sleary in person at the conference) |
| 07:46 |
pinesol |
News from commits: LP#2000482: add a brief release notes entry <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=09b001a2dbc5dd8877b5f61d9f4ecb5a68d9403f> |
| 07:46 |
pinesol |
News from commits: LP#2000482: (follow-up) couple more layout tweaks <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=635370da24e9b2ed7da887e48045688a1e9443cb> |
| 07:46 |
pinesol |
News from commits: LP#2000482: (follow-up) update Angular cheat sheet <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=c37328795ac368f4a0b4f5f7514a5b31a25abb27> |
| 07:46 |
pinesol |
News from commits: LP2000482: Get tests passing <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=c1fcbda53d2d2a7858464fb8ca808e814cb7bcdf> |
| 07:46 |
pinesol |
News from commits: LP2000482: update tsconfig options to satisfy compiler warning <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=7d8923e075a83318acf01a3236587c802278f4bc> |
| 07:46 |
pinesol |
News from commits: LP2000482 Bootstrap 5 continued <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=3b747e6fd12089c22dfac928ad6b692f69279a52> |
| 07:46 |
pinesol |
News from commits: LP2000482 Angular 15 and Bootstrap 5 upgrade <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=c76e4ad6c2aba1a918992659686bb6b50bfea79c> |
| 08:07 |
csharp_ |
notes for Sys Admin IG: https://docs.google.com/document/d/1EUa9oIvmp5s9mbCRYIwG6dKMEcuirOEKcqbs90OjjWc/edit?usp=sharing |
| 08:19 |
|
mmorgan joined #evergreen |
| 08:53 |
|
mmorgan left #evergreen |
| 14:36 |
pinesol |
abneiman is going out with degraafk to see Blighted Tormenter Contours tonight. |
| 14:43 |
gmcharlt |
there's now an updated branch for bug 1997485 |
| 14:43 |
pinesol |
Launchpad bug 1997485 in Evergreen "wishlist: Did you mean? Multi word, single class search suggestions" [Wishlist,Confirmed] https://launchpad.net/bugs/1997485 - Assigned to Galen Charlton (gmc) |
| 14:43 |
gmcharlt |
I think this is ready to go, and I intend to push it tonight, but if anybody intends to test it today, please speak up |
| 14:52 |
|
jvwoolf joined #evergreen |
| 14:54 |
|
kworstell-isl joined #evergreen |
| 15:11 |
|
jihpringle joined #evergreen |
| 16:39 |
jihpringle |
that is outside of my expertise - if you don't get a response from anyone else I'd recommend emailing the general list next week (when people are back from the conference) |
| 16:39 |
jihpringle |
https://evergreen-ils.org/communicate/mailing-lists/ |
| 16:40 |
derekz |
Sounds good. If you're at the conference, I hope you're enjoying it and I appreciate you taking the time to respond |
| 16:47 |
jeffdavis |
derekz: I'm pretty sure the structure of email templates is (1) headers including To, From, and any custom headers, (2) a blank line, (3) the body of the message |
| 16:48 |
jeffdavis |
If you put custom headers with To and From etc *before* the blank line, I think that should work |
| 16:48 |
jeffdavis |
(please test first though, don't take my word for it :) |
| 16:51 |
derekz |
The structural outline is helpful. I'll give it try. Thank you! |
| 17:09 |
derekz |
Does line 83 indicate that only From, To, Bcc, Cc, Reply-To, Sender are being extracted for further processing by the email perl module? |
| 17:09 |
derekz |
https://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/Application/Trigger/Reactor/SendEmail.pm;h=71354e6b6506ac8584af470fb51f04040ac49ab7;hb=09b001a2dbc5dd8877b5f61d9f4ecb5a68d9403f |
| 17:16 |
|
jvwoolf joined #evergreen |
| 17:19 |
jeffdavis |
derekz: I believe you're not restricted to those headers - our templates add a Message-ID header using the method I described, for example, and it appears to work |
| 17:19 |
jeffdavis |
it may be that other headers are not MIME-encoded |
| 17:23 |
derekz |
(y) I'll do some testing and see how it goes. Headed out for the evening. Thanks for the help! |
| 17:44 |
|
abowling1 joined #evergreen |
| 16:26 |
kmlussier |
git shortlog --group=trailer:signed-off-by --after="03 Apr 2023" --before="20 Apr 2023" -s -- ":(exclude)./docs/" |
| 16:26 |
kmlussier |
Does anyone know if there is a way to count the signoffs where the person signing off is not the author? I'm thinking the answer is no, but maybe somebody smarter than me when it comes to git knows of a way. |
| 16:27 |
Bmagic |
abowling: Try dividing the file that you're submitting in half, and then half again and again until it imports correctly. |
| 16:29 |
abowling |
Bmagic: Thanks, but it's one record (a test) ;) |
| 16:29 |
Bmagic |
kmlussier: I'm wish I knew the right answer for that. After you mentioned it the other day, I spent some time on getting sign-offs out of git with counts like you were talking about. I'm sure someone, ahem gmcharlt, might know it. Since he publishes these numbers sometimes |
| 16:29 |
Bmagic |
abowling: hmmm, do you get this error for any* record? |
| 16:29 |
abowling |
seemingly, yes |
| 10:02 |
Dyrcona |
hrm... This is going to be an interesting rebase... I want to drop a bunch of commits, split one commit up into several smaller commits, and then squash some other commits into the new commits. I wonder if I can get away with doing it once, or will I have to do two rebases.... |
| 10:04 |
Dyrcona |
Now that I think about it, maybe I should rebase a different branch and then recreate the branch that I was planning to rebase from scratch.... |
| 10:19 |
Dyrcona |
I suppose that I could just make a new branch without rebasing either.... |
| 10:25 |
Dyrcona |
hm... wonder if I really need the changes to these two images. I'll make them their own commit so I can remove them later for testing. |
| 10:34 |
|
stephengwills joined #evergreen |
| 10:39 |
Dyrcona |
a) Does anyone use KPAC? b) Do you use override directories with KPAC? |
| 10:52 |
Dyrcona |
Still working on this rebase, and I think I want to reorganize things even more. |
| 08:47 |
|
dguarrac joined #evergreen |
| 08:52 |
|
rfrasur joined #evergreen |
| 09:02 |
|
mantis1 joined #evergreen |
| 10:08 |
Stompro |
jmurray-isl, Re: Content Cafe, they are serving up old images, but only to evergreen libraries because we seem to be the only customers that make use of the XMLPost request method. And they seem to have no way to test request to that service. |
| 10:13 |
Dyrcona |
Stompro: So, someone should open a bug on Lp for us to switch to the REST interface or whatever it is that Koha uses? |
| 10:14 |
Stompro |
Dyrcona, they have a specific method for grabbing just cover art, but we also get author notes and reviews from them. I think the XMLPost method is the only method for grabbing that info. |
| 10:15 |
Dyrcona |
I see... |
| 10:15 |
csharp_ |
Dyrcona++ |
| 10:16 |
csharp_ |
Dyrcona: you used /me, so we all understood that to be internal monologue |
| 10:18 |
Dyrcona |
Yeah, but it is still on the record. |
| 10:18 |
Stompro |
I'm getting really frustrated with them not being able to test their own service. |
| 10:20 |
Dyrcona |
I was just thinking of how I should word this in an email to other CW MARS staff, but I think I'll skip it since no one has opened a ticket, yet. |
| 10:21 |
Dyrcona |
Could we grab images via GET and still get the other information via POST? |
| 10:27 |
Stompro |
Dyrcona, yes, I'm sure that would work, just added complexity. If I remember correctly, it does try and combine different types of content into one request... but I don't think that happens in reality because of how clients request the data. |
| 10:28 |
csharp_ |
most vendors don't really take testing that seriously |
| 10:28 |
csharp_ |
(that could probably provide to all developers everywhere :-)) |
| 10:28 |
* Dyrcona |
thinks we are included in "most vendors." |
| 10:28 |
csharp_ |
s/provide/apply/ |
| 10:28 |
Dyrcona |
csharp_++ |
| 10:58 |
Dyrcona |
There are only 2 hard problems in computer science: naming things, cache invalidation, and off-by-one errors. :) |
| 11:01 |
Stompro |
They asked me what our memcache TTL is... and I'm like, "24 hours, now lets talk about what yours it set to?, it has been serving old data for 5 weeks now??" |
| 11:05 |
Dyrcona |
-1? |
| 11:27 |
jmurray-isl |
Stompro: To test ContentCafe images, I go to the OPAC record and look through the sources for contentcafe. There, I can find something with the following format: https://contentcafe2.btol.com/ContentCafe/jacket.aspx?UserID=<UserID>&Password=<Password>&Return=T&Type=S&Value=<ISBN-Number> |
| 11:27 |
jmurray-isl |
Type equates to S, M, or L. |
| 11:29 |
jmurray-isl |
I mean, it is a bit concerning that just anyone can view our ContentCafe credentials this way... |
| 11:31 |
Bmagic |
jmurray-isl: I had the same thought whilst looking through this code. Syndetics works the same way. The "authentication" is simply our ID string embedded in the query string. If they charged based on number of requests, then I would be a bit more concerned :) |
| 11:36 |
Stompro |
jmurray-isl, our Evergreen setup doesn't expose the username and pw, I did notice that Evergreen Indiana does have two different sets of cover art links. The problem is that the jacket.aspx method is returning fresh data, but the XMLpost method that evergreen uses is serving old data. let me grab an example. |
| 11:37 |
Stompro |
Compare https://evergreen.lib.in.us/opac/extras/ac/jacket/medium/9781608095377 and https://evergreen.lib.in.us/eg/opac/record/22903128 |
| 12:51 |
Dyrcona |
jvwoolf: I seem to recall encountering this before, and I think the only way to fix metarecord maps is to update bib.record_entry. pingest doesn't handle it for sure. |
| 12:52 |
Dyrcona |
It's bug worthy as a feature requrest. |
| 12:52 |
Dyrcona |
request, even. |
| 12:58 |
jvwoolf |
Dyrcona: I updated biblio.record_entry in order to generate the new fingerprints. Do I have to do it again for the metarecords? |
| 12:59 |
jvwoolf |
I think you, JBoyer and I had this conversation before, and what I came away with seemed to work in my first test, but not the most recent few |
| 13:03 |
Dyrcona |
jvwoolf: There's a flag... let me look it up. |
| 13:04 |
Dyrcona |
ingest.reingest.force_on_same_marc <- Needs to be true in config.internal_flag if the MARC didn't change, I think. |
| 13:13 |
jvwoolf |
Dyrcona: This is a global flag? |
| 12:27 |
mantis34 |
this was after running an npm install in the Angular folder |
| 12:40 |
jvwoolf |
We tracked the errors down to this file introduced with the fix for LP 2002435: Open-ILS/src/eg2/src/app/staff/share/admin-page/admin-page.component.spec.ts |
| 12:41 |
pinesol |
Launchpad bug 2002435 in Evergreen 3.9 "Can Still Delete Shelving Locations with Items Attached" [Medium,Fix released] https://launchpad.net/bugs/2002435 |
| 13:09 |
JBoyer |
mantis34, jvwoolf, if that's a test failure related to the defaultNewRecord test that's harmless. Because of the timing for the security release we let that through but I can fix it soon. (The "fix" is to just remove that test, because the patch being tested isn't in 3.9) |
| 13:10 |
JBoyer |
But the spec file was added in the conflict resolution of another patch that came after. |
| 13:11 |
|
mmorgan1 joined #evergreen |
| 13:14 |
jvwoolf |
JBoyer++ |
| 13:20 |
|
mmorgan joined #evergreen |
| 13:21 |
|
mantis41 joined #evergreen |
| 13:22 |
|
mmorgan2 joined #evergreen |
| 13:30 |
Dyrcona |
Speaking of tests: Does anyone know the magic sauce to the get cover uploader live test to pass with 3.10 on Debian Bullseye? |
| 13:32 |
Dyrcona |
Apparently, it is getting a 404 response, but the configuration appears to be in place. I'll check that again. |
| 13:34 |
|
mantis25 joined #evergreen |
| 13:35 |
Dyrcona |
I also changed the /tmp directory having some vague memory of that being a problem in the past. |
| 13:39 |
JBoyer |
The failing test on rel_3_9 has been fixed. That doesn't change the 3.9.2 tarball or branch, but we're good going forward/ |
| 13:42 |
JBoyer |
Dyrcona, I think that test depends on /openils/var/web/opac/extras/ac is writable by the apache user. Is apache running as opensrf on your test system? To my knowledge this is the first test that actually uses the local web server. |
| 13:44 |
Dyrcona |
JBoyer: Thanks for the suggestion. It looks like running autogen.sh fixed my issue. |
| 13:44 |
Dyrcona |
I guess I forgot to do it the first time... |
| 13:45 |
gmcharlt |
does anybody happen to have examples of using authorities with 148 fields in production? |
| 13:45 |
Dyrcona |
JBoyer++ |
| 13:45 |
JBoyer |
Probably the first test that depends on that too. :) (I wasn't real fond of adding that to autogen.sh, but it was more expedient than teaching the build system to create the necessary directories) |
| 13:45 |
Dyrcona |
Yeah. I agree. |
| 14:32 |
|
dtmoore joined #evergreen |
| 14:53 |
csharp_ |
gmcharlt: how would we know? |
| 10:31 |
Dyrcona |
When I hash just the relpath "ahr" I get "35b605f929209fc6cba65789d1f6b61c" with Python and with Emacs. |
| 10:33 |
Dyrcona |
With the Python, I went through the steps of split and join, etc., as well just to see if that made a difference. It didn't. |
| 10:36 |
|
mmorgan joined #evergreen |
| 10:42 |
Dyrcona |
I love that this is the only test for the hex_md5 function in our library: return hex_md5("abc") == "900150983cd24fb0d6963f7d28e17f72"; |
| 10:43 |
Dyrcona |
Python, Emacs, and our JS library all agree on that one, just not on other strings. |
| 10:44 |
Dyrcona |
Oops. Spoke too soon. They don't agree. The beginning and ends are the same. |
| 10:44 |
Dyrcona |
So, I suspect a bug in md5.js.... |
| 12:18 |
gmcharlt |
(though 99% of the time it would, since there's little reason to have not done a configure/make in your Git checkout) |
| 12:18 |
gmcharlt |
more likelike to bite one is making changes to Cronscript.pm and forgeting that Cronscript.pm.in is the file that's acdtually under version control |
| 12:18 |
gmcharlt |
*likely |
| 12:20 |
Bmagic |
I see. So in almost all of the Perl file cases, you can edit the *.pm files in the repository, and with the symlink, they would be "live" (after a service restart) - whereas, Cronscript.pm.in is not "live" and I would need to copy my changes from Cronscript.pm -> Cronscript.pm.in once tested |
| 12:21 |
gmcharlt |
yep |
| 12:21 |
Bmagic |
gmcharlt++ |
| 12:21 |
gmcharlt |
(though in practice, that file does not get touched all that often) |
| 12:29 |
Dyrcona |
All of the *.in files bet mangled during installation. Most of them are modified with sed. There's a better way to do it with make targets to have AC_SUBST run on them. |
| 12:29 |
Dyrcona |
s/bet/get/ |
| 12:30 |
Dyrcona |
Well, I guess we'd add them to a list in configure.ac. |
| 12:33 |
Dyrcona |
You can copy the files from lib over to the installation location after you've modified them, then restart services. That's what I do if I'm testing a change in one or two files. |
| 12:34 |
|
collum joined #evergreen |
| 12:38 |
Dyrcona |
So, when I load the report utils functions and the md5 functions in jsc, I do NOT get the same relation values that I'm seeing in this one reports template. I'm going to check another template with the same tables. |
| 12:44 |
* Dyrcona |
must be missing something in the composition of path, but I'm using the path that appears in the report template itself, which is what the JS code appears to use. |
| 09:08 |
pinesol |
News from commits: LP2002435: Add optional undelete action to basic admin page <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=be72a596d18fac13f35ffc14e9c62d559a3a3f10> |
| 09:08 |
pinesol |
News from commits: LP2002435: Don't allow shelving location fm-editor to change delete flag <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=3bd72a7782696ff03c8823c03459fee3be435d89> |
| 09:26 |
Bmagic |
Dyrcona: It's probably a missing/malformed environment or template making use of something that doesn't exist |
| 09:52 |
Dyrcona |
Bmagic: Maybe. I've noticed that the standard filters have not been renamed on the utility server. I'm testing that hypothesis first. |
| 09:56 |
Dyrcona |
Yeah. Renaming action_trigger_filters.json.example to action_trigger_filters.json fixed one of the two events on my test vm. (I found another that had not run since October 9.) |
| 09:57 |
Dyrcona |
Well, let's say it appeared to fix the event. |
| 09:58 |
Dyrcona |
Since one of the events has hourly granularity, I'll change it in production and see what happens in 10 to 15 minutes or so. |
| 10:03 |
Dyrcona |
Yeah, that was it. I got events for the hourly granularity event had not had an event created since 2022-10-09. Funny that no one noticed. Maybe we don't need to send out reminders that items are about to expire on the hold shelf? |
| 10:18 |
* mmorgan |
was going to suggest inserting Autorenew notify events directly into the table, but that's not necessary in your case. |
| 10:31 |
Dyrcona |
Well, if I had to do that, I was going to use Perl with DBI to figure out the user data for the autorenew notify events, and then use open-ils.trigger.event.autocreate to make the notify events. |
| 10:31 |
|
ahazaril joined #evergreen |
| 10:32 |
ahazaril |
I'm having difficulty to import MARC Records. Evergreen version that I used are 3.9.1. I follow the manual exactly. I tried on test server (https://bugsquash.mobiusconsortium.org/eg/staff) seems successfully, but when I tried using our Library Server, its shown error. |
| 10:32 |
ahazaril |
Any advice regarding this problems? |
| 10:32 |
ahazaril |
Here the osrfsys.log file |
| 10:32 |
ahazaril |
[2023-03-10 20:30:14] open-ils.vandelay [INFO:6795:CStoreEditor.pm:155:1678451399712214] editor[1|1] request en-US open-ils.cstore.json_query.atomic {"select":{"au":[{"column":"id","transform":"permission.usr_has_object_perm","params":["CREATE_BIB_IMPORT_QUEUE","vbq",4,"1"],"alias":"has_perm"}]},"where":{"id":"1"},"from":"au"} |
| 10:32 |
ahazaril |
open-ils.cstore 2023-03-10 20:30:14 [INFO:6996:osrf_application.c:1075:1678451399712214] CALL: open-ils.cstore open-ils.cstore.json_query.atomic {"from":"au","where":{"id":"1"},"select":{"au":[{"transform":"permission.usr_has_object_perm","column":"id","alias":"has_perm","params":["CREATE_BIB_IMPORT_QUEUE","vbq",4,"1"]}]}} |
| 10:32 |
ahazaril |
open-ils.cstore 2023-03-10 20:30:14 [INFO:6996:osrf_app_session.c:1181:1678451399712214] [open-ils.cstore] sent 385 bytes of data to opensrf private.localhost/open-ils.vandelay_drone_at_localhost_6795 |
| 10:32 |
ahazaril |
open-ils.cstore 2023-03-10 20:30:14 [INFO:6996:osrf_stack.c:163:1678451399712214] Message processing duration 0.006715 |
| 10:32 |
ahazaril |
[2023-03-10 20:30:14] open-ils.vandelay [INFO:6795:CStoreEditor.pm:155:1678451399712214] editor[1|1] json_query : returned 1 result(s) |
| 10:32 |
ahazaril |
[2023-03-10 20:30:14] open-ils.vandelay [ERR :6795:Vandelay.pm:272:1678451399712214] unable to read MARC file /tmp/bc98fed09b3081514035f98464280b7c.mrc |
| 10:32 |
ahazaril |
[2023-03-10 12:30:14] open-ils.vandelay [INFO:6795:Transport.pm:163:1678451399712214] Message processing duration: 0.137 |
| 10:32 |
ahazaril |
open-ils.cstore 2023-03-10 20:30:14 [INFO:6996:osrf_stack.c:163:1678451399712214] Message processing duration 0.000004 |
| 10:33 |
berick |
ahazaril: see this https://bugs.launchpad.net/evergreen/+bug/1855199 |
| 10:33 |
pinesol |
Launchpad bug 1855199 in Evergreen "Vandelay record queuing can fail if spool directory is /tmp" [Medium,Confirmed] |
| 10:34 |
ahazaril |
tq berick & pinesol! |
| 12:13 |
Dyrcona |
I don't imagine it would be that hard to add it to Angular. |
| 12:30 |
Stompro |
mmorgan, works for me now also. |
| 12:31 |
|
collum joined #evergreen |
| 13:37 |
Stompro |
First live perl test created!!! I want a badge. |
| 13:38 |
Dyrcona |
Heh. |
| 13:38 |
Stompro |
It took me an embarrassing long time to get it right. |
| 13:39 |
Dyrcona |
Stompro++ |
| 13:40 |
Dyrcona |
Was getting the number of tests correct at the top of the file one of those issues? |
| 13:45 |
Stompro |
No, I just ran it and updated that number once things seemed to be working. |
| 13:46 |
Stompro |
But maybe I misunderstood it. |
| 13:47 |
Stompro |
Dyrcona, I'll put my ncip changes into the ncip working repo, thanks for the feedback. I was being careless with our new repo, I'll get it fixed up. |
| 13:51 |
Dyrcona |
Stompro coll on both fronts. |
| 13:52 |
Dyrcona |
For tests, there's a trick to have it calculate them for you. |
| 13:56 |
Dyrcona |
Stompro: https://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/perlmods/live_t/lp1883171-copy-inventory.t;h=a745939ba04e166d8981942bedad3e2e5f0bc514;hb=HEAD uses done_testing() at the end because it runs a variable number of tests depending on circumstances. |
| 13:58 |
Dyrcona |
!-3:s/coll/cool/ |
| 14:03 |
mmorgan |
Stompro++ |
| 14:14 |
Dyrcona |
We need more tests and they need to be more complete, but time..... |
| 14:14 |
csharp_ |
@decide coll or cool |
| 14:14 |
pinesol |
csharp_: go with cool |
| 14:15 |
csharp_ |
test writing sounds like a decent thing for the newdev group to consider |
| 14:16 |
Dyrcona |
In some ways writing tests is harder than writing regular code. |
| 14:17 |
Dyrcona |
Or, I think it ought to be harder. |
| 14:38 |
jeffdavis |
This query has been running in our database for over a week: SELECT * FROM action.emergency_closing_stage_2_circ( '390528' ) |
| 14:38 |
jeffdavis |
The circ in question has an hourly loan duration. |
| 11:46 |
Dyrcona |
query.. |
| 11:48 |
Dyrcona |
hmm.. this is already too big... |
| 11:48 |
Dyrcona |
And, I should use a non-replica db: pg_dump: detail: Error message from server: ERROR: canceling statement due to conflict with recovery |
| 11:50 |
Dyrcona |
I'll just see about pulling the data that I need. I've been asked to delete some data from acquisitions and I think I need to modify the function that I wrote for that, so I want to pull the data into a test database to try it out there first. |
| 12:05 |
|
jihpringle joined #evergreen |
| 12:11 |
pinesol |
News from commits: LP1989284 Input labels for Manage Authorities <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=582ba4e9761461606db7459360376ac01ca97a91> |
| 12:11 |
pinesol |
News from commits: LP1997098 Stamping DB Upgrade: PG 15 <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=cce04dcc77309d86ee6a241e8487750e0ef43c60> |
| 12:16 |
berick |
Stompro: all expire times for frozen holds are null for us |
| 12:18 |
Dyrcona |
What berick said goes for us too. |
| 12:18 |
jeffdavis |
192 frozen holds with non-null expire_time here |
| 12:19 |
Dyrcona |
berick: I think I'll just use copy with queries to dump only the rows that I need to do my test. |
| 12:19 |
Stompro |
Great, it probably isn't an issue then, just some strange data in our system. |
| 12:20 |
Dyrcona |
It might not hurt to add something to the db upgrade to null the expire_time on frozen holds. |
| 12:20 |
Dyrcona |
jeffdavis just reported having some. |
