| 12:01 |
Dyrcona |
It can't download to gvfs mounted location. |
| 12:03 |
Dyrcona |
I may have to seriously consider switching distros. |
| 12:24 |
Dyrcona |
Maybe I'll switch back to FreeBSD on the desk....erm laptop? |
| 12:33 |
Dyrcona |
3.9.4 is basically ready. I need to test it. |
| 12:38 |
Dyrcona |
Heh, Listening to Def Leppard while doing this takes me back to when I first started programming on Commodore and Apple computers.... |
| 12:42 |
Dyrcona |
@decide new vm or focal |
| 12:42 |
pinesol |
Dyrcona: go with new vm |
| 12:43 |
Dyrcona |
Thanks for your opinion, pinesol, but I'm going to override that answer. :) |
| 13:18 |
* Dyrcona |
wonders if some of our tests still depend on undefined behavior. I find that live_t/29-lp1817645-remoteauth-patron-api.t seems to fail and then succeed later. |
| 13:19 |
Dyrcona |
Hmm cover uploader failed, too. I ran autogen.sh..... |
| 13:20 |
Dyrcona |
Pretty sure that I restarted apache2... I'll try again. |
| 13:26 |
Dyrcona |
Nope: Failed test 'Basic request for external user correctly returned 403' at live_t/29-lp1817645-remoteauth-patron-api.t line 137. got: '502' expected: '403' |
| 13:27 |
Dyrcona |
So, nginx or apache config is botched? |
| 13:29 |
Dyrcona |
OK. figured it out. |
| 13:31 |
Dyrcona |
Forgot to change the ports in the eg.conf VirtualHost entries. |
| 13:35 |
Dyrcona |
I think we neglect the Apache ports in the configuration instructions. |
| 13:38 |
Dyrcona |
And, live_t/30-lp1508208-age-protect-hold-capture.t fails on me for like the first time ever. |
| 13:38 |
* Dyrcona |
mumbles something about Micky Mouse. |
| 13:41 |
Dyrcona |
Meh. Feels like I'm the only one who runs all the tests for releases. I'll "release" it anyway. |
| 14:34 |
|
Dyrcona joined #evergreen |
| 14:35 |
Dyrcona |
So I guess things are missing from the 3.9.4 release notes because things were backported that should not have been. If someone else wants to fix the release notes, feel free. I'm done. |
| 16:30 |
|
sleary joined #evergreen |
| 10:54 |
|
jvwoolf left #evergreen |
| 10:57 |
|
sandbergja joined #evergreen |
| 11:01 |
|
sandbergja joined #evergreen |
| 11:09 |
Bmagic |
testing 3.10.3 tarball |
| 11:36 |
Bmagic |
test is good, making 3.11 now |
| 11:41 |
sandbergja |
Bmagic++ |
| 11:46 |
|
terranm joined #evergreen |
| 11:53 |
sharpsie |
Bmagic++ |
| 12:40 |
sharpsie |
well now you have to admit it! |
| 12:40 |
* mmorgan |
was thinking the same thing! |
| 12:41 |
Dyrcona |
I overwrote the authorized_keys file for a user on a server, but I can probably just copy another user's file on top of it. |
| 12:42 |
sharpsie |
this one time, I removed /usr from a running server - that was a fun test of our backup capabilities |
| 12:43 |
berick |
this one time... in band camp... |
| 12:43 |
sharpsie |
berick: almost said that |
| 12:43 |
sharpsie |
their band camp sounds way more fun that ours was IRL |
| 12:49 |
sharpsie |
Dyrcona++ |
| 12:49 |
Dyrcona |
I was being clever and doing a keyscan on a new host for a vendor, and I redirected the output to the wrong file. |
| 12:50 |
sharpsie |
in other news, joining the MS-ISAC alert lists has made me very glad I'm not administering big proprietary things like Citrix stuff |
| 12:51 |
Bmagic |
testing 3.11.1 |
| 13:19 |
Bmagic |
3.11.11 good, publishing on our site |
| 13:29 |
Bmagic |
ok yall, new tarballs for 3.10.3 and 3.11.1 are on the page, complete with release notes and changelog and readme's. The last step would be to commit the tag branches to the main repo: collab/blake/tags/rel_3_11_1 and collab/blake/tags/rel_3_10_3 . Anyone around to evaluate/push those? |
| 13:31 |
Dyrcona |
Bmagic++ |
| 13:41 |
Dyrcona |
I'll take a look at the tag branches. |
| 13:49 |
Dyrcona |
Has anyone done a release announcement? |
| 14:02 |
terranm |
Trying to wrap my head around the basic concept of creating a new table (student_card.school) that can be edited from the server admin page. I have a script to create it and I've added it to the fieldmapper (class id="scs") and it's appearing, but when I navigate to the page I get an error with this in the logs: "Method [open-ils.pcrud.search.scs] |
| 14:02 |
terranm |
not found for service open-ils.pcrud" -- any thoughts? My test code is here: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=56ae78eed93c8dbe7040db543d75e796a1d3737f |
| 14:05 |
Dyrcona |
terranm: I'm pretty sure that an object with a pcrud controller needs a permacrud block, even if it is mostly empty. |
| 14:06 |
terranm |
Ooooh, thanks I'll try that! |
| 14:13 |
terranm |
Dyrcona++ that solved that error, thanks! |
| 08:29 |
|
mmorgan joined #evergreen |
| 08:53 |
|
kworstell-isl joined #evergreen |
| 08:55 |
|
sandbergja joined #evergreen |
| 08:59 |
mantis |
Morning. Tried to start a reingest on our test server with 3.11 installed and got back an error. https://pastebin.com/Kv6tHz4m |
| 08:59 |
mantis |
any advice appreciated |
| 09:00 |
mantis |
ERROR: index row size 3136 exceeds maximum 2712 for index "browse_entry_sort_value_value_key" HINT: Values larger than 1/3 of a buffer page cannot be indexed. Consider a function index of an MD5 hash of the value, or use full text indexi |
| 09:08 |
|
sandbergja joined #evergreen |
| 09:16 |
|
rfrasur joined #evergreen |
| 10:51 |
sharpsie |
so, yeah, the same |
| 10:54 |
sharpsie |
argh - I hate when there's no record of changes - apparently whatever that index is was added out-of-band |
| 10:54 |
mantis |
alright at least we know that |
| 10:55 |
sharpsie |
mantis: nevertheless, eeevil's suggestion should help - basically it's saying "however long the actual value is, truncate it after 1000 chars" |
| 10:56 |
sharpsie |
mantis: is this in a test environment or live? |
| 10:56 |
mantis |
test environment |
| 10:56 |
sharpsie |
good :-) |
| 10:58 |
mantis |
haha |
| 10:58 |
sharpsie |
in a test environment that no one else depends on, you can be cavalier |
| 10:59 |
sharpsie |
the "safe" way to create/drop indexes on a live server is usually to create the new index with "concurrently" which doesn't lock the table and make everyone miserable |
| 11:00 |
sharpsie |
then drop the "old" index (again, with "concurrently") |
| 11:02 |
sharpsie |
in this case though, you can DROP INDEX CONCURRENTLY browse_entry_sort_value_value_key; since it is apparently unnecessary? |
| 11:04 |
sharpsie |
then DROP INDEX CONCURRENTLY browse_entry_sort_value_idx; CREATE INDEX CONCURRENTLY browse_entry_sort_value_idx ON metabib.browse_entry USING BTREE (substring(sort_value from 1 for 1000)); (completely untested, just following substr docs) |
| 11:59 |
sharpsie |
Dyrcona: might be a different bug, but worth looking at for future generations' sakes |
| 12:30 |
|
collum joined #evergreen |
| 12:52 |
|
kworstell-isl joined #evergreen |
| 13:05 |
eeevil |
mantis / sharpsie / Dyrcona / jeff / jeffdavis: sorry, meetings and then lunch! glad you found the old bug, a bell was ringing... berick has a reasonable plan in that older bug, but one key to keep in mind is making sure that we can find duplicates quickly, as that's core to the browse phase of ingest. so, large dataset testing is necessary for this one, and ingest function changes might be needed. the configuration-offered fix of using substr() to |
| 13:05 |
eeevil |
cap the length can retain the existing infrastructure (that's we're confident works) and can be automated in the upgrade script by just applying the normalizer to extant browse fields, but will require thought when adding new browse fields locally as Dyrcona implies via "fix it for everyone". I'd personally prefer avoiding encoding low level implementation restrictions in the indexing, but display-field truncation is something to consider as a trade |
| 13:05 |
eeevil |
off there. |
| 13:26 |
sharpsie |
eeevil: 10-4 |
| 13:29 |
|
Dyrcona joined #evergreen |
| 13:30 |
|
jihpringle joined #evergreen |
| 14:48 |
jeff |
Dyrcona: there are various tricks for doing that, especially if you don't care which row you keep. Most involve using ctid. :-) |
| 14:52 |
|
kworstell_isl joined #evergreen |
| 14:54 |
sharpsie |
like "Circ report (clone) (clone) (clone) (clone) (clone)" |
| 15:09 |
jeffdavis |
wondering if there should be a way for certain users to be able to bypass MFA - like consortial support staff logging in with a Circ Desk Staff account at BR1 for support/testing purposes without having to use whatever second auth factor that would normally require |
| 15:10 |
jeff |
arguably that should be a different account. |
| 15:11 |
jeff |
but yes, that's just one of a pile of questions that remain to be addressed. :-) |
| 15:12 |
jeffdavis |
yeah I'm sure we'll come up with more headaches^Wuse cases to think about |
| 15:14 |
jeff |
including determining some hard guidelines around what requires a user to use MFA to auth (home_ou, any working location requiring MFA, workstation OU? other?), and given a user that does not require MFA, are they prevented from logging in in any scenarios, like with a workstation tied to an org unit that does require MFA, etc? |
| 15:28 |
Dyrcona |
MFA for everyone. |
| 15:30 |
Dyrcona |
jeff: On my delete thing from earlier, I'm just going to delete the 3 rows and then insert the data back once. (That's easy enough.) I'll then add a unique constraint. I've tested it, and it works. |
| 15:48 |
|
mantis left #evergreen |
| 16:23 |
|
jvwoolf joined #evergreen |
| 16:23 |
|
jihpringle joined #evergreen |
| 11:20 |
|
Christineb joined #evergreen |
| 11:36 |
|
sleary joined #evergreen |
| 11:43 |
|
tsadok joined #evergreen |
| 13:33 |
Dyrcona |
Hmm. I seem to be getting random live test failures on Ubuntu 22.04 with user/berick/lp2017941-opensrf-on-redis-v2 and PostgreSQL 15. I ran livecheck, and the neg balances test failed. I ran eg_db_config, restarted things, and ran livecheck again. This time the geosort test failed. |
| 13:34 |
berick |
Dyrcona: i'm assuming stock eg/osrf on pg15 does not have these issues? i mostly tested with pg 14. |
| 13:36 |
Dyrcona |
berick: Well, it didn't have these issues with the same branch last week or the week before. I have seen the neg balance test fail on the first try, and succeed on the second in the past. |
| 13:37 |
Dyrcona |
I.E., the neg balance test has been finicky. |
| 13:38 |
Dyrcona |
I'm going for a 3rd try to see if anything is different. |
| 13:41 |
Dyrcona |
Right. All passed this time. |
| 13:41 |
Dyrcona |
:/ |
| 13:47 |
Dyrcona |
I'll test stock main on a different Ubuntu 22.04 vm talking to the same pg 15 database server. |
| 13:59 |
Dyrcona |
Hm.. This one appears to have frozen up while installing prerequisites. |
| 14:03 |
Dyrcona |
Looks like it finally finished installing prerequisites for OpenSRF. |
| 14:46 |
mantis |
I'm starting a new blog on all the mistakes I'm going to make as a sys admin: openseedsforme.wordpress.com |
| 15:30 |
mmorgan |
If I tried to chronicle all my mistakes, I would never succeed with anything :) |
| 15:31 |
mmorgan |
sharpsie: Your blog is telling me it's open only to invited readers. |
| 15:47 |
* Dyrcona |
used to blog, too, but time.... |
| 15:48 |
Dyrcona |
All right, I finally ran livecheck on stock main with ubuntu 22.04 and pg 15, and a bunch of tests failed. I'm pretty sure I did everything correctly, but I might have missed some setup step. |
| 15:50 |
* Dyrcona |
tries again. |
| 15:54 |
Dyrcona |
I wonder if there's some network issues going on where my VMs are hosted? |
| 15:56 |
Dyrcona |
Ok. I think my apache or some other configuration is busted for the moment. I looked at the output of the auth api test and it's getting 500, not 403, so internal server error. Apache and nginx are running, though. |
| 16:09 |
jeff |
makelivecheck || make undeadcheck |
| 16:09 |
jeff |
er, only without the typo. |
| 16:12 |
sharpsie |
mmorgan: try again if you want |
| 16:12 |
sharpsie |
apparently made it private way back then since I was nervous about people seeing it |
| 16:17 |
mmorgan |
sharpsie++ |
| 16:25 |
Dyrcona |
Hmm... Didn't change anything, and geosort is failing. |
| 16:25 |
Dyrcona |
The tests are being erratic for me today. |
| 16:27 |
Dyrcona |
RE Blogs, here's mine: http://evergreen.sigio.com/ |
| 16:32 |
berick |
and mine :) https://chomp.dev/ |
| 16:36 |
Dyrcona |
And, all tests pass this time.... |
| 17:03 |
|
mmorgan left #evergreen |
| 18:51 |
|
Jaysal joined #evergreen |
| 12:52 |
Dyrcona |
Doesn't xact_begin start a new session if there isn't one? Could the session have gone away, but the drone not know it? |
| 12:56 |
berick |
Dyrcona: that's what i'm thinking. the session timed out while compiling the template, it then tried to send a BEGIN on a disconnected session. |
| 12:57 |
Bmagic |
it almost has to be |
| 12:57 |
berick |
and it didn't know it was disconnected because no recv() / queue_wait calls occurred before the "am I still connected" test in editor's xact_begin() sub. |
| 12:57 |
Dyrcona |
I'd still check the database logs for anything weird around that time. |
| 12:58 |
Bmagic |
db logs don't have anything interesting around that time |
| 12:58 |
Bmagic |
lots of " WARNING: there is no transaction in progress" |
| 12:59 |
Dyrcona |
Well, that's a bummer. |
| 13:00 |
Bmagic |
we do have a clear log that says "No request was received in 6 seconds, exiting stateful session" - so, I wouldn't expect that the postgres service would have expierenced an error |
| 13:06 |
Dyrcona |
Can you tell if that's for the same cstore drone/process? |
| 13:13 |
* Dyrcona |
just added 64 tests to live_t/20-hold-targeter.t. |
| 13:21 |
|
sleary joined #evergreen |
| 13:25 |
* Dyrcona |
wishes there was a decent way to test the pull list from the backend, but the results are not predictable enough. |
| 13:37 |
|
Dyrcona joined #evergreen |
| 13:38 |
Bmagic |
sorry guys, I was pulled away, now, I'm back at it |
| 13:38 |
* Dyrcona |
is switching internet connections. |
| 13:46 |
Bmagic |
now I'm getting hits, to answer the question about what the action trigger logs look like above* the 6 second timeout line |
| 13:47 |
Dyrcona |
OK. I was going to suggest using -F on the grep or zgrep, or even eliminating the second grep and try the timestamp via zgrep. |
| 13:51 |
|
collum joined #evergreen |
| 13:54 |
* Dyrcona |
considers adding more tests... but needs to refresh his memory on making cstore requests from srfsh. |
| 13:54 |
Bmagic |
berick: RE: "between 08:47:07 and 08:47:13 or thereabouts" https://pastebin.com/8agDcMnX |
| 13:55 |
Bmagic |
the event ID that I'm tracking: 123020652 |
| 13:59 |
Bmagic |
do we start the transaction (the one that we're going to use to write the output to the database), and then* start generating the template? Leaving that transaction open for the duration? |
| 14:08 |
Bmagic |
It does succeed most of the time |
| 14:08 |
Bmagic |
I was just curious about this time |
| 14:09 |
Dyrcona |
Yeah. It happens more often than one would like. |
| 14:19 |
Dyrcona |
Well, I think that's enough tests. We can always add more later. |
| 14:25 |
berick |
oddly it tries to create the transaction after it's compiled the template. "trigger: writing 3273 bytes to template output" happens after template compilation. |
| 14:26 |
berick |
then cstore sends a bunch of stuff back after the begin. that part I don't get. |
| 14:43 |
Dyrcona |
Eighteen commits rebased down to 1, and I'm ready to share the code... |
| 15:04 |
Dyrcona |
I suppose we have functional tests for the staff client that can be run. I guess I should learn how those work. |
| 15:11 |
* eeevil |
reads up and sees Bmagic's adventure... ah yes, a Very Expensive Template Output (esp a grouped set of expensive events) could take longer than the session keepalive time (configured in opensrf.xml, per service) and it does look like that. the fast fix is to increase the keepalive time. I know of EG instances that have in the past had a timeout of 12s (slower hardware, and before some code changes lowered the timeout risk), but I don't see |
| 15:11 |
* eeevil |
any currently. if it's right at the edge of the time limit, that'd give breathing room to figure out where we need to insert more interaction and avoid that particular session timeout in A/T land. |
| 15:19 |
Bmagic |
eeevil++ berick++ Dyrcona++ mmorgan++ # thanks for the ideas. timeout 6 > 12 seems easy enough. What's the drawback? Tying up more Drones, and running up against max_children? |
| 09:43 |
berick |
Dyrcona: i've had similar thoughts lately re: merging opensrf because of this project. there's quite a bit of duplicated effort. |
| 09:43 |
berick |
Dyrcona: yes, those are the correct branches. |
| 09:43 |
Dyrcona |
berick: Thanks. |
| 09:44 |
berick |
Dyrcona++ # testing |
| 10:04 |
|
sleary joined #evergreen |
| 10:33 |
* Dyrcona |
hasn't done much today. I've been mucking about with UNIX account configuration. |
| 10:40 |
StomproJ |
oclc-- |
| 13:47 |
Dyrcona |
berick: For practicing rust locally would your recommend installing the rust-all apt package or going with rustup? |
| 13:48 |
Dyrcona |
s/your/you/ |
| 13:48 |
berick |
Dyrcona: either works. i've mostly used rust-all. |
| 13:49 |
Dyrcona |
Ok. I was thinking of going with rustup on my laptop for newer features, etc. I installed rust-all on the Ubuntu 22 vm where I'm testing redis. I'll give universe-rs a whirl later. |
| 13:50 |
Dyrcona |
I'm rerunning the perl live tests because I forgot to start apache2, so the tests that depended on Apache failed... |
| 13:51 |
Dyrcona |
Looks good so far |
| 14:23 |
Dyrcona |
I notice that gmcharlt is (righly) concerned about the universe-rs pulling in 167 crates. However, npm pulls in almost 1390 packages in Open-ILS/src/eg2. That should be a concern, too, no? |
| 14:23 |
Dyrcona |
Where are my fingers today?.... Must Typoday.... |
| 10:20 |
Dyrcona |
That's much safer than setting a flag in actor.usr. |
| 10:21 |
Dyrcona |
My second promised email about our rusty future might go into some detail about issues I have with the current staff client, but I might save that for yet another email. |
| 10:21 |
Dyrcona |
I have examples of bad API design and even worse use or bypassing of existing API. |
| 10:22 |
berick |
we have exactly 2 accounts w/ superuser. one for logging in/testing/etc and one a backend utility account. not following the use case where a standard human person would get superuser. |
| 10:24 |
jeff |
seconding deprecation and possibly eventual removal of actor.usr.superuser, if only for simplicity and for the sake of having permissions in fewer places. |
| 10:24 |
Dyrcona |
berick: Doesn't matter if you don't get it. Doesn't mean it's wrong. When someone is on the phone wanting something fixed, that permission comes in handy. |
| 10:25 |
jeff |
and yes, both EVERYTHING and superuser should be rarely handed out / relied upon. |
| 10:34 |
jeff |
csharp_: that "unless" bit around the check_perms call is because check_perms returns undef on success. if the return value is truthy, it means that the user doesn't have the perm. it's... perhaps less than intuitive. |
| 10:35 |
csharp_ |
jeff: ah - out of context it was really throwing me |
| 10:35 |
Dyrcona |
Another unpopular opinion: I think we should ditch Perl for the back end (other than utility scripts). |
| 10:36 |
jeff |
Dyrcona: I don't object to PL/pgSQL functions being used to test "does this user have this perm at X location" and such. It seems efficient and not an egregious "that doesn't BELONG in the database!" kind of thing. |
| 10:36 |
csharp_ |
Dyrcona: preview of your "rusty" email? :-) |
| 10:36 |
Dyrcona |
csharp_: yes, but I'll have to write it. It might take me a few more days. |
| 10:38 |
|
kworstell_isl joined #evergreen |
| 11:04 |
mmorgan |
Cool! |
| 11:04 |
Dyrcona |
Yeah, thanks. |
| 11:05 |
mantis1 |
Dyrcona++ |
| 11:07 |
gmcharlt |
Dyrcona== |
| 11:07 |
gmcharlt |
er |
| 11:08 |
gmcharlt |
Dyrcona++ |
| 11:14 |
gmcharlt |
if you give a mouse a cookie^W^W^W^W GitHub Actions a commit... |
| 11:14 |
gmcharlt |
anyway, the GitHub-based automatic tests are now happy again |
| 11:14 |
pinesol |
News from commits: fix title of 3.11.0 release notes <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=8c52cb5dfef7485f4bec742c2a431c35b39d6c58> |
| 11:15 |
pinesol |
News from commits: LP#2023582 - 3.11.0 release notes - remove redundant section <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=ba9550376925919ddab361b4b9f918fd8f5b66f7> |
| 11:15 |
pinesol |
News from commits: LP#2023582: Update RELEASE_NOTES_3_11.adoc - formatting fixes <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=500b04d7a729d30bc87b66aafe53d52220163256> |
| 11:28 |
|
Christineb_ joined #evergreen |
| 12:51 |
|
jvwoolf joined #evergreen |
| 13:13 |
|
dmoore joined #evergreen |
| 13:45 |
jvwoolf |
Anybody have an issue with Perl modules not getting installed correctly with 3.9.3? |
| 13:45 |
jvwoolf |
We've installed it a few times over the past few weeks (including for our production system) but seem to be having issues with the install on 2 different test servers today. |
| 13:58 |
JBoyer |
jvwoolf, any OS upgrades in the mix there? |
| 13:59 |
JBoyer |
(Like 20.04 -> 22.04, not 20.04.9 -> 20.04.10) |
| 14:13 |
jeff |
jvwoolf: can you say more about what the issues/symptoms are? are there errors at "make install" time, or something else? |
| 15:10 |
jvwoolf |
I know I did everything right this time on the server I'm working on and I'm getting the same error on make check |
| 15:11 |
jvwoolf |
@bartender mantis1 |
| 15:11 |
* pinesol |
fills a pint glass with Ommegang Witte, and sends it sliding down the bar to mantis1 (http://beeradvocate.com/beer/profile/42/16506/) |
| 15:13 |
jeff |
Above the "Test Summary Report" should be a collection of more specific/detailed error messages. Often times I like to start with the first one, though it's not guaranteed to be the clue that leads to a solution. :-) |
| 15:14 |
Dyrcona |
jvwoolf: Is this a virtual machine? |
| 15:15 |
jvwoolf |
Dyrcona: Yes |
| 15:16 |
|
mantis1 left #evergreen |
| 15:17 |
Dyrcona |
I'd destroy it and start over. The output from your find commands suggests that it has been upgraded from Ubuntu 16 to 18 to 20. |
| 15:19 |
jvwoolf |
Dyrcona: That's the case with all of our test VMs at this point |
| 15:20 |
jvwoolf |
This is the only one that's decided to be a PITA |
| 15:25 |
Dyrcona |
Try this one: find /usr -name Logger.pm |
| 15:28 |
* Dyrcona |
was just wondering why my database was missing indexes, and then realized I was checking the wrong schema. |
| 15:28 |
Dyrcona |
No asset.copy indexes in the actor schema! |
| 15:29 |
jeff |
based on that output, my next suggestion would be perl -c /usr/local/share/perl/5.30.0/OpenSRF/Utils/Logger.pm |
| 15:30 |
Dyrcona |
Yeahp. What jeff said. |
| 15:30 |
Dyrcona |
Probably a busted module somewhere. |
| 15:32 |
jeff |
(but I also think we may be using the output of paste gKQdDQSz ("the start error") to debug a different machine, so that may not be helpful.) |
| 15:33 |
jeff |
the errors from "make check" that occurred before the Test Summary Report are my best suggestion at the moment. |
| 15:33 |
jvwoolf |
jeff: Yes, sorry for the noise on that one |
| 15:33 |
jvwoolf |
It was just a coincidence that they were both getting Perl-related errors at the same time |
| 15:34 |
jvwoolf |
/usr/local/share/perl/5.30.0/OpenSRF/Utils/Logger.pm syntax OK |
| 16:42 |
pinesol |
Launchpad bug 1904737 in Evergreen "Flag/setting for Items with Specific Statuses to Display on Holds Pull List" [Wishlist,In progress] https://launchpad.net/bugs/1904737 - Assigned to Jason Stephenson (jstephenson) |
| 16:43 |
Dyrcona |
I think I'll see what happens with the current query using that index and dropping the cp_available... index. |
| 16:43 |
Dyrcona |
I'll bet it's faster. |
| 16:47 |
Dyrcona |
Yeah... On my test system performance is comparable to the modified query and just slightly faster than the previous cp_available_by_circ_lib_idx. Going to modify the queries to include "deleted is false" to force the is false index to be used. Maybe drop the circ with status code index, too. |
| 16:49 |
Dyrcona |
Heh. It's using both indexes when they are there. |
| 16:49 |
Dyrcona |
oops. It's the index on serial.unit that I'm seeing... |
| 16:53 |
Dyrcona |
To be fair, I should probably loop these variations thousands of times and average them out, and they will likely all be comparable, i.e. within a fraction of a second of each other. |
| 09:07 |
|
Dyrcona joined #evergreen |
| 09:09 |
|
Christineb joined #evergreen |
| 09:23 |
|
mantis1 joined #evergreen |
| 09:24 |
mantis1 |
Found this error when running autoreconf -i for our 3.11.0 test server install |
| 09:24 |
mantis1 |
autoreconf: automake failed with exit status: 1 |
| 09:24 |
mantis1 |
I think this was related to a makefile when I saw it before, but it's been some time |
| 09:32 |
gmcharlt |
mantis1: what Linux distribution? |
| 09:40 |
pinesol |
News from commits: LP2019735 Fix Bootstrap5 checkbox borders <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=e62173478e9e509f3f8c225b4ea262e0ffb18dfa> |
| 09:41 |
mantis1 |
gmcharlt: I figured it out |
| 10:11 |
pinesol |
News from commits: LP#1996818 Issues Placing Holds from the Patron Record <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=2a2af7843d2db0440ffb3b0fe4c59e3157af35f9> |
| 10:11 |
Dyrcona |
That might have been the problem. Whenever you do a major version upgrade of Evergreen, it's best to delete the node files in /usr/local/ and to do a `git clean -x -f -d` in your local Evergreen repository to remove any old files. |
| 10:14 |
mantis1 |
Dyrcona: I have the code prep and scripts done. Is it possible to run these now or does it need to be done at a specific time during the code prep? |
| 10:16 |
Dyrcona |
mantis1: They should be done before you do anything else. You will probably be OK, because we don't change Node versions that often. I do the git clean -x -f -d from time to time to clean things up on my dev systems particularly if I'm switching release versions or about to test big changes, |
| 10:18 |
Dyrcona |
I've had weird issues after doing an installation that going back and doing the node deletion or a git clean and reinstalling has fixed. |
| 10:54 |
Dyrcona |
@blame Apple |
| 10:54 |
pinesol |
Dyrcona: Apple is really just another name for autogen |
| 15:05 |
berick |
Dyrcona++ |
| 15:05 |
Bmagic |
#info RUST timeline |
| 15:05 |
Bmagic |
berick: I threw this on the agenda because it was bare. Feel free to tell me to move on |
| 15:06 |
berick |
well... |
| 15:06 |
berick |
not much so say on the Rust side at this point. kind of waiting/hoping others will get interested and join the momentum |
| 15:06 |
berick |
i did at this https://github.com/kcls/evergreen-universe-rs/blob/main/PRIMER.md |
| 15:06 |
berick |
tiny primer |
| 15:07 |
berick |
i think the bigger question now is more about the Redis stuff, which has been decoupled from Rust now |
| 15:07 |
berick |
and is ready for wider testing |
| 15:07 |
Dyrcona |
berick++ |
| 15:07 |
Bmagic |
oh! berick++ |
| 15:07 |
Dyrcona |
I'll take a look. |
| 15:16 |
berick |
so, it's a long game |
| 15:17 |
jeffdavis |
kind of works as a roadmap though - there's some time to get up to speed on Rust while Redis dev continues, then ramp up with Rust once the Redis stuff is in main? |
| 15:18 |
berick |
jeffdavis: yeah, pretty much |
| 15:18 |
Bmagic |
I'm sure more discussions will be had, we can table it. Good to know that berick has Redis up for testing sans Rust! |
| 15:18 |
Bmagic |
berick++ # for good measure |
| 15:18 |
jeffdavis |
yeah, really excited for Redis and hoping the Rust interest takes off |
| 15:18 |
JBoyer |
berick++ |
| 15:31 |
jeff |
i've no strong opinion either way on one-channel or many-channels, but support having a list of "official" project channels and making logs more readily available for those channels. |
| 15:32 |
Bmagic |
hmmm, it's public as far as I know. The security stuff wouldn't be there (correct me if I'm wrong releaseers) |
| 15:33 |
Dyrcona |
It's public, but it is not logged by the bots. |
| 15:33 |
jeff |
sleary: I think the reason you can't see the channel in your IRC client is the same reason you wouldn't be able to see this channel if you weren't already in it: the channels are +s ("secret") to avoid being listed in the commands that spam bots use, etc. Something we did long ago, and could test removing if folk think +s is causing more trouble than its worth. |
| 15:33 |
Bmagic |
I mean, the chatter is public |
| 15:34 |
jeff |
I mention the above because I'm happy to be the one to set up logging / join the bots / list the channels on the wiki or web page / toggle channel modes as needed / etc. |
| 15:34 |
Bmagic |
so, shall we remove it? |
| 16:16 |
Dyrcona |
It might be a while before others see the change. |
| 16:19 |
|
sleary_ joined #evergreen |
| 16:51 |
jeff |
gmcharlt: in a recent comment on bug 1483496 you mentioned "evergreen.change_db_setting() will be removed shortly" -- I'm wondering if there's additional context to that? I've no objection, just curiosity. |
| 16:51 |
pinesol |
Launchpad bug 1483496 in Evergreen "evergreen.change_db_setting needs test" [Undecided,Won't fix] https://launchpad.net/bugs/1483496 |
| 16:52 |
gmcharlt |
jeff: a pending security fix |
| 16:52 |
jeff |
ah. :-) |
| 17:02 |
|
mmorgan left #evergreen |
| 08:04 |
|
BDorsey joined #evergreen |
| 08:09 |
|
rfrasur joined #evergreen |
| 08:10 |
|
PhilMakesStuff joined #evergreen |
| 08:11 |
PhilMakesStuff |
This is a test message to see if I am posting in the correct channel |
| 08:12 |
PhilMakesStuff |
Quick question: I was wondering if evergreen has a Voluntary Product Accessibility Template (VPAT)? |
| 08:13 |
PhilMakesStuff |
We will need this in order for our organization to use Evergreen |
| 08:23 |
JBoyer |
Hi PhilMakesStuff , that sounds familiar but you may have more luck getting responses on the Evergreen general email lists as IRC activity is pretty irregular. |
| 16:00 |
javier_guel |
great thanks, i will try |
| 16:44 |
|
dmoore_doppel joined #evergreen |
| 16:59 |
|
mmorgan left #evergreen |
| 17:31 |
dmoore |
hey all - any thoughts on this API note published on EBSCO's Novelist page - https://connect.ebsco.com/s/article/Setting-up-On-The-Shelf?language=en_US |
| 17:32 |
dmoore |
"Note: There is an Evergreen API that supports automatic harvesting of your collection. However, we were unable to obtain a complete harvest for any customers during the testing of this functionality, as Evergreen’s Web Services API was not built for such a wide-scale application. We discourage Evergreen customers from utilizing this feature for collection harvesting." |
| 17:32 |
csharp_ |
dmoore: we don't use it in PINES, but anecdotally, I've heard from sites who do that the harvesting can eat into available server resources |
| 17:33 |
berick |
hah, yeah, IIRC, they were madly spewing api calls |
| 17:33 |
csharp_ |
dmoore: we sent a monthly upload to NoveList so they can reference it offline |
| 08:06 |
|
ahazaril joined #evergreen |
| 08:50 |
ahazaril |
Hi! I'm trying to do Batch MARC Import in Evergreen 3.11 RC on my test server |
| 08:51 |
ahazaril |
but it seems error like this: |
| 08:51 |
ahazaril |
ERROR TypeError: r.id is not a function |
| 08:51 |
ahazaril |
at Object.next (5959.1f96455ba4311aeb.js:1:14565) |
| 08:51 |
ahazaril |
at De.next (main.a07a83aabf044c34.js:3:39334) |
| 08:51 |
ahazaril |
at Re._next (main.a07a83aabf044c34.js:3:39003) |
| 08:51 |
ahazaril |
at Re.next (main.a07a83aabf044c34.js:3:38689) |
| 08:51 |
ahazaril |
at x.dispatchResponse (main.a07a83aabf044c34.js:3:14786) |
| 08:51 |
ahazaril |
at OpenSRF.Request.onresponse (main.a07a83aabf044c34.js:3:14057) |
| 08:51 |
ahazaril |
at OpenSRF.Stack.handle_message (opensrf.js:748:28) |
| 08:51 |
ahazaril |
at OpenSRF.Stack.push (opensrf.js:693:23) |
| 08:51 |
ahazaril |
at OpenSRF.websocketConnection.onmessage (opensrf.js:388:23) |
| 08:51 |
ahazaril |
at socket.onmessage [as __zone_symbol__ON_PROPERTYmessage] (opensrf_ws.j |
| 08:51 |
ahazaril |
Vandelay file uploaded OK with key f114583e2c27f43954f487556c7816fe |
| 09:09 |
|
ahazaril joined #evergreen |
| 11:45 |
jeffdavis |
ahazaril: those look like errors in the browser console, are there any related error messages in the server logs? |
| 12:07 |
ahazaril |
which log file i need to view jeffdavis? |
| 12:33 |
ahazaril |
hahaha its ok, i forgot also to report a bug in Launchpad before |
| 12:34 |
jeffdavis |
I've reported it now, bug 2021402 |
| 12:34 |
pinesol |
Launchpad bug 2021402 in Evergreen "Default Vandelay import folder is not readable by opensrf" [Undecided,New] https://launchpad.net/bugs/2021402 |
| 12:36 |
jeffdavis |
Hope the rest of your testing goes well! :) |
| 12:36 |
ahazaril |
tq so much pinesol! |
| 12:36 |
ahazaril |
tq jeffdavis! |
| 07:58 |
|
collum joined #evergreen |
| 08:10 |
|
BDorsey joined #evergreen |
| 08:11 |
|
rfrasur joined #evergreen |
| 08:16 |
JBoyer |
Evergreen 3.11.0-rc1 is up and announced. To testing! |
| 09:12 |
|
mmorgan joined #evergreen |
| 09:27 |
JBoyer |
Bmagic, are you involved in the docs auto-build for docs.evergreen-ils.org/eg/ ? It looks like it was unhappy with something recently and all of the docs are gone. |
| 09:29 |
JBoyer |
Ooor, since it's CNAME'd to a gpls system, csharp_ ? |
| 10:08 |
JBoyer |
I also mean they may be things that we need to document (ha...) about how best to do formatting on this or that page level, etc. I did some experimenting to try to silence the "level 0 blah blah book" error that latency.adoc is throwing and apparently could not make the thing happy. |
| 10:09 |
JBoyer |
Though it occurs to me it may have tried building multiple versions even though I was in the rel_3_11 branch and I was only looking at 1 copy (and not committing the changes...) |
| 10:09 |
JBoyer |
I need to re-familiarize myself with the whole process apparently. :) |
| 10:49 |
jvwoolf |
TIL that if you set the intenal flag ingest.force_on_same_marc to true your metarecords seem to remap themselves without kicking off pingest.pl |
| 10:50 |
jvwoolf |
The bad part is that I accidentally set the flag to true in production instead of a test system like I had intended.:-D |
| 10:50 |
jvwoolf |
Doesn't seem like anything bad happened luckily. |
| 10:52 |
jvwoolf |
Does anybody know how to check on whether whatever it's doing in the background is done? |
| 10:56 |
Dyrcona |
jvwoolf: Your foreground update doesn't finish unti its done, I think. |
| 10:59 |
Dyrcona |
That is, the triggers don't run in the background. |
| 11:00 |
jvwoolf |
Dyrcona++ |
| 10:07 |
|
dguarrac joined #evergreen |
| 10:18 |
|
mantis1 joined #evergreen |
| 11:12 |
gmcharlt |
updated the wiki to the latest stable version of Dokuwiki |
| 11:13 |
tlittle |
gmcharlt++ |
| 11:34 |
|
ACSpike joined #evergreen |
| 11:34 |
|
ACSpike joined #evergreen |
| 11:35 |
tlittle |
Reports don't appear to be running on my test server, and I'm not sure what else to check as to why. I've already restarted everything on this list: https://wiki.evergreen-ils.org/doku.php?id=newdevs:restarting |
| 11:36 |
tlittle |
Any ideas what else I should try? |
| 11:37 |
gmcharlt |
tlittle: if Clark is running (ps -ef | grep -i Clark), it's possible that Clark things that there's a report still running |
| 11:37 |
ACSpike |
Is Hatch specific to Evergreen? Could it be used by other web apps? |
| 11:37 |
gmcharlt |
if so, SELECT * FROM reporter.currenly_running would show one or more rows |
| 11:29 |
csharp_ |
yeah, that was last Tuesday - Wednesday was fun |
| 11:42 |
|
ariez_hazaril joined #evergreen |
| 11:43 |
ariez_hazaril |
hi everyone! I wanna ask something. Can Evergreen ILS port we change from 80 to 8080? i manage to change the port, but the eg_vhost still listen to port 80. thanks |
| 11:57 |
jeff |
ariez_hazaril: in theory, it could be. it's not a common configuration, and may not be well tested. I don't think we have specific documentation on how to do it, and I'm not personally in a position to help troubleshoot your attempt. Out of curiosity, what are you trying to do? |
| 11:58 |
ariez_hazaril |
Hi jeff, im trying to change opac port from 80 to 8080 as i need to use port 80 for something else |
| 12:08 |
|
Christineb joined #evergreen |
| 12:25 |
|
genpaku joined #evergreen |
| 11:21 |
sandbergja |
Dyrcona++ |
| 12:14 |
|
jihpringle joined #evergreen |
| 12:24 |
|
kmlussier joined #evergreen |
| 12:28 |
terranm |
When refreshing a test server, it's really helpful to log into the correct one. |
| 12:39 |
Dyrcona |
terranm++ |
| 12:40 |
Dyrcona |
sandbergja++ |
| 12:40 |
Dyrcona |
It looks like we'll have point releases next week, and there is a high likelihood of there being one or more security patches in the releases. |
| 12:46 |
csharp_ |
for when you do an OS upgrade and it breaks NPM all to hell: https://pastebin.com/aWcn6jkC |
| 12:46 |
csharp_ |
(thanks to gmcharlt for the kernel of this back at the 2019 hackaway) |
| 12:57 |
Dyrcona |
csharp_++ I have a less comprehensive version of that, but I think I'll steal yours. |
| 12:57 |
Dyrcona |
I find it useful sometimes to wipe out Node and reinstall it when switching branches on a test VM. |
| 13:01 |
csharp_ |
I may variable-ize the Evergreen source dir name to allow for non-Git or alternate repo usage |
| 13:03 |
csharp_ |
updated the paste with that change |
| 13:05 |
Dyrcona |
csharp_: Good idea. You might want to add this for bootstrap OPAC: rm -rf $INSTALL_DIR/var/web/opac/deps/node_modules |
| 13:09 |
csharp_ |
-ohs*t |
| 13:10 |
berick |
hah |
| 13:11 |
Dyrcona |
:) |
| 13:13 |
* Dyrcona |
tries the script out on a test vm, because I was just about to install Lp1947898 for testing with rel_3_10. |
| 13:13 |
Dyrcona |
Lp 1947898 |
| 13:13 |
pinesol |
Launchpad bug 1947898 in Evergreen "Enhanced MARC importer script electronic_marc_import.pl" [Wishlist,Confirmed] https://launchpad.net/bugs/1947898 - Assigned to Jason Stephenson (jstephenson) |
| 13:36 |
csharp_ |
updated the paste with the bootstrap addition |
| 07:10 |
|
kworstell_isl joined #evergreen |
| 07:29 |
gmcharlt |
I have pushed the bootstrap 5 + angular15 branch that berick, sleary, and sandbergja have been working on to master |
| 07:30 |
gmcharlt |
the BS5 upgrade in particular introduces a number of changes to how Bootstrap CSS classes work, so if you run into trouble when reviewing Angular changes that predate this morning, please be aware (and don't hesitate to ask for help, especially if you have an opportunity to bug berick and sleary in person at the conference) |
| 07:46 |
pinesol |
News from commits: LP#2000482: add a brief release notes entry <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=09b001a2dbc5dd8877b5f61d9f4ecb5a68d9403f> |
| 07:46 |
pinesol |
News from commits: LP#2000482: (follow-up) couple more layout tweaks <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=635370da24e9b2ed7da887e48045688a1e9443cb> |
| 07:46 |
pinesol |
News from commits: LP#2000482: (follow-up) update Angular cheat sheet <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=c37328795ac368f4a0b4f5f7514a5b31a25abb27> |
| 07:46 |
pinesol |
News from commits: LP2000482: Get tests passing <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=c1fcbda53d2d2a7858464fb8ca808e814cb7bcdf> |
| 07:46 |
pinesol |
News from commits: LP2000482: update tsconfig options to satisfy compiler warning <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=7d8923e075a83318acf01a3236587c802278f4bc> |
| 07:46 |
pinesol |
News from commits: LP2000482 Bootstrap 5 continued <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=3b747e6fd12089c22dfac928ad6b692f69279a52> |
| 07:46 |
pinesol |
News from commits: LP2000482 Angular 15 and Bootstrap 5 upgrade <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=c76e4ad6c2aba1a918992659686bb6b50bfea79c> |
| 08:07 |
csharp_ |
notes for Sys Admin IG: https://docs.google.com/document/d/1EUa9oIvmp5s9mbCRYIwG6dKMEcuirOEKcqbs90OjjWc/edit?usp=sharing |
| 08:19 |
|
mmorgan joined #evergreen |
| 08:53 |
|
mmorgan left #evergreen |
| 14:36 |
pinesol |
abneiman is going out with degraafk to see Blighted Tormenter Contours tonight. |
| 14:43 |
gmcharlt |
there's now an updated branch for bug 1997485 |
| 14:43 |
pinesol |
Launchpad bug 1997485 in Evergreen "wishlist: Did you mean? Multi word, single class search suggestions" [Wishlist,Confirmed] https://launchpad.net/bugs/1997485 - Assigned to Galen Charlton (gmc) |
| 14:43 |
gmcharlt |
I think this is ready to go, and I intend to push it tonight, but if anybody intends to test it today, please speak up |
| 14:52 |
|
jvwoolf joined #evergreen |
| 14:54 |
|
kworstell-isl joined #evergreen |
| 15:11 |
|
jihpringle joined #evergreen |
| 16:39 |
jihpringle |
that is outside of my expertise - if you don't get a response from anyone else I'd recommend emailing the general list next week (when people are back from the conference) |
| 16:39 |
jihpringle |
https://evergreen-ils.org/communicate/mailing-lists/ |
| 16:40 |
derekz |
Sounds good. If you're at the conference, I hope you're enjoying it and I appreciate you taking the time to respond |
| 16:47 |
jeffdavis |
derekz: I'm pretty sure the structure of email templates is (1) headers including To, From, and any custom headers, (2) a blank line, (3) the body of the message |
| 16:48 |
jeffdavis |
If you put custom headers with To and From etc *before* the blank line, I think that should work |
| 16:48 |
jeffdavis |
(please test first though, don't take my word for it :) |
| 16:51 |
derekz |
The structural outline is helpful. I'll give it try. Thank you! |
| 17:09 |
derekz |
Does line 83 indicate that only From, To, Bcc, Cc, Reply-To, Sender are being extracted for further processing by the email perl module? |
| 17:09 |
derekz |
https://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/Application/Trigger/Reactor/SendEmail.pm;h=71354e6b6506ac8584af470fb51f04040ac49ab7;hb=09b001a2dbc5dd8877b5f61d9f4ecb5a68d9403f |
| 17:16 |
|
jvwoolf joined #evergreen |
| 17:19 |
jeffdavis |
derekz: I believe you're not restricted to those headers - our templates add a Message-ID header using the method I described, for example, and it appears to work |
| 17:19 |
jeffdavis |
it may be that other headers are not MIME-encoded |
| 17:23 |
derekz |
(y) I'll do some testing and see how it goes. Headed out for the evening. Thanks for the help! |
| 17:44 |
|
abowling1 joined #evergreen |
| 16:26 |
kmlussier |
git shortlog --group=trailer:signed-off-by --after="03 Apr 2023" --before="20 Apr 2023" -s -- ":(exclude)./docs/" |
| 16:26 |
kmlussier |
Does anyone know if there is a way to count the signoffs where the person signing off is not the author? I'm thinking the answer is no, but maybe somebody smarter than me when it comes to git knows of a way. |
| 16:27 |
Bmagic |
abowling: Try dividing the file that you're submitting in half, and then half again and again until it imports correctly. |
| 16:29 |
abowling |
Bmagic: Thanks, but it's one record (a test) ;) |
| 16:29 |
Bmagic |
kmlussier: I'm wish I knew the right answer for that. After you mentioned it the other day, I spent some time on getting sign-offs out of git with counts like you were talking about. I'm sure someone, ahem gmcharlt, might know it. Since he publishes these numbers sometimes |
| 16:29 |
Bmagic |
abowling: hmmm, do you get this error for any* record? |
| 16:29 |
abowling |
seemingly, yes |
| 10:02 |
Dyrcona |
hrm... This is going to be an interesting rebase... I want to drop a bunch of commits, split one commit up into several smaller commits, and then squash some other commits into the new commits. I wonder if I can get away with doing it once, or will I have to do two rebases.... |
| 10:04 |
Dyrcona |
Now that I think about it, maybe I should rebase a different branch and then recreate the branch that I was planning to rebase from scratch.... |
| 10:19 |
Dyrcona |
I suppose that I could just make a new branch without rebasing either.... |
| 10:25 |
Dyrcona |
hm... wonder if I really need the changes to these two images. I'll make them their own commit so I can remove them later for testing. |
| 10:34 |
|
stephengwills joined #evergreen |
| 10:39 |
Dyrcona |
a) Does anyone use KPAC? b) Do you use override directories with KPAC? |
| 10:52 |
Dyrcona |
Still working on this rebase, and I think I want to reorganize things even more. |
| 08:47 |
|
dguarrac joined #evergreen |
| 08:52 |
|
rfrasur joined #evergreen |
| 09:02 |
|
mantis1 joined #evergreen |
| 10:08 |
Stompro |
jmurray-isl, Re: Content Cafe, they are serving up old images, but only to evergreen libraries because we seem to be the only customers that make use of the XMLPost request method. And they seem to have no way to test request to that service. |
| 10:13 |
Dyrcona |
Stompro: So, someone should open a bug on Lp for us to switch to the REST interface or whatever it is that Koha uses? |
| 10:14 |
Stompro |
Dyrcona, they have a specific method for grabbing just cover art, but we also get author notes and reviews from them. I think the XMLPost method is the only method for grabbing that info. |
| 10:15 |
Dyrcona |
I see... |
| 10:20 |
Dyrcona |
I was just thinking of how I should word this in an email to other CW MARS staff, but I think I'll skip it since no one has opened a ticket, yet. |
| 10:21 |
Dyrcona |
Could we grab images via GET and still get the other information via POST? |
| 10:27 |
Stompro |
Dyrcona, yes, I'm sure that would work, just added complexity. If I remember correctly, it does try and combine different types of content into one request... but I don't think that happens in reality because of how clients request the data. |
| 10:28 |
csharp_ |
most vendors don't really take testing that seriously |
| 10:28 |
csharp_ |
(that could probably provide to all developers everywhere :-)) |
| 10:28 |
* Dyrcona |
thinks we are included in "most vendors." |
| 10:28 |
csharp_ |
s/provide/apply/ |
| 10:28 |
Dyrcona |
csharp_++ |
| 10:58 |
Dyrcona |
There are only 2 hard problems in computer science: naming things, cache invalidation, and off-by-one errors. :) |
| 11:01 |
Stompro |
They asked me what our memcache TTL is... and I'm like, "24 hours, now lets talk about what yours it set to?, it has been serving old data for 5 weeks now??" |
| 11:05 |
Dyrcona |
-1? |
| 11:27 |
jmurray-isl |
Stompro: To test ContentCafe images, I go to the OPAC record and look through the sources for contentcafe. There, I can find something with the following format: https://contentcafe2.btol.com/ContentCafe/jacket.aspx?UserID=<UserID>&Password=<Password>&Return=T&Type=S&Value=<ISBN-Number> |
| 11:27 |
jmurray-isl |
Type equates to S, M, or L. |
| 11:29 |
jmurray-isl |
I mean, it is a bit concerning that just anyone can view our ContentCafe credentials this way... |
| 11:31 |
Bmagic |
jmurray-isl: I had the same thought whilst looking through this code. Syndetics works the same way. The "authentication" is simply our ID string embedded in the query string. If they charged based on number of requests, then I would be a bit more concerned :) |
| 11:36 |
Stompro |
jmurray-isl, our Evergreen setup doesn't expose the username and pw, I did notice that Evergreen Indiana does have two different sets of cover art links. The problem is that the jacket.aspx method is returning fresh data, but the XMLpost method that evergreen uses is serving old data. let me grab an example. |
| 11:37 |
Stompro |
Compare https://evergreen.lib.in.us/opac/extras/ac/jacket/medium/9781608095377 and https://evergreen.lib.in.us/eg/opac/record/22903128 |
