| 00:04 |
|
sandbergja joined #evergreen |
| 00:18 |
|
jamesrf joined #evergreen |
| 01:27 |
|
jamesrf joined #evergreen |
| 05:01 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-03-28T04:58:20,153401959-0400 -0> |
| 07:01 |
|
agoben joined #evergreen |
| 07:16 |
|
rjackson_isl joined #evergreen |
| 08:03 |
|
littlet joined #evergreen |
| 12:48 |
jeff |
picking a Z39.50 source that supports Keyword and one that does not, and then submitting a search with only a keyword specified... leads to a failure along the lines of "Can't call method "option" on an undefined value at /usr/local/share/perl/5.24.1/OpenILS/Application/Search/Z3950.pm line 437." |
| 12:50 |
jeff |
Interestingly enough, perhaps due to a local logging quirk, I'm only seeing the error appear in Apache logs. |
| 13:08 |
|
wsmoak joined #evergreen |
| 13:55 |
bshum |
berick: Some feedback on the remoteip commit for the ansible installer |
| 13:55 |
bshum |
It looks like we need to add a step to do a2enmod remoteip as well |
| 13:56 |
bshum |
Otherwise, just editing the config file leads to a failed ansible run due to not being able to start apache due to the config change |
| 13:56 |
bshum |
This is from a test run I'm doing on 18.04, not sure if the same issue presents in 16.04 but the commit didn't seem too different |
| 13:57 |
bshum |
I'll file a bug and put up a pullrequest later if you don't get to fixing it quicker :) |
| 14:13 |
berick |
bshum: oh, hm |
| 14:14 |
berick |
good catch, thanks bshum |
| 14:15 |
|
stephengwills joined #evergreen |
| 15:51 |
bshum |
But uh... yeah, my info knowledge is many years out of date now |
| 15:51 |
jeff |
mmorgan: i believe that they do, yes. |
| 15:51 |
bshum |
So I'll be quiet :) |
| 15:52 |
jeff |
mmorgan: increasing the timeout on the SIP client means in theory that it will take longer to give up on the SIP server in cases of actual outage. depends on your AMH, and how patrons interact with it (if at all), but in this scenario increasing the timeout is likely a good option for a workaround. |
| 15:53 |
jeff |
mmorgan: empirical testing may give most accurate results. :-) |
| 15:54 |
* jeff |
breaks user editor changes into logical commits and bugs |
| 15:55 |
mmorgan |
jeff: We can request an increase in the timeout to see if that helps. I'd prefer to fix the bug, though ;-) |
| 15:57 |
mmorgan |
So if nonholdable items weren't in the hold_copy_map, would that prevent evergreen from polling through 100 holds that the item can't fill? Or would it still do that? |
| 15:59 |
jeff |
i believe the ahcm table is what is consulted at checkin time for opportunistic hold capture |
| 16:28 |
mmorgan |
Yes, exactly. |
| 16:29 |
jeff |
i'm wondering what would happen if you did something that caused that row to no longer be present in action.hold_copy_map. say, deleting it manually, or attempting to force retarget the hold (or maybe thawing then freezing the hold) |
| 16:30 |
mmorgan |
Hold that thought. I'm going to check the copy auditor table to make sure. |
| 16:30 |
jeff |
oh, to test the theory that the frozen hold was placed (or last targeted) before the copy was made non-holdable? |
| 16:31 |
mmorgan |
Well, to make sure that the item was actually nonholdable when these transactions happened. |
| 16:31 |
jeff |
ah. |
| 16:31 |
mmorgan |
Interestingly, the frozen hold was placed before the copy was made active. Can't say when the hold was frozen, though. |
| 16:35 |
jeff |
are you in a position to be able to do something that causes that copy to no longer appear in action.hold_copy_map, and then check the item in again to see if it's still checked against a bunch of holds? |
| 16:35 |
mmorgan |
Yes, prev_check_time is null for the hold. |
| 16:36 |
mmorgan |
jeff: not with that particular item. |
| 16:38 |
jeff |
are you able to create a fake copy on a title with many holds, make the fake copy holdable=false, and check that item in? |
| 16:39 |
jeff |
bonus points if you want to test it with and without a single frozen hold that has that copy in its copy map... bit of work to set up, i know. |
| 16:40 |
jeff |
i could probably test this theory here. |
| 16:40 |
mmorgan |
Item was created as a holdable on order item. Item was changed to not holdable at 12:53, and checked in at 14:17 the same day. So it likely appeared in the hold_copy_map for many holds at that point. |
| 16:40 |
mmorgan |
So, that kind of blows the theory :) |
| 16:42 |
* mmorgan |
can check more recent logs for the same item to see how many holds get tested. |
| 01:24 |
|
jamesrf joined #evergreen |
| 03:14 |
|
sandbergja joined #evergreen |
| 05:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:16 |
JBoyer |
jeff++ # That's a good idea. |
| 07:37 |
|
littlet joined #evergreen |
| 07:49 |
|
agoben joined #evergreen |
| 09:59 |
jeff |
We probably shouldn't allow a password reset request to be initiated using the barcode of an inactive card. |
| 10:00 |
* mmorgan |
would agree with that. |
| 10:08 |
|
StomproJ joined #evergreen |
| 10:38 |
dbwells |
berick: Testing the RC, and not seeing any search results in the experimental staff catalog. The search completes, the facets and counts load, I see the holdings fetches happening, but nothing gets drawn in the main area. Any thoughts on troubleshooting this? |
| 10:47 |
berick |
dbwells: that's different... |
| 10:47 |
berick |
console errors? |
| 10:47 |
dbwells |
not seeing any... |
| 11:07 |
berick |
can you freely navigate other eg2 interfaces? |
| 11:07 |
dbwells |
It all feels pretty free |
| 11:08 |
dbwells |
It seems likely to be something wrong with our local install and not the code, but I'd love to figure out what. |
| 11:09 |
berick |
hm, so the pager works, which means the search call is returning... |
| 11:10 |
berick |
but then it never even tries to grab the bibs |
| 11:11 |
berick |
it uses the /opac/extras/unapi... stuff to grab the initial bib and holdings data |
| 11:11 |
berick |
i wonder if you see those calls hitting the apache/nginx access logs? |
| 11:12 |
berick |
e.g. GET /opac/extras/unapi?id=tag::U2 bre/30{holdings_xml}/CONS/0&format=holdings_xml ... |
| 11:15 |
berick |
also good to know if that URL produces results on your test machine |
| 11:25 |
|
sandbergja joined #evergreen |
| 11:27 |
dbwells |
berick: sorry, got pulled away. Yes I see those in the Network tab in chrome, and they appear to be working. |
| 11:31 |
berick |
k |
| 12:05 |
dbwells |
biblio.multiclass.query.staff, then facet_cache.retrieve, then pcrud.search.bre |
| 12:05 |
dbwells |
That's the end, I think for real this time. |
| 12:06 |
berick |
ok, good, that at least makes mores sense. |
| 12:07 |
dbwells |
It feels like a timing/promise resolution issue, but I can't easily see where. |
| 12:08 |
dbwells |
Or, again, maybe just something not right with our setup. |
| 12:09 |
dbwells |
berick: One other odd symptom, possibly unrelated. Occasionally, the facets do not load, or it appears that they load, then disappear. |
| 12:09 |
dbwells |
I can't reproduce it, but it has happened 3-4 times in testing this morning. |
| 12:09 |
berick |
dbwells: i have actually seen that one. |
| 12:10 |
berick |
same here, difficult to reproduce |
| 12:10 |
berick |
as far as the records go, all I can suggest at this point is adding console logs :( |
| 17:24 |
nfBurton |
That's really odd |
| 17:24 |
Bmagic |
no doubt |
| 17:28 |
Bmagic |
If you mark something lost after* it was checked in, will the system first move the item into checked out, then mark it lost in order to facilitate the billing properly? |
| 17:31 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:32 |
jeff |
Bmagic: any clues in the auditor tables with regard to the audit user or audit workstation? |
| 17:32 |
Bmagic |
those are blank, however, the editor column is populated with a staff account |
| 17:32 |
Bmagic |
my theory is that someone marked it lost (somehow) after it was checked in |
| 01:04 |
|
dbwells joined #evergreen |
| 01:15 |
|
bshum joined #evergreen |
| 01:37 |
|
yar joined #evergreen |
| 05:00 |
pinesol |
News from qatests: Failed Installing Evergreen pre-requisites <http://testing.evergreen-ils.org/~live/test.26.html#2019-03-26T04:40:24,364130820-0400 -0> |
| 05:00 |
pinesol |
News from qatests: Failed Building Evergreen <http://testing.evergreen-ils.org/~live/test.30.html#2019-03-26T04:40:24,390696480-0400 -2> |
| 05:00 |
pinesol |
News from qatests: Failed Running Evergreen tests <http://testing.evergreen-ils.org/~live/test.31.html#2019-03-26T04:40:24,418037892-0400 -4> |
| 05:00 |
pinesol |
News from qatests: Failed Installing Evergreen <http://testing.evergreen-ils.org/~live/test.32.html#2019-03-26T04:40:24,444235953-0400 -6> |
| 05:00 |
pinesol |
News from qatests: Failed Installing Dojo <http://testing.evergreen-ils.org/~live/test.35.html#2019-03-26T04:40:24,471526623-0400 -8> |
| 05:00 |
pinesol |
News from qatests: Failed configure apache <http://testing.evergreen-ils.org/~live/test.36.html#2019-03-26T04:40:24,498755526-0400 -10> |
| 05:00 |
pinesol |
News from qatests: Failed configure EG Action/Trigger <http://testing.evergreen-ils.org/~live/test.38.html#2019-03-26T04:40:24,524966532-0400 -12> |
| 05:00 |
pinesol |
News from qatests: Failed Create Evergreen Database <http://testing.evergreen-ils.org/~live/test.41.html#2019-03-26T04:40:24,553494577-0400 -14> |
| 05:00 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-03-26T04:40:24,579855051-0400 -16> |
| 05:00 |
pinesol |
News from qatests: Failed Running autogen.sh <http://testing.evergreen-ils.org/~live/test.44.html#2019-03-26T04:40:24,606282934-0400 -18> |
| 05:00 |
pinesol |
News from qatests: Failed Running pgTAP live tests <http://testing.evergreen-ils.org/~live/test.47.html#2019-03-26T04:40:24,632750868-0400 -20> |
| 05:00 |
pinesol |
News from qatests: Failed Running settings-tester.pl <http://testing.evergreen-ils.org/~live/test.48.html#2019-03-26T04:40:24,659089678-0400 -22> |
| 05:00 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live/test.49.html#2019-03-26T04:40:24,685532524-0400 -24> |
| 05:00 |
pinesol |
News from qatests: Failed Log Output: srfsh.log <http://testing.evergreen-ils.org/~live/test.58.html#2019-03-26T04:40:24,830537784-0400 -26> |
| 06:56 |
|
agoben joined #evergreen |
| 07:11 |
|
rjackson_isl joined #evergreen |
| 07:30 |
|
bdljohn joined #evergreen |
| 08:34 |
pinesol |
csharp: It really IS itself's fault! for bringin' csharp down |
| 08:44 |
JBoyer |
oh, that reminds me! Turns out that it's super easy to swap headless chrom(e|ium) for PhantomJS, especially in eg2 since karma-chrome-launcher is already installed. |
| 08:45 |
JBoyer |
The only problem is that while you can *run* chrome headless, you're probably still going to be stuck installing a lot of X libs. |
| 08:50 |
JBoyer |
So it's a little less ideal to run tests as just part of a regular install, but moving over would mean that when tests are run the version of JS would be current, so we could (obj) => { obj.cool_stuff; } all day long. |
| 08:52 |
|
mmorgan joined #evergreen |
| 09:15 |
|
tlittle joined #evergreen |
| 09:22 |
bos20k |
Hello. We are seeing an issue when library staff tries to catalog an item (not in acq). I think my analysis of the issue may be correct and I assume it is an issue with what the staff is doing somehow but I am not a cataloger so I'm not sure what may be going on. I will try to paste the information using paste.evergreen-ils.org. Any ideas would be greatly appreciated. |
| 11:19 |
pinesol |
Launchpad bug 1750894 in Evergreen "Wishlist: Store web staff workstation settings on the server" [Wishlist,Fix released] https://launchpad.net/bugs/1750894 |
| 11:20 |
mmorgan |
jeff: Yes, 3.2+ |
| 11:25 |
jeff |
mmorgan++ |
| 11:28 |
mmorgan |
I am looking at a 3.2.4 test server and the reporter interface won't load. I just get You are logged in as with no username, and Loading... Any ideas? |
| 11:56 |
pinesol |
[evergreen|Bill Erickson] LP1821067 Angular Czech translation bundle - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=17ddeaf> |
| 11:56 |
pinesol |
[evergreen|Bill Erickson] LP1821067 Angular i18n uses XMB; cs-CZ examples - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0dbc36d> |
| 12:02 |
|
wsmoak joined #evergreen |
| 12:09 |
* mmorgan |
believes both copies of the idl are the same, but will double check. |
| 12:10 |
mmorgan |
I see this in the console: GET https://egtraining.noblenet.org/reports/oils_rpt.xhtml?ses=75116f04bf85600a2162def63a294d78 net::ERR_INCOMPLETE_CHUNKED_ENCODING 200 (OK) |
| 12:11 |
JBoyer |
Oh, that would be caused by something else, haven't seen that one. |
| 12:11 |
JBoyer |
Where you testing anything specific? |
| 12:12 |
JBoyer |
Oh, and what version of OSRF? I wouldn't be too surprised about that if Eg wanted a newer version than was installed, perhaps. |
| 12:18 |
|
jihpringle joined #evergreen |
| 12:19 |
mmorgan |
JBoyer: You mean testing any specific code? Not in terms of reports. I'll try copying the idl. |
| 12:21 |
JBoyer |
I was confused that I couldn't find that error anywhere, looks like it's probably related to node/chrome interactions. |
| 12:22 |
JBoyer |
Also, because I almost clicked on that link not realizing what was in there, you may want to log out and start over. :) |
| 12:25 |
mmorgan |
Oops. Killed that session :) |
| 15:06 |
JBoyer |
Yeah, you could use the originally fetched user as the data for a plain template replacement on the page rather than as a model in an editable control. |
| 15:15 |
|
sandbergja joined #evergreen |
| 16:02 |
jeff |
okay, yep. that works. |
| 17:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:07 |
|
mmorgan left #evergreen |
| 17:23 |
jeff |
berick, JBoyer: this is what i was trying to do: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=39800262d06dfac14e80fcd10ff5e0dd0c01b52a for bug 1264746 |
| 17:23 |
pinesol |
Launchpad bug 1264746 in Evergreen "Add "email password reset" button to user editor" [Wishlist,In progress] https://launchpad.net/bugs/1264746 - Assigned to Jeff Godin (jgodin) |
| 17:32 |
jeff |
Hrm. I should handle the case where the barcode's been changed also, since we don't have a "request password reset link email via userid" option. |
| 18:08 |
pinesol |
[evergreen|Dan Wells] Fix Asciidoc levels in 3.3 release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c09ef9a> |
| 18:17 |
|
sandbergja joined #evergreen |
| 18:29 |
dbwells |
After a few brief rounds of fixes/enhancements, the 3.3.0 RC is now available in the previews area: https://evergreen-ils.org/downloads/previews/Evergreen-ILS-3.3.0.tar.gz As named, this will be 3.3.0 barring any meltdowns discoverd in testing tomorrow. More testing would be much appreciated! |
| 18:31 |
rhamby |
dbwells++ |
| 19:00 |
|
sandbergja joined #evergreen |
| 19:25 |
jeff |
While you can request and complete a password reset with an inactive barcode, you can't actually then log in with said barcode... so I guess we'll warn about that also. |
| 00:25 |
|
jamesrf joined #evergreen |
| 00:42 |
|
sandbergja joined #evergreen |
| 05:00 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-03-25T04:57:33,988624201-0400 -0> |
| 05:53 |
|
jamesrf joined #evergreen |
| 06:43 |
|
JBoyer joined #evergreen |
| 06:56 |
|
jamesrf joined #evergreen |
| 10:17 |
krvmga |
the key text element in the error refers to where the ISBN typically is and the UPC should be if no ISBN |
| 10:30 |
bshum |
krvmga: That sounds similar to https://bugs.launchpad.net/evergreen/+bug/1549393 |
| 10:30 |
pinesol |
Launchpad bug 1549393 in Evergreen 2.9 "AddedContent: Invalid ISBN's are sent to Content Cafe as blank string" [Medium,Fix released] |
| 10:30 |
bshum |
Which is an ancient and closed bug |
| 10:31 |
bshum |
Are you sure it's a valid UPC and no ISBN on the bib record you're checking? |
| 10:31 |
|
Christineb joined #evergreen |
| 10:32 |
bshum |
Interesting |
| 10:32 |
bshum |
That fix that Stompro provided in that bug only applied to ISBN/ISSN |
| 10:33 |
bshum |
So maybe it's an undef UPC value |
| 10:33 |
bshum |
https://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=15890219867ea44524a36b8becfaa12594984927 |
| 10:34 |
bshum |
See around line 184 of AddedContent.pm where it yanks out bad isbn/issn, maybe we need to add upc there |
| 10:37 |
bshum |
Yeah that seems logical. I don't have ContentCafe to test, but the symptoms and code seem to read out the way |
| 10:38 |
bshum |
So maybe try adding @upcs = grep {defined} @upcs; |
| 10:39 |
bshum |
Like the other ones there |
| 10:39 |
bshum |
Stompro++ |
| 10:40 |
bshum |
krvmga++ |
| 11:33 |
dbs |
bshum++ |
| 12:02 |
|
khuckins joined #evergreen |
| 12:09 |
|
jihpringle joined #evergreen |
| 14:44 |
csharp |
looks like this is some corner case with metarecord hold cancellation that I'm going to have to dig into in a week where I'm not under this much pressure |
| 14:44 |
csharp |
(migrating PINES to new colo in 2 weeks and I'm off next week) |
| 14:45 |
JBoyer |
csharp++ # good vibes! |
| 14:55 |
jeff |
Good reason to test "unusual" reingest methods. Passing a list of display fields to metabib.reingest_metabib_field_entries() means that only those display fields will be present after it completes. |
| 14:56 |
jeff |
i.e., if there were other display fields present for that record before, they will be removed if they are not in the supplied list of fields to reingest. |
| 14:56 |
jeff |
(at least in 3.1) |
| 14:56 |
jeff |
(mild surprise, not outright shock) |
| 15:09 |
csharp |
JBoyer: thanks! |
| 15:21 |
|
khuckins joined #evergreen |
| 16:19 |
pastebot |
"phasefx" at 64.57.241.14 pasted "user/berick/lp1811288-fm-editor-combobox" (78 lines) at http://paste.evergreen-ils.org/10823 |
| 16:30 |
berick |
bit of an edge case, where we pass in hard-coded values |
| 16:31 |
phasefx |
edge case is my name.. or maybe that was head case |
| 16:32 |
berick |
chaos-powers++ |
| 16:33 |
phasefx |
testing. I can probably streamline my build process.. it's a sledgehammer |
| 16:34 |
phasefx |
berick: all good, new and chaos resistant |
| 16:35 |
pinesol |
[evergreen|Jane Sandberg] LP1797934: follow-up: make the reservations tab in MyOpac optional - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5046ced> |
| 16:36 |
berick |
phasefx++ |
| 16:39 |
phasefx |
berick: minor one, tanget. got an ERROR Error: Uncaught (in promise): Object: {"dismissed":true,"message":"cross_click"} clicking the X to close the fm editor dialog |
| 16:49 |
berick |
may as well make the sandbox examples as useful as possible... |
| 16:53 |
phasefx |
berick: looks good! |
| 16:54 |
phasefx |
berick: though I must confess, I didn't expec to really create an entry in config.marc_field just now :D |
| 16:56 |
berick |
oh yeah, it's testing the actual plumbing |
| 16:57 |
pinesol |
[evergreen|Bill Erickson] LP1821409 Ang admin editor clears fields on new - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=29b100c> |
| 17:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:03 |
pinesol |
Showing latest 5 of 6 commits to Evergreen... |
| 17:03 |
pinesol |
[evergreen|Bill Erickson] LP1811288 Angular fm-editor uses combobox - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d63c7c3> |
| 17:03 |
pinesol |
[evergreen|Bill Erickson] LP1811288 Basic admin page readonlyFields repair - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=00de314> |
| 17:03 |
pinesol |
[evergreen|Bill Erickson] LP1811288 Admin grids preload combobox values - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9e69671> |
| 17:03 |
pinesol |
[evergreen|Bill Erickson] LP1811288 Allow Combobox to default to field id - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a3731c9> |
| 17:03 |
pinesol |
[evergreen|Bill Erickson] LP1811288 Sandbox editor handles dismissals - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fc8bd35> |
| 17:05 |
Bmagic |
When something is a direct charge - it doesn't seem to have any rows in acq.lineitem_detail. Is there any way to connect those fund_debit's to anything? The invoice_entry is null |
| 17:07 |
|
mmorgan left #evergreen |
| 17:15 |
berick |
Bmagic: acq.po_item |
| 05:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 08:02 |
|
collum joined #evergreen |
| 08:07 |
|
troy____ joined #evergreen |
| 08:08 |
|
bshum_ joined #evergreen |
| 15:13 |
berick |
ok it's fixed in the branch for bug 1811288 |
| 15:13 |
pinesol |
Launchpad bug 1811288 in Evergreen "Angular Fieldmapper Editor should use combobox for linked fields" [Medium,New] https://launchpad.net/bugs/1811288 |
| 15:13 |
berick |
https://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=e9d2882b79816ba52e1db55a6cc96990b3526b68 |
| 15:13 |
sandbergja |
Oh, great! |
| 15:13 |
sandbergja |
berick++ |
| 15:17 |
sandbergja |
dbwells: what are the chances that bug 1811288 could get into the release candidate, if I could test it and sign off on it within the next few hours? |
| 15:17 |
pinesol |
Launchpad bug 1811288 in Evergreen "Angular Fieldmapper Editor should use combobox for linked fields" [Medium,New] https://launchpad.net/bugs/1811288 |
| 15:17 |
sandbergja |
it would be really nice to save users and servers from dropdown menus that are populated with every single bib record in the catalog! |
| 15:24 |
dbwells |
It's a pretty big change at this late hour, and the diffs are a little hard for me to read. |
| 15:33 |
berick |
ok, so I rebased user/berick/lp1811288-fm-editor-combobox to master |
| 15:33 |
berick |
retested and confirmed it fixes the booking issue |
| 15:34 |
berick |
and that it behaves as expected for creating booking resources, etc. |
| 15:47 |
dbwells |
sandbergja: My brain is getting a little leaky with all the various eg2 branches, so I am starting to test a few to hopefully push in as well. Just a heads up in case some merge conflicts result. |
| 15:48 |
berick |
dbwells: holler if I can be of assistance |
| 15:48 |
dbwells |
will do |
| 16:07 |
dbwells |
berick: Testing #1807461, I see a bug, but I think it is unrelated. If you edit a row, you can no longer create new rows. The old edit data is still there, so I am guessing it might be an ID collision, as the old ID is there, and you can't delete it. Does that sound familiar? |
| 16:08 |
dbwells |
"old edit data is still there" meaning the editor form is still populated with all data from the edit, even when creating new. |
| 16:11 |
* berick |
looks |
| 16:12 |
dbwells |
This was in the "Claim Type" editor, since that is what was referenced on the bug, but it probably manifests elsewhere as well. |
| 16:14 |
pinesol |
[evergreen|Bill Erickson] LP#1807458 Angular admin grid Edit Selected option - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=89948f5> |
| 16:47 |
sandbergja |
in case of really big lists? |
| 16:51 |
berick |
sandbergja: exactly. that's how the dojo widget handled it, so i tried to keep it consisten |
| 16:55 |
sandbergja |
berick: thanks! |
| 17:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:03 |
pinesol |
[evergreen|Bill Erickson] LP1812670 Angular grid shows selector labels - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8480ca2> |
| 17:03 |
pinesol |
[evergreen|Bill Erickson] LP#1819179: Angular value formatter gets link smarts - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2fe4212> |
| 17:03 |
pinesol |
[evergreen|Bill Erickson] LP1819179 IDL2js includes 'map' attribute data - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d26ece2> |
| 17:03 |
pinesol |
[evergreen|Bill Erickson] LP1819179 PCRUD selector fleshing handles maps - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1db81cf> |
| 17:08 |
|
mmorgan left #evergreen |
| 17:12 |
berick |
dbwells++ |
| 17:16 |
sandbergja |
berick: I like all the comboboxes, but I'm a little hesitant about how many interfaces that used to preload those values (both in dojo, and of course under the current ng client) now would not. I suspect that -- in some of those cases -- users rely on being able to see a complete list of possible values. |
| 05:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:01 |
|
agoben joined #evergreen |
| 07:15 |
|
rjackson_isl joined #evergreen |
| 07:34 |
|
bdljohn joined #evergreen |
| 08:40 |
|
bos20k joined #evergreen |
| 08:53 |
|
mmorgan joined #evergreen |
| 08:54 |
Dyrcona |
So, I think my issues with the fine generator and open-ils.storage are memory issues. |
| 08:57 |
Dyrcona |
Because, I started running the fine generator on a test VM yesterday and today, I see that is has used swap, and there's a decent amount of RAM in the O/S cache: 4GB. |
| 08:57 |
Dyrcona |
I'm working on getting the rss sizes of the drones, the listener is not presently all that big. |
| 08:59 |
|
aabbee joined #evergreen |
| 09:07 |
Dyrcona |
Interesting... All of the storage processes, including the listener have had 15,000+ minor page faults while running. That's no big deal, right, because that's accessing stuff that's in RAM already. |
| 09:44 |
|
nfBurton joined #evergreen |
| 09:55 |
|
tlittle joined #evergreen |
| 10:01 |
|
tlittle joined #evergreen |
| 10:05 |
Dyrcona |
So, our storage drones seem to use around 260MB of RAM apiece and I'm cycling through them rather quickly, at least on this test machine. |
| 10:06 |
Dyrcona |
Perhaps, I should up the connection count settings on the machine that runs the fine generator? |
| 10:22 |
jeff |
I wouldn't focus on the swap usage too much, especially that amount. If vm.swappiness is at the default of 60, swap usage isn't something that indicates "we're running out of physical memory". |
| 10:25 |
Dyrcona |
jeff: I know that it normally doesn't. It can, though if your swap usage gets really high and you have a large number of swap ins and swap outs....When swap usage is 100%, you've got real problems. :) |
| 10:26 |
Dyrcona |
I also think that bumping the connection count for storage on the utility server will help, as I'll cycle through drones less quickly that way. |
| 10:27 |
jeff |
Sure, just trying to talk you down from chasing "why did my system use 1.6 megabytes of swap" :-) |
| 10:27 |
Dyrcona |
Yeah, and it dropped to 160K rather soon after. |
| 10:28 |
Dyrcona |
The fine generator has been running for the past 1.5 hours on my test vm, and it is still doing something as I'm tailing syslog. |
| 10:29 |
Dyrcona |
The test db is also busy with other things. |
| 10:29 |
Dyrcona |
when this stops. I'll up the connection count by a factor of 10. |
| 10:34 |
|
collum joined #evergreen |
| 10:36 |
Dyrcona |
Looks like drones are being recycled at a rate of about 1 every 3 minutes. |
| 10:47 |
Dyrcona |
Seems to be going through cstore drones at a similar clip, too. That must be some of the storage calls using cstore. |
| 10:48 |
Dyrcona |
Think I'll up the max requests on cstore for the next test. |
| 11:22 |
phasefx |
@later tell sandbergja re: LP1721109, I noticed a syntax error in line 430 of cat/item/app.js, with var all_items = itemSvc.copies.map((item) => {return item.id}); |
| 11:22 |
pinesol |
phasefx: The operation succeeded. |
| 11:32 |
jeff |
certificate expired on https://yeti.esilibrary.com |
| 11:36 |
|
sandbergja joined #evergreen |
| 11:37 |
Dyrcona |
Lp 1721109 |
| 11:37 |
pinesol |
Launchpad bug 1721109 in Evergreen 3.2 "Web client: Editing item information from the item status screen does not automatically update item status display" [Medium,Fix committed] https://launchpad.net/bugs/1721109 |
| 11:37 |
phasefx |
also, I only saw the syntax error with npm, haven't tested it in a real browser. Could be a version issue on my end given that the functionality tested out |
| 11:38 |
phasefx |
npm and rhino |
| 11:38 |
berick |
that would be interesting if browsers supported arrow functions |
| 11:38 |
berick |
not impossible |
| 11:39 |
Dyrcona |
rhino? Really? |
| 11:45 |
Dyrcona |
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions#Browser_compatibility |
| 11:45 |
berick |
Dyrcona: neat |
| 11:45 |
|
khuckins joined #evergreen |
| 11:45 |
phasefx |
fwiw, the live tester behaves the same (reports a syntax error) but doesn't flag a warning/error with the QA tests |
| 11:46 |
Dyrcona |
phasefx: You're getting the syntax from npm run test ? |
| 11:46 |
phasefx |
Dyrcona: yeap |
| 11:47 |
phasefx |
http://testing.evergreen-ils.org/~live/cronoutput.txt |
| 11:47 |
* Dyrcona |
usually skips that. |
| 11:48 |
berick |
probably best to de-arrow-ify for now |
| 11:48 |
|
sandbergja_ joined #evergreen |
| 11:49 |
Dyrcona |
So, PhantomJS doesn't like it. |
| 11:49 |
phasefx |
Dyrcona: I tried to make the installer match the instructions on the website as closely as possible; we call for npm run test there |
| 11:49 |
Dyrcona |
phasefx: Yeah, it definitely makes sense to run the test on the QA testing server. :) |
| 11:49 |
phasefx |
:D |
| 11:50 |
Dyrcona |
I usually skip it on my own installations because it usually passes and I'm lazy. :) |
| 11:50 |
Dyrcona |
I do run it for new stuff that I'm doing, though. |
| 11:51 |
phasefx |
so the actual shell level return value from npm run test is 0, which is why the tests didn't sound an alarm |
| 11:51 |
phasefx |
though I could start looking for it explicitly |
| 11:51 |
phasefx |
http://testing.evergreen-ils.org/~live/test.28.html |
| 11:53 |
* Dyrcona |
agrees with berick that it is probably best to de-arrowify it for now. |
| 11:53 |
Dyrcona |
Shame to miss out on language features from the 1950s, though. :) |
| 11:54 |
JBoyer |
Oh, and as for the arrow func, it's probably complaining because what that really says is "return return item.id;" -- The only contents of an arrow function are "return (your text here)" |
| 11:57 |
jeff |
so that's unlikely to happen anytime soon. |
| 11:58 |
sandbergja |
JBoyer: hahaha, that's what I thought. :-) |
| 11:58 |
JBoyer |
Is it still used by node, or only the version of node that builds the AngularJS parts of the client? |
| 11:59 |
berick |
JBoyer: it's used for headless unit tests |
| 11:59 |
berick |
node doesn't use it |
| 11:59 |
JBoyer |
Ah, that's where I was getting confused. |
| 11:59 |
JBoyer |
berick++ |
| 12:02 |
|
jeff_ joined #evergreen |
| 12:30 |
nfBurton |
sandbergja++ |
| 12:32 |
|
afterl joined #evergreen |
| 13:04 |
|
krvmga joined #evergreen |
| 13:21 |
Dyrcona |
Doing another fine_generator.pl run while monitoring drone memory usage. Looks like I was right, the first drone that gets the list of overdue circs is the biggest, but not by much in this test run. |
| 13:23 |
berick |
3043651 |
| 13:23 |
pinesol |
berick: [opensrf|Bill Erickson] LP#1706147 Perl Force-Recycle drone option - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=3043651> |
| 13:23 |
berick |
Dyrcona: ^-- may be of interest |
| 13:24 |
berick |
if a drone gobbles up a lot of ram, the API in question can be modified to exit after a single call of said API. |
| 13:25 |
Dyrcona |
Might be handy, but for this run it's only using about 13MB more than the others. |
| 13:30 |
Dyrcona |
I'll test that patch later, as in tomorrow or after next week. |
| 13:31 |
Dyrcona |
As expected, after upping max requests for both storage and cstore, drones are sticking around longer. It also took longer to spawn a 6th cstore drone, though that may not be related to the setting change. |
| 13:38 |
|
Christineb joined #evergreen |
| 13:38 |
Dyrcona |
I expected storage drones to start dying off by now, but they haven't. |
| 14:22 |
miker |
#topic Release Manager (Dan Wells) |
| 14:23 |
|
Topic for #evergreen is now Release Manager (Dan Wells) (Meeting topic: EOB meeting for 2019-03-21, agenda: https://wiki.evergreen-ils.org/doku.php?id=governance:minutes:2019-03-21) |
| 14:23 |
miker |
dbwells: sir, have you anything for us? |
| 14:23 |
dbwells |
Not too much to report. I'll be building and testing the RC over the next couple days. |
| 14:23 |
dbwells |
We also need to still sort out some of the new translation bits, but we're getting there. |
| 14:23 |
dbwells |
It's been a pretty quiet and routine release cycle, which I think is as expected. |
| 14:23 |
dbwells |
Any questions? |
| 14:24 |
terran |
dbwells++ |
| 14:24 |
collum |
dbwells++ |
| 14:24 |
miker |
dbwells: one -- should we be avoiding angular7 infrastructure pushes in 3.3? |
| 15:29 |
JBoyer |
collum++ |
| 15:30 |
agoben |
collum++ |
| 15:35 |
|
afterl left #evergreen |
| 17:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:04 |
|
mmorgan left #evergreen |
| 17:25 |
|
yboston joined #evergreen |
| 18:04 |
|
dbwells_ joined #evergreen |
| 01:21 |
|
sandbergja_ joined #evergreen |
| 05:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:48 |
|
agoben joined #evergreen |
| 07:11 |
|
rjackson_isl joined #evergreen |
| 07:36 |
|
bdljohn joined #evergreen |
| 15:32 |
berick |
dbwells++ |
| 15:32 |
berick |
thanks |
| 15:40 |
phasefx |
Stompro: Dyrcona: the call number pull list fix (lp1749502), for me, if you do Print Full List twice in a row, it renders the affix id's and not the labels |
| 15:41 |
csharp |
ok, so the next step, I think, is to implement cross-domain registration in a test environment. Does anyone out there have docs or examples I could use for this? I have a high-level understanding of what needs to happen, but I'm not sure how to actually do it |
| 15:42 |
* csharp |
steps away for a bit but will be back soon |
| 15:49 |
|
sandbergja_ joined #evergreen |
| 15:50 |
berick |
csharp: take w/ grain of salt cuz I'm not using it, but IIRC you just have to add public and private <router> entries in opensrf_core.xml per each host |
| 15:50 |
berick |
that's assuming the bricks can already route to each other and jabber is using non-localhost domains (e.g. private.brick01, public.brick01, etc.) |
| 15:52 |
Dyrcona |
phasefx: I see that one some rows but not others. I'm getting -1 on some prefixes. |
| 15:52 |
Dyrcona |
Also, doing it a third time, everything looks OK. |
| 15:53 |
Stompro |
phasefx, Interesting, I'll test that out. |
| 15:55 |
phasefx |
I imagine most folks will only invoke it once per page load, but my chaos powers are compulsive |
| 15:55 |
Dyrcona |
Doesn't seem to be much rhyme nor reason when it happens and if it it is prefix, suffix, or both. |
| 15:55 |
Dyrcona |
Well, if you do it again and again you get different results each time, at least I seem to. |
| 16:09 |
phasefx |
Stompro: sure, it's back up, but with an extra commit beyond master |
| 16:09 |
phasefx |
in the pull list grid UI, no less :) but shouldn't affect the bug |
| 16:10 |
Dyrcona |
Stompro: I saw the same thing as phasefx. I could open it, look at it, close, then open it again. |
| 16:12 |
Stompro |
phasefx, yep, I see it too on your test system. Hmm, I'll check to see what I missed when creating the commit. |
| 16:15 |
Dyrcona |
I'm only seeing it with affixes of -1. phasefx did you see it with others? |
| 16:15 |
phasefx |
Dyrcona: yes, the REF one from concerto |
| 16:16 |
Dyrcona |
OK. Could be that the list I was looking at had no actual affixes. |
| 16:16 |
Dyrcona |
I was using production data with a small library. |
| 16:16 |
phasefx |
I created a pull list in concerto by hitting up 3 bibs with copy level holds, and specifically modifying the item for the 2nd hold to have a prefix and suffix |
| 16:17 |
Dyrcona |
Good way to test it. I just logged in and brought up the pull list. :) |
| 16:17 |
phasefx |
I also played with location affixes too, because I forgot those were just for label printing |
| 16:19 |
* phasefx |
is poking at lp1779316 and wanted to see what changes were made recently |
| 16:19 |
Dyrcona |
I wonder if fleshing the affixes would be better than going back and retrieving them? We seem to do a lot of pcrud lookups in the web staff client for that sort of thing. |
| 16:57 |
|
sandbergja__ joined #evergreen |
| 17:00 |
sandbergja__ |
Hey all -- I've got Evergreen running on localhost, using docker. But Firefox doesn't like weird ports like 7682 under a self-signed certificate. Does anybody know if there's a way I can adjust about:config so that Firefox isn't so picky about that? |
| 17:00 |
sandbergja__ |
FWIW, I can use Chromium just fine. |
| 17:02 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-03-20T16:59:00,937625555-0400 -0> |
| 17:03 |
sandbergja__ |
I tried setting network.security.ports.banned.override to 7682, but that didn't help :-( |
| 17:05 |
|
mmorgan left #evergreen |
| 17:13 |
berick |
sandbergja__: try navigating to https://HOST:7682/osrf-websocket-translator |
| 00:02 |
|
sandbergja joined #evergreen |
| 05:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:15 |
|
rjackson_isl joined #evergreen |
| 07:31 |
|
agoben joined #evergreen |
| 07:41 |
|
bdljohn joined #evergreen |
| 11:26 |
Dyrcona |
Ok. I take that back. Of the two that are active, one has a custom granularity that works out to daily, the other doesn't. |
| 11:27 |
Dyrcona |
Ours are working, but we're on 3.0.13. |
| 11:28 |
pastebot |
"Bmagic" at 64.57.241.14 pasted "Trigger logs" (7 lines) at http://paste.evergreen-ils.org/10507 |
| 11:28 |
Dyrcona |
They seem to be working on our 3.2 test machine. |
| 11:29 |
Dyrcona |
To answer your question, no. If that's the main trigger that marks items lost it goes by checkout.due. |
| 11:30 |
Dyrcona |
The notices and extra triggers that play off something going lost should have lost.auto. |
| 11:30 |
Bmagic |
yep, that's what I've got |
| 16:45 |
|
nfBurton joined #evergreen |
| 16:45 |
csharp |
okay - websocketd is back in place - no significant difference between now and before with apache2-websockets |
| 16:45 |
csharp |
also looks like restarting services staves off the issue for a while |
| 16:46 |
nfBurton |
Quick Q: Running an update on my test server and keep getting " duplicate key value violates unique constraint "upgrade_log_pkey"". Is there something wrong with my DB or the upgrade script? |
| 16:46 |
nfBurton |
The DB upgrades are not my friend today |
| 16:47 |
csharp |
nfBurton: sounds like you're trying to apply an upgrade you already have? |
| 16:47 |
nfBurton |
I'm not though... |
| 16:52 |
nfBurton |
I've been commenting those out since they aren't Combo Breakers |
| 16:53 |
csharp |
it only happens if you apply upgrade scripts outside normal "version" upgrades |
| 16:53 |
csharp |
which I think all of us do from time to time |
| 16:54 |
nfBurton |
Yeah. This is just my test which I thought was in line with my production site but may have pushed some updates along at some point |
| 16:55 |
nfBurton |
Is there a generally accepted reinjest script for the whole catalog as well? While I am here |
| 16:55 |
nfBurton |
I should run that too |
| 16:56 |
csharp |
nfBurton: Open-ILS/src/support-scripts/pingest.pl is nice if you have a large database |
| 17:01 |
csharp |
hmm |
| 17:01 |
nfBurton |
Yeah |
| 17:01 |
nfBurton |
I have set up 3 new collections and they all do the same thing |
| 17:01 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-03-19T16:57:59,497208919-0400 -0> |
| 17:01 |
nfBurton |
I feel like a CRON job must clean them up if it randomly happens |
| 17:03 |
csharp |
might need to look directly at the metabib data for the records where it's not changing |
| 17:04 |
csharp |
that's getting into territory I'm less familiar with day-to-day, but have had to troubleshoot before |
| 00:46 |
|
sandbergja joined #evergreen |
| 04:37 |
|
jamesrf joined #evergreen |
| 05:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:00 |
|
JBoyer joined #evergreen |
| 07:02 |
|
agoben joined #evergreen |
| 07:10 |
|
rjackson_isl joined #evergreen |
| 09:59 |
Dyrcona |
berick: I think csharp was referring to the fact that apache2-websocket processes would go ballistic from time to time, not that it made a difference in drone usage. |
| 09:59 |
Dyrcona |
At least, that's what I meant about websocketd making a difference. |
| 10:04 |
csharp |
berick: so the idle timeout with websocketd is set in the nginx config, right? (as opposed to the apache config for apache2-websockets where we left the nginx timeouts higher) |
| 10:04 |
berick |
csharp: correct |
| 10:05 |
berick |
as a test, maybe knock it down to 1 minute |
| 10:05 |
miker |
csharp: opensrf is already able to distribute load. you can create a single xmpp domain, as Dyrcona suggests, or just tell the services about all the existing domains (which requires they have non-localhost addresses and unique names) |
| 10:05 |
csharp |
berick: thanks |
| 10:05 |
* Dyrcona |
uses non-localhost addresses anyway, but doesn't do cross-brick communication, yet. |
| 15:40 |
miker |
gmcharlt: will look, sec |
| 15:44 |
berick |
forgot all about that stuff |
| 15:45 |
berick |
gmcharlt: i trust your research there. |
| 15:48 |
miker |
gmcharlt: hrm. it looks to me like we still eval it into place if no added content provider is defined in opensrf.xml, no? I haven't looked past the named commit yet |
| 15:49 |
miker |
gmcharlt: we don't in master... ok, it does look dead to me, indeed |
| 15:51 |
miker |
looks like we can drop a test! :) |
| 15:52 |
miker |
Open-ILS/src/perlmods/t/06-OpenILS-Application-Search.t specifically |
| 15:52 |
miker |
or, one in there |
| 15:53 |
|
bdljohn joined #evergreen |
| 16:25 |
csharp |
...and we're back to drone saturation |
| 16:25 |
csharp |
might have to revert to apache2-websockets |
| 16:58 |
csharp |
sounds more like the album name than the band name though |
| 17:00 |
bshum |
jeff++ berick++ csharp++ # I miss production issues (not really) |
| 17:00 |
csharp |
it's a mixed bag - the soul-crushing lows are often followed by dizzying highs |
| 17:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:01 |
* bshum |
now wants pumpkin pie |
| 17:01 |
bshum |
It's too early for this. |
| 17:02 |
* bshum |
wanders off, but will read the rest of this adventure story later |
| 17:41 |
csharp |
this feels like something that could be fixed with tuning configs though |
| 17:42 |
csharp |
at this very moment, everything is pretty balanced across (after restarting opensrf to reactivate backlog queuing) |
| 17:42 |
csharp |
also just generally calmer |
| 17:43 |
berick |
yeah, probably over the hump |
| 17:44 |
berick |
well, keep us posted, especially if you decide to revert websocketd to test. |
| 17:44 |
csharp |
thanks! |
| 17:44 |
berick |
guessing tests now won't prove much |
| 17:45 |
csharp |
agreed |
| 19:33 |
|
Dyrcona joined #evergreen |
| 20:26 |
|
gryffonophenomen joined #evergreen |
| 05:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 05:17 |
|
RBecker joined #evergreen |
| 06:59 |
|
agoben joined #evergreen |
| 07:14 |
|
rjackson_isl joined #evergreen |
| 13:05 |
Dyrcona |
Bmagic 00:00:06, 00:00:08, and one is 5 minutes. |
| 13:05 |
Dyrcona |
RMiller_ I'm working on a complete insert SQL for you. |
| 13:06 |
RMiller_ |
Thank you! I'm starting to figure out SQL stuff a little, but I don't want to make a bigger mess |
| 13:08 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "RMiller_ Should work. I have not tested it." (9 lines) at http://paste.evergreen-ils.org/10296 |
| 13:08 |
mmorgan |
Dyrcona++ |
| 13:12 |
RMiller_ |
That fixed it! Check in is working now! |
| 13:12 |
RMiller_ |
Thank you so much! |
| 13:12 |
Dyrcona |
You're welcome. |
| 13:29 |
* Dyrcona |
is going to reboot the laptop. |
| 13:38 |
|
Dyrcona joined #evergreen |
| 14:24 |
Stompro |
Dyrcona, about splitting the code up. Does each commit need to be fully independent of each other for a situation like this, or can they build off of each other, seperate commits in the same branch that should be tested together? |
| 14:26 |
Dyrcona |
Stompro: Either way, could also all be in one commit. It depends on the tickets, etc. |
| 14:26 |
Dyrcona |
I prefer to split things up into logical chunks and prefer not to have branches that cover multiple Lp bugs, but I sometimes do the latter. |
| 14:27 |
* Dyrcona |
is not a huge fan of omnibus branches or bugs, but deals with 'em when they happen. |
| 14:29 |
Dyrcona |
More specifically, I was offering to help if you had a single commit, say, that you wanted to split into multiple commits. |
| 14:44 |
|
stephengwills joined #evergreen |
| 14:52 |
|
yboston joined #evergreen |
| 17:01 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-03-15T16:58:14,560346605-0400 -0> |
| 17:05 |
|
mmorgan left #evergreen |
| 17:44 |
|
mcgriff joined #evergreen |
| 18:42 |
|
stephengwills joined #evergreen |
| 00:23 |
|
sandbergja joined #evergreen |
| 05:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:32 |
|
JBoyer_alt joined #evergreen |
| 06:37 |
|
bos20k joined #evergreen |
| 06:55 |
|
agoben joined #evergreen |
| 09:49 |
|
sandbergja joined #evergreen |
| 10:03 |
pinesol |
[evergreen|Bill Erickson] LP1739293 Record merge horizontal; optional holdings - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=29882b4> |
| 10:03 |
pinesol |
[evergreen|Bill Erickson] LP1739293 Record merge fits container - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d2ad575> |
| 10:03 |
Bmagic |
csharp: Do you have a machine seperate from the production cluster that you can test on? Things started becoming more clear once I did that |
| 10:03 |
pinesol |
[evergreen|Bill Erickson] LP1739293 Record merged edit-in-place avoid wrap - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=df8973b> |
| 10:13 |
|
Dyrcona joined #evergreen |
| 10:40 |
csharp |
Bmagic: were you able to resolve your issue? |
| 10:40 |
Bmagic |
my issue was resolved by uncommenting the remote IP business in eg_vhost.conf |
| 10:40 |
csharp |
(yes, I do have a couple of production-ish test clusters) |
| 10:40 |
csharp |
ok cool |
| 10:41 |
Bmagic |
Not the same as your issue though |
| 10:41 |
Bmagic |
(We've not tried the org unit editor on our new production environment though, we may have the same issue) |
| 10:42 |
Bmagic |
berick++ # remote IP |
| 12:58 |
sandbergja |
RMiller: no problem! FWIW, this can be super helpful for questions like that: http://docs.evergreen-ils.org/3.2_schema/ |
| 13:00 |
Dyrcona |
I'd do something more complicated for the org_units. |
| 13:02 |
RMiller |
My org units are really really simple at the moment, so I think this does the trick for now, unless there's something else I should know? |
| 13:05 |
Dyrcona |
Yeah, I was just testing the SQL before sharing it. The work firewall doesn't always play nice. |
| 13:05 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "Rmiller: Getting org_units that can have users" (5 lines) at http://paste.evergreen-ils.org/10236 |
| 13:06 |
RMiller |
Oh, gotcha. I can see how that would be handy. |
| 13:10 |
sandbergja |
Dyrcona++ |
| 16:53 |
gsams |
Bmagic: I'd be all for that. |
| 16:54 |
Bmagic |
seems like a simple solution |
| 16:54 |
Bmagic |
replacing \n with <br /> |
| 17:01 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-03-14T17:00:39,182624603-0400 -0> |
| 17:08 |
|
bdljohn left #evergreen |
| 17:10 |
Dyrcona |
For every problem, there is a solution that is simple, obvious and wrong. :) |
| 17:17 |
|
AMM_ joined #evergreen |
| 00:39 |
|
sandbergja joined #evergreen |
| 02:09 |
|
yar joined #evergreen |
| 05:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:55 |
|
Dyrcona joined #evergreen |
| 06:59 |
|
agoben joined #evergreen |
| 07:05 |
|
jamesrf joined #evergreen |
| 11:53 |
berick |
miker: I feel like a dummy. Anyway, I like how your branch adds smarts to FormatService (plus grid additions), so it can be used in grid and non-grid contexts and I like how mine adds the logic to pcrud so it's not limited to admin pages. I'd like to merge the two if that works for you. |
| 11:53 |
berick |
s/the logic/the link-fleshing logic/ |
| 11:54 |
terran |
berick++ for commits! |
| 11:55 |
miker |
berick: +1. one thought, instead of using virtual=true, should we use reltype={has_a|might_have} instead? (though we may have to be careful of map=$something) |
| 11:56 |
miker |
so that we can do might_have, that is |
| 11:56 |
miker |
or... are those not virtual... gah, going to go confirm |
| 11:57 |
miker |
might_have is virtual, so we'd need to test reltype for that |
| 11:58 |
miker |
(we could make map=$something cases work, of course, by jumping through the remote link) |
| 12:00 |
miker |
FTR, there are only 2 instances of might_have with a map |
| 12:00 |
miker |
they're on bre: metarecord and language |
| 12:00 |
berick |
miker: so instead of this: filter(f => f.datatype === 'link' && !f.virtual) |
| 12:00 |
berick |
something like: filter(f => f.datatype === 'link' && (f.rel_type === 'has_a' || f.rel_type === 'might_have')) |
| 12:01 |
miker |
right, that's my thought. though I'm not sure if we surface the map attr in idl2JS |
| 12:03 |
miker |
we ... don't seem to: {name:"metarecord",label:"Metarecord",virtual:true,type:"link",key:"source","class":"mmrsm",reltype:"might_have",datatype:"link"} |
| 12:04 |
miker |
berick: but ... we don't show non-virt fields in grids via * in any case, do we? |
| 12:04 |
berick |
miker: that's true, it filters those out when auto-generating fields |
| 12:05 |
miker |
however, I'd still advocate for testing reltype='has_a' rather than virtual='false' |
| 12:06 |
miker |
because if we do expand to showing might-have's (or even doing something smarter with has_many's, like counts or something) then it's more obvious. |
| 12:06 |
miker |
IOW |
| 12:07 |
miker |
filter up front via virtual now, and work on the result based on the more direct description (reltype). that feels like a better separation of concerns to me |
| 12:07 |
berick |
+1 |
| 12:08 |
miker |
awesome, thanks berick! |
| 12:08 |
miker |
berick++ |
| 13:39 |
pinesol |
[evergreen|Chris Sharp] LP#1709698 - stamping upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c20bfea> |
| 13:48 |
Dyrcona |
Calling 1157 |
| 14:02 |
|
terran joined #evergreen |
| 14:03 |
pinesol |
[evergreen|Bill Erickson] LP#712490 Vandelay merge-based field replacement - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=23293c7> |
| 14:03 |
pinesol |
[evergreen|Bill Erickson] LP#712490 Vandelay replace/merge PGTAP tests - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=99b75e0> |
| 14:03 |
pinesol |
[evergreen|Jason Stephenson] Lp 712490: Stamping UPgrade Script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f098f38> |
| 14:16 |
terran |
abneiman++ for hitting 100 tag/bug updates! |
| 14:17 |
csharp |
calling 1158 |
| 14:17 |
abneiman |
:-D I knew I was close but thanks for the shoutout! |
| 16:37 |
abneiman |
yeah, I'm looking at the oldest ones still marked "new" |
| 16:44 |
|
jamesrf joined #evergreen |
| 17:01 |
|
jvwoolf1 left #evergreen |
| 17:01 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-03-08T16:58:14,635466859-0500 -0> |
| 17:06 |
|
mmorgan left #evergreen |
| 17:12 |
terran |
Wrapping up my day, but on Monday I will update the Bug Squashing Week chart with everything that comes in through midnight :D (Like, you'll all be working on this on a Friday night) |
| 17:50 |
|
yboston joined #evergreen |
| 02:33 |
|
beanjammin joined #evergreen |
| 05:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:06 |
|
agoben joined #evergreen |
| 07:07 |
|
rjackson_isl joined #evergreen |
| 07:35 |
|
bos20k joined #evergreen |
| 09:35 |
|
sandbergja joined #evergreen |
| 09:46 |
|
yboston joined #evergreen |
| 10:13 |
|
Christineb joined #evergreen |
| 10:19 |
pinesol |
[evergreen|Jane Sandberg] Docs: Fixing broken link - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7f7919e> |
| 10:20 |
|
beanjammin joined #evergreen |
| 10:42 |
|
jvwoolf joined #evergreen |
| 10:43 |
terran |
mmorgan++ for finding the link to my patch when I forgot to include it :D |
| 11:48 |
Bmagic |
vs |
| 11:48 |
Bmagic |
https://missourievergreen.org/eg/opac/results?query=dog&qtype=keyword&fi%3Asearch_format=&locg=1&detail_record_view=1&sort= |
| 11:49 |
Bmagic |
26 seconds for gapines, 14 seconds on missourievergreen |
| 11:51 |
Bmagic |
It's not quite apples to apples of course, due to the db's not having the exact same data. The test machine with the exact same data is here http://104.155.152.239/eg/opac/home |
| 11:53 |
csharp |
Bmagic: maybe a comparison of queries and explain data would help? |
| 11:53 |
Bmagic |
yeah, good point |
| 11:54 |
Bmagic |
I've been here before, and the two versions of evergreen are fundamentally different in the search strategy. No conclusion |
| 12:48 |
Bmagic |
ty |
| 12:48 |
csharp |
if it weren't for the move from QTS -> ITS, we would have already moved to Ubuntu 18.04/PG 10 |
| 12:49 |
csharp |
probably do that over Labor Day |
| 12:50 |
Dyrcona |
Someone (me?) should start testing with Pg 11. We only started looking at Pg 10 when 11 was released. :) |
| 12:55 |
|
jvwoolf joined #evergreen |
| 13:06 |
Bmagic |
fresh reboot, same cats query 190 seconds! |
| 13:06 |
Bmagic |
collapsable join was at 10 |
| 13:18 |
Bmagic |
yeah, but that was the point of rebooting |
| 13:18 |
Bmagic |
restarting postgres wasn't enough |
| 13:18 |
Bmagic |
what's the command to warm up the cache after reboot? |
| 13:19 |
jeffdavis |
You don't want your test query in cache, but you want indexes etc to be cached so that performance is normal (or else test on two different cold-cache servers I guess) |
| 13:21 |
jeffdavis |
doing some other searches or typical queries and/or vacuuming metabib index tables might help, I'm not actually sure what's best beyond letting the server get used a bit |
| 13:23 |
jeffdavis |
you could ask in #postgres for advice on benchmarking and cache issues |
| 13:25 |
Bmagic |
yeah, it's hard to get a good test after changing those config points |
| 13:25 |
Bmagic |
to know whether or not the change made a difference |
| 13:26 |
|
sandbergja_ joined #evergreen |
| 14:30 |
|
littlet_ joined #evergreen |
| 14:31 |
terran |
Okay, thanks |
| 14:32 |
terran |
I've been removing some of the unofficial tags if there is a better existing term already in place |
| 14:32 |
abneiman |
another one I've been wondering about but haven't looked into -- test-writing-day-1 |
| 14:32 |
abneiman |
https://bugs.launchpad.net/evergreen/+bugs?field.tag=test-writing-day-1 |
| 14:34 |
abneiman |
All file by Liam Whalen, 3 years ago, seemingly about things that need tests written. We typically use needstest to flag new code that needs a unit/pgtap tests, so I'm not sure that applies here, but it seems like a bit of a one-off |
| 14:35 |
abneiman |
oh, mmorgan does have one with that tag too, my mistake. mmorgan please chime in if you have thoughts on this. |
| 14:38 |
terran |
I'm unsure about that one as well |
| 14:39 |
mmorgan |
abneiman: Looks like Liam added the tag to bug 1331174, I have no strong feelings about that tag. |
| 14:39 |
terran |
Was it flagging things that needed end user test instructions added? |
| 14:39 |
pinesol |
Launchpad bug 1331174 in Evergreen "Long Overdue processing needs org unit settings separate from Lost Processing" [Wishlist,Confirmed] https://launchpad.net/bugs/1331174 |
| 14:39 |
abneiman |
http://libmail.georgialibraries.org/pipermail/open-ils-dev/2015-November/009998.html |
| 14:41 |
abneiman |
and here https://wiki.evergreen-ils.org/doku.php?id=dev:test_writing_day |
| 16:22 |
|
yboston joined #evergreen |
| 16:32 |
* csharp |
plans to work on committing more tomorrow too |
| 16:56 |
|
afterl left #evergreen |
| 17:01 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-03-07T16:59:16,091764708-0500 -0> |
| 17:07 |
|
mmorgan left #evergreen |
| 17:13 |
|
jamesrf joined #evergreen |
| 17:14 |
|
jvwoolf left #evergreen |
