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
| 13:23 | kmlussier | I need to head out, but thanks everyone for listening to me vent. If I have time this weekend, maybe I'll do the legwork of going through the Wayback machine in the hopes that somebody with power can address this. |
| 13:23 | kmlussier | Have a good weekend! |
| 13:24 | Bmagic | you too! |
| 14:12 | JBoyer | Dyrcona, an FYI for you since I know we're both interested, I was testing NCIPServer on Buster and Bullseye and things seem fine without the patch from lp 1732485 . Have you tested things on Ubuntu 20.04+ |
| 14:12 | JBoyer | ? |
| 14:12 | pinesol | Launchpad bug 1732485 in NCIPServer "Crash with mime type application/xml on recent distros" [High,Confirmed] https://launchpad.net/bugs/1732485 |
| 14:14 | JBoyer | (granted, I'm mostly throwing LookupUser requests at it with curl, but things work with and without the Content-Type: application/xml header. |
| 14:15 | Dyrcona | JBoyer: I don't think I have tested NCIP on Ubuntu 20.04+. I know that I have not tested it on Ubuntu 22.04. |
| 14:16 | JBoyer | Possibly good news then, though i guess if you're not going to be managing the hosting it's not such a big deal locally. :) |
| 14:19 | Dyrcona | Well, I should try it anyway. |
| 14:21 | Dyrcona | Not today, though... |
| 14:21 | JBoyer | Dyrcona++ |
| 14:22 | JBoyer | And yeah, just wanted to make sure you knew it was worth checking out whenever there's free time. |
| 14:24 | Dyrcona | JBoyer++ |
| 14:24 | Dyrcona | I may have tested it on 20.04 and don't remember doing it. |
| 14:51 | Dyrcona | hmmm... Looks like we can lose a modification to the IDL. Either it was fixed or our change was unnecessary to begin with. I should try to figure out if we're using the field we added in any reports. |
| 14:59 | Dyrcona | Wudnchanoit.... 3 templates use our "junk" field. |
| 15:25 | jihpringle joined #evergreen |
| 10:27 | Dyrcona | And, I always force the record encoding to UTF-8 via options. |
| 10:28 | Dyrcona | There are also no differences in how they handle the encoding option input or output. |
| 10:28 | Dyrcona | There's something weird going on with one set of records, and I'll modify my generic preprocessor to use utf8 on the output. |
| 10:29 | Dyrcona | I'll have to test if that breaks other record loads, and if so, add an exception for Kanopy..... |
| 10:29 | Dyrcona | Y'know. I may just add the exception for Kanopy anyway.... |
| 10:31 | Dyrcona | It's ugly, but it's Perl. |
| 10:34 | Dyrcona | I did plan on using a shell wrapper around the generic script for the Overdrive records, but that got put on hold because of other things. |
| 14:16 | jeff | Budget season approaches! |
| 14:17 | jeff | AWS has a number of ARM-based instance types. |
| 14:18 | jeff | ...and GCP has some in preview / pre-GA |
| 14:18 | mixo | I tried now add workstation in windows and it was succesfull |
| 14:19 | mixo | and I have one question, thank you for help |
| 14:19 | mixo | WARNING Error parsing JSON message on STDIN org.json.JSONException: A JSONObject text must begin with '{' at 3 [character 1 line 2] : |
| 14:20 | mixo | this appears during hatch test |
| 14:20 | mixo | is this problem? |
| 14:20 | Dyrcona | jeff: I imagine that ARM would as well as x86. |
| 14:21 | Dyrcona | ...would work as well as x86. |
| 14:26 | Dyrcona | mixo: I don't have any experience with Hatch. Maybe someone else knows? |
| 12:03 | jeff | one log message that could help looks like this: |
| 12:03 | jeff | $logger->info("updating pickup lib for hold ".$hold->id." while on holds shelf"); |
| 12:04 | jvwoolf | jeff++ |
| 12:08 | jeff | I believe the "Wrong Shelf" hold status is designed to be noticed if staff are viewing the hold shelf in the staff client, especially the "show clearable holds" part. In our environment, we'd likely use a report for that, similar to how we report on cancelled holds on shelf. |
| 12:11 | jeff | I'm not sure without some more digging/testing how the hold would behave, but I think everything would stop regarding that hold and copy until the copy was checked in, at which point it would go in transit to the new pickup_lib. |
| 12:13 | jvwoolf | I think I figured out what might be going on |
| 12:13 | jvwoolf | Someone is trying to filter the pull list by pickup library, but they're changing the pickup library for the holds on the list instead |
| 12:15 | jihpringle joined #evergreen |
| 14:53 | Dyrcona | @loves |
| 14:53 | pinesol | Dyrcona loves git; sed; OpenBSD; gnu/emacs; git-quickpick; tmux; and #evergreen |
| 14:55 | jeff | @hates csharp |
| 14:55 | pinesol | csharp hates dojo_hold_policies_interface; SIP; when libraries purchase third party products without testing and blame Evergreen for it not working; reports; the fact that the Base Filters is unnecessarily greyed out when applying an Aggregate Filter and vice versa; evil; reports more; reports even moar; details; reports even more; the fact that the Base Filters is unnecessarily greyed out when applying an (2 more messages) |
| 14:55 | jeff | @more |
| 14:55 | pinesol | jeff: Aggregate Filter and vice versa even more; having to teach SIP2 client vendors about the SIP2 specification; troubleshooting reports; money reports; marc; reports even more than before; the EDI ruby bits; acquisitions; <quote>fun<unquote>; edi; sip2; sip too; sip two; acq; acq more; acq way more than before; omg I hate acq; omg I love acq; hate hate hate; comcast; action_triggers; javascript; (1 more message) |
| 14:55 | jeff | @more |
| 10:21 | csharp_ | holy crazznap: Execution time: 127095178.213 ms |
| 10:22 | csharp_ | 35.3041666667 hours (thanks to DuckDuckGo) |
| 10:25 | Dyrcona | That's what happens when you do a Cartesian product of two very large tables, provided you don't run out of memory first. |
| 10:26 | Dyrcona | Which reminds me...I've got something running on a test vm that I should check. It's probably finished by now. |
| 10:27 | Dyrcona | I used time on it: 2719m34.212s |
| 10:33 | Dyrcona | 45 hours 19 minutes. |
| 10:37 | Dyrcona | PostgreSQL and kernel updates..... |
| 10:42 | Dyrcona | Pg 15 release planned "in the third quarter of 2022." I can't find anything more specific than that, though Beta 3 was just released. |
| 11:39 | BDorsey joined #evergreen | |
| 11:51 | jihpringle joined #evergreen | |
| 11:54 | Dyrcona | Well, no errors in the test record load since I fixed the encoding in the Perl code. |
| 13:21 | stephengwills left #evergreen | |
| 14:15 | BDorsey joined #evergreen | |
| 22:33 | bshum joined #evergreen |
| 10:14 | berick | miker: k, yeah, i figure there's some indexes, etc. we could add. as a data point, my last attempt timed out out after 6 hours. |
| 10:14 | berick | it was barebones |
| 10:20 | rjackson_isl_hom joined #evergreen | |
| 10:21 | csharp_ | I'm backporting it here to my 3.8 test server just to play around |
| 10:25 | miker | berick: well, barebones is ... relative, if you look at the source query. "less filters" doesn't necessarily mean "less work for PG" |
| 10:26 | berick | this one was count of circs per month in 2018 |
| 10:38 | miker | I'd suggest SR might be the wrong tool for that particular report ;) ... and that's only about 1/4 snarky -- the example a trivial template to create and share in the normal reporter, and SR is meant to make Hard(tm) things (arguably some impossible things, for normal folks in the normal reporter) simple(r), not all things one-click easy AND fast. It trades internal complexity for external simplicity. |
| 14:20 | jvwoolf left #evergreen | |
| 14:27 | rjackson_isl_hom joined #evergreen | |
| 15:27 | rjackson_isl_hom joined #evergreen | |
| 15:31 | mmorgan | FIFO question. If a library has FIFO set as best-hold selection sort order, shouldn't the item be captured for the hold with the highest priority, no matter the pickup location? |
| 15:32 | mmorgan | I'm finding that a local hold is captured when there are higher priority holds for pickup elsewhere. |
| 15:33 | mmorgan | We don't use FIFO, just testing for a particular situation. |
| 17:04 | mmorgan left #evergreen |
| 14:34 | JBoyer | Thoughts on punting until September? |
| 14:35 | mmorgan | +1 from me (since my question was answered) :) |
| 14:36 | * mmorgan | may get pulled away anyway |
| 14:40 | Dyrcona | +1 to punting until September. I may actually get to look at test setup by the next meeting. |
| 14:41 | jihpringle joined #evergreen | |
| 14:51 | tlittle joined #evergreen | |
| 14:55 | terranm joined #evergreen |
| 10:16 | Dyrcona | I'm going to try and solve my record issue by rewriting the prep script in Python using PyMarc and chardet to autodetect the character set of each record. I wonder what chardet will say about MARC-8 records? Maybe, it will call them ISO 2022? |
| 10:23 | Dyrcona | Maybe I can keep most of the Perl code and just throw the XML at a character set detection program? |
| 10:30 | Dyrcona | Running chardet on the input files says, "utf-8 with confidence 0.99." |
| 10:30 | * Dyrcona | sighs. Guess I'll just jam the bad records in, like my current test is doing. |
| 10:49 | jvwoolf joined #evergreen | |
| 11:08 | jihpringle joined #evergreen | |
| 11:29 | Dyrcona | I wonder if $raw =~ s/\xC2/.../g; works on UTF-8 files that might have \xC2A9 and other multibyte sequences.... |
| 11:32 | Dyrcona | I suppose that I could test it. |
| 11:53 | Dyrcona | Weird, 0xC2A doesn't give me they copyright symbol. Let me try it reversed for little endian. |
| 11:54 | Dyrcona | Funny, too, how 0xC2 only prints "correctly" when other unicode sequences are in the string. Otherwise it prints as an unknown character glyph. |
| 12:26 | Dyrcona | Unicode in Perl is a pain. |
| 11:21 | Dyrcona | berick foun the missing step... :) |
| 11:21 | Dyrcona | found, even.. |
| 11:26 | jihpringle joined #evergreen | |
| 11:38 | mmorgan | berick++ |
| 11:38 | mmorgan | Thanks! |
| 11:38 | * mmorgan | now moves on to 4. profit and 5. invest wisely :) |
| 11:45 | * mmorgan | has been trying all morning to test a checkin of an item in a certain shelving location with a particular variety of item alerts. |
| 11:46 | mmorgan | It has been an adventure just setting up the scenario :-/ |
| 11:55 | csharp_ | has anyone developed/found any tools that would be useful in de-duping authority records? |
| 11:56 | csharp_ | mmorgan: don't you wish some of the end users who are always mad that something "isn't fixed" could watch what we do sometimes? :-) |
| 12:01 | mmorgan | csharp_: Actually, I feel for them! This library is trying to use the shelving location attribute Hold capture delay and it's not working with item alerts. Evergreen just seems to "forget" that it's in the middle of a checkin. |
| 12:03 | mmorgan | Our test system is on 3.8.1 and I ran across a couple of item alert bugs that are fixed - in 3.8.2 |
| 12:04 | mmorgan | rabbit-holes-- |
| 12:07 | jihpringle | mmorgan: that sounds very similar to https://bugs.launchpad.net/evergreen/+bug/1735221 |
| 12:07 | pinesol | Launchpad bug 1735221 in Evergreen "webclient: items with copy alert and hold verify fail to capture for hold" [Low,Confirmed] |
| 12:08 | mmorgan | jihpringle++ |
| 12:08 | mmorgan | Aha! Didn't find that and it's exactly the issue! |
| 12:10 | mmorgan | And it's not a new issue either. |
| 12:11 | jihpringle | ya, we've been running into that one since we switched to the web client |
| 12:12 | jihpringle | it's on my list to test in 3.9 and possibly in the angualr circ (if that server is still up this week) |
| 12:14 | mmorgan | Definitely still an issue in 3.8! |
| 12:18 | mmorgan | Our library is trying to use hold capture delay for hotspots, I think they need to check or reset them before they can go out again. I suggested they use the hold capture delay, not knowing there was a bug :-( |
| 12:21 | jihpringle | they could use the Suppress Holds and Transits check in modifier (not as good since staff have to remember to use it) but could work for now |
| 12:25 | mmorgan | jihpringle: Thanks, I will suggest that option. Just commented on the bug. |
| 12:27 | jihpringle | just tested it in the new angular circ and it's still an issue there |
| 12:27 | jihpringle | I'll update the bug and the circ spreadsheet |
| 12:45 | Dyrcona | I didn't look very hard, but it appears to me that hold verify is just gonna break checkin no matter what. The location having hold_verify set does a bail on events, and do checkin returns if there is a bail on events right after that check is made. However, I didn't look much farther than that and circulation code is tricky. |
| 13:01 | mmorgan left #evergreen | |
| 13:11 | * Dyrcona | wonders if it is time to have the community git discussion again. We're looking at possibly making some changes here because of things going on, and it would be useful if we could link what we're doing with the community. |
| 08:22 | collum joined #evergreen | |
| 08:32 | terranm joined #evergreen | |
| 08:33 | mmorgan joined #evergreen | |
| 09:29 | abneiman | @later tell smorrison I'm sorry I missed your message about test servers, but I'm glad it was sorted - quassel is sketch for me with notifications; I'm more likely to see emial faster - abneiman equinoxOLI.org |
| 09:29 | pinesol | abneiman: The operation succeeded. |
| 09:39 | smorrison joined #evergreen | |
| 09:53 | terranm joined #evergreen |
| 08:58 | smorrison joined #evergreen | |
| 09:03 | terranm joined #evergreen | |
| 09:28 | terranm joined #evergreen | |
| 09:29 | terranm | berick: For the Angular circ/patron interface testing, do you want me to copy over all the findings onto the LP ticket, or would it be easier for you to go off of the testing spreadsheet at https://docs.google.com/spreadsheets/d/1PL04fcjom0l2xuum_Do-w04asn-ifAEHwuBY6yWIESQ/edit#gid=0 ? |
| 09:37 | smorrison joined #evergreen | |
| 09:40 | jihpringle joined #evergreen | |
| 09:50 | smorrison joined #evergreen | |
| 09:55 | csharp_ | berick: I was testing https://bugs.launchpad.net/opensrf/+bug/1970667 and saw a very long delay when installing ejabberd while running the OpenSRF Makefile.install - this is on a stock 22.04 machine - did you see simlar? |
| 09:55 | pinesol | Launchpad bug 1970667 in OpenSRF "Add Installation Support for Ubuntu 22.04 Jammy Jellyfish" [Undecided,New] |
| 09:57 | csharp_ | Created symlink /etc/systemd/system/multi-user.target.wants/ejabberd.service → /lib/systemd/system/ejabberd.service. |
| 09:57 | csharp_ | ... <several minutes delay> ... |
| 12:53 | csharp_ | @decide git blame or git blam? |
| 12:53 | pinesol | csharp_: go with git blame |
| 15:21 | smorrison joined #evergreen | |
| 16:19 | terranm | You guys... we're actually running out of pullrequests to test! (Well, ones that end users can test anyway.) |
| 16:25 | mmorgan | Wow! That's great! |
| 16:25 | mmorgan | terranm++ |
| 16:28 | JBoyer | I won't be around tomorrow so pattypan and festivus are pretty much The Way They're Going To Be, but there are some good things to check out on both! Also that Hatch patch; you can test that against any server, not necessarily a testing one! |
| 16:28 | JBoyer | and yeah, terranm++ Great work, it's much appreciated. |
| 16:30 | terranm | JBoyer++ The multiple server refreshes definitely kept things moving this week! |
| 17:15 | mmorgan left #evergreen |
| 15:17 | pinesol | Launchpad bug 1978889 in Evergreen 3.8 "Item alert types not displaying with alert" [Medium,Confirmed] https://launchpad.net/bugs/1978889 |
| 15:20 | shulabear joined #evergreen | |
| 15:22 | berick | terranm: yes |
| 15:23 | terranm | Okay, I think I missed including that line on my test server since it had a different LP number. Trying to apply it now... |
| 15:23 | berick | ah, k |
| 15:43 | terranm | Hrrm, I don't see Galen's changes to Open-ILS/src/eg2/src/app/staff/share/holdings/copy-alerts-dialog.component.html in your commit |
| 15:43 | csharp_ | looks like https://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=cc9c27b8647b39c44a1270b74b65bbe1a044739a was missed in the signoff/add'l branch |
| 15:44 | terranm | I have applied it to my test server and Elaine tested it successfully, so it is ready to be committed |
| 15:44 | csharp_ | sorry, that's wrong |
| 15:44 | csharp_ | let me keep looking |
| 15:45 | terranm | It should be the 4th commit here - https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1978889-copy-alerts-various-fixes |
| 11:25 | terranm joined #evergreen | |
| 11:47 | jihpringle joined #evergreen | |
| 11:56 | Stompro joined #evergreen | |
| 11:59 | Stompro | Is anyone already working on testing the stripe messages on terran-master? |
| 12:08 | terranm | I don't think so |
| 12:14 | terranm joined #evergreen | |
| 12:20 | jihpringle joined #evergreen | |
| 12:30 | Stompro | terranm, thanks for the instructions, I just emailed Dawn Dale to get a screenshot of the stripe dashboard. |
| 13:12 | JBoyer | terranm++ |
| 13:14 | collum | Stompro - I was testing while you were writing. I just posted a signed-off branch. |
| 13:15 | Stompro | collum, double tested then! |
| 13:16 | collum | Excellent. Never can have too much testing. |
| 13:17 | Stompro | collum, I was just trying to remember how to do a signoff branch, so you let me know just in time. |
| 13:21 | terranm | Stompro++ collum++ Yay! Adding the patron id has helped us greatly since we implemented it. |
| 13:22 | collum | terranm, I really like that feature. It will help us, as well. |
| 13:36 | terranm | berick: If you do any updates on your test server this week can you please add the angular self-check as well? https://bugs.launchpad.net/evergreen/+bug/1840773 (I was going to test on mine, but I don't want to install the Angular circ branch on mine for this round of testing) |
| 13:36 | pinesol | Launchpad bug 1840773 in Evergreen "Angularize the Self-Check Interface" [Wishlist,Confirmed] |
| 13:39 | berick | terranm: can do. |
| 13:40 | terranm | berick++ |
| 13:52 | terranm joined #evergreen | |
| 13:55 | jihpringle joined #evergreen | |
| 14:16 | terranm | mmorgan: I loaded the current version of https://bugs.launchpad.net/evergreen/+bug/1891369 - wanted to let you know since you did a thorough testing of an earlier version |
| 14:16 | pinesol | Launchpad bug 1891369 in Evergreen "Circulation renewals near the due date should be extended" [Wishlist,Confirmed] |
| 14:17 | mmorgan | terranm++ |
| 14:17 | mmorgan | I'll see if I can take a look. |
| 14:30 | JBoyer | going to rebuild pattypan with pretty much all of berick's Angular-patron-related branches to try to get a little bit of testing for all of them. |
| 14:36 | jihpringle joined #evergreen | |
| 14:36 | JBoyer | And something I wanted to throw out since I noticed it go by in email: Testing at all is great, but don't forget to fire up Firefox also; there are still 2 supported browser engines! |
| 14:37 | JBoyer | And everyone++ |
| 14:38 | terranm | +1 |
| 15:06 | JBoyer | So that Angular patron statement is a little less impressive because one of the branched labeled as requiring it was mislabeled. (and it conflicts with the Angular stuff, so oops.) |
| 15:08 | terranm | That was probably my fault, sorry! |
| 16:19 | terranm joined #evergreen | |
| 16:19 | jvwoolf1 joined #evergreen | |
| 16:30 | JBoyer | FYI, there's a preview Hatch Installer linked from the spreadsheet. Both patches are client-side only so you can test them against any Evergreen server |
| 16:31 | JBoyer | Though both fixes are *also* client-side only so you could pretty much install, check perms in a couple places, uninstall and make sure everything is really gone. |
| 16:42 | jvwoolf1 | terranm: The link to festivus seems to go to pattypan |
| 16:53 | * berick | updates evgdemo.kcls.org |
| 17:07 | csharp_ | @decide evgdemo or venmo? |
| 17:07 | pinesol | csharp_: go with evgdemo |
| 17:20 | berick | terranm: https://evgdemo.kcls.org/eg2/en-US/staff/scko -- this demo server has some odd caching proxy in front of it, sometimes I have to add a ?foo=bar to the end of the URL to get the latest page. |
| 17:21 | terranm | jvwoolf1 - it sure did! Fixed |
| 17:22 | terranm | berick: okay, thanks |
| 17:22 | terranm | berick: I will test in the morning! |
| 17:33 | jvwoolf1 left #evergreen |
| 15:57 | berick | i think it only uses memcache for certain types of values |
| 15:57 | berick | otherwise, just a locally cached value |
| 15:58 | Bmagic | browser cache? apache cache maybe? |
| 15:58 | Bmagic | on a test machine, the variable looks like this: $VAR1 = bless( [569,'icon_format','eaudio','E-audio',undef,'t','E-audio','f',undef], 'Fieldmapper::config::coded_value_map' );node |
| 15:59 | Dyrcona | The memcache key looks like "EGWeb.$locale.$hint." where $locale is the current locale (probably en-US) and $hint is the IDL classs: ccvm. |
| 15:59 | Bmagic | but on the broken system: $VAR1 = '' |
| 16:00 | Dyrcona | The list will have list appended, so : "EGWeb.en-US.ccvm.list" or something like that. |
| 16:30 | Bmagic | sounds good to me. I'll just have to wait till night |
| 16:31 | Dyrcona | If you empty out the list key, it might reload. I think it works like that. berick would know better than I. |
| 16:31 | Bmagic | that key isn't in the cache |
| 16:32 | Bmagic | it exists on my test system, but not on the broken system |
| 16:37 | berick | the only thing that would prevent it from getting added to the cache is if the value for the requested ID is in the process-level cache |
| 16:37 | berick | but if you reload Apache, then that should be moot |
| 16:37 | berick | may restart apache instead *shrug* |
| 13:39 | csharp_ | we had a number of patrons in my DeKalb library days who would pay the 1 penny to get below the no-checkout fines threshold |
| 13:52 | rjackson_isl_hom joined #evergreen | |
| 14:05 | jvwoolf joined #evergreen | |
| 14:14 | gmcharlt | noting my current thinking for the 3.8 and 3.9 maintenance releases |
| 14:14 | gmcharlt | - produce release notes draft on Friday |
| 14:14 | gmcharlt | - accept feedback through Monday |
| 14:14 | gmcharlt | - create tarballs Tuesday and test |
| 14:14 | gmcharlt | - release on Wednesday |
| 14:20 | mantis1 | Has anyone successfully added a recaptcha to a form? One of our libraries is getting targeted by spam bots from different IPs within the past few days. |
| 15:42 | jihpringle joined #evergreen | |
| 16:30 | Bmagic | mantis1: I have not |
| 09:57 | Dyrcona | ~~~~~~~~~~~~~~~~~~~~~~ |
| 09:57 | Dyrcona | src/app/share/fm-editor/fm-editor.component.ts:518:51 - error TS2339: Property 'linkedSearchConditions' does not exist on type 'FmFieldOptions'. |
| 09:57 | Dyrcona | 518 field.idlBaseQuery = fieldOptions.linkedSearchConditions; |
| 10:00 | Dyrcona | Yeahp. Looks like Lp 1851884 should not have been backported or should have been tested/modified for rel_3_7. |
| 10:00 | pinesol | Launchpad bug 1851884 in Evergreen 3.8 "eg-fm-record-editor: take care wiring up comboboxes" [High,Fix committed] https://launchpad.net/bugs/1851884 |
| 10:02 | Dyrcona | JBoyer | gmcharlt_ ^^ |
| 10:03 | Dyrcona | I'm gonna revert it locally and will likely revert it before building the actual 3.7.4 release unless someone comes up with a fix. |
| 14:44 | Dyrcona | So, ng build --prod blows up on rel_3_7, but just ng build doesn't. |
| 14:47 | gmcharlt_ | hmm - I may have a bit of time to look over the weekend |
| 14:48 | gmcharlt_ | but yeah, AIUI, --prod vs. not is actually two different copilers |
| 15:03 | Dyrcona | gmcharlt_: Cool. I'll not revert anything else. It looks like 5380bfb11a3a38bac521ce8ef92216c13d46f3b9 has issues as well. I swear that worked when I looked at it, but maybe I didn't really test it on 3.7. |
| 15:03 | Dyrcona | backports-- |
| 15:10 | mantis1 joined #evergreen | |
| 15:18 | Dyrcona | I am inclined to just revert that commit, too, but I'll wait to see what gmcharlt_ thinks. |
| 11:16 | gmcharlt_ | berick++ |
| 12:14 | berick | Bmagic++ # just saw your earlier comment. |
| 12:15 | berick | working on cleaning up the branch now |
| 12:18 | Dyrcona | Crazy. I'm still seeing the discrepancy in 856 display on this test vm compared to production, and I can't find the difference in the code. |
| 12:28 | Dyrcona | Hmm.... Looks like the difference may be in the database. 856$3 shows up in asset.uri.label in the test db but goes in asset.uri.use_restriction in production. |
| 12:28 | Dyrcona | But! The database code should be identical since the test db was restored from a dump on Sunday. |
| 12:29 | collum joined #evergreen | |
| 12:29 | mmorgan | Dyrcona: Is there a difference in the function biblio.extract_located_uris? |
| 12:34 | Dyrcona | mmorgan: I'll check but there shouldn't be. It's a restored dump, both on Pg 10. |
| 12:47 | Dyrcona | But, how..... |
| 12:48 | Dyrcona | I have only 1 biblio.extract_located_uris, so there's not one with a different signature hanging around. |
| 12:51 | Dyrcona | According to the db function, $Z or $2 should go in use_restriction and $y or $3 should go into label. My production db entries look like $y or $z is in label and $3 is in use_restriction. |
| 12:53 | Dyrcona | My old entries in the test database look like production, but when I update them, they get the "correct" values. I'm going to see if I can find some that were recently added. I suspect we had a hacked version of the db function that didn't make it through an upgrade. |
| 12:55 | Dyrcona | Too bad I don't have any really old dumps hanging around.... |
| 12:55 | Dyrcona | Hmm... I'll check the training server it might be old enough. |
| 12:55 | Dyrcona | mmorgan++ |
| 15:22 | Dyrcona | DB server is slow while it's creating a database with another as a template. |
| 15:29 | dbriem joined #evergreen | |
| 15:43 | collum joined #evergreen | |
| 16:35 | * Dyrcona | tests if setting an internal flag during a transaction, doing an update, then resetting the flag before commit works. I think it does, but the answer is that may depend on deferred triggers or not. |
| 16:36 | Dyrcona | I know that the internal flag update won't be visible outside of the transaction. |
| 16:36 | Dyrcona | Hmm... what's the thing to make all triggers immediate..... |
| 16:40 | Dyrcona | SET CONSTRAINTS ALL IMMEDIATE; # If you ever need it. |
| 16:40 | Dyrcona | That might break things for me but we'll see. |
| 16:41 | * Dyrcona | has a feeling the test transaction won't finish in the next 20 minutes, so we'll have to wait until tomorrow morning. |
| 16:51 | jvwoolf left #evergreen | |
| 17:05 | mmorgan left #evergreen | |
| 19:56 | jihpringle joined #evergreen |
| 10:50 | pinesol | News from commits: LP1958573 PMC messages created by action triggers not patron-visible <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=ba2fc41399e9723361245a95e64d78a6c1eb2e59> |
| 12:15 | mmorgan | berick++ gmcharlt++ # fixing :) |
| 12:32 | Dyrcona | DBD::Pg++ |
| 13:03 | Dyrcona | Hrm.. URIs aren't displaying correctly on my test VM, and I just merged my production branch into my test branch.... |
| 13:04 | Dyrcona | And, there are no differences in the OPAC according to git diff.... |
| 13:13 | Dyrcona | Grr... Thought maybe a git clean -xfd and a rebuild would help, but no.... |
| 13:14 | Dyrcona | In production, the link is on subfield z and subfield 3 appears after it. On my test VM it is the opposite in both ways. |
| 13:21 | Dyrcona | Not even wiping out the installed bootstrap templates and reinstalling them helped.... |
| 13:22 | jvwoolf left #evergreen | |
| 13:29 | Dyrcona | Ah, wait a minute.... I recall something now about a difference between the ttopac and bootstrap opac and I had to patch it. However the patch doesn't seem to be missing from the git branch AFAICT. |
| 13:48 | Dyrcona | But the results are definitely different.... |
| 13:53 | * Dyrcona | is perplexed, but this will have to wait, I guess. |
| 14:46 | shulabear joined #evergreen | |
| 14:46 | Dyrcona | The training server looks like production, but I can't find any relevant differences between the test vm branch and those for training or production. The installed files also match those from the branches. Is there some server cache that I'm overlooking? |
| 14:50 | terranm joined #evergreen | |
| 14:50 | Dyrcona | Found the eg_template_cache in the systemd temp files and deleted it just in case. Makes no difference on training. |
| 14:53 | Dyrcona | Oh... I see one thing. There's a bug in a program that I'm running to update 856s. That might be the culprit... |
| 15:08 | gmcharlt_ | yes, please sign up on the spreadsheet; I'll start bugging people by Thursday |
| 15:08 | shulabear | gmcharlt++ Dyrcona++ |
| 15:09 | JBoyer | I know a few people may be in late or may not make the meeting, I can send something to the dev list unless you're planning to. |
| 15:09 | gmcharlt_ | and I think otherwise, given the spurt of activity the past couple days, that help testing pending Angular holdings and item editor bugs would be Good Thing |
| 15:09 | gmcharlt_ | JBoyer: I'll coordinate it |
| 15:09 | JBoyer | gmcharlt_++ |
| 15:09 | terranm | gmcharlt_++ |
| 15:10 | JBoyer | It sounds like point releases are on their way, any discussion before moving on to LP stats updates? |
| 15:15 | JBoyer | And +1 to spacing also. Were they forced together for some reason or has experience suggested that they need more space than before? |
| 15:15 | terranm | I think it just happened sort of randomly |
| 15:16 | JBoyer | Dyrcona, perhaps worth checking, is the person you're thinking of here? |
| 15:17 | terranm | I think we get more testing participation if they are spaced out rather than in two months back to back |
| 15:17 | Dyrcona | JBoyer: They |
| 15:17 | berick | i should be able to host a bug squashing VM this time around |
| 15:17 | terranm | berick++ |
| 15:27 | berick | sans menu entry changes, I should say |
| 15:27 | gmcharlt_ | the branch is realistically far too large for detailed patch-level scrutiny |
| 15:27 | berick | yeah, it's a beast |
| 15:28 | gmcharlt_ | but if we merge soon (and I do see reasons for doing that), I think we're going to need to organize community testing on a large scale; possibly larger than previoulsy attempted |
| 15:28 | berick | my thinking is if the UI is not yet exposed, a minimal amount of the new code will actually be used. |
| 15:29 | berick | once we do expose the new UI's, which may come after 3.10, then loads of testing would be needed |
| 15:29 | gmcharlt_ | yeah, but that just kicks the can down the road, since of course the point is eventually to switch to it |
| 15:29 | Dyrcona | gmcharlt_++ |
| 15:29 | Dyrcona | +1, too.... I think if it goes in, turn it on. |
| 15:30 | berick | sort of. if we can expose less ambitious interfaces that use the underlying code, then we get the chance to test parts of it without flipping a giant switch |
| 15:30 | gmcharlt_ | so I think what I'm saying is that organizing broad testing needs to happen on the heals of a merge |
| 15:30 | gmcharlt_ | *heels |
| 15:31 | berick | gmcharlt_: so you're thinking flip the big switch on day one too? |
| 15:32 | terranm | I could work up a list of tasks that need to be tested for each of the new interfaces as a starting point. It might be easier to get people to test if it's broken into bite-sized pieces. |
| 15:32 | mmorgan | Just to clarify, right now, the new uis are under an org unit setting? |
| 15:32 | gmcharlt_ | more like stand up test systems that have the switch flipped |
| 15:32 | berick | mmorgan: sort of. it's kind of a mess what we have. |
| 15:32 | berick | that we were going to test with |
| 15:32 | berick | i'm of the opinion that when we do flip the switch, it has to be fully flipped or it's going to get really confusing real fast |
| 15:33 | berick | hopping between the same UI's depending on how you got there |
| 15:33 | gmcharlt_ | (also noting that soon there will be a dump of the Angular acquisitions sprint 4 stuff, though that's more self-contained than the patron/circ stuff) |
| 15:34 | JBoyer | terranm++ I do think having a reminder of what all needs to be tested helps. I wonder if some of the staff interfaces have the 1-2 things users do *most* and then say "yeah, didn't fall over" by end users. A guide would help them test things they maybe do quarterly or less. |
| 15:34 | mmorgan | terranm++ |
| 15:34 | mmorgan | +1 to broad community testing |
| 15:35 | shulabear | terranm++ |
| 15:35 | gmcharlt_ | also, I think the more that the branch can be cleaned up to have new and changed shared component live in self-contained patches, the better |
| 15:36 | gmcharlt_ | as individually, those should be much more amenable to piecemeal testing by devs and committers |
| 15:38 | berick | yeah, i can clean up the shared/core changes. that's a small portion of it. |
| 15:39 | gmcharlt_ | and I think the other thing that would help is ensuring that there's one big ol' switch (or maybe a small set of them) to reliably switch between old and new interfaces |
| 15:39 | berick | it gets a little complicated with the patron UI, since it's basically one big application. it kind has to be added as a whole. |
| 15:42 | jeff | another option is to have no switch, and "don't upgrade" is your only switch. combined with potentially a longer support life for the previous release, that might make sunsetting the old interfaces more of a sure thing. |
| 15:42 | berick | jeff: that would be my pref. |
| 15:43 | berick | running them side by side will get messy no matter what, imo |
| 15:43 | gmcharlt_ | that still presupposes actively organized and broad testing |
| 15:43 | berick | absolutely |
| 15:43 | * Bmagic | scrolls up |
| 15:44 | * phasefx | still remembers having three or so pull lists |
| 15:44 | gmcharlt_ | but I mislike the notion of potenially have 3.10.0 end up being intentionally full of regressions |
| 15:44 | berick | but going back to my original proposal, if we merge the code without any menu/link updates, then we have a body of code we can start building on, which will have the affect of testing said code. Eg. it's a lot easier to test a new Item Status UI then overhauling the whole patron UI. |
| 15:44 | mmorgan | gmcharlt_++ |
| 15:44 | gmcharlt_ | I wonder if we should consider an extended timeframe for 3.10, balanced with a brief 3.11 |
| 15:45 | berick | i wasn't trying to flip the switch for 3.10. a full switch flip should happen basically the day after a major release is made |
| 15:48 | mmorgan | berick: Meaning not going all in and the "switch" being don't upgrade. |
| 15:48 | gmcharlt_ | JBoyer: one huge change and a largish change (acq) |
| 15:48 | Dyrcona | Why not add it after 3.10, go all in, and 3.11 becomes 4.0 if the changes are that big? |
| 15:49 | gmcharlt_ | because anything that isn't turned until 3.11 will largely not get significant testing untikl 3.11 starts (is my fear) |
| 15:50 | Dyrcona | Anyone testing leading up to the 3.11 release would be using the new interfaces. |
| 15:50 | gmcharlt_ | berick: let me ask you this - assuming a longer 3.10 cycle, is your branch essentially feature complete now? (barring the inevitable obscure YAOUS implementations and so forth)? |
| 15:50 | phasefx | this is probably crazy, but how about we hold releases hostage until we get significant testing? super long rc-1 for whatever holds the new stuff |
| 15:51 | gmcharlt_ | or are there significant known bits of the overall AngularJS circ app that aren't yet implemented in Angular? |
| 15:51 | berick | gmcharlt_: we're using in production, w/ some patches I have not yet backported. I think the patron messages stuff might need some tweaking as well |
| 15:51 | berick | since it was concurrently developed |
| 15:54 | gmcharlt_ | and it sounds like - other than catching up with trigger events interfaces and notes/messages changes - there aren't significant ones? |
| 15:54 | berick | no, those are the 2 menu items that are disabled in the UI right now |
| 15:54 | berick | should be the only big things |
| 15:55 | gmcharlt_ | in that case, here's a thought |
| 15:55 | gmcharlt_ | 1. ensure that there's a Big Red Switch for insurance purposes |
| 15:55 | gmcharlt_ | 2. merge sooner rather than later, hopefully with some cleanup of the branch |
| 15:56 | gmcharlt_ | 3. target this for 3.10, then aim for broad testing |
| 15:56 | berick | what if the Big Red Switch is a patch/commit? making all the links/buttons have optional destinations is non-trivial |
| 15:56 | gmcharlt_ | 3a including nudges, test systems, etc. |
| 15:57 | gmcharlt_ | 4. we agree to prepare to extend 3.10 into November, possibly early December |
| 15:58 | gmcharlt_ | 5. and by mid-November, review the state of the bugs against the Angular interfaces and make a go/no-go decision |
| 15:58 | gmcharlt_ | 5a. (which is potentially when the decision to apply the BRS as a commit, if that's what it has to be, gets made) |
| 15:58 | gmcharlt_ | (end of my list) |
| 15:59 | gmcharlt_ | but basically, combine (a) a quick merge so that the code doesn't age or diverge too much with (b) a much more intentional testing stance for a big change like this than may have been the case in the past |
| 16:00 | gmcharlt_ | without kicking the can to 3.11, since the testing needs to happen eventually and it would be good not to block the potentiall for normal enhancements to patrons/circ |
| 16:00 | berick | gmcharlt_: ok, that makes sense. and the BRS will be a commit that just reverses all the link/button/menu changes? |
| 16:01 | berick | or a revert, basically |
| 16:02 | gmcharlt_ | if need be; a global setting / YAOUS would make it easier for ongoing testing if we're not confident enough to release 3.10 with $NewCirc, but if it's not feasible, it's not feasible |
| 16:03 | berick | k. do-able, was just hoping to avoid that, but I understand the desire. |
| 16:03 | berick | a bold plan and I like it |
| 16:03 | berick | gmcharlt_++ |
| 16:06 | JBoyer | #topic Consider merging bug 1979357? (phasefx) |
| 16:06 | pinesol | Launchpad bug 1979357 in Evergreen "fixes for qatester failures" [Undecided,New] https://launchpad.net/bugs/1979357 |
| 16:06 | phasefx | yeah, someone push this |
| 16:06 | JBoyer | #info Need this so we can get the QA tester going again; changes some pre-reqs for stretch and buster, and fixes a live test |
| 16:06 | phasefx | also fixes a bug with cover image uploader for stretch |
| 16:07 | Dyrcona | So, stretch is like EOL and we should drop it from our prerequisites. |
| 16:07 | phasefx | sure |
| 08:13 | mantis1 joined #evergreen | |
| 08:54 | mmorgan joined #evergreen | |
| 08:55 | Dyrcona joined #evergreen | |
| 09:28 | Dyrcona | I ended up undoing the switch to Pg 14 as the main cluster on my test db server. I haven't applied all of the necessary patches to our production database, so the restore spit out some warnings about missing functions. |
| 10:17 | pinesol | News from commits: LP1959716 Follow up to allow managing/deleting in-place copies <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=a12a7ad653631ec09ee690571f9ec265e06c801b> |
| 10:17 | pinesol | News from commits: LP1955065 Item note dialog close value repairs <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=49307d613ad2d59375748bb127ceaec1c4642509> |
| 10:17 | pinesol | News from commits: LP#1955065: fix deletion of item notes in Angular item attributes editor <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=deab630a5837dbe723fe2f2b7fbe38926ca86121> |
| 09:55 | Dyrcona | :) |
| 09:55 | Dyrcona | @blame [band] |
| 09:55 | pinesol | Dyrcona: Destructo Dog is probably integrated with systemd |
| 09:56 | Dyrcona | Anyway, I'm thinking of switching over to using Pg 14 instead of 10 as the main PostgreSQL instance over the weekend, so that means I may have to cut this test run short. |
| 09:57 | Dyrcona | I did start another query on the same cluster: 239373 | 00:26:26.838289 | active | 192.168.100.103 | psql | delete from action.hold_request where frozen and thaw_date is null and request_time::date < now()::date - '1 years'::interval; |
| 09:59 | Dyrcona | I should probably have that query output the database name, but I typically use it only the production Evergreen dbs where evergreen is the only active database. |
| 10:12 | Dyrcona | Well, the delete works. |
| 11:03 | Dyrcona | Wow: /dev/sdc1 6.4T 5.4T 1.1T 84% /var/lib/postgresql |
| 11:04 | Dyrcona | I think it has started cleaning up. |
| 11:19 | Dyrcona | Well, I was going to wait until 9:00 PM tonight to reboot the server, but might as well do it now. |
| 11:31 | * Dyrcona | hangs his head in shame. My testing has been inadequate of late. |
| 11:40 | pinesol | News from commits: LP1976557: (follow-up) fix lint <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=e0bdcf1d033a63c3c77657759b8c32d01ab88140> |
| 12:03 | jihpringle joined #evergreen | |
| 12:40 | collum joined #evergreen |
| 16:18 | stephengwills left #evergreen | |
| 16:39 | Guest75 joined #evergreen | |
| 16:41 | Guest75 | Hello everyone, I had someone ask a question and I do not know the answer... In Evergreen, is there a way to add multiple email addresses for hold notification? |
| 16:47 | jeffdavis | Guest75: I *think* it's possible although I haven't tested. There is some discussion in this bug report: https://bugs.launchpad.net/evergreen/+bug/1755625 |
| 16:47 | pinesol | Launchpad bug 1755625 in Evergreen 3.1 "Web Client: Edit Patron Email Address Box Does Not Allow Multiple Addresses" [Medium,Fix released] |
| 16:50 | jeffdavis | basically you should be able to put multiple comma-separated addresses in the email field in the patron editor, but you may need to modify the "Regex for email field on patron registration" setting to allow it |
| 16:55 | Guest75 | thanks for the info, I tried a comma without space and got an error. I will try comma with space and ; |
| 18:19 | csharp_ | @who wants to delete all other languages? |
| 18:19 | pinesol | Christineb wants to delete all other languages. |
| 18:20 | jihpringle | I mean, that's true :) |
| 18:20 | csharp_ | haha |
| 18:20 | csharp_ | jeffdavis: I *think* that's all you need to do - maybe try on a test server? |
| 18:24 | jeffdavis | yeah I can give it a try, I'm just nervous because locales touch some pretty core stuff in EG |
| 18:25 | mantis1 joined #evergreen | |
| 18:26 | jeffdavis | yet another reason we should all just use Esperanto |
| 08:34 | Dyrcona joined #evergreen | |
| 08:39 | mmorgan joined #evergreen | |
| 09:09 | Stompro joined #evergreen | |
| 09:28 | Stompro | Baker and Taylor support notified me this morning that PASV mode should work again on the normal ftp site. But I haven't tested it yet. |
| 09:33 | mmorgan | Offline circ issue: A library can't record checkouts, likely because the "Working Location" field isn't filled in. But the dropdown for that field is not populated. Any suggestions? |
| 09:34 | Stompro | Seems to be working when I test. Public IP returned when passive commands are sent using netkit-ftp, which doesn't have special handling I believe. |
| 09:45 | * mmorgan | goes offline to test offline circ for real |
| 09:49 | Dyrcona | mmorgan: You have to be completely offline. If it can see the server at all, offline doesn't work. |
| 09:50 | Dyrcona | :) |
| 09:50 | Dyrcona | I figured she knew, but..."Won't someone please think of the logs!?" |
| 11:02 | Dyrcona | There are also 3 autovacuum worker processes running in the database. I've been meaning to look into our autovacuum settings. |
| 11:16 | Dyrcona | INFO: scanned index "symspell_dictionary_updates_tid_idx" to remove 126549937 row versions |
| 11:22 | Dyrcona | miker: https://pastebin.com/E4iNzSzw |
| 11:23 | miker | yeah, the delayed reification isn't actually being tested... wheeee |
| 11:23 | miker | you're just testing the deadlock code (again) |
| 11:23 | Dyrcona | Did I miss a flag to turn that on? |
| 11:24 | miker | the pingest param is supposed to casue a function to be called that turns that delay feature on, and then at the end it calls a separate "clean it all up" function |
| 11:24 | miker | you know pingest better than me, so I'd appreciate eyes on that logic change |
| 11:26 | Dyrcona | OK. So, I missed using that option. |
| 11:27 | Dyrcona | Can I ask why that is optional? Shouldn't it just work that way, all the time? |
| 11:28 | Dyrcona | I simply forgot about the option when I started the test run. This is what happens when you a) get older, b) work on many things, and c) have to put one thing down for a week or more before coming back to it. |
| 11:33 | miker | because for non-batch ingest it just creates headaches. human bib editing doesn't interact often enough to matter, but because it does cause serialization (INSERT ... ON CONFLICT does that to prevent deadlocks) with intentionally parallel updates the delay makes it overall faster. same thing as with the browse part of ingest |
| 11:34 | miker | now, I could certainly see making it the default for pingest! but I didn't want to change the default behavior on my own |
| 11:34 | miker | default behavior of pingest, I mean |
| 10:38 | Dyrcona | My SIP2 check programs are all written to work with ldirectord or haproxy, and that may be why I have not shared them. |
| 10:39 | Dyrcona | I have 5 because of experiments with different "features." |
| 10:40 | Dyrcona | Also, many hardcoded values, such as path to a configuration file. |
| 10:45 | Dyrcona | So, I discovered that my previous test of the symspell fixes were invalid. I forgot to enable the triggers on the tables, so I'm running them again. |
| 10:45 | Bmagic | Dyrcona++ |
| 10:47 | Dyrcona | I've already signed off on the branch..... *sigh* |
| 10:57 | Dyrcona | It is taking longer than before. I do hope it is acceptable. The first batch have been running for 4 hours and 15 minutes. Prior to symspell, they typically have finished by now. |
| 14:09 | pinesol | Launchpad bug 1945385 in Evergreen 3.8 "Circulation Limit Set interface missing sorting, filters, and back button" [Medium,Confirmed] https://launchpad.net/bugs/1945385 |
| 14:10 | Dyrcona | hey, pinesol, where are the commit messages? |
| 14:11 | jihpringle | Dyrcona: great I'll add a signoff |
| 14:12 | Dyrcona | I'm going to test the code today and possibly tomorrow depending on how long it takes. I want to test on 3.7 and master at least, probably on 3.9 also. |
| 14:14 | pinesol | News from commits: LP#1932203: serialize requests on Edit Due Date in Items Out tab <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=92b75f94aa82176338084deb200be6fc9cb43820> |
| 14:15 | Dyrcona | I also plan to push the fix for bug 1931737 by the end of the week. If someone else wants to have a look at it, I'll gladly push a signoff branch and let anyone else have a look. |
| 14:15 | pinesol | Launchpad bug 1931737 in Evergreen 3.8 "Did you mean breaks parallel reingest and causes deadlocks when loading/overlaying bib records in the client" [High,Confirmed] https://launchpad.net/bugs/1931737 |
| 08:55 | jvwoolf joined #evergreen | |
| 10:36 | Stompro joined #evergreen | |
| 10:58 | RFrasur joined #evergreen | |
| 11:00 | Bmagic | I'm testing an upgrade to PG 10. Performing pg_dump, then pg_restore on pg10. I'm pre-creating the database on PG10 following the Evergreen create database extension file "create_database_extensions.sql" - That setup does not call for tsearch2, which was removed back in EG2.4. When I restore my dumped database, I get errors about missing tsearch2 |
| 11:00 | Bmagic | ERROR: could not open extension control file "/usr/share/postgresql/10/extension/tsearch2.control": No such file or directory |
| 11:01 | Bmagic | Command was: CREATE EXTENSION IF NOT EXISTS tsearch2 WITH SCHEMA public; |
| 11:02 | Bmagic | I found this patch bug 1175287 which was part of db upgrade 0743. which was* ran on this db according to config.upgrade_log. But maybe I'm barking up the wrong tree |
| 16:12 | Dyrcona | Trying to find patrons with over 80 circulations and this happened: SSL SYSCALL error: Connection timed out |
| 16:15 | jvwoolf left #evergreen | |
| 16:18 | Bmagic | That's "fun" |
| 16:24 | Dyrcona | Well, I reconnected and ran a query with a lower having and it returned pretty quickly, so I bumped it back up to 80 and got some accounts to test with. |
| 17:17 | mmorgan left #evergreen | |
| 17:24 | jihpringle joined #evergreen | |
| 17:30 | Christineb joined #evergreen |
| 16:27 | * Dyrcona | calls it a day. got a long drive home. |
| 16:29 | JBoyer | jeff++ |
| 16:30 | JBoyer | I was just about to post that, but too slow. :) |
| 17:30 | Bmagic | B&T created an alternate server that is working in PASV mode, still in test mode ATM. But, FYI RFrasur Dyrcona (niether are here, but hey, there's IRC logs) |
| 17:30 | Bmagic | /niether/neither |
| 17:43 | jmurray-isl | Bmagic++ |
| 19:57 | Dyrcona joined #evergreen |
| 12:29 | jihpringle joined #evergreen | |
| 12:34 | collum joined #evergreen | |
| 12:51 | collum joined #evergreen | |
| 12:59 | stompro__ | I wonder if it would make sense to add a test script in front of the edi_pusher/edi_fetcher that does a pre check for connectivity to ftp.baker-taylor.com, to avoid runs that won't succeed? |
| 13:00 | stompro__ | And avoid having to reset POs for edi_pusher orders. |
| 13:06 | Dyrcona | The whole process could be made a bit smarter.. |
| 13:06 | Dyrcona | I have thoughts, some more solid than others. |
| 13:15 | stompro__ | Passive is working for Filezilla because it has a setting that automatically substitutes the servers public IP if a private IP is returned in response to a PASV command, so they must have their port forwards setup at least. Maybe NET::FTP could be adjusted to have that behavior? |
| 11:14 | Bmagic | B&T had a "meeting" yesterday. Still no worky today |
| 11:29 | Dyrcona | B&T seems to be working with PASV today, but it is taking two minutes per connection. I have logs that look we're getting things via the fetcher. I've not checked the pusher, yet. |
| 11:30 | Dyrcona | We're looking at configuring our firewall for active FTP. |
| 11:31 | Dyrcona | miker: Cool! I was thinking more eyes would be good, but I'm not sure who else would get to testing it nor when they could make time. |
| 11:31 | Dyrcona | miker: I'm testing with production data upgraded to rel_3_9 latest today. |
| 11:56 | stompro__ | berick, we added an ftp proxy helper to our firewall and switched to Active mode for B&T ftp last week and that has been working. We noticed that on the 14th, they broke their own invoice uploading to the ftp server so invoices that should have been received that day are missing. |
| 12:03 | stompro__ | berick, I just tested passive mode and it does seem to be working now, at least more than it was. The initial file list works now. |
| 12:04 | berick | thanks stompro__ |
| 12:05 | stompro__ | I'm not seeing the 2 minute delay that Dyrcona mentioned... but maybe that is for actual uploads? |
| 12:06 | stompro__ | I tried downloading a response and it seemed to work fine... but I'm just testing with filezilla on my workstation. |
| 12:12 | Dyrcona | The 2-minute delay seems to happen when we get 0 files. |
| 12:12 | jihpringle joined #evergreen | |
| 12:20 | miker | Dyrcona++ |
| 09:39 | Bmagic | @coffee [someone] |
| 09:39 | * pinesol | brews and pours a cup of Natural Decaf Espresso, and sends it sliding down the bar to jweston |
| 11:39 | jihpringle joined #evergreen | |
| 14:37 | pinesol | News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 16:39 | jihpringle joined #evergreen |
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