Evergreen ILS Website

Search in #evergreen

Channels | #evergreen index




Results

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

Results for 2022-07-12

10:50 pinesol News from commits: LP1958573 PMC messages created by action triggers not patron-visible <https://git.evergreen-ils.org/?p=E​vergreen.git;a=commitdiff;h=ba2fc4​1399e9723361245a95e64d78a6c1eb2e59>
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.
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: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_++

Results for 2022-07-11

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=E​vergreen.git;a=commitdiff;h=a12a7a​d653631ec09ee690571f9ec265e06c801b>
10:17 pinesol News from commits: LP1955065 Item note dialog close value repairs <https://git.evergreen-ils.org/?p=E​vergreen.git;a=commitdiff;h=49307d​613ad2d59375748bb127ceaec1c4642509>
10:17 pinesol News from commits: LP#1955065: fix deletion of item notes in Angular item attributes editor <https://git.evergreen-ils.org/?p=E​vergreen.git;a=commitdiff;h=deab63​0a5837dbe723fe2f2b7fbe38926ca86121>

Results for 2022-07-08

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=E​vergreen.git;a=commitdiff;h=e0bdcf​1d033a63c3c77657759b8c32d01ab88140>
12:03 jihpringle joined #evergreen
12:40 collum joined #evergreen

Results for 2022-07-05

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

Results for 2022-06-30

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

Results for 2022-06-29

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.

Results for 2022-06-28

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=E​vergreen.git;a=commitdiff;h=92b75f​94aa82176338084deb200be6fc9cb43820>
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

Results for 2022-06-27

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/e​xtension/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

Results for 2022-06-23

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

Results for 2022-06-22

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?

Results for 2022-06-21

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++

Results for 2022-06-20

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

Results for 2022-06-17

06:02 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
07:05 kmlussier joined #evergreen
07:05 kmlussier bshum++
07:05 kmlussier parts++
09:13 mmorgan Good morning!
09:13 Stompro joined #evergreen
09:22 rjackson_isl_hom joined #evergreen
09:40 eby miker: / berick : going to test more next week but curious with your mention of setting workstation prefs as org unit settings. Does it act as a fall back default or as a forced preference?
09:49 phasefx berick: do you want to talk SIP2M sometime today?  I don't have an agenda, but we could determine/sanity-check next steps
09:51 berick eby: it acts as fall back default.  ignored in cases where a workstation setting value is already saved.
09:52 berick best way to create is to save the value you want at a workstation, then copy the JSON from the value into the newly created org unit setting.
09:59 pinesol Dyrcona: go with local git
10:07 * Dyrcona wonders if we should add some instrumentation to pingest.pl (and possibly drop the .pl extension).
10:16 Dyrcona Hmm. I guess rebasing from master to rel_3_7 is not a good idea.
10:18 miker Dyrcona: do I feel my ears burning? ;) (if you're looking at what I think you're looking at, if you can test closer to master I think you'll have more success)
10:18 Dyrcona Remote syntax in git can be annoying: orign/rel_3_7 for one command and origin[space]rel_3_7 for another.
10:19 Dyrcona miker: I am. I plan to start testing with rel_3_7 today and an upgrade to rel_3_9 next week if that's OK.
10:20 mdriscoll joined #evergreen
10:20 Dyrcona I suppose the different syntax is what they call commitish (in the / case) and remote[space]branch in the latter.
10:22 Dyrcona I should copy the database that I want to use so it won't get obliterated this weekend.
10:23 * Dyrcona is tempted to test on Pg 14 since there was an update this morning... ;)
10:43 miker Dyrcona: as far as order and timing goes, I'm just glad someone's looking at it, but just to note that deadlock+symspell branch was developed after 3.7 (recall, nocase browse) so starting with vanilla 3.8 or 3.9 (/not/ patched with this and then upgraded) may be less of a headache. I get that "with your data" testing isn't particularly feasible at scale for versions past what you're actually on, though.
10:46 Dyrcona miker: Right. I previously made a 3.7 backport and only had had to change the db upgrade script. Looks the same still, but I'll see what happens. If it just blows up, I'll move to upgrading to 3.9 over the weekend.
10:47 Dyrcona I'm going to compare the implementation of metabib.reingest_metabib_field_entries in the two db upgrades. I think we can delete the one from the WWW upgrade.
10:51 Dyrcona Yeah, only difference is the check for reification.
13:16 JBoyer I'm also basically out of pocket / on the bench / choose your own favorite game / sport related euphemism for unavailable for any real hacking at the fest. Additionally, if anyone wanted to take the reins / read the agenda for the dev meeting this afternoon I would be happy to just listen in and pop in should I have something worth saying.
13:19 miker Dyrcona: huzzah! with that option it /should/ be as fast as before (insert-only into the unlogged table) and then at the end there'll be a pause while it shoves the changes in, in one go
13:22 Dyrcona miker: We'll see.
13:22 Dyrcona I also just tested a 3.7.3 to 3.9 db upgrade that I prepared for next week, and I got this error: psql:3.7.3-3.9-upgrade-db.sql:3509: ERROR:  cannot drop type search.search_result because other objects depend on it
13:22 Dyrcona DETAIL:  function search.query_parser_fts(integer,intege​r,text,integer[],integer[],integer,int​eger,integer,boolean,boolean,integer) depends on type search.search_result
13:22 Dyrcona I wonder if we have something old or custom  hanging around?
13:23 Dyrcona The suggestion in the error report was to use drop cascade.
13:24 Dyrcona Looks like we won't be needing it.
13:27 jeffdavis We have two versions of search.query_parser_fts in our environment and I've had to manually drop the second one for the upgrade scripts to work in testing.
13:27 jeffdavis So yeah, probably an old version of that function sticking around on ancient EG installs.
13:30 Dyrcona jeffdavis: Thanks. That's what this looks like.
13:30 Dyrcona I'm using cascade on the type drop, and that appears to work.
13:32 Dyrcona It's fun running upgrades over multiple version. :)

