Result pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148
| 08:58 | kmlussier1 joined #evergreen | |
| 09:08 | * Dyrcona | should implement a Fieldmapper that doesn't depend on OpenSRF being installed. |
| 09:16 | Dyrcona | Guess I'll just copy the Aspen PHP code today because I want to play with enhancements to the Aspen Evergreen driver. |
| 09:17 | Dyrcona | And.... I don't want to install Aspen to test things before submitting pull requests. |
| 09:24 | Dyrcona | Oh, nifty.... Aspen looks up each class from the IDL as it needs it, but caches the results in memcached. I was gonna just grab the whole IDL at the start of a program and parse it. |
| 09:27 | Bmagic | Dyrcona++ |
| 09:41 | dguarrac joined #evergreen | |
| 12:41 | Dyrcona | Yeah, search and replace was faster to do. |
| 12:42 | smayo joined #evergreen | |
| 12:59 | smayo joined #evergreen | |
| 13:01 | * Dyrcona | caused a deadlock on a test database. yay..... whatever.... |
| 13:42 | jihpringle joined #evergreen | |
| 13:43 | Dyrcona | There are two URLs where one can get the IDL aren't there? |
| 13:46 | Dyrcona | Oh, right. |
| 15:26 | mantis1 left #evergreen | |
| 15:30 | Dyrcona | "They say these days are made of rust..." Or should that be Rust? Eh, berick? |
| 15:33 | Stompro | I'm looking at how Aspen categorizes things as fiction/non-fiction... and it categorizes poetry as Fiction by default? Which seems wrong for how Libraries usually categorize things. |
| 15:33 | Dyrcona | Command line programming with PHP: I don't recommend it if you don't need to for some crazy reason... like oh, testing the Aspen Evergreen driver without installing Aspen. |
| 15:35 | Dyrcona | Stompro: Most of that comes from the MARC, I wager. Not sure if poetry can also say "fiction" in the coded values/wherever that lives, but I've seen lots of crazy stuff in MARC records over the years...decades. |
| 15:36 | Dyrcona | Come to think of it, I don't recommend web programming with PHP, either. |
| 15:36 | Dyrcona | :) |
| 08:16 | BDorsey joined #evergreen | |
| 08:32 | Dyrcona joined #evergreen | |
| 08:43 | mmorgan joined #evergreen | |
| 08:54 | Dyrcona | Do the Angular and AngularJS tests work with Firefox and Chromium snaps? |
| 08:58 | Dyrcona | Apparently not: Firefox have not captured in 60000 ms, killing. |
| 08:59 | Dyrcona | snaps-- |
| 09:02 | mantis1 joined #evergreen | |
| 09:07 | mantis1 | I have commands for it but just wanted to check before I try |
| 09:08 | Dyrcona | You can remotely delete branches if you own them. |
| 09:09 | mantis1 | Drycona++ |
| 09:20 | Dyrcona | How long should the nightwatch tests run? I suspect that they're not working with the firefox snap. |
| 09:20 | dguarrac joined #evergreen | |
| 09:32 | Dyrcona | Maybe it was doing something. I see output in logs/. |
| 09:44 | Dyrcona | Yeah. ng e2e works with the Firefox snap. |
| 15:12 | pinesol | berick: go with Canapés |
| 15:13 | Dyrcona | csharp_++ I'll have to investigate Iron & Wine. |
| 15:15 | Dyrcona | Oh, I guess my other mistake was "CASE" after "END" in a values list. Postgres complained about the syntax. |
| 15:17 | Dyrcona | I suppose I should come up with some pgtap tests for the db changes. |
| 15:20 | Dyrcona | Now that I think about it, those two commits might be wrong. The auto_renewal column isn't used to mean auto-renewal is allowed. It means that the renewal was an auto-renewal, doesn't it...... |
| 15:23 | mantis1 | Question on this commit: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=fb7e31fd790074a1b62c882913395400223556ad |
| 15:23 | mantis1 | I would like to remove the po files from the commit. What I have been doing is git rm <file> after checking out the working branch locally then saved the commit, but after I pushed, the files remained |
| 15:49 | Dyrcona | "As we get older...Stop making sense. You won't find her waiting long...." |
| 15:50 | Dyrcona | Talking Heads come around on the shuffle again. |
| 16:23 | Dyrcona | t/regress/lp1773452_copy_state_post_checkin.pg:11: ERROR: null value in column "auto_renewal_remaining" of relation "circulation" violates not-null constraint |
| 16:23 | Dyrcona | Looks like I get to update another test, too. |
| 16:28 | Dyrcona | But, wait! There's more! |
| 16:32 | Dyrcona | I bet I've broken some perl tests, too. I'll have to check those tomorrow. |
| 16:35 | Dyrcona | it's gonna be fun going through the circ and staff client code making sure that the auto_renewal fields actually get a value put into them. I suppose i could cop out and add 'default 0'. |
| 16:36 | Dyrcona | pgtap tests have been updated at least. |
| 16:38 | Dyrcona | Might be strange for me to say this, but we need more tests. |
| 17:09 | mmorgan left #evergreen |
| 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 |
| 13:49 | kmlussier | jeffdavis: When I started, the community was on 1.6. I remember at our first MassLNC meeting, Dyrcona was telling us we should all be looking to migrate to 2.0 because it would have all the new stuff coming with the KCLS grant. In the end, we went live with later releases, but I can't forget all the hype around that one particular release. |
| 13:49 | kmlussier | 3.5 doesn't seem long ago to me because it happened after I left. |
| 14:00 | Dyrcona | For us 3.5.3 was April of 2021. I had a quick look at our old 3.5.3 branch and didn't see anything in the DB upgrade. I bet there was a patch to Vandelay or something like that. |
| 14:05 | Dyrcona | I think I'm going to have to postpone my fix test until Monday at the latest. It doesn't look like my script to dump the pretest data for later comparison with post-test data is going to finish in a reasonable time. |
| 14:06 | Dyrcona | My test db refreshes this Sunday morning, so I'd have to do this all over again anyway. |
| 14:09 | Dyrcona | The '80s were just 20 years ago, right? :) |
| 14:13 | kmlussier | Dyrcona: Yes, they absolutely were. Please don't tell me any differently. |
| 14:13 | kmlussier | And I'm still 39 years old. |
| 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:33 | Dyrcona joined #evergreen | |
| 12:50 | collum joined #evergreen | |
| 12:57 | Dyrcona joined #evergreen | |
| 13:15 | eeevil | sandbergja: I'm pointing this in your general direction because you've been AWESOME about pushing for more test automation ... do you have thoughts about where we might want to stick the following test? `(cd Open-ILS/examples && xmllint --schema fm_IDL.xsd --noout fm_IDL.xml)` |
| 13:19 | sandbergja | eeevil: ooh, good question! Maybe we could lightly wrap it in a perl test? Like run that command in backticks, and confirm that the exit code is 0? |
| 13:20 | sandbergja | or something along those lines |
| 13:21 | eeevil | maybe as part of `make check` directly? I don't have strong feelings about it, but would prefer it yell at us easily/quickly |
| 13:22 | sandbergja | yes, +1 to yelling :-) |
| 13:23 | sandbergja | example of the perl approach in the first subtest here: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=2f264c6ad779bacef4dd910bc63ece0174f82083 (the ok($output, 'runs without error');) |
| 13:24 | Dyrcona | if you only want the return value, system() would be preferable to backticks, and if you care about the output, I'd prefer a pipe open, but that's just my Perl style.... |
| 13:25 | sandbergja | Dyrcona++ # thanks! That is good to know. |
| 13:27 | Dyrcona | Just running it from 'make check' would also be good. |
| 13:49 | terranm | Bmagic or anyone - I'm trying to set one of my test servers to have the Czech option in the staff client and I can't figure out what I'm missing. These are the set up instructions I have so far: https://wiki.evergreen-ils.org/doku.php?id=newdevs:i18n |
| 13:49 | terranm | Of course, now it is working |
| 13:50 | terranm | No it's not. Argh |
| 13:52 | terranm | at https://terran-testbox.gapines.org/eg/staff - Czech is working in the OPAC. On the eg login page the Czech option is appearing in the top menu, but when logged in and on an eg2 page it's not there |
| 13:55 | jvwoolf left #evergreen | |
| 14:30 | jvwoolf joined #evergreen | |
| 14:33 | jihpringle joined #evergreen |
| 17:35 | jihpringle | I think good to have it pulled out as its own bugs, since both of us initially missed it within that bug |
| 17:35 | Bmagic | I agree |
| 17:47 | terranm | Claiming 1397 |
| 17:51 | pinesol | News from commits: LP1965985 Empty alt text for OPAC decorative images <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=b74e76e25a0856674348bfc970858cf8b6d115df> |
| 17:51 | pinesol | News from commits: LP2040314 BOOPAC 'send test email' link keyboard support <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=f15cb15e87518229e386cd7c28a767dba9d906e7> |
| 17:51 | pinesol | News from commits: LP2040314 OPAC 'send test email' link keyboard support <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=c75831ebb0f138ea4068f1aaa985946f5e8c94c8> |
| 18:04 | kmlussier left #evergreen | |
| 18:21 | pinesol | News from commits: LP2039750 Stamp upgrade script <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=ba54e37d253058ce5bc446533d9115ffaf72361e> |
| 18:21 | pinesol | News from commits: LP#2039750 Save Stat Cat Grid Settings <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=5bef90979832bd4fe9250fea0a367c7ecba28d9b> |
| 19:59 | jihpringle joined #evergreen |
| 13:41 | dguarrac | You're welcome! I used to have to use it a whole bunch in a past life. |
| 14:24 | kmlussier left #evergreen | |
| 14:58 | mmorgan1 joined #evergreen | |
| 15:11 | pinesol | News from commits: LP#2043437: stamp DB update <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=b40431111fd7f9bb20311788b3dc32b51d0fc90d> |
| 15:11 | pinesol | News from commits: Revert "lp1895699: search results page lets user know that course materials filter... <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=ead4f82da75728b459d12f595bd1bab5d2da1990> |
| 15:11 | pinesol | News from commits: lp2043437: fix flakey test <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=00003d7aa91bdf39272891da9f7c8e80aab24fb1> |
| 15:11 | pinesol | News from commits: lp2043437: add missing import to CatalogModule <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=ee6cb432f8d9eb1f8cc0b87665826c74a8d14dd4> |
| 15:17 | mantis1 left #evergreen | |
| 15:36 | Dyrcona | Well, one thing this project has revealed is that we should probably remove all of the 998 fields from our records. |
| 15:50 | Dyrcona | Interesting how MarcStreamReader and MarcPermissiveStreamReader throw different exceptions, even if you tell the latter not to be permissive. |
| 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:08 | Bmagic | I refreshed and I see new stuff |
| 15:08 | abneiman | and terranm++ sandbergja++ and mmorgan++ for many lovely merges |
| 15:08 | Bmagic | #link https://wiki.evergreen-ils.org/doku.php?id=dev:bug_squashing:2023-11 |
| 15:09 | abneiman | though there is a test conflict to talk about below in the agenda |
| 15:09 | Bmagic | terranm++ sandbergja++ mmorgan++ |
| 15:09 | terranm | 3.12 (currently) has an even 100 patches committed |
| 15:09 | sleary | terranm++ sandbergja++ mmorgan++ |
| 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:35 | sandbergja | But I don't know that I'll have much time to look into them |
| 15:36 | sandbergja | Dyrcona already started looking at the perl one, and posted some notes |
| 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:54 | sleary | ah! So, I went ahead and opened a bug for the next big Angular/Bootstrap upgrade, which should be less painful than the last one |
| 15:55 | sleary | I haven't looked too closely into what's involved on the Angular side, so I wanted to ask you all to keep an eye on that as you skim your news, and add comments to that bug if you find any potential blockers other than the ng-bootstrap accordion issue listed |
| 15:55 | sandbergja | sleary++ |
| 15:55 | smayo joined #evergreen | |
| 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 |
| 13:16 | degraafk joined #evergreen | |
| 13:18 | sandbergja joined #evergreen | |
| 13:34 | sleary joined #evergreen | |
| 15:20 | pinesol | News from commits: Fix test failure <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=a82a28788090fb31a00b0a15f3c3474f57a2c939> |
| 15:50 | pinesol | News from commits: LP1754364: Show timezone combobox in library settings editor <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=687c403fcd29cbd11b891fb91a681ba9ffc8bb56> |
| 17:21 | pinesol | News from commits: LP192012 Localize staff catalog search placeholders <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=8481ad5e6c8b20c5158b67e964ea479040e86a9a> |
| 19:03 | sleary joined #evergreen |
| 09:24 | jblyberg7 joined #evergreen | |
| 11:12 | jeffdavis joined #evergreen | |
| 11:33 | sandbergja joined #evergreen | |
| 11:34 | sandbergja | One of the live tests is failing on main. Turns out, the problem was that I had committed the wrong patch to main, thereby causing the failure. |
| 11:34 | sandbergja | Revert commit coming up |
| 11:35 | sandbergja | tests++ |
| 11:46 | pinesol | News from commits: LP#2009891: add item author to open-ils.actor.carousel.get_contents <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=dd778b5060fff492b1cdb83f3fa91ea7d3eb61ed> |
| 11:47 | pinesol | News from commits: Revert "LP#2009891: add item author to open-ils.actor.carousel.get_contents" <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=301fdb85adb5078e2aaaa128e679b8e36e3717a3> |
| 15:28 | sleary joined #evergreen | |
| 18:48 | pinesol | News from commits: LP2041364: Fix a mistake in the marc_export error reporting code <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=11a4c120352bc63642edcee003b3d2816ea074db> |
| 18:48 | pinesol | News from commits: LP2041364: Refactor marc_export cursor code <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=b2091fa8ffeab3598a4bd16370d4f88e94ae4952> |
| 18:48 | pinesol | News from commits: LP#2041364 - Use a cursor to load 10000 bibs at a time. <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=ac211b0f450177be8d3b27bcc565cad0ae63ecf9> |
| 18:48 | pinesol | News from commits: LP2041364: Attempt to speed up 852 insertion in marc_export <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=71b7e501a305a495b374d6971b185c02aae43672> |
| 19:42 | jblyberg7 joined #evergreen | |
| 19:48 | pinesol | News from commits: LP2012402 follow-up: let tests know about PcrudService constructor's new API <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=532315227a16223624eebc333e6ebb12b0d66be2> |
| 19:48 | pinesol | News from commits: LP2012402 Authoritative APIs are optional; disabled by default <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=db09291462c6102c83d4fc4eb59593d8225c9cd8> |
| 20:28 | ejk joined #evergreen | |
| 21:50 | eglogbot joined #evergreen | |
| 21:50 | Topic for #evergreen is now Welcome to #evergreen (https://evergreen-ils.org). This channel is publicly logged. Logs for today: http://irc.evergreen-ils.org/evergreen/today |
| 11:38 | terranm2 joined #evergreen | |
| 11:43 | pinesol | News from commits: LP2040186 Survey Q&A button colors and input labels <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=4edae0c4be27d2e4adb822542696ad546b9c02e3> |
| 12:13 | pinesol | News from commits: LP2037685 - Staff Catalog: Default Search and Preferred Library settings are deleted... <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=bcbb33a5fa97aff70f81f27cd16b0e18144323f6> |
| 12:18 | abneiman | anyone have some test love to show to https://bugs.launchpad.net/evergreen/+bug/1999158 ?? It's a needed a11y fix and is currently on https://terran-main.gapines.org/ |
| 12:18 | pinesol | Launchpad bug 1999158 in Evergreen 3.11 "Labels for eg-org-select combobox" [Medium,Confirmed] |
| 12:33 | eby joined #evergreen | |
| 14:05 | terranm joined #evergreen | |
| 15:00 | sandbergja joined #evergreen | |
| 15:02 | JBoyer | terranm++ This week really didn't end up working out for me at all but it looks like some good stuff has been done. |
| 16:04 | terranm | sandbergja and I are both working on getting more of the tested things committed too, so I think 3.12 is going to have a lot of stuff in it |
| 16:27 | abneiman | terranm++ sandbergja++ |
| 16:27 | abneiman | I've also put bugs (pun absolutely intended) in some other committer ears, too |
| 16:38 | sleary | terranm do you know if bug 1934018 is still on one of the testing servers? I think it was on the spreadsheet but got lost in the shuffle |
| 16:38 | pinesol | Launchpad bug 1934018 in Evergreen "Angular Staff Catalogue: More Link Missing from Facets" [High,Confirmed] https://launchpad.net/bugs/1934018 |
| 16:39 | jweston joined #evergreen | |
| 16:41 | terranm | sleary no, it's not on one of them right now |
| 16:44 | pinesol | News from commits: LP2035535: Add accessibility tests to nightwatch <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=74a240914ca86fa06d169b3928e57352156b7171> |
| 16:44 | pinesol | News from commits: LP#2033067 The "prev" and "next" navigation buttons in carousels are not translated. <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=632aca33848e7415d5b008c000c8cc432bbd6e54> |
| 16:44 | pinesol | News from commits: LP1908568: double-click item to open editor <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=8fba1be55ba291c2deb44604ed0fb8dc2539875f> |
| 17:00 | berick | grabbing 1390 |
| 17:14 | pinesol | News from commits: LP#2035389: Don't use locg to determine whether course reserves links display in... <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=e4288874c5ba6bbf6004f8fba038549d4d58d511> |
| 17:14 | pinesol | News from commits: LP#2037128: release note <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=f5ea0711e36254d03bfab8bb49f141320192f8e4> |
| 10:32 | terranm | redavis++ cool beans, thx |
| 10:41 | redavis | mmorgan, looking at https://bugs.launchpad.net/evergreen/+bug/1956241. In the patch, it says it adds it maps the missing permission to the concerto circ administrator and circulator permission groups. I'm only seeing it in the circulator permission group. BUT I think the main goal of the patch is to add the permissions. If I'm understanding that correctly, I think it's ready for a sign off. |
| 10:41 | pinesol | Launchpad bug 1956241 in Evergreen "Hold Groups: Staff Users Cannot View Patron Hold Groups" [Medium,Confirmed] |
| 10:46 | mmorgan | redavis: Yes, the goal was to add the permission to some permission groups that made sense, esp for testing. Not sure why the circ admin didn't get them. |
| 10:48 | redavis | ++, sign off added |
| 10:49 | redavis | Though Elizabeth Davis (not to be confused with Ruth Elizabeth Davis) did testing before me. |
| 10:49 | mmorgan | redavis++ |
| 11:03 | briank joined #evergreen | |
| 11:03 | Dyrcona joined #evergreen | |
| 11:10 | redavis | woohoo! Used the Axe DevTools and was able to run an accessibility test! |
| 11:10 | terranm | I noted in my comment that the seed data SQL and the upgrade SQL aren't consistent. It doesn't prevent it from working properly in production, but could be a little confusing for test servers. |
| 11:10 | redavis | terranm+ |
| 11:10 | redavis | terranm++ also |
| 11:16 | Rogan joined #evergreen | |
| 12:13 | jblyberg7 joined #evergreen | |
| 12:21 | Dyrcona | Y'know what? I'm done with captchas. If a site asks me to solve a puzzle or some crap, I'm going away and not coming back. So, how is this relevant here? Well, it means no bug report on MARC::Records' RT. Well, let's see what happens if I sign in, first. |
| 12:24 | Dyrcona | It wants you to solve a puzzle to logout of "guest." I know they've had issues with spam, but I'm so sick of "proving" that I'm human. (Also, turns out that bots are better at solving some of the puzzles than humans, so they consider failure to be success, too.) |
| 12:31 | pinesol | News from commits: LP2039612: regression test for creating carousels <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=b418f2dfa8b9ec16d132b74c25c240480d2b5ed0> |
| 12:31 | pinesol | News from commits: LP2039612: Fix Carousel create / edit <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=00bd4c88d60fedaf1a39a7d34a24f0c2e2bd2c00> |
| 12:34 | collum joined #evergreen | |
| 12:39 | redavis | terranm, have signed off on several of the accessibility LP tickets on terran-main.gapines.org. Gonna peace out for while. Maybe the day. Back at it tomorrow as time allows. |
| 12:52 | collum joined #evergreen |
| 09:57 | pinesol | News from commits: LP#2009891: add carousel default name to open-ils.actor.carousel.retrieve_by_org <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=0b2561df57fbed32351e07d883370358bc3a9314> |
| 09:57 | pinesol | News from commits: LP#2009891: add item author to open-ils.actor.carousel.get_contents <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=79080a199753a2240767d5ff8036af2fa18445a4> |
| 10:01 | sleary joined #evergreen | |
| 10:20 | terranm | Bmagic: Do you have reports running on your test server? |
| 10:22 | smayo joined #evergreen | |
| 10:51 | smorrison joined #evergreen | |
| 10:55 | briank joined #evergreen | |
| 12:18 | jeffdavis | we've been on PG14 in production for >6 months, it's just fine |
| 12:19 | berick | jeffdavis++ |
| 12:19 | Dyrcona | jeffdavis++ |
| 12:19 | Dyrcona | I've been testing production data with Pg 15, but not full time. |
| 12:19 | Dyrcona | I still run Pg 10 most of the time. |
| 12:20 | jeffdavis | we had to do a bit of cleanup prior to our Postgres upgrade because our EG install is so old, but nothing too arduous and we don't have any ongoing issues related to PG versions |
| 12:21 | Dyrcona | I can upgrade from Pg 10 to Pg 15 simply by applying the Evergreen db upgrades and doing a pg_dump and pg_restore. We have applied most of the necessary updates already. |
| 12:22 | Dyrcona | Hm. Maybe I'll swap Pg 10 and Pg 15 on my test system and just use Pg 10 to do the needed updates.... |
| 12:23 | Dyrcona | Yeah, I'll set that up this afternoon. |
| 12:24 | Dyrcona | Someone should open a Lp about Pg 10 and 11, and possibly Pg 16. |
| 12:34 | Dyrcona | jeffdavis: Have you seen the bug about disabling JIT in Pg? Lp 2042158 |
| 13:36 | jihpringle | the only common thing we could find with the holds that weren't showing was that it was the older holds |
| 13:52 | jonadab | Item-level holds have a number of gotchas, yeah. The capability is useful for a variety of technical reasons, but it almost ought to be locked behind a "Yes I want this specific copy" confirmation or something. |
| 14:26 | mmorgan | mantis1: By "item" do you actually mean item hold? That is hold_type = C? We have seen visibility oddities with metarecord holds (hold_type = M). |
| 14:26 | mantis1 | mmorgan: yes |
| 14:26 | mantis1 | I did try replicating the issue on a test server but it does work as 'intended' |
| 14:26 | mantis1 | I let them know just to do bib level for now |
| 14:26 | mantis1 | just baffled by what could cause this specifically |
| 14:35 | jeff | if you look at the hold in question, assuming it is hold_type = 'C', does the hold's target point to a valid, non-deleted copy in asset.copy? Does the hold have an entry in reporter.hold_request_record? |
| 14:42 | mantis1 | jeff: ah good question I will check |
| 14:45 | mantis1 | jeff; yes to all |
| 08:32 | Dyrcona joined #evergreen | |
| 08:34 | mmorgan joined #evergreen | |
| 08:49 | collum joined #evergreen | |
| 08:52 | Stompro | JBoyer, morning. My testing of NCIP AcceptItem and RequestItem with ToAgencyID set to our system level OU seems like it works ok. As long as <PickupLocation> is set in the AcceptItem message at least. I'll send you my notes. |
| 08:54 | JBoyer | Stompro ++ |
| 09:03 | sandbergja joined #evergreen | |
| 09:04 | sleary joined #evergreen | |
| 15:21 | berick | that would be ideal for the 2-hackers-on-the-same-keyboard setup |
| 15:21 | berick | just slappin keys |
| 15:28 | Stompro | Can't just add "use OpenSRF::Utils::Logger;" "Bareword "OpenSRF::Utils::Logger" not allowed while "strict subs" " |
| 15:39 | JBoyer | Stompro, when I've wanted this I just used the raw perl syslog module, hard-code the various params, and just dropped a log line with the whole incoming and outgoing xml messages for testing. I don't use it in prod because SHAREit does send passwords even though we don't check them. |
| 15:39 | Dyrcona | JBoyer++ |
| 15:42 | Stompro | JBoyer, thanks, I just want to add some print statements to figure out why certain code isn't working correctly. I don't actually need the messages right now. |
| 15:43 | JBoyer | Ah, fair. But the end result is the same, sprinkle syslog() calls wherever you want to shine a light. |
| 12:24 | Stompro | Dyrcona, what are you seeing now? |
| 12:41 | Dyrcona | Stompro: It's just that one of the exports also tried to pull in consortium-wide URIs. I think everything is OK. I've installed marc_export with the experimental patches to production. |
| 12:42 | Dyrcona | So, I meant that maybe the grep was not causing issues, but that doesn't explain the other library, so I guess it was really the problem. |
| 12:43 | Dyrcona | I'm getting similar numbers in my test environment as production at this point, so that's why I'm throwing it over there. |
| 12:44 | berick | rusty bits for the redis changes from above https://github.com/kcls/evergreen-universe-rs/tree/working/opensrf-bus-addrs-username |
| 12:45 | Dyrcona | berick++ # I was going to ask if I should update my development system for the latest OpenSRF/Redis stuff. Maybe later today..... |
| 12:46 | Dyrcona | Stompro: I'm about to add this to Lp 2015484: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/dyrcona/lp2015484_exclude_opac_visible_from_export-rebase |
| 12:46 | pinesol | Launchpad bug 2015484 in Evergreen "marc_export: provide way to exclude OPAC-suppressed items" [Wishlist,Confirmed] https://launchpad.net/bugs/2015484 - Assigned to Jason Stephenson (jstephenson) |
| 12:46 | Dyrcona | That's what I'm testing and have installed in production. |
| 12:48 | Stompro | Dyrcona, ahh, I thought you meant the @orgs lookups with grep, from the performance branch. |
| 12:52 | Dyrcona | I was talking about the extra grep in the exclude hidden items branch. |
| 12:52 | Dyrcona | If its any consolation, I had to sit for a minute earlier and rest my brain to focus on one thing at a time. :) |
| 12:58 | Stompro | Dyrcona, understood. |
| 12:59 | jeffdavis | eeevil++ Bmagic++ # jit_above_cost = -1 fixed the thing on our test server also - I would never have figured that out! |
| 13:12 | collum joined #evergreen | |
| 13:19 | Stompro | JBoyer++, thank you for helping me understand the possible roadblocks with NCIPServer and ReShare. Sorry about all the questions. |
| 13:20 | Stompro | Dyrcona has explained to me before about how varied NCIP implementations can be. |
| 14:39 | pinesol | News from commits: LP1965326 Hatch Printer Settings Port Release Notes; Lint. <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=2c707d83d6625137e7a89a7da5035b1bd84abd9f> |
| 14:39 | pinesol | News from commits: LP1965326 Move Hatch Printing to Printer Settings <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=ac97129d9adb5a36026fc25cb44ba4debc56ddc3> |
| 14:39 | pinesol | News from commits: LP1965326 Printer Settings Angular Port <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=b01b14fed8cee098b9911f24f4d656003f7b0f2a> |
| 15:07 | Stompro | JBoyer, if you haven't started replying to my last NCIP email... ignore it for now. I'll test out the AcceptItem and RequestItem requests with AgencyID set to our system shortname to see how it behaves in real life. |
| 15:08 | JBoyer | Stompro++ it was on the list but I'll set it aside now. |
| 15:32 | jihpringle joined #evergreen | |
| 16:02 | sandbergja joined #evergreen |
| 10:43 | BAMkubasa joined #evergreen | |
| 10:50 | mantis1 joined #evergreen | |
| 10:55 | briank joined #evergreen | |
| 11:15 | Dyrcona | OK. I have the latest Rust marc-export test running. I'll see how long this takes. |
| 11:27 | jihpringle joined #evergreen | |
| 12:14 | Christineb joined #evergreen | |
| 12:18 | eeevil | berick: drive by question (from immediately-post hack-a-way) incoming! meetings will probably keep me away from here for the rest of the day, but want to get it to you asap for RediSRF(?) goodness |
| 12:20 | eeevil | berick: I'm looking at opensrf/redis anew via the collab branches. I have two questions that jump out at me: is the --reset-message-bus documented beyond "you must do this at redis restart" somewhere? (the commit it comes in with isn't obvious to me; also, I want to help remove any instances of boilerplate stuff that we can automate or fold into other actions as early as possible -- ideally before merge -- and I know this is under discussion or at |
| 12:20 | eeevil | least being thought about); and, while the config and password list files don't require it themselves, it /looks/ like the usernames are pinned as "opensrf", "router", and "gateway" in the code that implements each part. is that correct and do you see any reason we /can't/ replace those strings with the value pulled from opensrf_core.xml as with ejabberd? the result being ACL-separated user sets that share a redis instance but can't talk to each |
| 12:20 | eeevil | other or guess each other's user and queue names. |
| 12:32 | Dyrcona | eeevil: berick said earlier that he modified osrf_control to do --reset-message-bus as required, so its not necessary now. I'm testing that and other updates. That's a good question about the names. (I generally don't change them.) |
| 12:33 | Bmagic | I'm troubleshooting a database issue. explain analyze on an insert into biblio.record_entry results in 6+ seconds. The analyze shows me that it spends the majority of the time in reporter.simple_rec_trigger(). Which is odd, because if it's an INSERT, it should just skip down to RETURN. Weird right? |
| 12:33 | Dyrcona | Bmagic: No. It still builds the rmsr entry. |
| 12:34 | Dyrcona | Wait until you update an authority with hundreds of bibs "attached." :) |
| 12:35 | Bmagic | this is EG 3.11.1 with queued ingest. I updated the global flag to turn off queued ingest, and tested it. and visa versa. it's 13 seconds for an insert with it turned off, and 6 seconds with it turned on. But still, 6 seconds seems insane for an insert on biblio.record_entry, especially if we're deferring all of the metabib stuff for the ingester process to come later |
| 12:35 | Dyrcona | Updating/inserting bibs and auths can be slow because of all the triggers. |
| 12:36 | Bmagic | I got here because it's breaking the course reserves interface. Taking too long |
| 12:37 | * Dyrcona | colour me unsurprised. |
| 16:52 | Bmagic | retested, and was dissappointed. Restarted postgres, still dissappointed |
| 16:52 | Bmagic | disappointed |
| 16:55 | jeffdavis | Is it consistently ~6 seconds even for other IDs? Like, not 4 or 8 seconds? |
| 16:59 | jeffdavis | We were having an issue on a test server where calls to open-ils.pcrud.search.circ were consistently taking about 6.5s per circ. I never got to the bottom of it (fortunately we're not seeing that in production). It's a long shot but maybe there is a connection? Don't want to send you down a rabbit hole though! |
| 17:00 | Dyrcona | There are only 1 or 2 tables involved in that function. Everything else is 4 views that percolate up. |
| 17:00 | jeffdavis | But the flesh fields for the problematic call include wide_display_entry. |
| 17:01 | Dyrcona | Which is a view, IIRC. |
| 17:09 | jeff | out for now, back later! |
| 17:10 | Bmagic | https://explain.depesz.com/s/Df5A |
| 17:11 | Bmagic | so that seems to have revealed that it's sequential scanning display_field_map |
| 17:16 | jeffdavis | I can confirm we're seeing the same behavior on our test server with your example query (explain (analyze, buffers) select * from reporter.old_super_simple_record where id=x) |
| 17:16 | Bmagic | so weird, two databases, one a replicant of the other. I just synced up those two settings in postgresql.conf and restarted the primary database. The query is still sequentially scanning that table instead of using an index. I run the same query against the secondary database and it's fast |
| 17:17 | Bmagic | jeffdavis: yous is sequential scanning? |
| 17:17 | jeffdavis | test db (slow): https://explain.depesz.com/s/pkwY |
| 17:17 | jeffdavis | prod db (fast): https://explain.depesz.com/s/UWu5 |
| 17:19 | Bmagic | jeffdavis: interesting. In my case, it's prod that's slow and the secondary database is fast |
| 17:20 | Bmagic | what's even more interesting, is for your fast case, it's seq scanning display_field_map and apparently that's not taking much time at all |
| 17:24 | Bmagic | jeffdavis: PG14? |
| 17:24 | jeffdavis | yes |
| 17:25 | Bmagic | jeffdavis++ |
| 17:25 | jeffdavis | The servers are pretty different, the test db is the product of pg_dump/pg_restore rather than replication |
| 17:25 | Bmagic | yeah, I'm tempted to dump/restore as well |
| 17:26 | Bmagic | I out of ideas, so that one comes to mind :) |
| 17:27 | jeffdavis | well, we're seeing it after dump/restore, but who knows, maybe it would help! |
Result pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148