| Time |
Nick |
Message |
| 00:49 |
|
JBoyer joined #evergreen |
| 00:49 |
|
jonadab joined #evergreen |
| 00:55 |
|
miker joined #evergreen |
| 00:55 |
|
Bmagic joined #evergreen |
| 00:55 |
|
bshum joined #evergreen |
| 00:55 |
|
abneiman joined #evergreen |
| 00:56 |
|
pastebot joined #evergreen |
| 01:00 |
|
berick joined #evergreen |
| 01:48 |
|
bshum joined #evergreen |
| 04:29 |
|
ejk_ joined #evergreen |
| 04:29 |
|
degraafk joined #evergreen |
| 04:32 |
|
Christineb joined #evergreen |
| 04:42 |
|
troy joined #evergreen |
| 04:42 |
|
jeffdavis joined #evergreen |
| 04:44 |
|
eby joined #evergreen |
| 06:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:46 |
|
collum joined #evergreen |
| 07:23 |
|
rjackson_isl_hom joined #evergreen |
| 08:37 |
|
mmorgan joined #evergreen |
| 08:56 |
|
mantis joined #evergreen |
| 09:10 |
|
rfrasur joined #evergreen |
| 09:25 |
mantis |
Follow up for those interested in the locker situation |
| 09:26 |
mantis |
We had one company Smiota that offered curbside pickup lockers but required all patron information in completion. One of our directors reached out to the company to see if there was a way just to pull information on patrons who had current holds and apparently that wasn't possible. |
| 09:27 |
mantis |
I haven't heard anything about the other company (the name escapes me) but I can't imagine it'd be any different. |
| 09:31 |
mantis |
For now they want to continue using the lockers because they already purchased it, but patrons need to register through the Smiosta system individually outside of placing holds in Evergreen. |
| 09:32 |
|
jvwoolf joined #evergreen |
| 09:40 |
|
Keith-isl joined #evergreen |
| 09:40 |
Bmagic |
mantis: bummer |
| 09:43 |
mantis |
Bmagic: I feel bad that they already bought those lockers |
| 09:43 |
Bmagic |
I thought they worked over SIP |
| 09:49 |
|
Dyrcona joined #evergreen |
| 09:52 |
|
jvwoolf joined #evergreen |
| 09:55 |
|
jvwoolf1 joined #evergreen |
| 09:59 |
Dyrcona |
So, I'm "off" today but have some Evergreen related stuff to work on. I thought that I'd add the prerequisite installation for new PostgreSQL versions to my branch. Along the way, I'm considering changing the prereqs to install postgresql-client-14. |
| 10:01 |
Bmagic |
Dyrcona++ # you get all* the karma |
| 10:01 |
jeff |
Why postgresql-client-14? |
| 10:03 |
jeff |
Would you also move to require PGDG repos for PostgreSQL packages? |
| 10:03 |
Dyrcona |
jeff: Because it works with all current releases of PostgreSQL server. If we continue to use postgresql-client-9.6, then you can't even inspect tables if 14 is installed on the server. |
| 10:03 |
Dyrcona |
jeff: We already do require PGDG repos for the two distros that we support. |
| 10:04 |
jeff |
for all OpenSRF connected hosts, or just for the database server? Maybe I missed that change. |
| 10:04 |
Dyrcona |
It's required in Evergreen. OpenSRF doesn't install Pg. |
| 10:05 |
jeff |
rephrasing: |
| 10:05 |
jeff |
for all OpenSRF connected hosts in an Evergreen system, or just for the database server? Maybe I missed that change. |
| 10:05 |
Dyrcona |
You can't install postgresql-client-9.6 if it isn't there, so yes, it is part of the base Make targets. |
| 10:08 |
Dyrcona |
It's under the "all" target which is run when you do the distro-specific target, i.e. ubuntu-bionic, debian-stretch, etc. |
| 10:09 |
jeff |
yep, I see it now. |
| 10:09 |
Dyrcona |
Also, I wanted to ask if it would be OK to role in removal of Debian Stretch targets into this same branch? bug 1947728. This would avoid duplication of work. |
| 10:09 |
pinesol |
Launchpad bug 1947728 in OpenSRF "Discontinue Support for Debian 9 "Stretch"" [Undecided,New] https://launchpad.net/bugs/1947728 |
| 10:10 |
Dyrcona |
I guess that should have been "roll in" not "role in." :) |
| 10:17 |
Dyrcona |
I've already based this branch off of the branch for bug 1947595, so what's another one? Squash 3 bugs in one branch.... |
| 10:17 |
pinesol |
Launchpad bug 1947595 in Evergreen "array_accum Aggregate and PostgreSQL 14" [Undecided,New] https://launchpad.net/bugs/1947595 |
| 10:23 |
Dyrcona |
I'm also working on tests and release notes for bug 1883171 and bug 1940663. I'm not sure which I'll get to first. |
| 10:23 |
pinesol |
Launchpad bug 1883171 in Evergreen "duplicate entries for a copy in asset.latest_inventory table" [Undecided,In progress] https://launchpad.net/bugs/1883171 - Assigned to Jason Stephenson (jstephenson) |
| 10:23 |
pinesol |
Launchpad bug 1940663 in Evergreen "Inventory: Staff users can update inventory dates on non-owned items" [Undecided,In progress] https://launchpad.net/bugs/1940663 - Assigned to Jason Stephenson (jstephenson) |
| 10:26 |
csharp_ |
Dyrcona++ |
| 10:41 |
jeff |
There doesn't seem to be a tag for OpenSRF 3.2.2. It looks like commit 17afac36 matches the tarball, and I'd expect there to be an osrf_rel_3_2_2 tag. |
| 10:41 |
pinesol |
jeff: [opensrf|Galen Charlton] update ChangeLog for 3.2.2 - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=17afac3> |
| 10:45 |
rfrasur |
Hello friends. I'm here as the sacrificial lamb to ask if the inability to select multiple holds from the angular "place holds" interface was something that was overlooked or a purpose-driven design choice? Is there an alternate workflow? We're working with 3.7.1. |
| 10:49 |
csharp_ |
rfrasur: can you provide specifics about how to get there? trying to see if that's something we can confirm here |
| 10:49 |
Dyrcona |
jeff: I think that was mentioned before, probably in the release channel. You should be able to tag it, or I could, or gmcharlt should because he released the tarball. |
| 10:54 |
jeff |
OpenSRF prerequisite installer fails on Debian 11, because it's still trying to install Python 2 packages (which don't exist in Debian 11 (bullseye)). Opened bug 1951850 |
| 10:54 |
pinesol |
Launchpad bug 1951850 in OpenSRF "Prerequisite installation fails for debian-bullseye" [Undecided,New] https://launchpad.net/bugs/1951850 |
| 10:55 |
mmorgan |
rfrasur: Is this the workflow: Search for a title, click Place Hold, and select a number of copies on the Place Hold screen? |
| 10:55 |
jeff |
Simplest fix is probably to cut a release with the "remove Python" changes, but I don't know if that was waiting for 3.3 and we want to fix 3.2 or not. |
| 10:58 |
mmorgan |
rfrasur: If so, that should be fixed as of 3.6.2: bug 1889128 |
| 10:58 |
pinesol |
Launchpad bug 1889128 in Evergreen "Angular Staff Catalog: Place Another Hold & Multi-Holds" [High,Fix released] https://launchpad.net/bugs/1889128 |
| 10:59 |
mmorgan |
I am able to select a number of copies when placing a hold on our 3.7.2 test system. |
| 11:00 |
rfrasur |
mmorgan, can you screen shot and send to me? |
| 11:01 |
Dyrcona |
jeff: I'm not sure I encountered that, or if I also had the remove Python branch when I installed on Debian 11. |
| 11:03 |
rfrasur |
csharp_, the workflow is go to record, click to place title hold, in the traditional catalog place holds, there's a drop down to select a number of items (that defaults to one). There is no such thing (that I'm seeing) in the angular place holds. |
| 11:04 |
rfrasur |
Unless there's a setting we're missing. Reading through all the stuff. |
| 11:08 |
berick |
rfrasur: there is a setting.. |
| 11:09 |
mmorgan |
circ.holds.max_duplicate_holds |
| 11:09 |
Dyrcona |
jeff: I think your master branch is out of date. |
| 11:09 |
Keith-isl |
We have Maximum number of duplicate holds allowed in Org Unit Settings set to 20 |
| 11:09 |
Keith-isl |
I think that's circ.holds.max_duplicate_holds ? |
| 11:09 |
jeff |
Dyrcona: oh? |
| 11:09 |
rfrasur |
Okay, we dealt with that permission. Checking it out. Might be something that requires a hard reload |
| 11:10 |
berick |
rfrasur: org unit settings are cached per login |
| 11:10 |
berick |
logout/in may be needed |
| 11:10 |
Keith-isl |
++ |
| 11:10 |
jeff |
Dyrcona: just added a comment: (forgot to specify: affects OpenSRF 3.2.2 / rel_3_2 branch) |
| 11:11 |
Dyrcona |
jeff: The Python removal code shows up in master before the support for Debian 11 is added. |
| 11:11 |
mmorgan |
rfrasur: Will grab a screenshot, but I do notice that the "Number of copies" selector doesn't appear until I enter the patron's barcode. |
| 11:11 |
rfrasur |
Okay. testing. |
| 11:11 |
Dyrcona |
Well, sure, 3.2 is behind, and we should have a 3.3 release in my opinion. I mostly just use master. |
| 11:11 |
jeff |
Dyrcona: the changes in bug 1827055 haven't made it to a release yet. |
| 11:11 |
pinesol |
Launchpad bug 1827055 in OpenSRF "Python binding for OpenSRF and Evergreen" [Medium,Fix committed] https://launchpad.net/bugs/1827055 |
| 11:12 |
Dyrcona |
Just use OpenSRF master. It works with all relevant Evergreen releases. |
| 11:12 |
rfrasur |
There it is! Thanks everyone! |
| 11:13 |
jeff |
also, and I'm not sure what the intent is so I'm not sure what to suggest: https://evergreen-ils.org/egdownloads/ has OpenSRF 3.2.2 listed for Evergreen 3.6 and Evergreen 3.7, and OpenSRF 3.2.1 for Evergreen 3.8... but all the links are to OpenSRF 3.2.1 :-) |
| 11:13 |
Dyrcona |
But, yeah, maybe it should be ported to 3.2 if 3.2 has support for Bullseye. |
| 11:13 |
Keith-isl |
csharp++ berick++ |
| 11:13 |
Keith-isl |
Thank you! |
| 11:14 |
mmorgan |
rfrasur: https://www.screencast.com/t/Xfaj0k4u |
| 11:14 |
Dyrcona |
jeff: Mistakes happen, and it would be nice to have more than 3 or 4 people involved in most releases, though I think OpenSRF 3.2.2 was gmcharlt all on his own. (Not knocking gmcharlt, just pointing out that more involvement would be helpful.) |
| 11:15 |
Dyrcona |
I'm of the opinion that our active development group is too small for monthly bug fixes and tarballs. I'm inclined to just put branches in git and say, check it out from git if you want the latest. |
| 11:16 |
jeff |
Dyrcona: certainly. I worry that I'm coming across as critical or looking to place blame. That was not my intent. |
| 11:18 |
Dyrcona |
jeff: I understand. I probably also sound like I'm complaining. I think we're at a point where we either get more people involved or we lower expectations as regards releases. |
| 11:22 |
Keith-isl |
(Also mmorgan++) |
| 11:23 |
rfrasur |
mmorgan++ csharp_++ berick++ |
| 11:29 |
jeff |
pushed tag for osrf_rel_3_2_2 |
| 11:30 |
Dyrcona |
jeff++ Did you sign it? I think gmcharlt was signing OpenSRF tags, but I could be mistaken. |
| 11:31 |
jeff |
well NOW you mention that... yes, I can clearly see now that the previous tag was signed. |
| 11:31 |
Dyrcona |
I don't think it's all that important. |
| 11:51 |
|
alynn26 joined #evergreen |
| 11:52 |
Dyrcona |
jeff: There's nothing, other than the ire of the other developers, stopping you and I from making an OpenSRF rel_3_3 branch and even releasing 3.3.0. |
| 11:54 |
* csharp_ |
revs up for serious ire |
| 11:55 |
Dyrcona |
:) |
| 11:56 |
* alynn26 |
with csharp_ |
| 11:59 |
Dyrcona |
I'm going to add backporting the removal of Python to OpenSRF 3.2 to the developers' meeting agenda, or possibly releasing 3.3. |
| 12:00 |
Dyrcona |
Remoing stretch and python would make a decent reason to release 3.3. |
| 12:00 |
Dyrcona |
But first, lunch! |
| 12:00 |
jeff |
removing stretch might be... a stretch? it's LTS until next June, I think. |
| 12:01 |
jeff |
(or do we limit ourselves to only supporting stable and oldstable?) |
| 12:12 |
|
jihpringle joined #evergreen |
| 12:31 |
Dyrcona |
jeff: We don't have a policy, but what has typically happened is we end up supporting two Ubuntu LTS releases and 3 Debian releases. In this case, since Stretch goes EOL just a couple of months after our next release, I think we should go ahead and remove it for the upcoming release. |
| 12:34 |
|
collum joined #evergreen |
| 12:34 |
jeff |
it's more reasonable now that I've taken a moment to think it through, and remember that it doesn't mean that stretch stops working for someone using it already. new stretch deployments at this time would be ill-advised. :-) |
| 12:38 |
Dyrcona |
Right. |
| 12:38 |
Dyrcona |
We tend to get pretty close to Ubuntu LTS release dates for the spring release. |
| 12:39 |
Dyrcona |
Debian declares a release when "it's done." |
| 12:44 |
|
collum joined #evergreen |
| 13:56 |
|
jihpringle joined #evergreen |
| 14:16 |
csharp_ |
mood: https://morbotron.com/video/S07E02/arYComXwV1rJWOrwyKWFSE33ZY8=.gif |
| 14:17 |
Dyrcona |
Yeah, I'm fizzling out after lunch. |
| 14:17 |
berick |
heh |
| 14:19 |
berick |
you need to https://morbotron.com/gif/S03E13/538470/542641/ |
| 14:36 |
csharp_ |
berick++ |
| 14:37 |
Dyrcona |
:) |
| 14:52 |
|
csharp_ joined #evergreen |
| 16:00 |
|
jvwoolf joined #evergreen |
| 16:33 |
|
jvwoolf left #evergreen |
| 17:10 |
|
mmorgan left #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