Results for 2022-06-16

12:42 * Dyrcona just having fun.
12:48 miker berick: I came in a few minutes late to your ES talk yesterday, are your slides up somewhere already? (I'll try to answer my own questions before peppering you!)
12:49 berick miker: https://github.com/berick/Present​ations/tree/master/Evergreen-2022
12:49 miker thanks!
13:03 miker berick: thanks again. maybe during hackfest we can discuss gaps? I'm curious about how much of the various visibility testing is implemented (staff vs patron, Located URIs with/without acts-as-copy, hierarchical org + depth, empty vs "patron empty" records) and MR search results ... to start ;)
13:05 berick miker: yeah, happy to talk.  from this list, only Located URI's are not yet taken into consideration.
13:05 berick the rest should be there
14:44 abowling joined #evergreen

Results for 2022-06-15

17:22 Bmagic berick++ # ES!
17:24 Dyrcona I should do more research, but I would be interested in a comparison of ES vs. Solr.
17:24 Dyrcona berick++
17:24 Dyrcona Also, just ran ALL THE TESTS on Ubuntu 22.04, twice. Got all passes the second time.
17:25 Dyrcona Had some perl live test failures the first time, but I think that was because Apache wasn't set up quite right.
17:26 Dyrcona I'll clean up the branch and add it to the bug tonight or tomorrow. Think I'll start looking at SCRAM, TLS, or SASL during the hackfest on Friday.
17:29 eby I think solr has caught up but when we were first comparing solr was much more fickle with index and doc changes. There was a lot of reingesting/indexing required while you could do it on the fly with es
17:29 eby or at least with minimal downtime/overhead

Results for 2022-06-11

06:01 pinesol News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live//arch​ive/2022-06/2022-06-11_04:00:04/test.49.html>
23:09 mmorgan joined #evergreen

Results for 2022-06-10

02:33 akilsdonk joined #evergreen
06:00 pinesol News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live//arch​ive/2022-06/2022-06-10_04:00:02/test.49.html>
07:26 rfrasur joined #evergreen
07:32 rjackson_isl_hom joined #evergreen
07:38 collum joined #evergreen
09:02 csharp_ screw it, I'll rewrite it in perl
09:04 csharp_ do we use warnings and use strict, Barry?  Yes, other Barry, we do.
09:07 JBoyer -Wall -Werror
09:08 JBoyer jeffdavis++ for looking into the http tests.
09:09 JBoyer Not sure the nginx issue is an issue for most testing though, I don't know what benefit there would be to standing that proxy up just for the tests.
09:19 mantis1 joined #evergreen
09:29 * Dyrcona missed something. To the logs!
09:31 Dyrcona JBoyer: Is it a nginx issue or is it the directories missing again?
09:32 Dyrcona csharp_: You can also install Modern::Perl and 'use Modern::Perl;" to get use strict; use warnings; and some other useful things.
09:32 Dyrcona The deb is libmodern-perl-perl
09:33 mantis2 joined #evergreen
09:33 Dyrcona JBoyer: IIRC, none of the other live tests require even Apache to be running, just OSRF services.
09:34 * Dyrcona likes it when a program that I haven't used/touched in 3 years or so still works.
09:36 JBoyer Dyrcona, I was referring to what jeffdavis said yesterday about one of the tests giving a false positive if nginx is running on the test machine. You might have to hit the logs if you're not running a bouncer.
09:36 JBoyer And there are a couple http tests, but not many, no.
09:52 Dyrcona JBoyer: OK. I was out yesterday. Also, I notice that image uploader test failed this morning.
10:15 csharp_ Dyrcona: thanks - I'll check it out
10:16 * csharp_ tries to rid his brain of Bowie's Modern Love
10:17 berick hey csharp_, roam if you want to
14:22 rfrasur joined #evergreen
17:08 mmorgan left #evergreen
17:31 jvwoolf left #evergreen
18:00 pinesol News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live//arch​ive/2022-06/2022-06-10_16:00:03/test.49.html>
18:56 pinesol News from commits: LP1950345-Format the Current Hold Groups table in bootstrap opac <https://git.evergreen-ils.org/?p=E​vergreen.git;a=commitdiff;h=1b4664​67109a9013dd3799d69be6e80c968ce433>
19:56 pinesol News from commits: Hold Management page update <https://git.evergreen-ils.org/?p=E​vergreen.git;a=commitdiff;h=2678ee​1dfcc448968ba8e8ae7fd0da1bc69eeecf>

Results for 2022-06-09

06:01 pinesol News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live//arch​ive/2022-06/2022-06-09_04:00:02/test.49.html>
07:28 collum joined #evergreen
07:33 rjackson_isl_hom joined #evergreen
07:48 rjackson_isl_hom joined #evergreen
09:25 mantis1 joined #evergreen
09:30 jvwoolf left #evergreen
09:31 jvwoolf joined #evergreen
09:58 mantis1 I upgraded one of our test servers from 3.6.5 to 3.9.  Has anyone had weird spacing problems in the Boopac after an upgrade?  I have no idea why it's spacing out so much like it is.  There is a width=device-width element added in base.tt2, but it doesn't seem to make a difference if it's deleted or not.
10:37 mantis2 joined #evergreen
10:38 csharp_ mantis1: is it stock EG or did you apply customizations on top of the upgrade?
10:39 csharp_ (or conversely, applied stock EG stuff on top of your customized stuff?)
17:02 csharp_ I'm on at&t, which while not awesome either, at least it's not comcast :-)
17:21 mmorgan not_comcast++
17:28 mmorgan left #evergreen
18:01 pinesol News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live//arch​ive/2022-06/2022-06-09_16:00:02/test.49.html>
20:14 jeffdavis the 34-lp1787968-cover-uploader.t live test is failing with a 404 on http://127.0.0.1/jacket-upload
20:16 jeffdavis 29-lp1817645-remoteauth-patron-api.t also does HTTP requests, but that test is actually being skipped right now because the test environment's version of LWP::Protocol::https is not >=6.0.7
20:19 jeffdavis and 24-offline-all-assets.t (which does a wget on https://localhost/eg/staff/offline-interface) technically isn't failing but I'm not sure the test is robust - in an environment with an nginx proxy, the test will pass if apache isn't running because the response is a 502 error and the test only checks for 404
20:20 jeffdavis I'm also not really sure that the wget output is being parsed properly
20:22 jeffdavis in other words, none of the 3 live tests that do direct HTTP requests against the test server are really "working"
20:23 jeffdavis something to fix at the hackfest maybe?

Results for 2022-06-08

02:50 berick joined #evergreen
06:00 pinesol News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live//arch​ive/2022-06/2022-06-08_04:00:02/test.49.html>
07:25 rjackson_isl_hom joined #evergreen
07:49 collum joined #evergreen
08:05 RFrasur joined #evergreen
15:19 Dyrcona People do get uptight about the queue order, but it's just a guess at best.
15:19 mmorgan We're not using a soft regarget interval. Maybe that would help.
15:21 Dyrcona We've experimented with every half hour, every 15 minutes, etc. Then, it started running into itself and it ended up being 1/hour effectively. We skip the hours between midnight and 6:00 am to avoid the overnight jobs that run during those hours.
15:22 Dyrcona The soft retarget interval might help. John Amundson could probably tell you better why we use it because it was his testing that made us decide on that value. I forget exactly why we ended up with that value.
15:23 * mmorgan would thing you could end up with a LOT more holds being retargeted using a soft interval.
15:25 Dyrcona Our "normal" retarget interval is 48 hours to keep things on pull lists a little bit longer.
15:25 Dyrcona We'd typically see the running into itself happen for a day or so after an upgrade, then it just kept up (probably because of the soft interval), so we changed the schedule.
17:09 mmorgan left #evergreen
17:14 jeffdavis hm, that doesn't work for me unfortunately
17:17 jeffdavis we're using skins, I wonder if that is causing trouble
18:00 pinesol News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live//arch​ive/2022-06/2022-06-08_16:00:03/test.49.html>
22:45 jeff jeffdavis: do you see the text-white class in the output html and it isn't working, or does that class not make it to the html seen by the browser?

Results for 2022-06-07

14:49 csharp__ joined #evergreen
16:12 jvwoolf left #evergreen
17:02 mmorgan left #evergreen
18:01 pinesol News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live//arch​ive/2022-06/2022-06-07_16:00:03/test.49.html>

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