| 02:14 |
|
sandbergja joined #evergreen |
| 03:22 |
|
yar joined #evergreen |
| 05:01 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-04-05T04:57:49,268509913-0400 -0> |
| 07:04 |
|
rjackson_isl joined #evergreen |
| 08:17 |
|
bos20k joined #evergreen |
| 08:29 |
|
Dyrcona joined #evergreen |
| 10:21 |
Dyrcona |
miker and I agree on something! :P |
| 10:21 |
miker |
Dyrcona: hey, it's not /that/ uncommon ;) |
| 10:21 |
Dyrcona |
mker++ # For confirming my suspicion about that particular line. |
| 10:22 |
* miker |
suspects we could probably just sed out all lines that contain INTERNAL in opensrf... anyone needing that verbosity can probably just add targetted INFO level calls for testing... |
| 10:22 |
Dyrcona |
Actually, the log function could be written to take a plain string, a sub, a bare code block, well, just about anything. |
| 10:23 |
Dyrcona |
Setting the log level to INTERNAL is a good way to fill your hard drive. :) |
| 10:23 |
phasefx |
let it do Data::Dumper on anything not a string or code :) |
| 10:47 |
berick |
Bmagic: in your copious free time, i'd love to know if the Hatch installer linked from bug 1817932 allows you to print to your Dymos |
| 10:47 |
pinesol |
Launchpad bug 1817932 in Evergreen "Update Hatch Java / Javafx versions" [Undecided,Confirmed] https://launchpad.net/bugs/1817932 |
| 10:48 |
Bmagic |
TY!! I'm excited to try it (although I no longer have the printer physically) I do have the drivers on my Windows box though |
| 11:00 |
gsams |
berick: I'm about to give it a test run. |
| 11:04 |
berick |
gsams++ |
| 11:22 |
|
sandbergja joined #evergreen |
| 11:23 |
sandbergja |
berick: I'm trying to wrap my head around the flesher method in the Angular 7 GridColumn class |
| 11:35 |
berick |
cool |
| 11:35 |
sandbergja |
So thanks for talking it out with me! I'd been really hung up on thinking about the flesher, when there was a better way. :-) |
| 11:35 |
sandbergja |
berick++ |
| 11:51 |
gsams |
berick: Okay, so we get printing, but it won't print correctly for us. |
| 11:52 |
gsams |
It tries to print the spine and pocket label no matter how we set it up and we only need the spine. |
| 11:53 |
gsams |
Also, don't test print with it. It literally prints one character on each label from that, which was amusing. |
| 11:53 |
Bmagic |
It's printing though! |
| 11:53 |
gsams |
It is! |
| 11:53 |
Bmagic |
that's great |
| 11:53 |
gsams |
I'm very excited about that factor for sure |
| 11:54 |
Bmagic |
and presumabely it's printing with javafx |
| 11:54 |
berick |
gsams: i wonder if you should test printing "with dialog" and confirm java is using the right paper size |
| 11:54 |
berick |
Bmagic: yes, using javafx |
| 11:55 |
berick |
gsams: the spine label issue.. that sounds like a staff client problem |
| 11:55 |
Bmagic |
mana from heaven. Let there be Dymo printing with javafx baby! |
| 12:00 |
gsams |
berick: It is probably a staff client problem, but it was worth checking the label print size as it was technically incorrect for us. |
| 12:01 |
gsams |
The label template ignores any changes I make to it on printing. |
| 03:17 |
|
yar joined #evergreen |
| 05:00 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-04-04T04:59:06,000630798-0400 -0> |
| 07:12 |
|
rjackson_isl joined #evergreen |
| 08:05 |
|
bdljohn joined #evergreen |
| 08:26 |
|
Dyrcona joined #evergreen |
| 12:46 |
Dyrcona |
Group permissions editor seems to just be broken. I tried adding a mapping and I don't even see an attempt to create a grp_perm_map entry in the logs. |
| 12:48 |
Dyrcona |
Only thing in the logs matching grp are related to opening conify/global/permission/grp_tree.hml |
| 12:50 |
mmorgan |
Dyrcona: I noticed that on a 3.3 system just this morning. Seems to be working ok on our 3.2.4 training system. |
| 12:51 |
Dyrcona |
I haven't been told its not working on our 3.2.5 training system. This machine where it's not working is a 3.2.4 test VM. We decided not to go to 3.2.5 after some performance issues with a couple of the fixes. |
| 12:53 |
Dyrcona |
So, wonder if it's "one of those things" or something that we backported, but I don't recall backporting any permissions-related things. |
| 13:00 |
Dyrcona |
Well, this explains it: POST https://jasontest.cwmars.org/osrf-http-translator 400 (Bad Request) |
| 13:02 |
Dyrcona |
I get a number of 404s for dojo.js and openils_dojo.js just opening the page. |
| 13:56 |
bshum |
Was the penalty set at org unit 1 for the whole consortium or just one place? |
| 13:56 |
Bmagic |
at the system level |
| 13:56 |
bshum |
Okay, and the workstation used to look up the patron was from that system? |
| 13:56 |
Bmagic |
on the web client in my testing, I was logged in at the branch under the system where the penalty is defined |
| 13:56 |
bshum |
Hmm |
| 13:57 |
bshum |
that sounds suspicious then |
| 13:58 |
* bshum |
doesn't know enough about the web client to comment further :D |
| 16:54 |
pinesol |
Launchpad bug 1758975 in Evergreen "Item status can be set to Lost and Paid inappropriately when closing a transaction for a Long Overdue or Lost returned item" [Medium,Confirmed] https://launchpad.net/bugs/1758975 |
| 16:54 |
Bmagic |
I was thinking that the system did the right thing by not billing the patron, because the circulation was closed |
| 16:58 |
pastebot |
"gmcharlt" at 64.57.241.14 pasted "for jeff: the Evergreen side of the experiment" (22 lines) at http://paste.evergreen-ils.org/10840 |
| 17:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:03 |
|
mmorgan left #evergreen |
| 17:08 |
jeff |
gmcharlt++ i'll keep my eyes out for the Mousetrap side, or let me know if there isn't one. Thanks! |
| 17:37 |
jeffdavis |
Are we going to have a proper dev meeting this month? I know there was an informal quasi-meeting on Tuesday... |
| 00:50 |
|
eady joined #evergreen |
| 02:15 |
|
eady joined #evergreen |
| 02:50 |
|
eady joined #evergreen |
| 05:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:12 |
|
rjackson_isl joined #evergreen |
| 07:33 |
|
agoben joined #evergreen |
| 07:58 |
|
_bott_ joined #evergreen |
| 14:50 |
berick |
The "The The" |
| 14:51 |
Dyrcona |
berick++ |
| 14:51 |
JBoyer |
berick++ |
| 14:51 |
Dyrcona |
The The has been a go to search for testing stop words. :) |
| 14:51 |
Dyrcona |
Or would that be a Go-Gos search? :P |
| 14:51 |
jeff |
mmorgan: thinking of using a database trigger to keep asset.copy.alert_message in sync with asset.copy_alert, and having staff only use one alert type for now. |
| 14:51 |
* Dyrcona |
runs and hides from the inevitable beatings. |
| 15:48 |
|
nfBurton joined #evergreen |
| 15:49 |
jeff |
and regarding bug 1814799, is there a scenario where you'd ever want to manually apply a copy alert that has been configured with a state value other than NORMAL? |
| 15:49 |
pinesol |
Launchpad bug 1814799 in Evergreen "State-Specific Copy Alerts Ignore State of Item" [Undecided,New] https://launchpad.net/bugs/1814799 |
| 15:53 |
jeff |
while we're on the subject, I'm also wondering about the comment in the upgrade script where the stock state <> 'NORMAL' copy alert types are enabled: |
| 15:53 |
jeff |
> Making the following copy alert types active by default; if you are not using the web staff client yet, you may want to disable them. |
| 15:55 |
jeff |
I think it might be based on the "upstream" comment: copy alerts upon checkin or renewal of exceptional copy statuses are not active by default; they're meant to be turned once a site is ready to fully commit to using the webstaff client for circulation |
| 15:55 |
jeff |
but neither is clear on the anticipated impact or reasons why you wouldn't enable them if you are not "ready to fully commit" |
| 16:02 |
|
yboston joined #evergreen |
| 16:08 |
|
sandbergja_ joined #evergreen |
| 16:22 |
|
khuckins joined #evergreen |
| 16:30 |
jeff |
in practice, turning on the stock event id 7 for alerting on checkin of DAMAGED items does not seem to impact the xul client in any observable adverse way. |
| 16:31 |
jeff |
(tested that a while ago, but just re-tested with a little more double-checking) |
| 16:33 |
mmorgan |
jeff: We seem to be accumulating rows in asset.copy_alert for checkins/checkouts in the xul client of exceptional status items. That's probably a good enough reason to disable the alerts. |
| 16:33 |
jeff |
In my observation, those rows are generated no matter if you're using the web or xul client. |
| 16:34 |
mmorgan |
Interesting. |
| 16:54 |
mmorgan |
:) |
| 16:56 |
jeff |
ack_time is set when clearing an alert from Manage Copy Alerts, but ack_staff isn't. Looks like ack_staff is only set when an alert is "temporary" and it's cleared from the alert dialog itself. |
| 16:58 |
mmorgan |
jeff++ # sharing observables |
| 17:02 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-04-03T16:58:26,496333537-0400 -0> |
| 17:06 |
|
mmorgan left #evergreen |
| 17:15 |
|
sandbergja_ joined #evergreen |
| 17:37 |
Bmagic |
I forget: is there a setting to keep a hold targeted on the first copy targeted for a certain amount of time before retargeting? But just for the first copy targeted? |
| 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. |
| 16:44 |
jeff |
ah, okay. i think i originally thought the logs in question were a bit more contemporary. i think i understand now. |
| 16:49 |
mmorgan |
jeff: TBH, I wasn't as mindful as I should have been of the age of the logs. A checkin of that item from yesterday does not show multiple holds being checked, not even the frozen one in the hold copy map. |
| 16:50 |
mmorgan |
jeff++ |
| 16:51 |
mmorgan |
Lots of entries in the hold_copy_map that are no longer relevant. Maybe we can work that angle. |
| 16:52 |
mmorgan |
Sorry to take up your time! |
| 16:52 |
mmorgan |
jeff++ |
| 17:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:03 |
jeff |
well, i'm glad to have the theory regarding non-holdable copies disproven. |
| 17:04 |
mmorgan |
Me too! |
| 17:04 |
jeff |
the age hold protected copies are still a bit of an issue. will have to revisit. |
| 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 |
