| Time |
Nick |
Message |
| 01:27 |
pinesol |
News from commits: LP1956626 Copy editor loads all needed copy locations <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=ab5478b879e9e34a6fe023c188c7a95c11c425ca> |
| 01:57 |
pinesol |
News from commits: LP#1965317 Barcode Completion on Traditional Cat Staff Holds <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=3663817ec8c975d09150fef4c578e1fbd7ae0312> |
| 04:36 |
|
gmcharlt joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live//archive/2022-04/2022-04-20_04:00:04/test.49.html> |
| 06:53 |
|
Dyrcona joined #evergreen |
| 07:16 |
|
rjackson_isl_hom joined #evergreen |
| 07:47 |
|
RFrasur joined #evergreen |
| 08:23 |
|
mantis joined #evergreen |
| 08:35 |
|
mmorgan joined #evergreen |
| 09:02 |
|
jvwoolf joined #evergreen |
| 09:03 |
|
collum joined #evergreen |
| 09:45 |
|
mantis joined #evergreen |
| 09:45 |
|
mdriscoll joined #evergreen |
| 09:54 |
Dyrcona |
We have reports of users getting the Welcome to Webby or a "white screen" on some computers when going to the new Angular staff catalog. One library reported that rebooting their computer fixed it. Has anyone else seen this and have ideas? I have done a cursory check to make sure that the Angular files are installed on all of the brick heads. |
| 09:55 |
|
collum joined #evergreen |
| 09:57 |
eeevil |
Dyrcona: they've bookmarked https://host.example.com/eg2/ (or similar, lacking staff/ at the end) |
| 10:06 |
Dyrcona |
eeevil: Could be. Although one ticket says, "When I go to 'Search the Catalog' I get this:" with a screenshot showing the blank screen. |
| 10:06 |
Dyrcona |
However the location bar shows .../eg2/en-US/ |
| 10:06 |
RFrasur |
Dyrcona, which browser? |
| 10:07 |
Dyrcona |
RFrasur: Screenshot looks like Chrome. |
| 10:09 |
* mmorgan |
remembers seeing this a few times, but can't remember/never figured out the exact circumstances. |
| 10:09 |
mmorgan |
Dyrcona: Have they cleared cache? |
| 10:10 |
RFrasur |
This is likely not related, but throwing it on the heap of possibility. The most recent Chrome update caused some website search results (not EG, that I've experienced) have been borked. The last time I saw it with EG, it seems like there was something missing with an apache config/setting/file. |
| 10:10 |
RFrasur |
hmm, ruth no sentence much. |
| 10:10 |
RFrasur |
The most recent Chrome update caused some website search results to bork for me. |
| 10:15 |
eeevil |
Dyrcona: the key is there's no "staff" part of the path in where they're going, however they're getting there |
| 10:16 |
Dyrcona |
RFrasur: Noted. mmorgan: I think so. eeevil: Yeahp. |
| 10:17 |
* eeevil |
wonders if "when I go to 'search the catalog'" they mean "when I click on my bookmark labeled thus which used to bring me to the "traditional" in-staff-client catalog wrapping frame" |
| 10:18 |
* Dyrcona |
has no idea. |
| 10:19 |
Dyrcona |
I just thought someone had seen this and it was something beyond the obvious things. |
| 10:19 |
Dyrcona |
Should be a maybe in there somewhere. |
| 10:19 |
eeevil |
Dyrcona: unrelated, I agree with pushing the fix from LP 1965317 back to 3.7 ... I hope 3.7.3 ends up happening |
| 10:19 |
* mmorgan |
has seen it in the past, but not recently |
| 10:19 |
pinesol |
Launchpad bug 1965317 in Evergreen "Internal Server Error when Staff Places Hold in Traditional Catalog using Patron Barcode Completion" [High,Fix committed] https://launchpad.net/bugs/1965317 |
| 10:20 |
* mmorgan |
doesn't use bookmarks, but often closes browser without logging out, and with tabs open :-/ |
| 10:23 |
Dyrcona |
I'm going to assume they're using a bookmark since clearing cache didn't help. I've added a not to our internal ticket to ask if they're using bookmarks at the library. |
| 10:23 |
Dyrcona |
eeevil++ RFrasur++ mmorgan++ |
| 10:24 |
Dyrcona |
eeevil: On the Lp bug, OK. I'll backport it to 3.7. |
| 10:25 |
JBoyer |
I don't know if I have time today but also +1 to 3.7.3 and backporting anything sensible. I know there were at least one or two bugs that weren't backported for lack of series targets, but those aren't always the best indcators. |
| 10:26 |
Dyrcona |
Well, if it could coincide with 3.9.0 general release that would work for me. I think release notes are our biggest obstacle. |
| 10:26 |
berick |
Dyrcona: if it's a bookmark, it could be https://bugs.launchpad.net/evergreen/+bug/1967532 |
| 10:26 |
pinesol |
Launchpad bug 1967532 in Evergreen "Opening browser client from desktop link sometimes fails to connect to Hatch" [Undecided,New] - Assigned to Bill Erickson (berick) |
| 10:27 |
Dyrcona |
Back to Webby: FWIW, they have an Evergreen bookmark in the bookmars bar, but not a "Search the Catalog" bookmark that I can see in the screenshot. |
| 10:27 |
berick |
oops, i meant to say desktop link, not bookmark |
| 10:27 |
Dyrcona |
berick: Yeah, I've also suggested that we find out if they're using Hatch. |
| 10:29 |
|
rjackson_isl_hom joined #evergreen |
| 10:34 |
|
rjackson_isl_hom joined #evergreen |
| 10:35 |
|
sandbergja joined #evergreen |
| 10:36 |
sandbergja |
Re: release notes being a release barrier: bug 1948674 has a perl script that will draft the release notes for you |
| 10:36 |
pinesol |
Launchpad bug 1948674 in Evergreen "Improve release building automation" [Undecided,New] https://launchpad.net/bugs/1948674 |
| 10:37 |
sandbergja |
Also, going along with the "get our act together as a community" theme, both github and gitlab have good automation around building releases, including (at least for Github, not sure about gitlab) automatically drafting the release notes for you... |
| 10:38 |
* Dyrcona |
wonders if our process is too complex for Github or Gitlab to handle. I've never tried. |
| 10:39 |
Dyrcona |
It is a good suggestion. We should really figure out (finally) what we're doing with git and releases, etc. |
| 10:39 |
Dyrcona |
sandbergja++ |
| 10:39 |
berick |
sandbergja++ |
| 10:45 |
sandbergja |
Dyrcona: I've wondered the same thing. I wonder if we had a proof-of-concept in either/both of the platforms, it would help in making the decision |
| 10:46 |
sandbergja |
^if it would help |
| 10:49 |
Dyrcona |
Yeah, it probably would help. |
| 11:25 |
Dyrcona |
We have found a common thread on the white screen/webby thing. The staff accounts were missing a working location. |
| 11:26 |
Dyrcona |
Resolving that seems to have resolved the white screens. |
| 11:43 |
|
mantis joined #evergreen |
| 11:43 |
berick |
Dyrcona: *sigh* I've been meaning to fix that so it's more obvious what the problem is. if you open an LP i'll post a fix |
| 12:06 |
Dyrcona |
berick: John Amundson reported it: https://bugs.launchpad.net/evergreen/+bug/1969641 |
| 12:06 |
pinesol |
Launchpad bug 1969641 in Evergreen "Missing Working Location Causes Angular Staff Catalog Not to Display" [Undecided,New] |
| 12:07 |
berick |
nice, thanks |
| 12:11 |
Dyrcona |
berick++ |
| 12:16 |
|
jihpringle joined #evergreen |
| 12:17 |
jeff |
tempting to fail staff login when no working locations are set. |
| 12:18 |
jeff |
but then you'd have to either set a working location for some things like SIP client users, or you'd need to create a perm for "allow staff login with no working location", or... |
| 12:19 |
jeff |
(not going to look right now, but there are a few other threads to pull at there also) |
| 12:20 |
Dyrcona |
jeff: After you tug on all the threads, your sweater turns into a ball of yarn. :) |
| 12:21 |
berick |
jeff: they fail now, my plan was to continue failing, but with a more useful message |
| 12:21 |
berick |
or do you mean on that back-end side? |
| 12:22 |
Dyrcona |
I assumed jeff meant the back-end, since he mentioned SIP. |
| 12:22 |
jeff |
berick: I meant have open-ils.auth fail staff logins when no working location is set. :-) |
| 12:22 |
jeff |
(and I was only half-serious) |
| 12:22 |
* berick |
nods |
| 12:24 |
jeff |
maybe start with logging a warning and providing a recommended query for identifying affected accounts (which I expect a lot of sites have already run a time or two) |
| 12:24 |
jeff |
I'm pretty sure no working location set has resulted in a failure of the patron edit interface loading for... many years now. |
| 12:26 |
|
RFrasur_ joined #evergreen |
| 12:34 |
JBoyer |
sandbergja++ |
| 12:35 |
JBoyer |
In reference to our release process being too complicated for GH/GL/CI/ETCBBQ I would say that's cause to alter the process rather than sweat the tools. (Though I suspect a properly constructed "action" on whatever platform could get 80%+ of the way there today) |
| 12:36 |
Dyrcona |
Well, part of altering the process would be to use the tools better. :) |
| 12:37 |
JBoyer |
Some smarts around upgrade scripts (i.e. "this chunk must be outside a transaction / could fail but that's ok / etc.) may be required to really simplify releases. Humans may miss that aspect of things, but they can today, so... |
| 12:39 |
berick |
yeah, i imagine some human-driven commits would still be needed before auto-release-building could take it home. |
| 12:39 |
JBoyer |
Dyrcona, that's pretty much what I mean; if we want to use GH but it can't handle our release processes then maybe we need to change the process to better use the tool. :) |
| 12:40 |
JBoyer |
berick, and since we'd want some kind of trigger anyway (since every commit need not be a release) that's a place that a few special instructions could be rather than a very large pile of instructions for the whole process. |
| 12:40 |
Dyrcona |
Well, we should make it more difficult for patches to alter the schema, i.e no schema changes in patch/bugfix releases. |
| 12:41 |
Dyrcona |
You pretty much only detect the conflicts with transactions by testing the db upgrade. I assume everyone does that, right? |
| 12:43 |
JBoyer |
Which brings to mind something I've thought about but had no time to really pursue: git hooks that run scripts to do things like run xlst to verify the IDL, try to alert you if you're pushing an upgrade script with an ALTER TABLE, etc. Having a hook automatically run a full (not live, I suppose) make check before pushing to origin, etc. Lots of ideas, not a lot of time. |
| 12:44 |
JBoyer |
Dyrcona, yeah, though there may be things you know you don't want in an xact (hello reingests) and some kind of barrier comment ( like a -- NOXACT -- in the sql file) could push those to the end of a generated point release file. |
| 12:48 |
Dyrcona |
I split the db upgrade code out of make_release some time ago because I find it useful CWMARS upgrades because we're always backporting things: https://gist.github.com/Dyrcona/00bd6b6290b6fbbb579c7f93b360ab0d |
| 12:48 |
Dyrcona |
We probably ought to split it out for real. |
| 12:50 |
Dyrcona |
I'm also not opposed to dropping release tarballs and just tagging release in git. |
| 12:51 |
Dyrcona |
Maybe we should do a survey to see who actually uses the tarball for upgrades, etc. |
| 12:51 |
JBoyer |
I'd want to find a way to make some tool auto-generate them in that case. Some people just like having a link to a tarball. (And they tend to be a lot smaller than a git clone unless you use --depth, and we want to make it *easier* for people to use, etc. :) ) |
| 12:53 |
Dyrcona |
Fixing our autoconf mess would get us a lot closer. In a properly autoconfiscated project, you can type `make release` and get a tarball. |
| 12:57 |
sandbergja |
Dyrcona: could you say more about the autoconf mess? I've never looked very closely at that part of the build process. |
| 13:00 |
Dyrcona |
I'm not exactly an autoconf expert, but from what I can tell, we're doing it almost completely wrong. :) |
| 13:00 |
sandbergja |
::facepalm:: |
| 13:01 |
sandbergja |
I love it :-) |
| 13:03 |
Dyrcona |
I'll give a few examples: we're using sed in places that autosubst variables work just fine, we're manaully copying files (whole directories including Makefiles) when install targets with the files listed are better, we're installing things at the wrong stages, i.e. config being installed as bin_SCRIPTS, we're also "building" some code/doing substitutions during the INSTALL step and not the usual "make" time. |
| 13:05 |
JBoyer |
I do especially dislike that last one, since that means some files are owned by root and you can no longer run git clean without sudo. (Also, make clean could be more similar to git clean than it is today) |
| 13:07 |
Dyrcona |
Jobyer: I always do `sudo chown -R opensrf:opensrf /openils ./` after make install. |
| 13:09 |
JBoyer |
That's one way to do it too, yeah. |
| 13:12 |
Dyrcona |
Also, when testing Evergreen on Ubuntu 22.04, I get a whole new set of messages from autotools about deprecation, etc. I haven't had time to really bang on it, yet. |
| 13:30 |
|
rfrasur joined #evergreen |
| 13:30 |
|
RFrasur__ joined #evergreen |
| 14:16 |
|
rjackson_isl_hom joined #evergreen |
| 15:21 |
|
RFrasur joined #evergreen |
| 16:29 |
|
jvwoolf left #evergreen |
| 16:41 |
|
abowling joined #evergreen |
| 17:00 |
|
jihpringle joined #evergreen |
| 17:12 |
|
mmorgan left #evergreen |
| 17:46 |
* eeevil |
thinks he just read that he needn't create an RC tarball! (j/k, I will be doing that this evening) |
| 17:46 |
miker |
my nick swapped back to eeevil at an appropriate time, at least |
| 18:00 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live//archive/2022-04/2022-04-20_16:00:03/test.49.html> |
