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 149 150
| 08:54 | dguarrac joined #evergreen | |
| 09:05 | mmorgan1 joined #evergreen | |
| 09:20 | Dyrcona joined #evergreen | |
| 10:18 | csharp_ | day one of any hackfest/hackaway/bugsquash/feedback fest is just trying to get the test server running :-/ |
| 10:19 | csharp_ | I Redis-ified my test server and I'm trying to reacquaint myself with how to administer it |
| 10:20 | berick | i'm around if I can be of service re: redis |
| 10:21 | Dyrcona | If berick happens to not be available, I might be able to answer set up questions. |
| 10:21 | kenstir joined #evergreen | |
| 12:16 | pinesol | News from commits: LP1803788 Gear icon for AngularJS grid settings menu <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=41d797d74ccffae209f71736f7a29af448058e4d> |
| 12:16 | pinesol | News from commits: LP#2039725: handle patrons without cards in Patrons with Negative Balances UI <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=ec21d4af39ea178de0a65987fb3daca66ed1a52a> |
| 12:16 | pinesol | News from commits: LP#2039725: users with negative balances should exclude deleted users <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=0d71f9b9a031da25b9d31d52dfe68ffaf38e5d85> |
| 12:40 | mantis | getting 500 errors in the MOBIUS test server when looking up anything in the patron account while logged into the OPAC |
| 12:41 | csharp_ | @blame [someone] for mantis's 500 errors |
| 12:41 | pinesol | genpaku stole csharp_'s ice cream! for mantis's 500 errors |
| 12:41 | mantis | lol |
| 10:59 | csharp_ | (assuming you haven't already gotten there 30 mins later ;-) ) |
| 11:12 | redavis_reboot joined #evergreen | |
| 11:48 | jihpringle joined #evergreen | |
| 11:53 | Dyrcona | This is frustrating. What I see in production is usually a failure to create the AutorenewNotify event because of a failure to get the hooks. What I got in testing last night is a failure to renew two items. |
| 11:54 | Dyrcona | csharp_: Thanks! I'm not sure what I posted is related to what I'm actually trying to solve. I just saw that and it looked weird. |
| 12:13 | Dyrcona | So, looks like there was no database transaction or a failure to create one in my test last night. |
| 12:15 | Dyrcona | 245378849:Mar 14 05:31:28 egtest open-ils.circ: [ERR :22856:CStoreEditor.pm:155:] editor[1|1741616] request error open-ils.cstore.direct.action.circulation.create : <new object> : Exception: OpenSRF::DomainObject::oilsMethodException 2024-03-14T09:31:28 OpenILS::Utils::CStoreEditor /usr/local/share/perl/5.30.0/OpenILS/Utils/CStoreEditor.pm:481 <400> No active transaction -- required for CREATE |
| 12:32 | Dyrcona | This is interesting. It looks like the CStoreEditor opened a transaction at 5:31:14 to work on a different circulation. At 5:31:28 the same(?) editor was asked to create a new circulation, but there was no transaction. At 5:31:30 the previously opened transaction was committed. |
| 12:36 | Dyrcona | The CStoreEditor messages are all coming from the same circ drone, so I assume it's the same CStoreEditor instance. |
| 15:30 | pinesol | rickyrnt: The operation succeeded. |
| 15:34 | Dyrcona | rickyrnt: If you need any help right now, feel free to ask. |
| 15:34 | rickyrnt | thanks! just rebooting the server currently |
| 15:48 | Dyrcona | Just two hours on a test system running "standard" cron jobs with OpenSRF loglevel set to 4, and the syslog files is 12GB. |
| 15:49 | Dyrcona | I hope the 500GB that I gave the image today is enough. :) |
| 15:51 | rickyrnt joined #evergreen | |
| 15:51 | jeffdavis | When I need to do that kind of debugging I pretty much always manually modify how the relevant Perl modules log things, rather than messing with log levels. |
| 12:39 | kworstell_isl joined #evergreen | |
| 12:52 | Dyrcona | And, now, there's a BIOS update. Might as well install that, too. |
| 13:00 | Dyrcona joined #evergreen | |
| 13:17 | Dyrcona | I'm looking at Lp 2040514. Does anyone have any tips for testing SFTP for EDI? I'm planning to set up one of my VMx to be the SFTP server. I'm wondering where I can look for actual messages to send back and forth. I'm pretty sure the actual EDI gets stored in the database somewhere. |
| 13:17 | pinesol | Launchpad bug 2040514 in Evergreen "EDI SFTP doesn't work" [High,In progress] https://launchpad.net/bugs/2040514 - Assigned to Jason Stephenson (jstephenson) |
| 13:18 | kworstell_isl_ joined #evergreen | |
| 13:29 | jvwoolf joined #evergreen | |
| 15:01 | Bmagic | #info mmorgan will explore moving LP stats to community site and automating same |
| 15:01 | mmorgan | Please carry forward. Wanted to also note that some of today's stats came from the Launchpad API. |
| 15:02 | Bmagic | #action mmorgan will explore moving LP stats to community site and automating same |
| 15:02 | Bmagic | #info sandbergja will see if gh actions can run the pgtap tests |
| 15:02 | sandbergja | I have a pullrequest for that, bug 2055796 |
| 15:02 | pinesol | Launchpad bug 2055796 in Evergreen "Have github actions run pgtap tests for us" [Undecided,New] https://launchpad.net/bugs/2055796 |
| 15:02 | Bmagic | sandbergja++ |
| 15:02 | smayo | sandbergja++ |
| 15:02 | dluch | sandbergja++ |
| 15:05 | collum joined #evergreen | |
| 15:05 | Bmagic | #action gmcharlt - create a Git commit message type and update bug 2051946 |
| 15:05 | pinesol | Launchpad bug 2051946 in Evergreen "institute a Git commit message template" [Wishlist,New] https://launchpad.net/bugs/2051946 - Assigned to Galen Charlton (gmc) |
| 15:05 | Dyrcona | Looks like it is in progress. I tested the other branch that makes release notes entries. |
| 15:05 | eeevil | gmcharlt_ is traveling today, aiui. |
| 15:05 | Bmagic | ah, cool |
| 15:05 | Bmagic | #info Stompro will formalize the tense usage in the release-note message |
| 15:13 | sandbergja | Dyrcona++ |
| 15:13 | eeevil | re the first part, I think that's smart (and then the release can get the squashed bugs) |
| 15:13 | Bmagic | +1 (and I can help with the building(s)) |
| 15:13 | abneiman | +1 to 27th, I can test & eval the release-notes script as part of point releases |
| 15:13 | mmorgan | +1 to March 27, I can help also. |
| 15:14 | sandbergja | Bmagic++ |
| 15:14 | sandbergja | abneiman++ |
| 15:23 | Bmagic | #topic New Business - Barriers to getting things committed |
| 15:23 | jeffdavis | I can start this off |
| 15:23 | Bmagic | please do |
| 15:23 | jeffdavis | I want to commit more pullrequests, but when I try, I often run into the same barriers: |
| 15:23 | jeffdavis | (1) no test environment available, (2) no test plan, (3) test plan is difficult to set up, (4) merge conflicts, esp with code that has sat uncommitted for months, (5) extra overhead required to backport and/or unsure whether to backport, (6) unresolved questions about the fix. |
| 15:23 | jeffdavis | I wonder if there are things we can be doing to mitigate some of those barriers? |
| 15:23 | jeffdavis | For example, would more community dev VMs be helpful? |
| 15:24 | Dyrcona | For 5 we can backport fewer fixes, particularly those that touch the database. |
| 15:24 | Bmagic | I think the answer is: yes |
| 15:24 | Bmagic | do we need a system for people to "checkout" a VM so it's their's for a time? |
| 15:25 | sandbergja | It seems that if we address some of the others, 4 might take care of itself (i.e. if we have a quicker commit cadence, branches won't sit for as long) |
| 15:25 | abneiman | 4 is a problem, but especially a chicken-and-egg thing since the longer things sit without review the more conflicts they accumulate. For 2, I can commit to sharing test plans for Equinox-developed features. |
| 15:25 | Bmagic | we could use Evergreen to manage the checkouts |
| 15:25 | abneiman | sandbergja: great minds, lol |
| 15:25 | Dyrcona | i also think it is perfectly fair to comment on the bug that there is no test plan provided, and it's not obvious how to test the bug. |
| 15:26 | Dyrcona | For 4, it's also perfectly fine to ask the original developer to rebase it, or at least comment that it needs a rebase if you're not comfortable doing it yourself. |
| 15:26 | sleary | If you are the person rebasing it, and the merge conflicts have to do with CSS or ARIA, please ping me here and I'll be happy to help. |
| 15:27 | abneiman | +1, asking for dev rebases is totally fair game |
| 15:27 | abneiman | sleary++ |
| 15:27 | jeffdavis | I've also shared pullrequests and had to rebase them multiple times, which gets frustrating, so asking the dev to rebase is fair but only goes so far IMO. |
| 15:28 | abneiman | so it sounds like we really have 4 communications problems, 1 technical problem (test environments), and 1 practice problem (when do we backport?) |
| 15:28 | Dyrcona | jeffdavis: I do try to handle the rebases myself, but sometimes, its not obvious how to resolve it. |
| 15:29 | mmorgan | abneiman++ |
| 15:29 | jeffdavis | abneiman: great point |
| 15:29 | kmlussier | Often, when somebody asks for a rebase, it's during a rare moment when the tester has time to look at the code. If the person doesn't rebase it quickly, that person may no longer be available to test. Not so much a communications problem, but a tuits problem. |
| 15:30 | Dyrcona | I think that's more of a time problem. Most of us have "other jobs" or at least our job has more requirements than working on Evergreen code. |
| 15:30 | dluch | abneiman++ |
| 15:31 | abneiman | perhaps if a tester and a dev had a quick conversation, though, everyone's time could be used more valuably - "hey I'm planning to test this in $timeframe, do you mind looking at a rebase?" "I can do rebase within $possibleothertimeframe and let you know when it's done" etc etc |
| 15:32 | mmorgan | I think the code review sessions have been great for getting folks together to tackle individual bugs, whatever their issues. |
| 15:32 | abneiman | code review is GREAT for this |
| 15:32 | abneiman | sandbergja++ |
| 15:32 | sleary | sandbergja floated the idea of a rebasing party during the code review meeting on Monday. If people would like to do that this Friday, I can be available to help out with all the UI stuff that changed in the last couple of versions. |
| 15:33 | dluch | redavis: that's a good thought! |
| 15:33 | redavis | sandbergja++ sleary++ |
| 15:33 | abneiman | don't want to lose terranm 's point about devs / committers being engaged with BSW |
| 15:33 | abneiman | that's a time when a critical mass of people are testing, etc. |
| 15:33 | sleary | terranm++ |
| 15:33 | Bmagic | agreed |
| 15:33 | redavis | agreed |
| 15:39 | Bmagic | :), nevermind on the winding down |
| 15:39 | kmlussier | Oh, my. That's an old bug. I even have comments on it. |
| 15:39 | abneiman | Dyrcona: curious if you have an alternate suggestion? |
| 15:40 | mmorgan | Regarding test environments - community ones that can be checked out exclusively would be great |
| 15:40 | terranm | Maybe we need to have a needsdiscussion cleanup party, too |
| 15:40 | redavis | Bmagic++ mmorgan++ |
| 15:40 | sleary | terranm++ |
| 15:45 | dluch | We might be able to help with VMs...have to discuss internally, though |
| 15:45 | abneiman | Monthly half-day open code reviews or the like, with rotating responsibilty for hosting / VMs? |
| 15:45 | csharp_ | Bmagic: for me/us, the networking piece is an issue - PINES/GPLS machines are behind a finicky firewall :-/ |
| 15:45 | Dyrcona | We're supposed to be requiring test plans and release notes, so enforce that. (I've been adding them for my recent branches.) |
| 15:45 | csharp_ | but we can talk logistics at that level later |
| 15:45 | abneiman | and a committment from each senior committer to attend 1 per year or something |
| 15:46 | kmlussier | abneiman: I think a middle way is desireable. Smaller and more consistent contributions is a better approach than a mass of contributions / review happening at the same time. |
| 15:49 | csharp_ | it's not just a matter of time/tuits - I just need to develop better habits |
| 15:49 | abneiman | I'm just trying to think about ways to spread the load - if more people are doing things, we're relying less on the community unicorns (you know who you are lol) to shoulder so much |
| 15:50 | dluch | ++ |
| 15:50 | Dyrcona | I've also been burned by not testing some big things thoroughly enough, so I like to set aside at least a day to test even small things. |
| 15:50 | redavis | (if you're in this meeting, you're a community unicorn) |
| 15:50 | Bmagic | redavis++ |
| 15:50 | sleary | kmlussier gmcharlt_ went over things with me, but I don't think there is much written down in the wiki on going from contributor to committer |
| 15:51 | csharp_ | 🦄🦄🦄 |
| 15:51 | kmlussier | redavis: No, I'm just here because I like talking to all of you. |
| 15:51 | Bmagic | we're coming up on our hour yall |
| 15:51 | sandbergja | Dyrcona made me think of something that would be helpful for me: if there is a way we could run the tests against each pull request automatically. |
| 15:51 | Dyrcona | kmlussier: If you do want the commit bit back, just let me know. I can do it without a vote. :) |
| 15:51 | sandbergja | That green checkbox in Github saying "your tests passed" really helps me in other open source projects |
| 15:52 | kmlussier | redavis brought up earlier the idea of talkng about this at the hackfest. I've been thinking it might be worthwhile to have a monthly meeting where we could focus on one problem we want to solve. Because we could talk about this all day. |
| 15:52 | Bmagic | sandbergja: yes! a container that lauches with a branch and runs the test and dumps the results |
| 15:52 | * csharp_ | feels us teetering on the edge of the "move Git" discussion - keep his mouth shut |
| 15:52 | sandbergja | it wouldn't catch everything for sure, but it would provide a bit of a confidence boost |
| 15:52 | kmlussier | Dyrcona: I won't ask for it back unless I know I have the time to contribute. |
| 15:55 | Bmagic | https://wiki.evergreen-ils.org/doku.php?id=versioning |
| 15:55 | jeff | Are we talking about freshening up the examples and the OpenSRF / PostgreSQL deps? |
| 15:55 | Bmagic | ok, good idea, mailling list |
| 15:55 | abneiman | OTOH I think more automated testing is always going to be a good thing but I will not teeter us into "move git" today |
| 15:55 | sleary | move Git tomorrow ;) |
| 15:55 | Bmagic | #topic New Business - Possible hackfest (or other date) discussion on Evergreen releases - see email (Kathy) |
| 15:55 | Bmagic | #link http://list.evergreen-ils.org/pipermail/evergreen-dev/2024-February/000740.html |
| 14:21 | Dyrcona | I can easily see a claims returned circulation being checked in and not getting xact_finish set even when there are no bills. |
| 14:22 | Bmagic | Thanks for looking! |
| 14:25 | Dyrcona | Gotta love this '# is this check still needed?' at line 3,799 where checkin_handle_circ_finish determines if it should set or clear the xact_finish. |
| 14:25 | Dyrcona | Well, I guess it's "test" not "check" in the comment, but still.... |
| 14:26 | Bmagic | :) |
| 14:26 | Bmagic | it's always fun reading history |
| 14:27 | dguarrac | I had a claims returned test going from a few weeks ago because we just created a new "Claims Returned" status. I just checked in that item and the circ got stamped with the current datetime for xact_finish, checkin_time, and checkin_scan_time. |
| 14:27 | Dyrcona | Are there any rows in money.billable_transaction_summary for that circulation? Well, probably not now if xact_finisht was set. |
| 14:27 | dguarrac | The circ's stop_fines_time is still the datetime from when the circ was marked as claims returned a few weeks ago, though. |
| 14:28 | Dyrcona | dguarrac: That sounds right. |
| 10:02 | jvwoolf joined #evergreen | |
| 10:44 | sandbergja joined #evergreen | |
| 11:13 | kworstell-isl joined #evergreen | |
| 11:43 | * Dyrcona | is trying to test marc_stream_importer, and I'm pretty sure that I have it set up correctly. When I try to cat a marc file at it with nc, the record never queues, and I get no error messages. |
| 11:43 | Dyrcona | I can see the connection to the importer in the logs, but nothing else that looks related. |
| 11:54 | Dyrcona | There's nothing in the log after the connection except stream importer saying it is startng a child. No osrf syst activity. nada. |
| 12:02 | jihpringle joined #evergreen |
| 13:48 | jeffdavis | Maybe that is a conference/hackfest discussion though. |
| 13:50 | jeffdavis | And maybe the recent work on improving our release process has exhausted our appetite for other process discussions. :) |
| 13:50 | Dyrcona | jeffdavis: Time... I need a clone. |
| 13:50 | * sleary | is always here for process discussions |
| 13:51 | sleary | At the last New Devs meeting, a lot of people said they had trouble just setting up test systems to work on. Docker helps, but it requires a ton of resources. |
| 13:52 | sandbergja | Bmagic: is node --version 16 or above on that box? |
| 13:56 | Bmagic | sandbergja, nope, 12.16.3 |
| 13:56 | sandbergja | I noticed that the new antora wants 16 or more: https://www.npmjs.com/package/antora/v/3.1.7?activeTab=code |
| 14:46 | jeffdavis | :) |
| 14:47 | Dyrcona | What do we mean "barriers to committing?" I assume it was about committers not reviewing code for main. |
| 14:47 | Dyrcona | My number 1 barrier is time. |
| 14:48 | sandbergja | For me, lack of time and access to a system for qa are big. But I'd also say that merge conflicts and semantic conflicts (e.g. an upgrade script changes a stored procedure, but that stored procedure has changed in the meantime, so committing it would cause a regression) also make things harder than they need to be |
| 14:49 | sandbergja | Also, I'd add that it takes a while to re-load concerto, or to manually run the automated tests |
| 14:50 | Dyrcona | For merge conflicts and semantic issues, just throw back at the original developer and ask for a rebase if you're not comfortable fixing the conflicts yourself. |
| 14:51 | jeffdavis | My other big ones are (1) no test plan, and/or tests are complicated to set up; (2) unresolved questions about the fix; (3) extra work to backport and uncertainty about whether to do so. |
| 14:51 | jeffdavis | Time is the big one, but the others all make the process even more time-consuming. |
| 14:52 | Dyrcona | yeah, testing is often difficult for me. I usually avoid staff client stuff because I never use it, so I often have trouble testing staff client changes. |
| 14:55 | jeffdavis | I wonder if some kind-hearted organization would be able to make a limited number of VMs available to committers to help mitigate the lack of access to test environments. |
| 14:56 | jeffdavis | (not thinking of any particular organization tbh, actually wondering if this is something my org could help with) |
| 14:59 | Dyrcona | My org is trying to get away from being in the hosting business. |
| 15:00 | jeffdavis | I know some wonderful folks do already set up test environments pre-loaded with branches for bug squashing weeks, I'm wondering about something a bit more flexible as a supplement. |
| 15:05 | Dyrcona | yeah, that's what I thought you meant. |
| 15:43 | jihpringle joined #evergreen | |
| 16:49 | jvwoolf joined #evergreen |
| 11:12 | pinesol | Launchpad bug 2056343 in Evergreen "marc-export: hidden items can be exported as visible" [Undecided,New] https://launchpad.net/bugs/2056343 - Assigned to Jason Stephenson (jstephenson) |
| 11:16 | * Dyrcona | should just call it a day. I keep mistaking makes..... |
| 11:16 | Dyrcona | :) |
| 11:21 | Dyrcona | Oh, right. I have to move the copy location over from production and update the copies to test this properly. At least my change didn't break anything when the items are opac_visible. |
| 11:32 | Dyrcona | Hey, that works! |
| 11:33 | mmorgan | Excedrine++ |
| 11:48 | jihpringle joined #evergreen |
| 08:57 | Dyrcona joined #evergreen | |
| 09:14 | dguarrac joined #evergreen | |
| 09:30 | sleary joined #evergreen | |
| 10:01 | pinesol | News from commits: LP1991103: (follow-up) note that record note permissions must be assigned globally <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=410a27c7c04f4ae09c3dd8aaac9db48fa53c2913> |
| 10:01 | pinesol | News from commits: LP1991103: incorporate feedback from review, address failing test <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=ca2275864d55bcb057674ce22589461af885aafd> |
| 10:01 | pinesol | News from commits: LP1991103: Display a count of record notes in the staff catalog tab <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=db672c3ec1cea5681c73ac54c20fabde7980ca31> |
| 10:46 | sandbergja joined #evergreen | |
| 11:27 | Stompro joined #evergreen | |
| 11:34 | kworstell-isl joined #evergreen |
| 12:43 | Dyrcona | So, I wrote a naive program to fork around some backend calls and it is failing with Redis as the communication layer. I have not tried it with ejabberd. |
| 12:43 | Dyrcona | I should try the non-forking version with Redis. Maybe the fork is on the issue. |
| 12:45 | Dyrcona | Non-forked version works with Redis. |
| 12:45 | Dyrcona | I'll test tomorrow with ejabberd. I already ran the non-forked version on that vm today, so the forked version won't do anything. |
| 12:48 | Dyrcona | The problem might be where/how I'm doing the fork. |
| 12:48 | berick | gotta connect to osrf after forking regardless of redis/ejabberd |
| 12:49 | Dyrcona | berick++ OK. I forgot/didn't know about that. |
| 14:26 | Dyrcona | This is actually a client. I was trying to emulate running multiple trigger reactors at once. |
| 14:30 | mantis left #evergreen | |
| 14:45 | Dyrcona | @blame Leap Day |
| 14:45 | pinesol | Dyrcona: Leap Day tests their code on the LIVE SERVERS, then blames the user. SAD! |
| 14:50 | sleary joined #evergreen | |
| 15:01 | kmlussier1 joined #evergreen | |
| 15:02 | mmorgan1 joined #evergreen |
| 14:47 | csharp_ | Dyrcona: feel free! |
| 14:47 | csharp_ | I totally missed Galen's feedback |
| 14:53 | Dyrcona | csharp_: OK. I'll take it over and see what I can do. |
| 15:01 | csharp_ | I was just looking at the Net::SFTP::Foreign documentation and I think breaking the args hash into its own variable whose elements are conditionally constructed allows for the fixes gmcharlt_ mentions in the first point of his comment |
| 15:02 | csharp_ | basically, only set the password in the hash if there is a password with the assumption that "no password" = "use keys instead" |
| 15:03 | csharp_ | also allow strict host checking to be an option? I understand both why you'd want that set to "no" and why you wouldn't |
| 15:04 | csharp_ | ... and that's where I was when you offered to take it over - happy to help and certainly happy to test/signoff |
| 15:09 | Dyrcona | csharp_: If you want to take it and make the changes yourself, feel free to steal it from me. |
| 15:11 | csharp_ | Dyrcona: yeah, I think I will and let you know if I hit some blocks - I'll let you know when there's something to test |
| 15:11 | Dyrcona | csharp_++ |
| 15:27 | mmorgan | Have any Stripe users had issues with duplicate charges? |
| 15:30 | Dyrcona | mmorgan: Not that I'm aware of. |
| 08:52 | Dyrcona joined #evergreen | |
| 08:57 | dguarrac joined #evergreen | |
| 09:34 | sandbergja joined #evergreen | |
| 09:58 | sandbergja | installing and running automated tests on the 3.11.4 tarball candidate |
| 09:58 | redavis | ++ |
| 10:06 | Bmagic | Does Evergreen's OPAC refresh back to the home page when no one is logged in and it's not currently on the home page after a certain amount of time? |
| 10:12 | redavis | There is an OPAC inactivity logout setting... |
| 14:10 | csharp_ | a lot of the pain of RHEL/Rocky has been bending over backwards to get EJabberD installed |
| 14:11 | Dyrcona | Yeahp, and it gets trickier with every Ubuntu release, too. |
| 14:14 | Dyrcona | "We're all just learning how to smile." |
| 14:33 | Dyrcona | Ugh. my test is gonna fail because of a typo. Guess I'll stop it and fix it. |
| 14:36 | kworstell-isl joined #evergreen | |
| 14:54 | sandbergja joined #evergreen | |
| 14:56 | jonadab joined #evergreen | |
| 15:47 | Rogan | I have no idea why but absolutely |
| 15:48 | Dyrcona | :) |
| 15:48 | Dyrcona | Rogan++ |
| 16:17 | * Dyrcona | prepares to install Evergreen 24.02.22 on a test system. :) |
| 16:17 | berick | already that time eh? |
| 16:18 | Dyrcona | I want to test some stuff with latest code and produciton data, so I made a branch versioned with today's date. |
| 16:18 | berick | Dyrcona++ |
| 16:20 | Dyrcona | I'll have to reload the db from a dump and run the upgrade script tomorrow. |
| 16:20 | Dyrcona | I decided to start versioning my test branches with the date. |
| 16:29 | * Dyrcona | takes off for the day. |
| 16:29 | Dyrcona | Catch y'all tomorrow! |
| 17:06 | mmorgan left #evergreen |
| 09:40 | Bmagic | I abandoned ship, and decided to let Evergreen absorb the values from redis-accounts.txt upon install (magic!) |
| 09:41 | berick | more like... Bmagic |
| 09:41 | Bmagic | It seems that installing Evergreen from the main branch, somewhere in the make process, it looks for redis-accounts.txt and plopps those UUID's into opensrf_core.xml.example. Pretty neat |
| 09:42 | Bmagic | Got a test machine running, and loaded 100 barcodes into item status, and did the same on a copy of the same machine but running ejabberd. Redis won! By a lot, like triple |
| 09:43 | sandbergja joined #evergreen | |
| 09:43 | berick | nice |
| 09:43 | berick | yeah, i tried to make the password setup as simple as possible. bound to be some rough edges though |
| 09:50 | berick | woohoo |
| 09:51 | JBoyer joined #evergreen | |
| 09:51 | Bmagic | FYI: we already have a PG15 machine in production. No problems! Other than the JIT feature needing to be turned off |
| 10:05 | * Dyrcona | has been testing Pg16 with production data with no issues. Granted, I do not hit every feature of Evergreen. |
| 10:14 | Dyrcona | Y'know what's funny? Before delete on some tables: 560G /var/lib/postgresql. After delete and vacuum full analyze: 571G /var/lib/postgresql. My suspicion: delayed wal archives/streaming. |
| 10:15 | Bmagic | yes, that's correct. The satisfaction is delayed |
| 10:16 | Dyrcona | Now: 560G/var/lib/postgresql. That is pretty much what I expected. |
| 14:18 | Stompro | https://github.com/mdnoble73/aspen-discovery/blob/9b708e77af8008976dc791bb9b87f57fd80d4c62/code/evergreen_export/src/org/aspendiscovery/evergreen_export/EvergreenExportMain.java#L1517 |
| 14:19 | Dyrcona | Yeah. I've looked at that file, but I've not tried to figure out exactly what needs to be done. |
| 14:20 | Stompro | I'm hopeful that Bywater is working on opening up their bug tracker... |
| 14:21 | Dyrcona | As for Aspen dev, I've been using a PHP Evergreen Client and a small compatibility lib to test my PHP changes, then I have to translate them to what Aspen actually does. The PHP Evergreen client is in a currently private repo on github if you want to look. It's private because I don't think it is done yet. I'll make it public after I've tested it more, cleaned it up, added documentation, and squashed it into a main branch |
| 14:22 | Stompro | Sure, my github account is StomproLARL2023 |
| 14:22 | Stompro | (if that helps... not sure how github private sharing works). |
| 14:25 | Dyrcona | Stompro: You should receive an invitation. |
| 14:26 | Stompro | Got it, thanks. |
| 14:28 | Dyrcona | I have an additional library that I haven't put up there called Aspen.php It has some code to map objects the way Aspen does and adds modified versions of some Aspen classes that were useful in testing. I'll see about making that available somehow. |
| 14:31 | Stompro | Did you create the reading history fixes? I think I saw those in the 25.02 release. We are starting to get people noticing that not all their history is imported. |
| 14:35 | Stompro | Err. 24.02 release... I don't see that far into the future. |
| 14:35 | Dyrcona | I think I explained to Mark what needed to change. |
| 14:42 | Dyrcona | I don't know if something needs to be done, but I think that they did clear ours out when applying the fix. |
| 14:44 | Stompro | Did users have to opt back in again? |
| 14:46 | Dyrcona | We |
| 14:46 | Dyrcona | We're not live, yet, so I don't know. I haven't been working that closely with the testing of the user side of things. I've mostly just been looking at code and proposing solutions. |
| 14:56 | Stompro | Hmm, I can see our item stat cats in the supercat info... it would be cool if we could use that for our Literary Form and Audience data. |
| 14:56 | Stompro | So I don't have to try and clean up our bibs. |
| 15:00 | Dyrcona | You should clean up your bibs. |
| 10:25 | Dyrcona | Also, I get the buzzing noises, too. I've got 4 different conversations going on right now, including this one. :) |
| 10:29 | kworstell-isl joined #evergreen | |
| 10:30 | redavis_reboot joined #evergreen | |
| 10:34 | pinesol | News from commits: LP#2053245: fix Angular staff client test failure <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=9aa81e3a89ff8631f5e026081a069e033a719d9e> |
| 10:51 | stephengwills joined #evergreen | |
| 10:56 | collum joined #evergreen | |
| 11:07 | Dyrcona | One thing that has come up in internal CW MARS discussion is that we need different intervals to clean data from different auditor tables. We keep 13 months on the biblio record entry history because we use it for a report. We keep 6 months on most tables. Then there's the hold request history where we need to keep 3 months or less because we purge certain holds at 3 months for privacy reasons. (NB: 6 months for most things was consi |
| 13:50 | Dyrcona | kmlussier++ tuits++ |
| 13:51 | * Dyrcona | should open a Lp bug to eliminate the acq auditor functions. |
| 13:53 | Dyrcona | csharp_: I could adapt fix_columns to a do block that hits these two tables. That might work for my purposes. |
| 13:59 | Dyrcona | Well, my test database is now a mess. |
| 14:01 | Dyrcona | Grr. It's not that simple.... Of course it's not that simple...... |
| 14:05 | Dyrcona | Well, that did not fix anything. |
| 14:06 | Dyrcona | because columns are still in different orders...... |
| 14:19 | Dyrcona | ugh... I'm going to have to do this again on a different schema version. |
| 14:20 | _collum joined #evergreen | |
| 14:23 | Dyrcona | So, the insert ... select takes longer when you don't truncate the source table first. |
| 14:29 | Dyrcona | Looks like the schema hasn't really changed between the two releases that I have test data for. |
| 14:33 | csharp_ | gmcharlt_: Rogan: in the Zoom waiting room for board meeting in case you can see this |
| 14:33 | csharp_ | or kmlussier or redavis |
| 14:33 | Rogan | csharp_: I'll mention it |
| 14:33 | csharp_ | Rogan: thank you |
| 14:41 | collum joined #evergreen | |
| 14:49 | collum joined #evergreen | |
| 15:03 | Dyrcona | heh. Test it on a database that hasn't had a refresh in over 6 months and all the rows disappear! That's a 100% space savings on that 1 table alone. :) |
| 15:17 | Bmagic | space good; cougar bad |
| 15:20 | jeff | space good. |
| 15:20 | jeff | sadly, this update wasn't nearly as exciting as it could have been: Introducing new Space Manager capabilities in Google Chat |
| 15:49 | Dyrcona | s/thought/though/ |
| 15:51 | Bmagic | Dyrcona: https://imgur.com/a/05CngrU |
| 15:51 | Dyrcona | heh. |
| 15:52 | Dyrcona | Well, it's tested as far as it works.... I'm just not sure if the streaming replication is gong to like it. |
| 15:52 | Dyrcona | I mean, I ran it on 4 databases..... :) |
| 15:53 | Bmagic | alright, I retract my link |
| 15:54 | mantis left #evergreen |
| 15:08 | Bmagic | carry it forward? |
| 15:08 | mmorgan | Yep! |
| 15:08 | Bmagic | #action mmorgan will explore moving LP stats to community site and automating same |
| 15:09 | Bmagic | #info sandbergja will see if gh actions can run the pgtap tests |
| 15:09 | Bmagic | skipping |
| 15:09 | Dyrcona | #info Dyrcona = Jason Stephenson, CW MARS |
| 15:09 | Bmagic | #info GalenCharlton will open LP bug with the official proposal for git commit message release-note |
| 15:09 | Bmagic | #action sandbergja will see if gh actions can run the pgtap tests |
| 15:10 | gmcharlton | So, the bug is opened: https://bugs.launchpad.net/evergreen/+bug/2051946 |
| 15:10 | pinesol | Launchpad bug 2051946 in Evergreen "institute a Git commit message template" [Wishlist,New] - Assigned to Galen Charlton (gmc) |
| 15:10 | gmcharlton | ah, sorry, wrong one |
| 16:00 | terranm57 | Bmagic++ |
| 16:01 | terranm57 | I'm inclined to push it back to March unless anyone wants it sooner |
| 16:01 | Bmagic | nope, that's fine! |
| 16:01 | abneiman | +1 to March, I can even promise some shiny new features to test :-D |
| 16:01 | terranm57 | Cool beans, I'll put it on the calendar and do all my stuff |
| 16:01 | abneiman | and some buffed-up old features |
| 16:02 | Bmagic | terranm++ |
| 11:34 | Stompro | Hello Friday Morning Evergreen Channel. I recently tried out using the patron address print template to create our new account welcome letters that we mail out for online applications. And that worked great. But it does take over the functionality there. Is there any way to add arbitrary print templates right now, and trigger them somehow? |
| 11:38 | Dyrcona | Stompro: Action trigger? |
| 11:40 | Stompro | Is there a way for front line staff to trigger that to generate on demand? That is the nice thing about how the print address template is setup. And the fact that each workstation can have custom templates easily. |
| 11:41 | Stompro | Obviously there is, thinking about the email and sms test notices. |
| 11:42 | Dyrcona | There's a way to trigger when a new patron is created. Action triggers can also be triggered on demand, examples include printing/emailing/downloading bib information the OPAC, downloading circulation history, etc. |
| 11:43 | Stompro | This wouldn't be for all new patrons is the issue, just the ones that need a welcome letter printed, which is just a subset of them. |
| 11:45 | Dyrcona | You said it was for online account sign ups? If you can't find a hook for those, you could use the normal hook and add a filter that identifies only the online account sign ups. |
| 10:26 | Dyrcona | Yeah, using the filenames works. I think I like that better. |
| 10:27 | jeff | Dyrcona: let me know when you settle on a VM naming scheme that IS a good idea. two hard problems... |
| 10:29 | Dyrcona | Place names from Middle Earth? Planets/systems from Star Wars or Star Trek? I've tended toward boring, utilitarian names like eg-vm1, eg-vm2, etc. At the University of KY, College of Engineering Computing Center, we named the servers and a few workstations for airplanes. |
| 10:30 | Dyrcona | I have named my local vms for Evergreen testing for the Debian/Ubuntu release: bullseye, bookworm, focal, jammy. That works because they're ephemeral and will almost never be upgraded to a new release. |
| 10:31 | Dyrcona | OK. I have a gist to update. |
| 10:34 | Dyrcona | ooh... Cool. Using the filenames lets me eliminate four uses of `cut` and delete the now redundant path when "reading" the upgrade script file. |
| 10:34 | stephengwills | I named my hosts after snow whites friends but then I needed an 8th server and the scheme broke. wa-wa. |
| 10:43 | Dyrcona | https://gist.github.com/Dyrcona/00bd6b6290b6fbbb579c7f93b360ab0d # I've shared it before. I'm sharing it again, now. |
| 10:46 | Dyrcona | Think I'll link it from the git repo to my bin instead of having he whole script in there. |
| 10:53 | Dyrcona | looks like a record ingest will be required going from 3.10.3 to main. |
| 10:54 | Dyrcona | Well, that'll be a nice test of Pg 16, won't it? |
| 11:01 | sandbergja joined #evergreen | |
| 11:05 | Dyrcona | Ugh. Looks like I'm going to have reinstall OpenSRf as well as Evergreen. I may end up rebuilding the VM from scratch if things don't go well. -- The joy of sikipping releases! |
| 11:29 | Dyrcona | The clobber option isn't clobbering the upgrade script.... |
| 10:39 | kworstell-isl joined #evergreen | |
| 10:57 | sandbergja joined #evergreen | |
| 11:14 | Dyrcona joined #evergreen | |
| 11:36 | * mmorgan | frequently encounters the off-by-one error lately that results in attempting to login to a test system as the user SNUB |
| 12:00 | jeff | if I shifted like that, that would end up being either "nub" or "snub", depending on how quickly I hit the first two. |
| 12:01 | mmorgan | :) |
| 12:07 | Dyrcona | There are only two hard problems in computer science: naming things, cache invalidation, and off by one errors. |
| 12:10 | Dyrcona | berick: Yeahp. Data integrity is not our strong point.... j/k, honsestly. |
| 12:10 | Dyrcona | Guess Aspen does need a patch after all. |
| 12:11 | Dyrcona | I am joking about the integrity thing. I can get what I need from the target_copy field. |
| 12:11 | Dyrcona | Guess I didn't waste my time writing this test program after all. |
| 12:11 | Dyrcona | berick++ |
| 12:17 | Dyrcona | heh. "investigating" sounds more professional than "playing around with" :) |
| 12:29 | jihpringle joined #evergreen |
| 10:33 | mantis joined #evergreen | |
| 10:36 | jvwoolf joined #evergreen | |
| 10:55 | sandbergja joined #evergreen | |
| 11:10 | Dyrcona | sandbergja: Did you get a chance to test the 3.11.3 tarball on Friday? |
| 11:14 | sandbergja | Dyrcona: yes, I ran the automated tests. They all passed except a few of the e2e nightwatch ones (which also fail on the rel_3_11 branch). I don't think they should block the release |
| 11:14 | Dyrcona | sandbergja++ |
| 11:14 | Dyrcona | Do you have an announcment ready to go? I could stage the files at almost any time today, though I do have a couple of meetings. |
| 11:15 | sandbergja | redavis is signed up for that, and has some things ready to go, I think |
| 09:34 | Dyrcona | I'm running it manually now. |
| 09:36 | Dyrcona | Grr. Insert can have only 1 ON COnFLICT clause. I'd actually like to do something different depending on which constraint triggers. |
| 09:36 | Dyrcona | Totally unrelated to offline blocklist, of course. |
| 09:39 | Dyrcona | This mean that I can't really test this update in its entirety. I'm updating some information related to users and my test database doesn't have all of the users from production. |
| 09:40 | Dyrcona | i suppose I could do the insert/update with a select statement or add a where exists.... |
| 09:46 | Dyrcona | No? "and exists (select 1 from actor.usr where id = <user_id>) didn't help. |
| 09:46 | Dyrcona | Oh, duh.... |
| 09:47 | redavis joined #evergreen | |
| 09:47 | Dyrcona | Bmagic: Looks like offline-blocklist finished and the output is 18MB. |
| 09:49 | Dyrcona | Maybe the AND EXISTS will work if I remove the rule from the constraint... |
| 09:51 | Dyrcona | Nope. Do update requires inference specification or constraint name. Guess I can't really test the update, though it "worked" for the ones that existed, so it's good. Hopefully all of the users exist in production. |
| 10:01 | berick | hey, Ubuntu, how about I pay you *not* to advertise Ubuntu Pro at me? bleh. |
| 10:01 | berick | maybe time to mix up the ol' desktop OS |
| 10:02 | Dyrcona | berick: Have you considered Arch? I use it on my personal laptop. |
| 12:38 | pinesol | Launchpad bug 1901726 in Evergreen "Required Fields Based on Hold Notification Preferences Too Strict" [Medium,Confirmed] https://launchpad.net/bugs/1901726 |
| 13:01 | abneiman | sandbergja++ redavis++ mmorgan++ Bmagic++ # rmaking point releases happen |
| 13:02 | mmorgan | abneiman++ |
| 13:32 | sandbergja | The 3.12.1 tarball finished building. I'm going to try installing it and running the tests |
| 13:40 | jihpringle joined #evergreen | |
| 13:44 | sandbergja | So far, the perl unit tests, perl live tests, pgtap, and angularjs unit tests have passed. Waiting on angular unit and e2e tests, OPAC js tests, and C tests. |
| 13:47 | sandbergja | I <3 tests, but dang, that is a lot of testing frameworks |
| 13:47 | sandbergja | I think two of them are my fault hahaha |
| 13:47 | Dyrcona | sandbergja++ |
| 13:48 | Dyrcona | Well, we need more tests, and maybe fewer frameworks. |
| 13:48 | sandbergja | +1 |
| 13:49 | Dyrcona | I suppose we can drop 1 of the frameworks, or at least 1 set of tests, when AngularJS is finally gone. |
| 13:49 | sandbergja | Oh, one test question that I've been meaning to ask forever. What is the distinction between pgtap regression tests and just regular pgtap tests? |
| 13:51 | Dyrcona | The regression tests are, I think, meant to check that certain database changes have not been undone. |
| 13:52 | Dyrcona | I added a regression test to my branch for Lp 1835953 to make sure that the columns have the not null constraint. |
| 13:52 | pinesol | Launchpad bug 1835953 in Evergreen "Circulation auto renewal remaining should not be nullable" [Medium,In progress] https://launchpad.net/bugs/1835953 |
| 13:53 | sandbergja | Dyrcona++ |
| 13:54 | sandbergja | I like that example! |
| 13:58 | Dyrcona | That branch makes a few updates to the pgtap tests and the sample data load. |
| 14:08 | sandbergja | 3.12.1 tarball tested and it passed! |
| 14:09 | sandbergja | I've uploaded the release directory here: https://drive.google.com/drive/folders/1PVlPVhJ8UtUUH7Yu1JRSsJkr1TOo0Fgv?usp=drive_link -- gmcharlt: could you please upload it to lupin? |
| 14:21 | sandbergja | I pushed my working branch to tags/rel_3_12_1. I also added the upgrade script to the rel_3_12 and main branches. Does that seem as it should be? |
| 14:21 | Dyrcona | Yes, that sounds right. Let me have a look. |
| 14:22 | sandbergja | Dyrcona++ |
| 14:22 | Dyrcona | Looks good to me. I can copy the files to Lupin if gmcharlt hasn't gotten to it, yet. |
| 16:00 | Bmagic | I've not done any release work today |
| 16:01 | Dyrcona | Bmagic: I'm talking about last time. |
| 16:02 | Bmagic | on point releases, I believe we skip down to Translations, Part 2: update_pofiles steps. new pot would be applied to the main branch of the evergreen release series. AKA rel_3_12. And not* against tags/rel_3_12_1. At least that's the way I understand it. Please feel free to correct me! |
| 16:03 | Dyrcona | Don't know if I'll finish testing this today. We'll see. |
| 16:03 | Dyrcona | Bmagic: newpot was done the previous two times on 3.11, so I did it again. |
| 16:03 | Dyrcona | The commits are there anyway. |
| 16:04 | Bmagic | ok, that's fine. It's ok if it's done against the point release tags branch, though I believe the design intension was to have new pot run ahead of time, at some frequency, independent of the point release cycle |
| 16:04 | Dyrcona | Should I test with OpenSRF main or 3.2.4? |
| 16:05 | Bmagic | I'm not sure it matters today if you use main opensrf or 3.2.4. Is there a commit difference between them? |
| 16:06 | Dyrcona | Yeah, I'm going with main because I already installed the prerequisites. |
| 16:06 | Dyrcona | I did that reflexively before I started working on release building. |
| 16:16 | Dyrcona | I fixed the syntax and regenerated the HTML. I'll have to update the tarball. |
| 16:16 | Dyrcona | No, you don't have a point release assigned to you. I don't think we're using the spreadsheet this time. |
| 16:18 | Dyrcona | oof. I just realized that I've been using markdown link syntax when I've been writing release notes lately. I'll have to fix those, I think. |
| 16:22 | Dyrcona | I'm not going to be able to test this today. |
| 16:25 | pinesol | News from commits: Fix syntax in 3.11 release notes <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=2d50b18103dcf0480467bfcab5b3ce2f173a7f38> |
| 16:27 | Dyrcona | i can probably test the db upgrade scripts without too much setup. |
| 16:29 | Dyrcona | nah, I'll have to test this later. |
| 16:30 | Dyrcona | I pushed the tag branch and copied the files to lupin where I can get them later to test. |
| 16:30 | Dyrcona | I'll have to see if I can test this tomorrow some time, but I've got stuff to do. |
| 16:34 | Dyrcona | I've put the release files here: https://drive.google.com/drive/folders/1Eys7BQV4TdDcgs8QtXy6XJ46QC8CMbyK?usp=sharing |
| 16:35 | Dyrcona | If anyone else wants to test. Also, let me know if you can't access that or the contents. It should be shared with anyone who has the link. |
| 16:35 | sandbergja | Dyrcona++ |
| 16:35 | sandbergja | I can run the automated tests on that tarball this afternoon |
| 16:36 | Dyrcona | sandbergja++ |
| 16:53 | sandbergja | It would be nice if we could make the perl live tests and nightwatch e2e tests faster too. I suspect that's a barrier to people running them regularly. |
| 17:06 | jihpringle joined #evergreen | |
| 17:09 | mmorgan left #evergreen | |
| 17:16 | sandbergja | all tests are passing for that 3.11.3 tarball, except for 3 of the nightwatch tests (for vandelay, holdings view, and acq providers). I didn't see anything obviously amiss with those screens, fwiw. It is not specific to the tarball. I get the same failures after installing rel_3_11 from source. |
| 17:16 | sandbergja | I think we should investigate them, but I don't think they need to block the release or anything. |
| 17:17 | sandbergja | abneiman++ redavis++ Bmagic++ Dyrcona++ mmorgan++ # thanks for helping with these releases! |
| 17:38 | book` joined #evergreen | |
| 19:27 | jihpringle joined #evergreen |
| 15:15 | berick | mmorgan: i only meant we don't systematically apply pcrud perms to every pcrud-accessible class in the IDL, esp. if pcrud was not initially used to manage the class. |
| 15:46 | adam_reid joined #evergreen | |
| 15:55 | adam_reid | hey all! I've been looking at the actor.verify_passwd() function in the evergreen DB, am I understanding it correctly that I should be able to pass in (usr.id, type, password) and get a true false result? I'm playing with a little custom tool and want to require users to verfiy beforehand |
| 15:58 | berick | adam_reid: yes, but it's a little more complicated with 'main' passwords |
| 16:00 | sandbergja joined #evergreen | |
| 16:00 | berick | adam_reid: select * from actor.verify_passwd(1, 'main', md5((select salt from actor.passwd where usr = 1) || md5('demo123'))); |
| 16:01 | berick | that's my test system where admin has password demo123 |
| 16:01 | adam_reid | amazing, I had the feeling I was missing the use of md5, I'll try with you example. Thanks berick! |
| 16:06 | adam_reid | Fantastic, that worked berick! |
| 16:06 | mantis1 left #evergreen |
| 10:51 | Bmagic | nothing formal |
| 10:51 | Dyrcona | OK. cool. |
| 10:51 | Dyrcona | How many I can attend depends on my schedule. I've been busy with Aspen stuff lately. |
| 10:52 | Dyrcona | My rebased branch works and all tests pass, including the ones I modified. I'm having a good day so far. :) |
| 10:55 | Dyrcona | Think I'll look for something to review on my own this afternoon. |
| 10:59 | sandbergja joined #evergreen | |
| 11:09 | jvwoolf joined #evergreen | |
| 14:46 | pinesol | News from commits: LP1998413 - Holdings Editor Batch Actions restore prefix/suffix option <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=230e7a23422b9e0b4ab587244079bad858c9eb17> |
| 14:47 | Dyrcona | pinesol I think you're a conspiracy theorist. |
| 14:47 | pinesol | Dyrcona: http://images.cryhavok.org/d/1291-1/Computer+Rage.gif |
| 14:52 | * Dyrcona | sometimes to assign bugs to himself when testing. |
| 14:53 | * Dyrcona | also sometimes forgets to type words in IRC. I think my brain gets ahead of my fingers. |
| 15:00 | kworstell_isl joined #evergreen | |
| 15:05 | sandbergja | nfaber: I've had a lot of luck using the docker containers from BMagic on my M1 macbook: https://hub.docker.com/r/mobiusoffice/evergreen-ils |
| 15:51 | * Dyrcona | decided to go with the STAFF_LOGIN version. |
| 16:19 | sandbergja | Dyrcona++ |
| 16:41 | Dyrcona | 2 files changed, 6953 insertions(+), 7122 deletions(-) |
| 16:48 | Dyrcona | Perl tests pass. |
| 16:48 | Dyrcona | I'll check some of the Angular interfaces tomorrow. |
| 16:57 | mantis1 left #evergreen | |
| 19:53 | jihpringle22 joined #evergreen |
| 10:26 | Dyrcona | berick: It gets crazier because the backend sends just the workstation id to the AngularJS client, and the client appears to use what the back end sends it. I would suspect a change in a dependency except it works with a stock release on the same data. |
| 10:27 | Dyrcona | No database errors either. |
| 10:30 | Dyrcona | I've got 47 commits to bisect... Dunno if I want to go all the way back to start since it apparently worked last week. |
| 10:32 | Dyrcona | I should test this on a more recent release with similar patches. |
| 10:33 | Dyrcona | I have two available. |
| 10:43 | Dyrcona | OK. it works on a more recent Evergreen release, but that one may not have all of the patches or may have one that's missing. I can't rule out that we dropped something. |
| 10:49 | Dyrcona | Guess I'll bisect everything. |
| 13:59 | Dyrcona | yes. |
| 14:00 | Dyrcona | I might give xmllint a whirl later. I think I'm going to put this aside for a bit and work on something more important. |
| 14:02 | Dyrcona | The indentation doesn't respect the vim/Emacs settings at the bottom. I have also noted that the Emacs on this Ubuntu 20.04 laptop is ignoring the settings. We've got mostly tabs, but some spaces mixed in. |
| 14:04 | Dyrcona | I suspect the file may be too large for Emacs to care about the settings at the bottom. If they were at the top, it would probably work. I may move the comment just to test that theory. They're also some "unsafe" variables, so I may need to check if I've allowed them to be changed in my Emacs config....Software.... |
| 14:22 | jvwoolf joined #evergreen | |
| 14:43 | jihpringle joined #evergreen | |
| 14:57 | kmlussier1 joined #evergreen |
| 10:24 | Dyrcona | Stompro++ # For most of the performance improvements. |
| 10:25 | Bmagic | I was tracking that thread |
| 10:25 | Dyrcona | Mostly for items, yes. |
| 10:26 | Bmagic | this execution is sans items. At least I think it is. I didn't pass any arguments to marc_export. My command: cat records.txt | marc_export > test.mrc |
| 10:27 | Dyrcona | Well, use your own extractor if it is faster. Also, "Patches welcome!" |
| 10:27 | pinesol | News from commits: LP1839364 Move login page error message; add ARIA <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=8a92c0619f366e1854575d686c3619d5d559f694> |
| 10:27 | pinesol | News from commits: LP#1945003: (follow-up) redo lint fixups <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=4fdaf17cf6a91a6f7e3a8bcf1864aef526ffeed8> |
| 09:10 | kworstell-isl joined #evergreen | |
| 09:42 | dguarrac joined #evergreen | |
| 09:50 | kworstell-isl joined #evergreen | |
| 10:30 | csharp_ | Bmagic: do y'all still have tools for LibraryIQ export that are shareable somewhere? the vendor has an outdated link to the mobius_evergreen repo... |
| 10:31 | csharp_ | we have a library interested in testing |
| 10:31 | Bmagic | yep! Let me get the link |
| 10:32 | Bmagic | csharp_: https://github.com/mcoia/evergreen-libraryiq-export |
| 10:38 | csharp_ | Bmagic++ # muchas gracias |
| 15:17 | Bmagic | I've decided (based on the strength of recent new installation of Evergreen 3.11.1 on PG15 for a new group of academics) that we upgrade to PG15 for anyone going to 3.11 and greater |
| 15:18 | Dyrcona | I wish more folks would actually look at new Pg versions. I'm playing with pg 16 and production data, now, but have no idea if it is really ready for prime time. |
| 15:19 | Bmagic | We have two production consortia on pg15. Been 6 weeks or so. So far it's just fine |
| 15:19 | Dyrcona | Also, i don't know that pg versions should really cause bad character issues in the data. We could check the release notes again. I know that we have had to adjust the creations of some indexes and update tests because of Pg changes with character set handling in the past. |
| 15:20 | Bmagic | the character issue may not be related. I was sort of guessing, because the PG version was something we changed between then and now. But records get added all the time too, so.... |
| 15:20 | Dyrcona | Those were mainly related to stripping accents in name search. |
| 15:22 | Dyrcona | We get wide character and other warnings during export all the time. The best is when some UTF-16 sneaks, usually copy and paste from a browser. It always seems to happen when someone copy/pastes a description from Amazon. |
| 09:40 | Dyrcona | "Pg16" sounds like a movie rating, not the name of a virtual machine. |
| 09:44 | Dyrcona | git: "Please tell me who you are." |
| 09:48 | csharp_ | Dyrcona++ |
| 09:51 | Dyrcona | git fetch --all shows some interesting things to test later. |
| 10:17 | Dyrcona | live_t/37-carousels.t (Wstat: 65280 Tests: 2 Failed: 1) |
| 10:24 | Dyrcona | huh. This time it worked.... |
| 10:30 | berick | conf deadline... i'd be happy to talk about redis, but I think people would rather hear from someone else at this point. |
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 149 150