| Time |
Nick |
Message |
| 00:46 |
|
Rogan joined #evergreen |
| 01:07 |
|
jmurray-isl joined #evergreen |
| 07:22 |
|
kworstell-isl joined #evergreen |
| 07:57 |
|
BDorsey joined #evergreen |
| 08:02 |
|
cbrown joined #evergreen |
| 08:34 |
|
mmorgan joined #evergreen |
| 08:42 |
|
cbrown_ joined #evergreen |
| 08:47 |
|
cbrown joined #evergreen |
| 08:47 |
|
sandbergja joined #evergreen |
| 09:04 |
|
dguarrac joined #evergreen |
| 09:07 |
|
redavis joined #evergreen |
| 10:06 |
|
BDorsey_ joined #evergreen |
| 10:18 |
|
Dyrcona joined #evergreen |
| 10:47 |
|
sandbergja joined #evergreen |
| 10:59 |
Dyrcona |
Has anyone gotten this with the 3.13.4 to 3.14.0 upgrade db script? "ERROR: ALTER TYPE ... ADD cannot run inside a transaction block". I'm only asking because I got it with another script that I wrote based on the 3.14 upgrade. However, I'm pretty sure that I didn't get it when I test the 3.14 upgrade after making it earlier this week. |
| 11:04 |
Dyrcona |
I am going to test the db upgrade again, this time on a Pg 10 database. It was Pg 10 where it failed on me. That behavior could have changed.... |
| 11:06 |
Dyrcona |
Yeah. It looks like it would fail with the same error... |
| 11:13 |
Dyrcona |
So, the 3.13.4-3.14.0 db upgrade works on Pg 16, which is where I think I tested it. I'll try Pg 10. |
| 11:18 |
redavis |
IIRC, we talked about stating that EG 3.14 required a minimum version of PG (I don't remember which) higher than 10 because it's out of support now. |
| 11:19 |
Dyrcona |
redavis: Yeah, but the release notes actually say it is compatible with Pg 10. We don't support less than Pg 13 for new installations. |
| 11:19 |
Dyrcona |
And, the upgrade fails on Pg 10. |
| 11:19 |
redavis |
Hmm, possible that the release notes are wrong (forgive me if that's the dumbest thing ever to say)? |
| 11:20 |
Dyrcona |
Same error message. I have to remove a BEGIN/COMMIT pair. |
| 11:20 |
Dyrcona |
No, the release notes are correct. We changed it to be compatible. |
| 11:20 |
redavis |
Oh. okay |
| 11:20 |
redavis |
makes sense |
| 11:21 |
Dyrcona |
I swear I tested it on Pg 10, also, but I guess I didn't and thought that I had. |
| 11:21 |
Dyrcona |
I'll modify the db upgrade and put out a new tarball. |
| 11:21 |
Dyrcona |
We've had to do this before. |
| 11:21 |
redavis |
Dyrcona++ |
| 11:24 |
Dyrcona |
We've tacked an a on the end of version in the tarball, and looks like that was done via link last time it happened. |
| 11:26 |
Dyrcona |
@blame MFA |
| 11:26 |
pinesol |
Dyrcona: MFA stole bradl's tux doll! |
| 11:28 |
|
jihpringle joined #evergreen |
| 11:30 |
Dyrcona |
OK. NOW, it works. |
| 11:31 |
redavis |
lol, Dyrcona++ |
| 11:31 |
redavis |
@blame php |
| 11:31 |
pinesol |
redavis: php is really just another name for autogen |
| 11:31 |
Dyrcona |
Heh. |
| 11:33 |
Dyrcona |
I think I still have the files extracted on my release build machine, so I'll just replace the db ugprade there and make a new tarball and md5, then replace them on the server. I'll send an email to dev and general about an issue since the release..... |
| 11:33 |
redavis |
Okay, thank you. And, if there's something you need me to do...holler. Not sure what it would be. But, I'm up for surprises. |
| 11:34 |
Dyrcona |
Ugh. I don't have the files there... |
| 11:35 |
Dyrcona |
I'm too hasty.. looked in the wrong place. Easy to forget ~/ on the command line. |
| 11:39 |
pinesol |
News from commits: Fix 3.13.4-3.14.0 DB upgrade script <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=e6aceb10e79596cf312fa729ff70bdfe493a6be6> |
| 11:44 |
|
redavis_reloaded joined #evergreen |
| 11:45 |
|
redavis_reloaded joined #evergreen |
| 11:47 |
Dyrcona |
Looks like something similar happened with the 3.12.0 release tarball. |
| 11:48 |
redavis_reloaded |
gross |
| 11:50 |
|
redavis joined #evergreen |
| 11:54 |
|
BDorsey__ joined #evergreen |
| 11:54 |
|
Christineb joined #evergreen |
| 11:54 |
|
BDorsey joined #evergreen |
| 11:55 |
Dyrcona |
We try to support too many different Pg versions. I'm glad that we've finally dropped 10 through 12. |
| 11:56 |
redavis |
++ |
| 11:56 |
Dyrcona |
Fortunately, the 3.13.4-3.14.0-upgrade-db.sql file is not very large. |
| 12:34 |
|
jihpringle joined #evergreen |
| 12:47 |
* Dyrcona |
signs out for a few. Gotta work call coming and then lunch. |
| 12:48 |
Bmagic |
along those same lines, the tarball and tags branch for 3.13.5 doesn't have the 3.13.3->3.13.4 upgrade script in it. I retro committed it for the rel_3_13 branch but I wasn't sure if it was prudent to update the tags branch after the tarball was already built from it |
| 14:04 |
|
Dyrcona joined #evergreen |
| 14:05 |
Dyrcona |
Bmagic: I think it's OK to update the tags branch for a missing db upgrade. |
| 14:14 |
|
Jon70 joined #evergreen |
| 14:16 |
Jon70 |
Hello! I'm at a small consortium in Maine using Evergreen. We recently switched off our ILL and then turned it back on. When we turned it back on, we are seeing potential items on title holds be limited to the number at your branch, whereas it used to be all items at all ILL locations. Any idea what setting may have caused this? |
| 14:29 |
jihpringle |
Jon70: you may need to check your Hard boundary and Soft boundary library settings |
| 14:30 |
Bmagic |
Jon70: the hold targeter might need to be ran in order for the potiential copies table to be updated. But also: I don't think that holds that were placed during the non-ILL period will be eligable for a greater number of copies unless you manually update the "selection_ou" in the table action.hold_request. New* holds that are placed after you changed the ILL settings, will likely be fine |
| 14:30 |
|
jon_knepp joined #evergreen |
| 14:30 |
jihpringle |
+1 to what Bmagic said |
| 14:31 |
|
BDorsey_ joined #evergreen |
| 14:31 |
Bmagic |
depending on what was exactly changed/done during the "switched off" period |
| 14:31 |
jihpringle |
for us holds placed when ILL is turned off only target the local items and you have to cancel and place new holds to get it to look at the wider zone |
| 14:32 |
jon_knepp |
new computer, same me! |
| 14:33 |
jon_knepp |
we had all our ILL libraries under the "library" of "Balsam ILL" and all ILL libraries as branches |
| 14:33 |
jon_knepp |
so when we shut off ILL we got rid of the library and made all the branches into libraries |
| 14:33 |
jon_knepp |
and then undid that, putting all ILL libraries as branches again under Balsam ILL |
| 14:33 |
Bmagic |
in this context, maybe the word "library" means "system"? |
| 14:35 |
Bmagic |
try running hold_targeter.pl and see if that makes a difference. If not, then the holds need canceled and re-created (unless you have direct access to the database) |
| 14:35 |
Bmagic |
also: when making dramatic changes to the org units, be sure and run autogen on all of the bricks |
| 14:37 |
|
stephengwills joined #evergreen |
| 14:43 |
|
jihpringle56 joined #evergreen |
| 14:45 |
Dyrcona |
Hrm. I think grabbing marc from bilbio.record_entry slows my query down. I wonder if it would be faster to grab the ids, then go back and get mar in a second query. |
| 14:46 |
Dyrcona |
I'm getting around 200,000 records, so the db is probably using a lot of temp space. |
| 14:48 |
Dyrcona |
Yep. It's a lot faster without the marc column. |
| 14:50 |
stephengwills |
remind me where the soft boundary gets set please? |
| 14:51 |
jihpringle56 |
stephengwills: it's a setting in Administration -> Local Administration -> Library Setting Editor |
| 14:51 |
stephengwills |
tx |
| 14:52 |
csharp_ |
we're having some trouble at the ITS level that may affect EG servers - I am (well, was) off today so I'm not aware of any specific outages, but PINES production is not working because of what appears to be a VMWare/networking issue |
| 14:52 |
csharp_ |
I'm chatting from an ITS server, so it's not everything |
| 14:57 |
Jon70 |
jihpringle56 that fixed it for stephengwills and I thx! |
| 14:58 |
jihpringle56 |
np, glad it fixed it :) |
| 14:58 |
stephengwills |
;)++ |
| 14:58 |
mmorgan |
jihpringle56++ |
| 15:02 |
|
frank_g joined #evergreen |
| 15:05 |
|
Dyrcona joined #evergreen |
| 15:06 |
Dyrcona |
Hm.. wifi flaked out on me. |
| 15:11 |
frank_g |
Hi all, we are migrating from 3.4.2v to 3.12.0v in a new EG server, and a Library Staff is testing the Staff view, but he says that the records migrated dont show the complete information in the Staff view label, He created a new record and it shows the complete information, so I tested just saving the old record (without any change), and now the |
| 15:11 |
frank_g |
record shows the complete information, My question is, Is there a Script that I have to run to upadte all records to show the complete information in Staff view label? Or the library staff has to open-save each record to update them? I hope I explain it correctly, tks |
| 15:14 |
Dyrcona |
frank_g: You are pretty much guaranteed to have to run some kind of ingest jumping over that many versions. I recommend running pingest.pl. It's installed in /openils/bin. |
| 15:17 |
Dyrcona |
I bet the library kicked me off the wifi for going over a data cap. :) |
| 15:21 |
Dyrcona |
Good thing Verizon doesn't care, so long as I pay my bill. |
| 15:30 |
|
Jon10 joined #evergreen |
| 15:33 |
frank_g |
Dyrcona: Do you have an example of how to run a complete ingest with the pingest.pl? |
| 15:39 |
Dyrcona |
frank_g: just `pingest.pl` will do it if the defaults are ok. Depending on circumstances, you might need to specify the database connection parameters, they are the same as psql's. Using `-b 1000` as an option often speeds it up as the default batch size of 10,000 seems too high for most systems. |
| 15:39 |
Dyrcona |
Depending on the number of cores on your database you might want to set `--max-child` to less than the default of 8, but the default usually works for me. |
| 15:42 |
Dyrcona |
The script itself has pretty good help: `pingest.pl --help` |
| 16:01 |
|
dbriem joined #evergreen |
| 16:07 |
|
jihpringle joined #evergreen |
| 16:15 |
Dyrcona |
After running this program to check for properly coded government documents, I realize that I could modify it to check all of our records for valid length 006 and 008 fields. These are too short on some of our older records. |
| 16:27 |
Dyrcona |
Well, they're going to kick us out of here in a few minutes, and they seemed a little surly last week when I took time to wrap up my stuff so I could put the laptop away properly. |
| 16:28 |
Dyrcona |
Talk to y'all later! |
| 16:38 |
|
stephengwills left #evergreen |
| 16:50 |
dbriem |
i'm getting random 404s for seemingly unrelated methods on a new build of main on ubuntu 22.04. services are running, config seems ok, and logs aren't pointing to anything yet, but i'm just throwing this out there in case anyone else did a new build and is seeing the same thing. for example: circ.open_non_cataloged_circulation.user.authoritative |
| 16:50 |
dbriem |
and search.staff.location_groups_with_lassos are returning 404 |
| 16:52 |
dbriem |
as soon as i hit enter, i just realized some of the Perl modules didn't compile...it seems like Email::Send is the culprit |
| 16:57 |
mmorgan |
dbriem: Bmagic and Dyrcona were chatting about that issue, http://irc.evergreen-ils.org/evergreen/2024-10-24#i_564594 |
| 16:58 |
Bmagic |
I was about to bring that exact issue up right now |
| 16:58 |
Bmagic |
I'm struggling to get Evergreen to install from scratch, and again, I think I've tracked it back to this perl issue |
| 16:58 |
dbriem |
mmorgan thanks |
| 16:58 |
Bmagic |
it's not just Email::Send that isn't getting installed |
| 16:58 |
dbriem |
yeah it has a dependency that's has failing tests |
| 16:59 |
Bmagic |
Email::Abstract isn't making it either |
| 17:01 |
Bmagic |
I'm checking to see if I can get a system up and running without having to install from cpan |
| 17:02 |
dbriem |
if i install Module::Pluggable directly, then Email::Send installs through cpan for me |
| 17:03 |
Bmagic |
and which method did you use to install Module::Pluggable ? |
| 17:04 |
|
mmorgan left #evergreen |
| 17:04 |
dbriem |
https://github.com/simonwistow/Module-Pluggable/issues/27 |
| 17:05 |
Bmagic |
!!, 14 hours ago |
| 17:10 |
Bmagic |
apt-get install libmodule-pluggable-perl fixed it for me |
| 17:22 |
Bmagic |
Submitted a patch for it: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/blake/install_pluggable_dependency |
| 17:22 |
Bmagic |
how annoying |
| 17:24 |
Bmagic |
that patch is really just for me and anyone else who's intersted, there's no LP yet, and it's just for jammy. I've not explored any of the other supported OSes. And it might just be for docker installs. I'm holding out hope that it will be resolved on the cpan side and we won't have to do anything for real |
| 17:41 |
dbriem |
i used the ansible installer (by the way, thank you berick for that, it's awesome) and ran into the same issue, hopefully Module::Pluggable can address that test. in the meantime i have your patch, thanks. |
