| 01:05 |
|
Keith__isl joined #evergreen |
| 06:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:39 |
|
brettgilio joined #evergreen |
| 07:23 |
|
mantis joined #evergreen |
| 08:35 |
|
mmorgan joined #evergreen |
| 09:27 |
Dyrcona |
So, for those following along (or not), I have run my db upgrade script on Pg 9.6, Pg 10, and Pg 11 so far. This includes a partial ingest of record attributes for MARC item type g. |
| 09:31 |
Dyrcona |
It took 28 hours 48 minutes on Pg 9.6. On Pg 10, it ran for 25 hours 3minutes. Pg 11 finished after 12 hours 7 minutes. This is with the db being "optimized" and the server rebooted in between each configuration change. |
| 09:31 |
berick |
pg11 FTW |
| 09:32 |
Dyrcona |
I probably won't get around to "testing" Pg 12 and Pg 13 until next week. I want to restore the configuration for Pg 10 for an automated production restore over the weekend. |
| 09:32 |
Dyrcona |
Yeah, my experience is newer Pg releases are faster over all, but some specific things have degraded performance. |
| 09:33 |
|
jvwoolf joined #evergreen |
| 09:35 |
Dyrcona |
I'm doing the full did you mean setup at the moment. I have a script that I run with time to get the timing of it. I thought about just using the files generated from the first process since they should be all the same, but that wouldn't quite be fair. |
| 09:37 |
Dyrcona |
That process took just about 4 hours (minus 2 or 3 minutes) on both Pg 9.6 and Pg 10, so it will be interesting to see the time for Pg 11. |
| 09:38 |
Dyrcona |
I may do all of this again if we get the bad drive replaced. |
| 09:43 |
Dyrcona |
Hmm. I may get to testing Pg 12 today after all. Pg 11 seems to be ripping right through the DYM stuff. |
| 09:45 |
Dyrcona |
66GB in cache.... |
| 09:45 |
|
mantis joined #evergreen |
| 09:49 |
berick |
too bad you can't do them all at once, we could take bets. |
| 12:08 |
|
jihpringle joined #evergreen |
| 13:49 |
Dyrcona |
Well, Pg 11 didn't make much difference for the did you mean setup. It finished only about 2 minutes faster than Pg 9.6. I think that's because the process spends most of its time reading and writing data files with Perl. |
| 14:33 |
|
stephengwills joined #evergreen |
| 15:24 |
Dyrcona |
berick: Do I have to md5 hash the password before using AppUtils::verify_user_password? I'm getting 0 when I try to verify either of the passwords on my test account. |
| 15:29 |
Dyrcona |
Apparently, I have to do more than that because the database function fails with the correct information. |
| 15:30 |
* Dyrcona |
looks at how open-ils.auth does it, again. |
| 15:33 |
berick |
Dyrcona: verify_user_password assumes non-md5'ed passwords. verify_migrated_user_password assumes md5-hashed passwords. |
| 15:55 |
berick |
mine |
| 15:55 |
Dyrcona |
berick: switching password and type looks wrong given the actor.verify_passwd signature and the code in AppUtils.pm. |
| 15:56 |
berick |
Dyrcona: right, your code is fine, it's just the sql that's different -- but the apputils code accounts for that |
| 15:56 |
Dyrcona |
berick: I accounted for that with my tests. |
| 15:57 |
Dyrcona |
Hey! patebot! You here? |
| 15:57 |
Dyrcona |
pastebot, even... |
| 15:58 |
Dyrcona |
http://paste.evergreen-ils.org/14413 |
| 16:27 |
Dyrcona |
typos-- :) |
| 16:28 |
Dyrcona |
Too many os, 0s, and uppercase vs. lowercase typos. :) |
| 16:28 |
Dyrcona |
IOW, it helps to use the correct password when trying to verify it. :) |
| 16:31 |
mmorgan |
Never hurts to test the wrong password, too, to make sure it's not verifying inapproriately :) |
| 16:32 |
Dyrcona |
Well, that's true. |
| 16:32 |
jeff |
yes. |
| 16:33 |
jeff |
Dropbox learned that lesson in a very public fashion in 2011. :-) |
| 16:55 |
Dyrcona |
Very few say "drone." |
| 16:58 |
* Dyrcona |
calls it a day. Thanks, everyone! |
| 17:22 |
|
mmorgan left #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 20:59 |
|
stephengwills left #evergreen |
| 02:28 |
|
eady joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 08:10 |
|
collum joined #evergreen |
| 08:32 |
|
mantis joined #evergreen |
| 08:32 |
|
Dyrcona joined #evergreen |
| 09:33 |
|
mmorgan left #evergreen |
| 09:35 |
|
mmorgan joined #evergreen |
| 09:42 |
mmorgan |
For a workstation using Hatch, is there a way to force the printer dialog? Staff want to have the option to choose a different printer for the pull list. |
| 09:45 |
JBoyer |
Dyrcona, so long as the array is messed up for all of them it should still a valid test. You're comparing the versions relative to each other, not to a similar box with a working array. |
| 10:01 |
|
jvwoolf joined #evergreen |
| 10:05 |
Dyrcona |
JBoyer: True, but I'd like to fix it. We're going to see if we have a drive we can swap in, soon. Failing that I have a couple of old database servers that I might be able to use, but they don't have enough space to hold multiple copies of our database. |
| 10:06 |
JBoyer |
Oh, sure; I don't mean you shouldn't look into it, just that the current work isn't wasted. Comparing things across the line where it's fixed is no good, but that's different. |
| 10:25 |
Dyrcona |
I haven't exercised 13 as much as 12, but if you're on a relatively recent schema, then there aren't blockers other than performance going to 12 that I am aware of. Everything seems to work. |
| 10:25 |
berick |
cool, thanks |
| 10:25 |
berick |
may just start pushing my dev VM's to 13 just cuz |
| 10:26 |
Dyrcona |
I've been using 12 with my test/development VMs at CW MARS. I just decided to switch port 5432 to Pg 10 last week in preparation for going to Pg 10 in production. |
| 10:29 |
Dyrcona |
On my generic VMs, where I install concerto data and run the DB locally, I've been installing Pg10. |
| 10:29 |
JBoyer |
I do have a few demo / concerto machines on 12/13 so there shouldn't be anything major, but there are a few things that never really get tested on those. (perf among them) |
| 10:31 |
Dyrcona |
We load 10,000+ batches of electronic resource records from time to time, and I have a Perl script for that which can output timing data with a command line switch. |
| 10:32 |
Dyrcona |
I'll run that on the test server with a batch occasionally. It will take a couple of seconds to update most records on Pg 9.6. On Pg 12 it's typically 5 to 10 seconds, with some records going over 20 to 30 seconds. |
| 10:32 |
Dyrcona |
A batch of 10,000 can take hours on Pg 9.6 and days on Pg 12. |
| 10:33 |
berick |
Dyrcona: and that's still located URI-related? |
| 10:33 |
Dyrcona |
I want to profile that with plprofiler. It will hopefully show where the slowness comes from. |
| 13:27 |
berick |
well, except in the printer settings UI where you can 'print with dialog' |
| 13:29 |
mmorgan |
berick: That's what I was looking for! I don't see it in printer settings, though. |
| 13:30 |
|
jvwoolf joined #evergreen |
| 13:33 |
berick |
mmorgan: it's under the Test Printing tab |
| 13:33 |
berick |
so, it's only there for testing |
| 13:34 |
berick |
if you test it, beware the dialog does not always (ever?) steal focus, so it sits open behind the browser window. |
| 13:35 |
berick |
i could imagine having a way to specify "print via browser" for certain print contexts / templates |
| 13:41 |
mmorgan |
Oh, ok. At least I know I didn't imagine it ;-). They are looking for a way to redirect to another printer when their main one has an issue. Likely not something that will happen that often. I will offer them the option of disabling hatch momentarily when that's necessary. |
| 13:41 |
mmorgan |
berick++ |
| 13:43 |
berick |
gotach. it's also a pretty quick change to tell Hatch to use a different printer |
| 16:34 |
|
jvwoolf1 joined #evergreen |
| 16:58 |
|
jvwoolf1 left #evergreen |
| 17:14 |
|
mmorgan left #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:21 |
|
collum joined #evergreen |
| 08:31 |
|
mantis joined #evergreen |
| 08:31 |
|
stephengwills joined #evergreen |
| 12:16 |
Dyrcona |
berick++ |
| 12:21 |
Dyrcona |
A better patch might be to move the functional code for undelete_biblio_record_entry to BibCommon.pm and call that from Cat.pm and AssetCommon.pm. Just throwin' that out there. |
| 12:25 |
Dyrcona |
So, my upgrade to master-d9bb7c9205 from 3.5.3 took 25 hours, and that's not counting the "did you mean" setup. |
| 12:25 |
pinesol |
Dyrcona: [evergreen|Jane Sandberg] LP1718782: follow up to fix failing test - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d9bb7c9> |
| 12:34 |
|
collum joined #evergreen |
| 12:54 |
|
collum joined #evergreen |
| 13:20 |
|
abowling joined #evergreen |
| 15:21 |
abowling |
berick: yeah. darndest thing. i've never run into this on other boxes |
| 15:21 |
abowling |
this is an AWS VM. i don't think that should matter, but... |
| 15:22 |
JBoyer |
abowling, anyhing interesting in your ~/.ssh/config? Seems odd that it's trying to use ssh to clone from github |
| 15:23 |
berick |
i think what Dyrcona said is the main issue, the package should not be using ssh: |
| 15:23 |
berick |
just tested on a VM with github key disabled and got the same error |
| 15:23 |
abowling |
JBoyer: berick: agree |
| 15:25 |
abowling |
JBoyer: not at all; straightforward |
| 15:26 |
JBoyer |
seeing berick's note about *removing* his makes my question kind of unnecessary. Agreed that Dyrcona nailed it above. Someone screwed up upstream. :/ |
| 16:10 |
Dyrcona |
Ah, so it was us... |
| 16:11 |
Dyrcona |
abowling++ |
| 17:19 |
|
denials joined #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:00 |
|
stephengwills left #evergreen |
| 20:43 |
|
stephengwills_ joined #evergreen |
| 20:44 |
|
stephengwills_ left #evergreen |
| 05:18 |
|
degraafk_ joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 08:18 |
|
mantis joined #evergreen |
| 08:19 |
|
Dyrcona joined #evergreen |
| 08:58 |
|
miker joined #evergreen |
| 09:30 |
Dyrcona |
It doesn't lose its mind, but changes don't always show up. |
| 09:31 |
Dyrcona |
I could be cargo culting.... |
| 09:37 |
Dyrcona |
I don't recall if the OPAC picks up changes right away, either. |
| 09:39 |
Dyrcona |
Bmagic | gmcharlt: FYI I'm messing with Pg settings on my test db server. I'm changing the ports that the different instances listen on and reviewing the optimization settings. I'm going to come up with a set of optimizations to use more of the hardware and possibly modify the "40%" settings. |
| 09:40 |
Dyrcona |
I'm also going to open a Lp bug and a Google doc for notes, etc. I think I'll make a folder for the project, so I can share multiple docs if necessary. |
| 09:50 |
|
jvwoolf joined #evergreen |
| 09:51 |
miker |
Bmagic: autogen's main purpose, outside of upgrades (where new classes are routinely added, and field positions change), is to flush the copy of the org tree (and related structures) from memcached. that's used by the web client just as much as it was the xul client. so, yes, you must run it after changes to the org tree that get cached there. also, there is some in-process caching in both mod_perl and certain service backends, so an apache and |
| 12:06 |
|
nfBurton joined #evergreen |
| 12:13 |
Dyrcona |
bshum++ |
| 12:53 |
|
sandbergja joined #evergreen |
| 13:08 |
jeff |
if you have a degraded array, you might want to correct that before putting effort into running tests. |
| 13:09 |
jeff |
though it's possible the results would be suitable for comparison with each other... maybe. |
| 13:12 |
Dyrcona |
jeff: I know. We replaced some drives in this machine a few years ago. I'll ask if we have any spares left over. If not, I may not have a choice at this point. |
| 13:13 |
Dyrcona |
If that's the case, then I'll see what other hardware we have available. We don't have anything else with as much disk space, so it would make the testing rather time consuming. |
| 13:14 |
jeff |
you might also be able to reconfigure the storage in a way that requires fewer physical drives. |
| 13:14 |
Dyrcona |
"If that's the case," meaning if we don't have spares. |
| 13:14 |
* jeff |
nods |
| 16:26 |
Keith_isl |
Dyrcona ++ |
| 16:27 |
Dyrcona |
I just ran totals for the day: 98 not connected in total, and only 8 for drones. So that's more like 1 in 12 is a drone. |
| 16:35 |
|
jvwoolf1 joined #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:05 |
|
jvwoolf1 left #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:54 |
|
brettgilio joined #evergreen |
| 08:29 |
|
Dyrcona joined #evergreen |
| 08:37 |
|
mantis joined #evergreen |
| 09:49 |
mantis |
Seems that the OPAC has the same results |
| 09:50 |
csharp_ |
we've talked about a "staff_visible" column on copies/locations but that's not been implemented yet as far as I know\ |
| 09:51 |
alynn26 |
OPAC Visible is only used in the public facing OPAC. Try it in incognito mode. And have you set the Actual Org unit as OPAC Visible. |
| 09:51 |
Bmagic |
mantis: be sure and log out before testing the OPAC. Even though you change the URL to the Patron side, you are still logged in (unless you actively click log off) - will will still show you staff results |
| 09:51 |
mantis |
select * from asset.copy where holdable = 'f' and opac_visible ='f' and not deleted and circ_lib = 95; comes up with the number of results I needed |
| 09:52 |
Dyrcona |
manits: What Bmagic said. I was typing up almost the same thing, or use an incognito/private window for the patron opac. |
| 09:52 |
mantis |
Bmagic: awesome thank you |
| 10:29 |
JBoyer |
nfBurton, I recall working on something like that; and possibly instance holds also. I'll see if I can find it. |
| 10:30 |
Dyrcona |
nfBurton: It doesn't look like the SIP code handles part holds at all. |
| 10:30 |
nfBurton |
I pushed a patch on my system from an LP bug where part holds would respond blank. |
| 10:31 |
nfBurton |
Still testing it though |
| 10:31 |
Dyrcona |
nfBurton: If you send your SIP logs through syslog, you'll get a timestamp added by syslog. |
| 10:31 |
JBoyer |
yeah, bug 1525394 |
| 10:31 |
pinesol |
Launchpad bug 1525394 in Evergreen 3.6 "SIP patron part level holds respond blank" [Undecided,New] https://launchpad.net/bugs/1525394 |
| 10:35 |
JBoyer |
1525394 has a signoff for Bmagic's commit, but not mine. Looks like it hasn't been touched since. |
| 10:35 |
JBoyer |
If you have some part holds that work and some that don't that might warrant investigation, otherwise it sounds like there's more to do on it. :/ |
| 10:35 |
Dyrcona |
nfButon: If it's working for you, you could always add a signoff. |
| 10:36 |
nfBurton |
I'm still testing but can once I get more results |
| 10:36 |
nfBurton |
i need to learn signoffs anyways |
| 10:36 |
nfBurton |
JBoyer Ah, I didn't see the second patch |
| 10:37 |
nfBurton |
JBoyer++ |
| 10:41 |
mantis |
Dyrcona: This one particular circ mod has a 14d_0r rule without any autorenewals |
| 10:42 |
mantis |
Yet I still got a notice saying "no autorenewals remaining" |
| 10:42 |
Dyrcona |
Yeah, that would seem to make sense. It does run for every circulation. |
| 10:42 |
mantis |
Ok thanks |
| 10:42 |
mantis |
Dyrcona++ |
| 10:43 |
mantis |
I guess I never had this come across via testing |
| 10:44 |
Dyrcona |
If you think of the notice as a reminder/courtesy to the patron, it makes sense to tell them that the item couldn't be renewed. After all, patrons can't be expected to know all of the circ rules. |
| 10:45 |
mantis |
Right. I agree. I can see why it also causes confusion with some people, too. |
| 10:45 |
mantis |
We're still on 3.5.4 but upgrading to 3.6.4 this year. I saw in the patch notes that the reasonings have been updated. |
| 15:53 |
Dyrcona |
So, it can be controlled without iptables, I hope. |
| 15:53 |
Dyrcona |
https://metacpan.org/pod/Net::Server#CONFIGURATION-FILE |
| 16:06 |
|
abneiman joined #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:09 |
|
rjackson_isl joined #evergreen |
| 08:05 |
|
Dyrcona joined #evergreen |
| 08:22 |
|
rfrasur joined #evergreen |
| 09:23 |
stephengwills |
no, at docs.evergreen-ils.org. and I thought I did make -f Open-ILS/src/extras/Makefile.install postgres-server-ubuntu-bionic-10 on my postgresql server. isn’t that enough to install the prerequisites? |
| 09:24 |
Dyrcona |
stephengwills: Maybe not. It could be a bug in the prerequisite install target. |
| 09:25 |
stephengwills |
i’ll try and cut some time to poke around more before I get complacent with my installed server and move on to other stuff. again, so helpful y’all. thanks. |
| 09:28 |
Dyrcona |
To be honest, I almost never refer to the documentation and go by release notes and trial and error. I've usually done the upgrade several times on test VMs before I do the production upgrade. |
| 09:30 |
stephengwills |
in the past I’ve done that too but I am an applications layer guy who spends most of my time in PHP so when I crawling onto the cloud the more NASA-like my steps are the smoother it goes for me. LOL! |
| 09:31 |
stephengwills |
Note to self: check to make sure the doc.eg-ils.org clearly states i must plug in my computer before I flip the ON switch. |
| 09:32 |
Dyrcona |
So, you could argue that it is a bug in the Pg server targets. They don't include any CPAN modules, and the Levenshtein, et al., are installed via CPAN. |
| 10:36 |
stephengwills |
I implied it when quoting the make install for ubuntu bionic and Pg10 |
| 10:36 |
Dyrcona |
Yeahp. |
| 10:37 |
Dyrcona |
I have confirmed that the CPAN modules don't get installed on Debian Buster. |
| 10:37 |
Dyrcona |
I should test again with a Bionic VM. |
| 10:37 |
Dyrcona |
I may have to amend my bug report. |
| 10:39 |
Dyrcona |
Maybe focal and stretch, too. Guess I'm spending the weekend rebuilding my local test VMs..... |
| 10:40 |
stephengwills |
my slice is an AWS EB2 Ubuntu 18.04 LTS with Pg v10 and I did make the extras from Eg3.7.1 on it and, ultimately had to install the two modules I mentioned above to make 3.6.2-3.7.0-upgrade-db.sql happy. |
| 10:45 |
Dyrcona |
stephengwills: Is the database on a separate host/instance from the Evergreen servers? If it was all on the same machine and the general ubunbut-bionic prerequisites were installed, then the modules should have been there. |
| 10:50 |
jeff |
I do really wish that Chrome had an option to allowlist an extension (Hatch) without force installing it. |
| 15:57 |
mmorgan |
Oooh. Dyrcona lives dangerously :) |
| 15:59 |
Dyrcona |
And, the patch works! |
| 16:00 |
Dyrcona |
I should update the commit message with verification instructions and then force push it. |
| 16:00 |
Dyrcona |
Still have to test on stretch and bionic, but I'm 99.9% certain that it will work there as well, since it's all the same code. |
| 16:15 |
|
mmorgan1 joined #evergreen |
| 17:21 |
|
mmorgan left #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 01:48 |
|
dluch joined #evergreen |
| 01:48 |
|
devted joined #evergreen |
| 01:48 |
|
Bmagic joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live//archive/2021-07/2021-07-14_04:00:03/test.42.html> |
| 07:15 |
|
rjackson_isl joined #evergreen |
| 08:23 |
|
collum joined #evergreen |
| 08:26 |
|
rfrasur joined #evergreen |
| 10:39 |
rhamby |
"copier beware" |
| 10:43 |
mmorgan |
berick: Ok thanks. But I was wondering if not nullifying the update_process might cause issues. |
| 10:43 |
berick |
mmorgan: nah, it's purely informational and gets immediately overwritten. |
| 10:44 |
mmorgan |
ok, thanks! |
| 10:44 |
mmorgan |
berick++ |
| 10:44 |
mmorgan |
stephengwills++ |
| 10:52 |
mmorgan |
stephengwills: Are you using TPAC or Bootstrap OPAC? I have a recent master test system on Bootstrap and am not seeing any such errors. |
| 10:53 |
stephengwills |
TPAC, I don’t want to complicate applying my customizations with bootstrap under i get it stable |
| 10:53 |
stephengwills |
until (not under) |
| 10:54 |
stephengwills |
now i’ll confess that I have not commented out my custom_templates to see if I still getthe probelm |
| 11:13 |
stephengwills |
yup…thanks. I’m stepping away. getting frustrated and making mistakes :). bbilb |
| 11:36 |
|
Dyrcona joined #evergreen |
| 11:38 |
Dyrcona |
Just throwing this out there: Hidden access points are more trouble than they are worth. |
| 11:45 |
sandbergja |
that failing test sure looks like it's from my patch for bug 1718782; I can go ahead and push a fix (unless somebody already started working on it) |
| 11:45 |
pinesol |
Launchpad bug 1718782 in Evergreen 3.6 "webclient: MARC bib editor doesn't show SRCE in the fixed fields" [Low,Fix committed] https://launchpad.net/bugs/1718782 |
| 11:49 |
Dyrcona |
sandbergja: You pushing a fix is OK by me. I had a quick look last night, but didn't go so far as to think about a fix. |
| 12:01 |
|
Dyrcona joined #evergreen |
| 12:07 |
|
stephengwills left #evergreen |
| 12:10 |
sandbergja |
Dyrcona: that's too bad. I like how repair-able the pinebook pro sounds from its web site |
| 12:15 |
Dyrcona |
I figured that I'd try it in the office today. I don't use it much. I seem to be having issues with the KDE session manager mostly. |
| 12:28 |
pinesol |
[evergreen|Jane Sandberg] LP1718782: follow up to fix failing test - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d9bb7c9> |
| 12:31 |
|
collum joined #evergreen |
| 12:41 |
eby |
besides running the cron at midnight are there any tricks to getting an action trigger delay/max_delay so it selects everything on a single day (midnight to midnight)? |
| 12:41 |
eby |
nothing is jumping out in the interval seconds calculations |
| 14:58 |
gmcharlt |
Acquisitions interest group meeting starting in two minutes: https://wiki.evergreen-ils.org/doku.php?id=acq:minutes:2021-07-14 |
| 16:39 |
|
mmorgan1 joined #evergreen |
| 17:11 |
|
mmorgan1 left #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:12 |
|
dluch joined #evergreen |
| 02:54 |
|
JBoyer joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:13 |
|
rjackson_isl joined #evergreen |
| 07:29 |
|
rfrasur joined #evergreen |
| 07:34 |
|
Dyrcona joined #evergreen |
| 10:25 |
pinesol |
[evergreen|Jason Boyer] LP1895737: Add Curbside Appointments to Bootstrap OPAC - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5cd1d52> |
| 10:26 |
* gmcharlt |
claims 1269 |
| 10:28 |
|
jonadab joined #evergreen |
| 10:29 |
pinesol |
[evergreen|Jane Sandberg] LP1910891: Add new booking perms to appropriate groups - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0c414a2> |
| 10:29 |
pinesol |
[evergreen|Galen Charlton] LP#1910891: stamp DB update - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9d4aec8> |
| 10:37 |
pinesol |
[evergreen|Jane Sandberg] LP1857060: Tests for ISBNs with 979 prefix - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3831d36> |
| 10:40 |
rjackson_isl |
looking at a request for a site specific self check receipt and looking at others notice a 5 second Processing Delay being set. Is there a reason this could not be 0 or 1? |
| 10:44 |
jeff |
is it 5 seconds or 5 minutes? stock selfcheck receipt doesn't specify a delay, so it would probably default to '00:05:00'::interval |
| 10:44 |
jeff |
either way, I don't think the value of the delay column is used for print-on-demand. |
| 10:44 |
rjackson_isl |
we were just discussing that locally after I hit enter :( jeff++ |
| 10:45 |
mmorgan |
rjackson_isl was just testing us :) |
| 10:45 |
rjackson_isl |
and it does appear to default to 5 minutes not seconds which would be one heck of a wait! |
| 10:46 |
rjackson_isl |
rjackson_isl is trying to engage brain transmission... |
| 10:48 |
Dyrcona |
Yeah, what jeff said. I think it just executes immediately. |
| 13:56 |
|
jihpringle joined #evergreen |
| 13:57 |
|
pastebot joined #evergreen |
| 14:00 |
|
pastebot joined #evergreen |
| 14:01 |
pastebot |
"jeff" at 168.25.130.30 pasted "testing" (1 line) at http://paste.evergreen-ils.org/10000 |
| 14:28 |
mantis |
jeff++ |
| 14:29 |
mantis |
jeff: I was looking around the fields for ILS User and wasn't finding anything. The explanation is very helpful! |
| 14:30 |
JBoyer |
Dev meeting in 30 |
| 14:36 |
|
mantis1 joined #evergreen |
| 14:37 |
|
cabreedl joined #evergreen |
| 14:40 |
|
pastebot joined #evergreen |
| 14:41 |
pastebot |
"jeff" at 168.25.130.30 pasted "testing 14402" (1 line) at http://paste.evergreen-ils.org/14402 |
| 14:52 |
Dyrcona |
jeff++ |
| 14:57 |
|
terranm joined #evergreen |
| 14:58 |
bshum |
jeff++ |
| 15:11 |
|
jvwoolf joined #evergreen |
| 15:11 |
JBoyer |
I use it to talk to Evergreen also, though Hatch support is likely 1) missing, and 2), not that difficult to add. |
| 15:12 |
|
jvwoolf left #evergreen |
| 15:12 |
gmcharlt |
Microsoft actually publishes .debs of Edge, so assuming that it has a headless mode, theoretically it could be folded into the Angular tests if somebody were sufficiently eager |
| 15:12 |
berick |
gmcharlt: huh, didn't know they made debs |
| 15:13 |
berick |
that simplifies some things |
| 15:13 |
JBoyer |
For Hatch I suspect they learned their lesson with old Edge's ridiculous extension mechanism and won't likely stray far from Chromium, though if we want Hatch on the Edge Extension store that's one more place to publish it. |
| 15:16 |
berick |
maybe we could limit this some and say just the Angular bits? maybe that's implied.. |
| 15:16 |
gmcharlt |
having the starting point be support-but-not-Hatch-yet seems like it would be OK |
| 15:16 |
JBoyer |
I don't mind trying to add Edge support to the Angular testing setup, though it will likely be optional so running <os>-<distro>-developer doesn't end up installing 4, 5, or 6 browsers in future. |
| 15:17 |
gmcharlt |
berick: that is, if I'm understanding your question correctly. If Edge somehow breaks on the Dojo or AngularJS stuff, fixing that may be more than we awnt to tackle |
| 15:17 |
JBoyer |
berick, do you mean no Hatch yet, or even more limited than that somehow? |
| 15:18 |
berick |
i mean what gmcharlt said. fixing stuff that's being actively replaced is not best use of time |
| 15:24 |
gmcharlt |
(all of that said, not particularly expecting any Dojo or AngularJS issues) |
| 15:24 |
* jeff |
nods |
| 15:24 |
jeffdavis |
I'd be hesitant to tell a library they can use Edge under those conditions tbh. |
| 15:25 |
jeff |
it sounds like there has been some light testing of the current code in Edge. |
| 15:25 |
gmcharlt |
yeah, and production use |
| 15:25 |
alynn26 |
The staff that use Edge know we do not support it. but use it anyway. Have not found any issues with Edge with the AngularJS or Dojo parts. |
| 15:25 |
JBoyer |
I understand the desire not to allow it to cause us any additional support burden, but as I understand it, neither Google or MS make many changes to the core rendering bits of Chromium, it's mostly the (pardon), chrome and syncing backends that are different. I don't see a situation where we have a compatibililty problem with Edge that we wouldn't have with Chrome within days. |
| 15:25 |
gmcharlt |
if Edge weren't Chromium-plus-stuff, I think it would be a bigger lift |
| 15:26 |
jeff |
I think the hesitency in this discussion to claim full support is mostly stemming from the fact that very few here have tested the staff interfaces in Edge. |
| 15:26 |
* mmorgan |
would be interested to know why Edge is preferred by those who are currently using it. |
| 15:27 |
JBoyer |
It's already there. |
| 15:27 |
JBoyer |
And if you're an IT department, it's more easily controlled with group policy. |
| 15:34 |
JBoyer |
(Since I'm on a Mac right now, anyway) |
| 15:35 |
gmcharlt |
alynn26: do you know if anybody has successfully used offline circ with Edge? |
| 15:35 |
JBoyer |
Since berick knocked out #2 already, is anyone interested in taking an action item on exercising the staff client in Edge? Hatch is not necessary, but offline would be. |
| 15:36 |
alynn26 |
No, not offline circ on edge. Testing edge on Windows 10 now. |
| 15:37 |
JBoyer |
To be clear, I don't mean anyone needs to try to knock out a client test right now, I know personally that it works fine for everything I've done in it, but there are a lot of things I don't touch. |
| 15:38 |
JBoyer |
Or I will poke at it. |
| 15:39 |
JBoyer |
#action JBoyer will exercise the staff client in a current release of Edge and report back in August |
| 15:39 |
mmorgan |
JBoyer++ |
| 15:43 |
JBoyer |
gmcharlt, I assume your 3.8 question is about bug 1904036? |
| 15:43 |
pinesol |
Launchpad bug 1904036 in Evergreen "Port patron interfaces to Angular (search, checkout, etc.)" [Wishlist,New] https://launchpad.net/bugs/1904036 |
| 15:43 |
berick |
i added that one |
| 15:44 |
gmcharlt |
JBoyer: yeah, mine was more of a general heads up about a bunch of big features for which we need testing |
| 15:44 |
JBoyer |
:( |
| 15:44 |
berick |
seeking feedback on trying to add it to 3.8 as experimental |
| 15:44 |
gmcharlt |
1904036 is definitely one of them, but there's also |
| 16:05 |
JBoyer |
berick++ |
| 16:06 |
berick |
mmorgan: if you hear anything of note, let me know! |
| 16:06 |
berick |
not sure I can make tomorrow's acq meeting |
| 16:06 |
JBoyer |
Ok, if there are no other questions or comments we can go about the rest of our days (and start testing Angular branches! ;) ) |
| 16:06 |
gmcharlt |
berick: I'll be demoing the acq admin interfaces there tomorrow, and would be happy to relay any questions you care to feed me |
| 16:07 |
mmorgan |
berick: Will share this with my colleague who will be attending that meeting. |
| 16:07 |
berick |
is it 2pm eastern? |
| 16:55 |
|
jvwoolf joined #evergreen |
| 17:18 |
|
mmorgan left #evergreen |
| 17:28 |
|
jvwoolf left #evergreen |
| 18:01 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live//archive/2021-07/2021-07-13_16:00:02/test.42.html> |
| 22:27 |
|
mmorgan1 joined #evergreen |
| 22:27 |
|
mmorgan1 left #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:12 |
|
rjackson_isl joined #evergreen |
| 07:38 |
|
mantis joined #evergreen |
| 08:14 |
|
mmorgan joined #evergreen |
| 08:45 |
|
dguarrac joined #evergreen |
| 08:54 |
|
tlittle joined #evergreen |
| 09:26 |
|
mmorgan joined #evergreen |
| 09:26 |
Dyrcona |
Kind of hard to test lost notices when your test data only gets 7 with filters, and the validator then sets them all to invalid. |
| 09:32 |
Dyrcona |
But, when I run "the query," I get hundreds of circulations that should be picked and create events. I must be doing something wrong with the date math. |
| 09:32 |
mmorgan |
Dyrcona: Sounds like your test patrons need to be more irresponsible :) |
| 09:35 |
Dyrcona |
mmorgan: Yeah, but auto-renewals are also an issue. |
| 09:36 |
Dyrcona |
I figured out what I was doing wrong. I was using between when I should have used > and <. |
| 09:36 |
Dyrcona |
I get 7 with the latter. |
| 10:14 |
mmorgan |
:) |
| 10:18 |
Dyrcona |
mmorgan++ rhamby++ |
| 10:18 |
mmorgan |
Dyrcona++ |
| 10:35 |
Dyrcona |
Think I'll adjust the delay and max_delay on the lost event for another test in a bit. |
| 10:45 |
Dyrcona |
Hm... I think I'm going to have to restart services. I changed the delay and tried running the a/t runner but I don't get any new events. |
| 10:47 |
Dyrcona |
Ah. Ok. Had to specify the filters, and they're all still invalid...... :( |
| 10:47 |
mmorgan |
Action triggers are complicated. |
| 12:06 |
|
seusszeusmoose joined #evergreen |
| 12:07 |
|
jihpringle joined #evergreen |
| 13:06 |
rhamby |
in the spirit of its complicated - an overly complicated squirrel feeding machine https://www.youtube.com/watch?v=U3-doqeWHPM&ab_channel=Creezy |
| 13:07 |
Dyrcona |
OK. So, I know I was messing with action triggers on a test vm, so why has production decided to have issues with action triggers today, too? |
| 13:11 |
alynn26 |
rhamby, https://www.youtube.com/watch?v=hFZFjoX2cGg |
| 13:12 |
Dyrcona |
And, so far, nothing appears to be wrong other than a/t runners going for a long time. |
| 13:17 |
Dyrcona |
@blame curbside |
| 14:08 |
Dyrcona |
I only blamed curbside because of the sheer number of events related to that process. |
| 14:11 |
Dyrcona |
There are currently 4,888 curbside offer events with a state of invalid for today. |
| 17:19 |
|
mmorgan left #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 21:07 |
|
stephengwills joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:11 |
|
rjackson_isl joined #evergreen |
| 07:30 |
|
Dyrcona joined #evergreen |
| 07:42 |
|
mantis joined #evergreen |
| 08:42 |
|
dguarrac joined #evergreen |
| 09:15 |
|
rfrasur joined #evergreen |
| 10:02 |
|
jihpringle joined #evergreen |
| 11:29 |
Dyrcona |
JBoyer: While running my modified Clark in testing, I did get a logged error message from the main process that it failed to connect to the db server. Crazy thing is it says 'no route to host' as if the network went down. |
| 11:29 |
Dyrcona |
Lp 1933984 |
| 11:30 |
pinesol |
Launchpad bug 1933984 in OpenSRF "Reporter Logging Improvements" [Undecided,Confirmed] https://launchpad.net/bugs/1933984 |
| 11:30 |
Dyrcona |
Services on the test VM are all still connected. |
| 11:35 |
Dyrcona |
Our Internet was up and down at the time, but I'm not sure how that would affect the LAN. Anyway, messages are going to syslog as I intended. |
| 12:10 |
JBoyer |
Dyrcona, that's interesting. And it kept working? (maybe failed a dns lookup or something) |
| 12:55 |
Dyrcona |
No, it crashed. |
| 17:23 |
jeff |
yeah, I'm pretty sure I can do a search that combines two search_format entries, but there's no UI that constructs such queries that I'm aware of. |
| 17:27 |
jeff |
a reingest of these types is not too much trouble. |
| 17:36 |
|
jihpringle joined #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
