| 01:27 |
|
sandbergja joined #evergreen |
| 01:41 |
|
dbwells__ joined #evergreen |
| 05:00 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live/test.49.html#2019-06-27T04:58:30,783957438-0400 -0> |
| 07:10 |
|
rjackson_isl joined #evergreen |
| 07:23 |
|
Dyrcona joined #evergreen |
| 08:19 |
|
agoben joined #evergreen |
| 08:54 |
|
bos20k joined #evergreen |
| 09:16 |
|
yboston joined #evergreen |
| 09:26 |
|
sandbergja joined #evergreen |
| 09:41 |
dbwells |
Does anyone have a good idea why the live tests are failing? |
| 09:42 |
dbwells |
We have the June release waiting in the wings, but I've been hoping someone would step up and poke at that. |
| 09:44 |
|
aabbee joined #evergreen |
| 09:52 |
JBoyer |
I'm trying to load master on one of my test machines so I can look at that. |
| 09:52 |
JBoyer |
I'm having issues unrelated to Evergreen at the moment though, so it's taking longer than I'd hoped. |
| 09:54 |
Dyrcona |
I've had live tests, in particular, fail for seemingly random reasons. Sometimes, a db reload of concerto resolves it, sometimes it fixes itself after a couple of reloads. |
| 09:55 |
|
Christineb joined #evergreen |
| 09:55 |
Dyrcona |
Our test coverage is weak, and the tests themselves are dependent on all of the preconditions being just so. |
| 09:55 |
JBoyer |
This one has been annoyingly consistent and shouldn't involve the database in any real way. |
| 09:56 |
Dyrcona |
My previous statement still applies. :) |
| 09:57 |
JBoyer |
True, I was (slowly) replying to your previous previous statement, heh. |
| 00:51 |
|
sandbergja joined #evergreen |
| 01:33 |
|
yar joined #evergreen |
| 05:01 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live/test.49.html#2019-06-26T04:57:28,462029343-0400 -0> |
| 06:56 |
|
agoben joined #evergreen |
| 07:11 |
|
rjackson_isl joined #evergreen |
| 08:08 |
|
bos20k joined #evergreen |
| 11:01 |
sandbergja |
i know, right! |
| 11:12 |
|
yboston joined #evergreen |
| 11:13 |
|
Christineb joined #evergreen |
| 11:19 |
Dyrcona |
Well, testing berick's remove apache2-websockets branch with haproxy on a single vm, and I'm getting something apparently unrelated.... Will rebuild. |
| 11:20 |
Dyrcona |
Error: [$injector:nomod] Module 'egWorkstationAdmin' is not available! |
| 11:22 |
|
khuckins joined #evergreen |
| 11:24 |
Dyrcona |
Eh, no... reinstalling Evergreen didn't help, neither did an empty cache and hard reload. |
| 11:36 |
Dyrcona |
Nope. something's definitely busted. |
| 11:37 |
* Dyrcona |
undoes the haproxy stuff to see if results change. |
| 11:42 |
|
gsams joined #evergreen |
| 11:44 |
Dyrcona |
Nope. still busted, as I figured. I hate when something unrelated to what I'm testing breaks. Particularly when it was working yesterday. |
| 11:44 |
Dyrcona |
Maybe I'll just destroy the VM and build a fresh one? |
| 12:00 |
|
jihpringle joined #evergreen |
| 12:27 |
|
yboston joined #evergreen |
| 12:31 |
berick |
Dyrcona++ # testing |
| 12:34 |
|
jvwoolf joined #evergreen |
| 12:42 |
|
collum joined #evergreen |
| 12:57 |
|
sandbergja joined #evergreen |
| 14:50 |
|
nfBurton joined #evergreen |
| 15:09 |
|
yboston joined #evergreen |
| 16:08 |
|
jvwoolf left #evergreen |
| 17:01 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live/test.49.html#2019-06-26T17:00:38,388557518-0400 -0> |
| 17:06 |
|
sandbergja joined #evergreen |
| 17:10 |
|
mmorgan left #evergreen |
| 17:25 |
jeffdavis |
QA has been failing on live_t/24-offline-all-assets.t for some time now... |
| 00:08 |
|
JasonEDN joined #evergreen |
| 02:59 |
|
dbwells_ joined #evergreen |
| 03:01 |
|
JasonEDN1 joined #evergreen |
| 05:00 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live/test.49.html#2019-06-25T04:57:10,126331995-0400 -0> |
| 06:58 |
|
Dyrcona joined #evergreen |
| 07:10 |
|
rjackson_isl joined #evergreen |
| 07:18 |
|
JBoyer joined #evergreen |
| 13:49 |
|
littlet joined #evergreen |
| 13:52 |
|
aabbee joined #evergreen |
| 13:54 |
|
jvwoolf1 joined #evergreen |
| 14:10 |
Dyrcona |
Whereas yesterday I was getting the busted search results, today, I'm getting no results, but that's probably because the test db server is being overworked. |
| 14:15 |
|
jvwoolf2 joined #evergreen |
| 14:15 |
|
jvwoolf2 left #evergreen |
| 15:03 |
|
khuckins_ joined #evergreen |
| 15:16 |
|
yboston joined #evergreen |
| 16:07 |
sandbergja |
berick: gmcharlt: if/when you have a chance, I'd appreciate your thoughts on bug 1831390 |
| 16:07 |
pinesol |
Launchpad bug 1831390 in Evergreen "Make Angular combobox, date-select, etc. implement ControlValueAccessor" [Undecided,New] https://launchpad.net/bugs/1831390 |
| 16:22 |
|
mmorgan joined #evergreen |
| 16:45 |
|
BAMkubasa joined #evergreen |
| 17:02 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live/test.49.html#2019-06-25T16:58:22,918911395-0400 -0> |
| 17:08 |
|
mmorgan left #evergreen |
| 17:08 |
berick |
sandbergja: will do. at a glance, I'm liking it. |
| 17:12 |
|
jvwoolf left #evergreen |
| 02:08 |
|
jeffdavis_ joined #evergreen |
| 02:08 |
|
ejk_ joined #evergreen |
| 02:09 |
|
bshum_ joined #evergreen |
| 05:01 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live/test.49.html#2019-06-24T04:59:37,643832565-0400 -0> |
| 06:54 |
|
JBoyer joined #evergreen |
| 07:11 |
|
rjackson_isl joined #evergreen |
| 07:56 |
|
Dyrcona joined #evergreen |
| 11:04 |
Dyrcona |
Nothing jumps out as an obvious problem, though. |
| 11:07 |
Dyrcona |
I'm switching to our production templates. |
| 11:07 |
Bmagic |
an odd problem indeed |
| 11:11 |
Dyrcona |
Not happening on training, so if it isn't the data, then it's something that I've installed on the test vm but not on training, yet. |
| 11:20 |
csharp |
Dyrcona: the only time I've seen empty result sets like that was fixed by a reingest but if it's a dump from prod, that doesn't sound like the same thing |
| 11:20 |
Dyrcona |
Still busted. Must be the database. I don't have time to wait for a pingest, so I'm giving up for now. |
| 11:20 |
csharp |
maybe do the searches from srfsh and see what returns? |
| 13:04 |
Dyrcona |
Well, something additional to consider. |
| 13:24 |
Dyrcona |
Well, nginx just failed to install for me on Ubuntu 16.04.... |
| 13:25 |
Dyrcona |
Oh, no. It installed. Failed to start, 'cause I haven't edited apache2, yet..... |
| 13:43 |
berick |
testing w/ a 1 minute timeout locally as well |
| 13:43 |
Dyrcona |
Anyone using HAProxy? |
| 13:46 |
Dyrcona |
The nginx steps in the README are missing some detail when it comes to opensrf_ws.js |
| 13:46 |
Dyrcona |
Looks like there are two copies and the path is not complete. |
| 16:06 |
|
gsams joined #evergreen |
| 16:41 |
|
jvwoolf left #evergreen |
| 16:58 |
|
sandbergja joined #evergreen |
| 17:01 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live/test.49.html#2019-06-24T16:58:43,335152394-0400 -0> |
| 17:07 |
|
mmorgan left #evergreen |
| 19:22 |
|
sandbergja joined #evergreen |
| 22:50 |
|
sandbergja joined #evergreen |
| 01:23 |
|
yar joined #evergreen |
| 01:38 |
|
sard_ joined #evergreen |
| 05:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:03 |
|
yar joined #evergreen |
| 06:58 |
|
agoben joined #evergreen |
| 07:13 |
|
rjackson_isl joined #evergreen |
| 15:17 |
berick |
not sure what I'm going to do when we start doign autorenewals.. more so since the volume will be /way/ higher |
| 15:17 |
berick |
than marking lost |
| 15:17 |
Dyrcona |
I think I saw I "noticed" reacting events before but ignored them because I was looking into something else. |
| 15:17 |
Dyrcona |
Yes, it looks like the volume is much higher from my tests. |
| 15:38 |
Dyrcona |
Well, that's a bummer. The reports of problems don't coincide with the times that the logs indicated the 'no children available' messages. |
| 15:42 |
Dyrcona |
Well, not always... |
| 17:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:26 |
khuckins |
berick: For the in transit/reshelve_on_checkin part from CAT-222: |
| 17:26 |
khuckins |
OpenILS/Application/Circ/Transit.pm -> __abort_transit |
| 17:26 |
khuckins |
If the copy status is "In Transit" and the transit's copy status is Available, Checked Out, In Process, On Holds Shelf, In Transit, Cataloging, On Reservation Shelf, or Reshelving, it is changed it Canceled Transit. Otherwise the copy status reverts to what it was before the transit. An additional field for this seems like it would be excessive unless we were to have an "additional_rules" string field, or possibly a map table, "copy statu |
| 04:27 |
|
jamesrf joined #evergreen |
| 05:31 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:01 |
|
agoben joined #evergreen |
| 07:08 |
|
rjackson_isl joined #evergreen |
| 07:51 |
|
collum joined #evergreen |
| 16:21 |
Dyrcona |
I started to type "all the fields" and realized I really only care about lines and bytes. Number of words is not so interesting. |
| 16:21 |
jeff |
Dyrcona: gzip -l has the advantage of using the gzip file header to get the size, which doesn't then require decompression of the entire stream. |
| 16:21 |
Dyrcona |
Well... |
| 16:22 |
jeff |
if you just want the uncompressed size, gzip -l messages.1.gz | tail --lines=+2 | awk '{print $2}' |
| 16:23 |
jeff |
and if you want to compare them, then... do both? :-) |
| 16:23 |
jeff |
"gzip -dc messages.1.gz | wc -c" and the above gzip -l | tail | awk match on the sample file I tested with. |
| 16:24 |
jeff |
one takes longer and decompresses the file to wc, the other does not. |
| 16:25 |
|
mmorgan joined #evergreen |
| 16:25 |
Dyrcona |
jeff: Yes. I'll try this because maybe I don't care about numbers of lines, either: gzip -l --quiet gateway.00.log.gz | awk ' {print $2}' |
| 16:26 |
jeff |
ah, nice use of --quiet in place of tail. |
| 16:51 |
berick |
miker: ah, good to know |
| 16:53 |
mmorgan |
Ok, that helps. Seems like after an upgrade, clearing files and images for all time is necessary. I'd like to just put that out as a general rule whenever cache clearing is necessary. |
| 16:53 |
sandbergja |
Grabbing 1167 |
| 17:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:02 |
sandbergja |
Core committers: this is my first time stamping an upgrade. Could somebody please give this a once over before I add to master and the release branches? |
| 17:02 |
sandbergja |
I've got my work here: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/sandbergja/lp1759343_sticky_annotate |
| 17:03 |
sandbergja |
(by which I mean JBoyer's work) |
| 01:37 |
|
jamesrf joined #evergreen |
| 02:27 |
|
sandbergja joined #evergreen |
| 04:59 |
|
jamesrf joined #evergreen |
| 05:09 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 05:17 |
|
jamesrf joined #evergreen |
| 06:59 |
|
agoben joined #evergreen |
| 07:14 |
|
rjackson_isl joined #evergreen |
| 09:36 |
|
yboston joined #evergreen |
| 09:47 |
|
jamesrf joined #evergreen |
| 09:50 |
|
sandbergja joined #evergreen |
| 09:51 |
JBoyer |
Dyrcona, good to see that's how that works, I'll definitely keep that in mind when testing things. |
| 09:56 |
Dyrcona |
So, I'm testing the autorenew events on training. I set all of the other evens to active false, and I added a daily granularity to the autorenew event. |
| 09:57 |
Dyrcona |
I ran our usual action-trigger runners, and it looks like the daily one created event entries for autorenew, but they are in a pending state. |
| 09:58 |
Dyrcona |
We have one that runs every half hour with no granularity that has --proccess-hooks --run-pending, but it doesn't seem to pick these up. |
| 09:59 |
Dyrcona |
Just looking for some suggestions. |
| 16:23 |
berick |
some links still go back to legacy versions though |
| 16:23 |
jeffdavis |
Cool, thanks. |
| 16:26 |
|
_bott_ joined #evergreen |
| 17:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:02 |
|
mdriscoll left #evergreen |
| 17:03 |
|
sandbergja joined #evergreen |
| 18:04 |
phasefx |
berick: don't know if it's a quick fix for you, but it looks like all the boolean fields for the eg2 grid are stuck presenting Yes |
| 05:17 |
|
jamesrf joined #evergreen |
| 05:32 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 05:49 |
|
jamesrf joined #evergreen |
| 06:27 |
|
jamesrf joined #evergreen |
| 06:58 |
|
agoben joined #evergreen |
| 09:50 |
|
gregb_fcls joined #evergreen |
| 09:54 |
|
gregb_fcls left #evergreen |
| 10:05 |
|
mmorgan1 joined #evergreen |
| 10:23 |
dbwells |
Okay, just throwing this out for any takers. For the first time, I am switching real soon to full-time Mac for my work machine. Wondering if folks have specific application or workflow pointers for dev productivity on that platform. |
| 10:24 |
dbwells |
Doesn't necessarily need to be Mac specific, just anything which works particularly well for you on that platform. Thanks! |
| 10:24 |
|
remingtron joined #evergreen |
| 10:29 |
dbwells |
For a little extra context, I have basically zero real Mac experience. Just kinda fed-up with Windows, and we're being forced to Windows 10 this summer, so it seemed like a good time to test the waters. |
| 10:30 |
Dyrcona |
I used to use a Mac. I installed MacPorts to have access to most of the F/OSS goodies. There are probably better ways. The XUL client was always hit or miss. Seems like each new Mac OS release would break something new. |
| 10:31 |
|
bos20k joined #evergreen |
| 10:32 |
Dyrcona |
What annoyed me the most about using a Mac was the keyboard. As an Emacs user, having only 1 Ctrl-key kind of messed with my usual workflow. I eventually mapped the "Command" key to do the same as Ctrl in Emacs. |
| 15:36 |
|
mmorgan1 joined #evergreen |
| 15:48 |
Dyrcona |
@later tell JBoyer: That table restore that I mentioned in private chat just worked without --disable-triggers and then I could delete the 1,400 or so rows for users added after the prior dump. |
| 15:48 |
pinesol |
Dyrcona: The operation succeeded. |
| 15:49 |
Dyrcona |
The joys of testing SQL code when you figure an AND in your WHERE. Updated more rows than intended. |
| 15:50 |
Dyrcona |
s/figure/forget/ # I suppose I should knock off the code after this and just update bug reports. :) |
| 15:52 |
Dyrcona |
That's better: 139K rows instead of 1.3M. |
| 15:52 |
phasefx |
new Jessie install of OpenSRF master: Failed to start apache2-websockets.service: Unit apache2-websockets.service failed to load: No such file or directory. Not sure what I did wrong |
| 16:36 |
* mmorgan |
grumbles about obscure labels for columns |
| 16:36 |
mmorgan |
khuckins++ |
| 16:46 |
|
bos20k joined #evergreen |
| 17:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:05 |
|
mmorgan left #evergreen |
| 17:34 |
|
khuckins joined #evergreen |
| 18:07 |
* phasefx |
says belatedly, "websocketd did work for me :) |
| 00:00 |
|
sandbergja joined #evergreen |
| 03:11 |
|
yar joined #evergreen |
| 05:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 05:37 |
|
yar joined #evergreen |
| 07:07 |
|
agoben joined #evergreen |
| 07:11 |
|
rjackson_isl joined #evergreen |
| 12:37 |
csharp |
JBoyer: has anyone been monkeying around with match sets? might be that some sort of dupe checking got borked |
| 12:38 |
JBoyer |
Nope, this is open a record from an opac search, click the edit tab, click Save, lose you TCN. |
| 12:39 |
csharp |
ouch |
| 12:39 |
JBoyer |
Which I finally made myself take the time to verify against one of our other test installs and of course that doesn't happen, so it's time for some spelunking fun... |
| 12:39 |
csharp |
sorry :-( |
| 12:40 |
rjackson_isl |
spelunking used to be fun - several decades ago... |
| 12:40 |
csharp |
it is ringing some sort of bell - maybe we saw something like that during our test phase |
| 12:40 |
* csharp |
blows the dust off 3.2 testing issue spreadsheet |
| 12:43 |
csharp |
JBoyer: probably not it, but can you verify that the fix for https://bugs.launchpad.net/evergreen/+bug/1764542 was applied? |
| 12:43 |
pinesol |
Launchpad bug 1764542 in Evergreen "Incorrect format on config.metabib_field insert results in segmentation fault" [High,Fix released] |
| 12:43 |
csharp |
should have been included in 3.2.2+ |
| 12:45 |
JBoyer |
I'm 1000% certain that's already in our db, because I applied that one the day *after* we upgraded to a version affected by it. I believe you helped me narrow down what was happening while everything was aflame. |
| 12:48 |
JBoyer |
There still are display issues with TCN labels and bib id values in the Z39.50 importer, but that's just a UI issue, it isn't doing anything crazy. |
| 12:48 |
csharp |
Elaine is out today - otherwise I'd ask her about it |
| 12:58 |
|
yboston joined #evergreen |
| 13:14 |
dbwells |
JBoyer: I am interested in testing what you are seeing, but not sure I understand. You are saving a record and seeing tcn_value in biblio.record_entry get updated somehow? |
| 13:15 |
JBoyer |
Aha. commit 4877cfe904483e181697cc48754395f34f28faf9 changed a pcrud.update call to an open-ils.cat.biblio.record.marc.replace api call for record edits. And sub biblio_record_replace_marc in Open-ILS/Application/Cat/Bibcommon.pm cares very much about tcns. |
| 13:15 |
pinesol |
JBoyer: [evergreen|Bill Erickson] LP1693580 Marc editor notify and API changes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4877cfe> |
| 13:16 |
JBoyer |
dbwells, What was happening here was that we had the "Cat: Maintain 001/003/035 according to the MARC21 specification" global flag enabled, and the "Cat: Use Internal ID for TCN Value" global flag disabled. |
| 15:52 |
jeff |
select Cataloging -> Search the Catalog... nested iframe again. |
| 15:52 |
gmcharlt |
jeff: <iframe loading="eager"> ? |
| 15:53 |
Dyrcona |
Meh.... Template's a mess.. I need some key strokes to match END with the construct that it's closing..... |
| 15:53 |
jeff |
gmcharlt: possibly! testing! |
| 15:54 |
jeff |
gmcharlt++ even if this isn't the issue... |
| 15:54 |
gmcharlt |
yeah, BigRig just mentioned the advent of lazy loading in Chrome 75 as being a potential problem |
| 15:55 |
jeff |
i see more Canary Yellow in my future |
| 15:59 |
jeff |
alas, simply adding loading="eager" to templates/staff/share/t_eframe.tt2 didn't seem to resolve the current symptoms. |
| 16:37 |
jeff |
That seems to have done the trick. |
| 16:42 |
jeff |
er, I also left loading="eager" in there... unclear if it's required, but I'd be interested to hear more about BigRig's experience there. |
| 16:44 |
jeff |
so, looking at that bug it's likely anyone on 3.1.7 or higher was not even affected. |
| 16:44 |
BigRig |
jeff not much experience. It was reported by a customer. I upated my chrome to v75 and did not get any issues. but I did not really do an indepth testing. |
| 16:44 |
BigRig |
that might explain why I did not have any issues. |
| 17:24 |
|
yar joined #evergreen |
| 17:31 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:49 |
|
jonadab joined #evergreen |
| 17:49 |
|
yboston joined #evergreen |
| 17:53 |
|
jamesrf joined #evergreen |
| 03:23 |
|
jamesrf joined #evergreen |
| 03:43 |
|
jamesrf joined #evergreen |
| 03:56 |
|
timo75 joined #evergreen |
| 05:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 05:28 |
|
jamesrf joined #evergreen |
| 06:14 |
|
JasonEDN joined #evergreen |
| 07:11 |
|
rjackson_isl joined #evergreen |
| 09:41 |
Dyrcona |
A JSON string is always quoted. |
| 09:41 |
bos20k |
Will try. Thanks. |
| 09:42 |
Dyrcona |
I'm also pretty sure that setting value will bite you if it is what I think it is. |
| 09:42 |
bos20k |
Looking to try minimum password length of 12 in a test system. |
| 09:42 |
Dyrcona |
That's not minimum, that's exactly 12, IIRC. |
| 09:43 |
Dyrcona |
And, it's not the setting I thought it was. :) |
| 09:43 |
Dyrcona |
I should have paid more attention to the DETAIL line... :) |
| 15:32 |
gmcharlt |
which basically boils down to if, and under what circumstances, we want to allow duplicate menu entries in the staff interface |
| 15:32 |
jeff |
It would be good to get a new Hatch build out there, especially with regard to the Oracle license changes. To the best of my understanding, the only Hatch that works well with OpenJDK is not available on the download page yet. |
| 15:33 |
gmcharlt |
JBoyer: any obstacle to ^^ that folks can help with? |
| 15:34 |
JBoyer |
To my knowledge all that's really needed is testing. berick has a branch available to build your own windows installer with all of the new openjdk bits |
| 15:34 |
JBoyer |
(looping up lp) |
| 15:35 |
JBoyer |
Ah, bug 1830391 and there's also a pre-built installer to test. |
| 15:35 |
pinesol |
Launchpad bug 1830391 in Evergreen "Hatch omnibus circa 3.3 (Java updates and more)" [Undecided,New] https://launchpad.net/bugs/1830391 |
| 15:36 |
JBoyer |
being an omnibus bug including Eg patches for one of the issues addressed might make it slightly more work to test, but if anyone wants to sign off on what they can test I'm sure it would help. |
| 15:37 |
gmcharlt |
#info Call for testers for Hatch ombnibus bug 1830391 (https://bugs.launchpad.net/evergreen/+bug/1830391) |
| 15:37 |
pinesol |
Launchpad bug 1830391 in Evergreen "Hatch omnibus circa 3.3 (Java updates and more)" [Undecided,New] |
| 15:37 |
jeff |
Once it has signoff and is committed / etc, how does the installer generally make it to the download page for Hatch? Ad hoc at the moment? |
| 16:00 |
miker |
gmcharlt++ |
| 16:29 |
|
yboston joined #evergreen |
| 17:11 |
|
mmorgan left #evergreen |
| 17:25 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:37 |
|
yar joined #evergreen |
| 21:04 |
|
dwgreen joined #evergreen |
| 21:22 |
|
sandbergja joined #evergreen |
| 03:53 |
|
kip joined #evergreen |
| 03:53 |
|
dkyle joined #evergreen |
| 03:59 |
|
genpaku joined #evergreen |
| 05:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 05:42 |
|
jamesrf joined #evergreen |
| 05:47 |
|
jamesrf joined #evergreen |
| 05:55 |
|
JasonEDN joined #evergreen |
| 11:30 |
|
remingtron_ joined #evergreen |
| 11:55 |
|
jihpringle joined #evergreen |
| 12:05 |
|
yboston joined #evergreen |
| 12:11 |
Dyrcona |
I'm trying to test the autorenew event, 124. Does it have to run at 1:00 am to renew the daily circulations? |
| 12:15 |
Dyrcona |
Ah. Bet I need to set max_auto_renewal. |
| 12:17 |
|
sandbergja joined #evergreen |
| 12:24 |
|
JBoyer joined #evergreen |
| 15:47 |
|
JasonEDN1 joined #evergreen |
| 16:23 |
|
dkyle joined #evergreen |
| 16:27 |
|
yboston joined #evergreen |
| 17:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:09 |
|
mmorgan left #evergreen |
| 17:39 |
|
sandbergja_ joined #evergreen |
| 18:02 |
|
JasonEDN joined #evergreen |
| 01:06 |
|
gsams joined #evergreen |
| 02:07 |
|
sandbergja joined #evergreen |
| 04:57 |
|
jamesrf joined #evergreen |
| 05:02 |
pinesol |
News from qatests: Failed Installing Angular web client <http://testing.evergreen-ils.org/~live/test.29.html#2019-05-29T04:53:52,213499125-0400 -0> |
| 05:02 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live/test.49.html#2019-05-29T04:53:52,247157428-0400 -2> |
| 06:32 |
bshum |
Hmm.. Time for Node v10? ;) |
| 06:33 |
bshum |
Or we need to pin a lower version of Angular CLI |
| 06:33 |
bshum |
Either way v8 is marked EOL on the site by end of 2019 |
| 07:35 |
bshum |
Well, technically it's not out of support (yet). So I'm OK with downgrading it since the new one also only just arrived on the scene :D |
| 07:35 |
bshum |
But yeah, getting to newer node versions is more complicated I think |
| 07:35 |
csharp |
ok - I was just thinking about the EOL issue |
| 07:36 |
bshum |
Maybe berick and everyone already has secret branches testing new Nodes :D |
| 07:36 |
* csharp |
wants to avoid repeating XUL/Dojo, etc. |
| 07:36 |
csharp |
prolly too early for this kind of discussion :-) |
| 07:37 |
bshum |
Probably :) |
| 07:56 |
bshum |
Since this is more of a hack fix to me, than a real long-term solution |
| 07:56 |
bshum |
Plus also, with EOL, it's better to look to the future |
| 07:57 |
csharp |
+1 |
| 07:58 |
bshum |
csharp++ # good mornin'! |
| 08:14 |
bshum |
Huzzah, happy install :) |
| 08:17 |
bshum |
So my test VM built the web client successfully without any errors with the branch change I made above |
| 08:19 |
* bshum |
leaves it there for now and heads off to work |
| 08:19 |
bshum |
Have a good day everybody! |
| 08:25 |
|
bos20k joined #evergreen |
| 08:45 |
|
mmorgan joined #evergreen |
| 08:52 |
csharp |
bshum++ |
| 16:44 |
pinesol |
Launchpad bug 1830394 in Evergreen "holdings editor can spew MultiMap errors in browser log" [Medium,New] |
| 16:45 |
abowling |
berick++ |
| 16:45 |
abowling |
gmcharlt++ |
| 17:00 |
pinesol |
News from qatests: Failed Installing Angular web client <http://testing.evergreen-ils.org/~live/test.29.html#2019-05-29T16:55:54,955319834-0400 -0> |
| 17:00 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live/test.49.html#2019-05-29T16:55:54,982778127-0400 -2> |
| 17:09 |
|
khuckins joined #evergreen |
| 17:42 |
gmcharlt |
berick: bug 1830972 now has a pull reuest |
| 17:42 |
pinesol |
Launchpad bug 1830972 in Evergreen 3.2 "pin version of angular/cli that is installed globally by Makefile.common" [High,New] https://launchpad.net/bugs/1830972 |
| 00:24 |
|
JasonEDN1 joined #evergreen |
| 00:28 |
|
JasonEDN joined #evergreen |
| 04:32 |
|
jamesrf joined #evergreen |
| 05:31 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:48 |
|
JBoyer joined #evergreen |
| 06:50 |
|
agoben joined #evergreen |
| 07:52 |
|
rjackson_isl joined #evergreen |
| 11:02 |
miker |
csharp / Bmagic: both of your error messages are about the client quiting before the response is sent, I'm 99% sure. for the apache version of that, there are patches for both opensrf and evergreen (probably still untested) to detect the situation and cancel ongoing requests (think: 100 refreshes of a search, and cutting the first 99 off because they're now just wasting server time). we can't really detect the websockets version, though -- it just |
| 11:02 |
miker |
runs our code as an external command and shovels the bits between our stdout and a socket. |
| 11:18 |
csharp |
miker: thanks for that - do you know the bug #s for the patches? |
| 11:18 |
* miker |
looks... |
| 11:20 |
miker |
csharp: heh ... you were the last to test the evergreen part, actually: https://bugs.launchpad.net/opensrf/+bug/1616501 ... and the opensrf part is in there now, as it turns out |
| 11:20 |
pinesol |
Launchpad bug 1616501 in Evergreen "Stop waiting for method response when browser disconnects" [Medium,Confirmed] |
| 11:29 |
Bmagic |
Dyrcona: we have it running in production. Yes I believe it's good for a pullrequest. If people had tried to setup HTML templates and they weren't working, then left them alone, with this patch, they will suddenly start working. RE: comment #3 |
| 11:30 |
Dyrcona |
We might be interested in having a look. |
| 16:52 |
Dyrcona |
Hmm... It looks a little more even, now, at from pairs of drone server. Still some bricks at 70% or so, and others at 17-20%. |
| 16:54 |
Dyrcona |
Really? "no_tz.open-ils.storage.actor.user.crazy_search" |
| 16:58 |
|
mmorgan joined #evergreen |
| 17:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:16 |
|
mmorgan left #evergreen |
| 17:50 |
berick |
love there's an EDI code for "number of law suits" |
| 18:18 |
Dyrcona |
@quote add <berick> love there's an EDI code for "number of law suits" |
| 01:53 |
|
jamesrf joined #evergreen |
| 01:58 |
|
sandbergja joined #evergreen |
| 03:27 |
|
jamesrf joined #evergreen |
| 05:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:03 |
|
agoben joined #evergreen |
| 07:07 |
|
rjackson_isl joined #evergreen |
| 07:17 |
|
JBoyer joined #evergreen |
| 11:09 |
terran |
bugsquashers++ |
| 11:09 |
berick |
terran: bug squashing will do that to a person |
| 11:10 |
terran |
lol |
| 11:12 |
dbwells |
Well, if we get rid of the "* 100", we aren't doing any math there anymore :) It's fine, really. I've felt too silly caring about it to bring it up, and now I feel silly having brought it up, but at least I've said my peace :) I'll just unassign myself, but feel free it pass it back if it needs another sign-off. As far as I have tested, it works fine. |
| 11:15 |
Dyrcona |
If x is a floating point number maybe we want x == 0.0 ? |
| 11:16 |
Dyrcona |
I can't remember if the decimal really matters in Perl. In some languages the floating number will be silently cast to int if compared to an int. |
| 11:17 |
dbwells |
berick: I certainly can appreciate the idea of not changing more than needed in this case, being on the edges of FP-voodoo land. Just back away slowly, don't bump anything. |
| 11:27 |
dbwells |
gmcharlt++ |
| 11:30 |
pinesol |
[evergreen|Bill Erickson] LP#1704819 Fine generator avoids int() rounding - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=297fedb> |
| 11:40 |
Dyrcona |
gmcharlt++ berick++ |
| 11:41 |
Dyrcona |
And, my script to shut down opensrf services and remove the opensrf user's crontab works from cron. I'm doing this on a test VM where I refresh the database weekly. Don't want the database being used to prevent the reload. |
| 11:42 |
aabbee |
floats are the worst. as the bug notes, int(100*2.30) is 229. testing "near enough" can be done: perl -e 'my $c = ((100*2.30) - 230); print(($c==0?'zero':'nonzero'), ", ", (abs($c)<(10**-10)?'near':'nope'), "\n");' # says "nonzero, near' |
| 11:43 |
aabbee |
or force rounding to behave: int((100*2.30)+.5) ==> 230. |
| 11:44 |
Dyrcona |
Oddly enough, computers are bad at math. :) |
| 11:44 |
aabbee |
idk if the zeros here are "real" zeros or if they are be calculated like $c was above, so unsure if this applies here |
| 11:44 |
* Dyrcona |
decides on a new file in /etc/cron.d rather than junking up /etc/crontab. |
| 16:13 |
|
mmorgan joined #evergreen |
| 16:15 |
Dyrcona |
csharp: I'll be going to 100 per brick, i.e. 50 per drone server. |
| 16:15 |
Dyrcona |
We're currently at 80 per brick. |
| 16:20 |
aabbee |
my test server was on eg3.3ish with various customizations. i want to test some stuff on vanilla eg3.2. i did a `git checkout rel_3_2`, rebuilt and restarted everything i know of. |
| 16:20 |
aabbee |
but i think i missed something. some, but not all, osrf calls are coming back 404: two examples: open-ils.circ.open_non_cataloged_circulation.user.authoritative, open-ils.circ.copy_note.retrieve.all |
| 16:20 |
aabbee |
sound familiar to anyone? |
| 16:23 |
Dyrcona |
aabbee: Going backwards isn't really supported. Might be a good idea to rm -rf /openils and reinstall fresh. |
| 16:24 |
aabbee |
ok, i'll try that. |
| 16:36 |
aabbee |
nope. :-( error log says: "Method [open-ils.circ.copy_note.retrieve.all] not found for OpenILS::Application::Circ", but `grep 'open-ils.circ.copy_note.retrieve.all' /usr/local/share/perl/5.26.1/OpenILS/Application/Circ.pm` shows: |
| 17:00 |
Bmagic |
does websocketd not work with opensrf 3.0.2? It's only included in the official install instructions for opensrf 3.1.0 |
| 17:01 |
berick |
Bmagic: it's trivial to back port, but I don't think it's included in 3.0 |
| 17:01 |
Bmagic |
there is something needed in opensrf for it to work? |
| 17:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:02 |
Bmagic |
how about this: any reason to not use opensrf 3.1.0 with EG 3.1.6? |
| 17:05 |
berick |
nothing is needed in osrf to run websocketd. it's a standalone pass-thru replacement for the apache2-websockets |
| 17:05 |
berick |
osrf has no knowledge either exists |
git.evergreen-ils.org:security/Evergreen and you should have access, otherwise holler.