05:01 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live/test.49.html#2019-06-28T04:58:00,775679270-0400 -0> |
06:52 |
|
agoben joined #evergreen |
07:09 |
|
rjackson_isl joined #evergreen |
07:16 |
|
JBoyer joined #evergreen |
07:19 |
csharp |
those appear to all be in the ng layer :-/ |
07:28 |
* csharp |
figured it out |
07:29 |
* JBoyer |
is on pins and needles |
07:29 |
csharp |
the failing test is basically, wget the offline interface and check for anything missing, in this case by grepping the string "404" |
07:29 |
csharp |
wget --no-check-certificate -m https://localhost/eg/staff/offline-interface 2>&1 |grep -B 2 404|grep https|grep -v robots.txt|wc -l |
07:29 |
bshum |
Yeah I just reading that in the test file. Hmm. |
07:29 |
csharp |
if there's any line that matches, it will be counted by wc -l and anything higher than 0 means failure |
07:30 |
csharp |
this is the line it's finding: --2019-06-28 07:27:46-- https://localhost/eg2/en-US/runtime.baaae695dca404f5a78b.js |
07:30 |
csharp |
so, um, bad test |
07:30 |
JBoyer |
csharp++ |
07:30 |
bshum |
csharp++ |
07:31 |
JBoyer |
That would explain why it worked fine for me when I was trying it locally, different filename. |
07:31 |
csharp |
right - it's just chance that this would have ever appeared, ever |
07:32 |
JBoyer |
looks like 404 -> ' 404 ' will take care of it. |
07:32 |
csharp |
ok - glad you know that because I don't know what bad output looks like :-) |
07:34 |
JBoyer |
If you just run the plain wget part you can see that the http status has a space to either side, so unless we end up with a file size that's 404 bytes, that should fix this test. |
07:35 |
csharp |
JBoyer: if you want to create a patch, I'll sign off/commit |
07:35 |
JBoyer |
++ |
07:44 |
|
bos20k joined #evergreen |
07:50 |
JBoyer |
Finally: user/jboyer/fix-offline-test |
07:51 |
JBoyer |
Had to re-setup some things because this new machine is apparently missing some things... |
07:53 |
csharp |
getting mine reset too since the livecheck creates data |
07:59 |
csharp |
sigh - the negative balances test is failing now too |
07:59 |
JBoyer |
Hmm. :/ |
08:00 |
csharp |
your fix works and I'm going to push it to master so we can move on from that, but I expect tests to still break |
08:01 |
csharp |
Script already running with lockfile /tmp/09-lp1198465_neg_balances.t-LOCK at /home/opensrf/Evergreen/Open-ILS/src/perlmods/blib/lib/OpenILS/Utils/Cronscript.pm line 151. |
08:01 |
csharp |
^^ that's what I'm seeing when I run it |
08:01 |
csharp |
oh - that's my fault |
08:01 |
csharp |
nevermind :-/ |
08:02 |
JBoyer |
Past run interrupted? |
08:02 |
csharp |
I canceled out of tests |
08:02 |
csharp |
yeah |
08:02 |
JBoyer |
+1 |
08:02 |
JBoyer |
I will say there are more warnings that I'd prefer when running them, but everything did work for me. |
08:02 |
csharp |
yeah, same here |
08:12 |
csharp |
done |
08:12 |
csharp |
JBoyer++ |
08:12 |
JBoyer |
csharp++ |
08:15 |
pinesol |
[evergreen|Jason Boyer] Correct False Positive on Offline Test - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a150021> |
08:41 |
|
Dyrcona joined #evergreen |
08:50 |
|
aabbee joined #evergreen |
09:01 |
|
jvwoolf1 joined #evergreen |
09:05 |
Dyrcona |
git++ |
09:08 |
dbwells |
csharp++ JBoyer++ |
09:13 |
Dyrcona |
csharp++ JBoyer++ tests++ fragility-- |
09:14 |
Dyrcona |
sed++ |
09:15 |
Dyrcona |
I got the haproxy config issue sorted out for Ubuntu. Gonna test it on Debian 8 & 9 a bit later. |
09:15 |
csharp |
tests might be a good way for the new devs group to get involved |
09:16 |
Dyrcona |
csharp: I have had that thought. Writing tests it a good way to learn the back end, and maybe that should be a conference presentation. |
09:17 |
|
yboston joined #evergreen |
09:18 |
csharp |
yeah definitely |
09:18 |
|
mmorgan joined #evergreen |
13:06 |
Dyrcona |
@dunno |
13:06 |
pinesol |
Dyrcona: zarro boogs found |
13:18 |
jonadab |
Heh. |
13:22 |
Dyrcona |
So, I'm not sure if this haproxy or something else, but I keep getting blank pages when testing the web staff client with a Debian host. I have to reload just about every page. I'm also using Chromium 75 and an Incognito window. |
13:23 |
jonadab |
We get that in production when we have network performance issues. |
13:23 |
Dyrcona |
By "Debian host," I mean that I see the same behavior with Jessie (8) and Stretch (9). |
13:23 |
Dyrcona |
Well, this is a vm running on my laptop. The network should actually be RAM... |
13:28 |
Dyrcona |
chrome-- |
13:29 |
Dyrcona |
I'll try with Firefox, but I'm pretty sure that I've got the haproxy config working. |
13:30 |
Dyrcona |
Firefox's cert warning has gotten even scarier than it used to be. |
13:30 |
jonadab |
For developers, browsers really need to have a command-line argument that says, effectively, all certs are valid by fiat. |
13:31 |
jonadab |
It's not practical to do a Let's Encrypt cert for something that's not public facing. |
13:31 |
jonadab |
Like a test setup. |
13:31 |
berick |
and the process for making chrome trust a self-signed cert is a bit more cumbserome now as well. |
13:32 |
Dyrcona |
Well, I could use my let's encrypt wildcard cert. |
13:32 |
Dyrcona |
I used to use my own CA and add it to my browsers. |
13:33 |
jonadab |
Actually, I'd be happy if it were domain specific, like --ignore-cert-errors=mydomain.example.com |
13:33 |
Dyrcona |
Reason that I could use my wildcard cert is that I also use dnsmasq with /etc/hosts entries for my test vms, so they're accessible as {vmane}.sigio.{com,org,net} |
13:34 |
Dyrcona |
bleh... typos... :) |
13:34 |
Dyrcona |
I wish the browser just had a "I know what I'm doing" configuration option. |
13:34 |
jonadab |
^ Indeed. |
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. |
09:57 |
|
stephengwills joined #evergreen |
09:58 |
Dyrcona |
Someone forget --create-offline when doing eg_db_config? |
10:21 |
csharp |
trying to recreate the test failure on my dev machine - I ran "prove" in the perlmods directory and all the tests passed |
10:21 |
csharp |
(on 3.1.13) |
10:22 |
Dyrcona |
I'm setting up a vm with our production branch on it. After yesterday's weird errors, I decided I should rebuild the vm from scratch. |
10:22 |
Dyrcona |
I'll try the failing test on it. |
10:25 |
csharp |
same with the master branch |
10:25 |
csharp |
All tests successful. Files=25, Tests=3250, 18 wallclock secs ( 0.43 usr 0.06 sys + 16.57 cusr 1.12 csys = 18.18 CPU) Result: PASS |
10:26 |
csharp |
(this is on Ubuntu 16.04, perl 5.22.1 |
10:26 |
csharp |
) |
10:29 |
Dyrcona |
Funn thing: While installing OpenSRF, I forgot the ldconfig step and OpenSRF still worked for the srfsh test. This is on Ubuntu 16.04. I've since done the ldconfig test, 'cause I suspect Evergreen and the Apache stuff depends on it. |
10:32 |
* Dyrcona |
is having one of those mornings... |
10:37 |
csharp |
oh - duh - those are live tests |
10:38 |
csharp |
hmm - not remember how to run those... |
10:41 |
csharp |
ah - make livecheck |
10:41 |
jeff |
This is how the qatests run the live tests: https://git.evergreen-ils.org/?p=working/random.git;a=blob;f=installer/stretch/eg_stretch_installer.sh;h=fdc96c54a9ec1d9b5701ac0ee4475a40589b8837;hb=2997e070d001c2448baad643e1d00560bd7a82f2#l1012 |
10:43 |
csharp |
jeff++ # thanks |
10:43 |
csharp |
mine are failing because my admin user doesn't have the password expected by the testes |
10:43 |
csharp |
tests |
10:50 |
Dyrcona |
csharp: You can also run prove on the live test directory or run them individually with prove or perl |
10:50 |
csharp |
Dyrcona: oh - good to know |
10:50 |
csharp |
I figured it was simple - I just haven't done it much and for a long time |
10:51 |
jeff |
when running individually, i'm pretty sure there are still assumptions that they all run once, in order. |
10:51 |
jeff |
i.e., later tests rely on the state left behind by earlier tests. |
10:52 |
jeff |
though we may have gotten away from that, in which case i missed it. |
10:56 |
Dyrcona |
jeff: They really should be totally independent of each other, but the offline test doesn't depend on any others. |
10:57 |
Dyrcona |
Like I said before.... :( |
10:57 |
Dyrcona |
But no one is paying to write tests, so... |
11:04 |
csharp |
might be something to consider for some of the dev-funding coops |
11:06 |
|
khuckins joined #evergreen |
11:24 |
JBoyer |
Writing the specs for writing test could be a fun one. dev:"This is just a sheet of paper with the words '100% codepath coverage' on it." user:"Yes. How much is that?" dev:"How much money exists?" |
11:26 |
csharp |
JBoyer++ |
12:04 |
Dyrcona |
So, for the logs 24-offline-all-assets.t succeeds for me on 3.2.4-custom+backports. |
12:05 |
Dyrcona |
Fun thing... Using haproxy on my test vm, I know get 504 Gateway Timeout instead of no search results. :) |
12:06 |
Dyrcona |
Now, to see if the complete rebuild resolves my missing web client files issue from yesterday morning's tests. |
12:07 |
Dyrcona |
Apparently, it did, so the breakage was unrelated to haproxy. |
12:08 |
Dyrcona |
So far, haproxy++ |
12:09 |
Dyrcona |
Oh, look at that! Time for lunch! :) |
12:58 |
Dyrcona |
So, I see something today that contradicts what I swear I saw in the code...It looks like doing a --process-hooks with no granularity does pick up events that have a granularity set. I swear that I saw the query deliberately looking for null granularity, though. |
13:03 |
csharp |
I thought you had to say --granularity-only to pick up ones with granularity, but it's been a while since I looked closely |
13:04 |
csharp |
maybe that's not for --process-hooks |
13:08 |
Dyrcona |
csharp: I'm testing some things. I removed --process-hooks from the one that runs with a granularity. |
13:08 |
Dyrcona |
s/with/without/ |
13:08 |
Dyrcona |
The others have a granularity but not --granularity-only and they seem to work OK. |
13:09 |
Dyrcona |
The only that has --granularity-only in my current set up is the password reset. |
15:16 |
|
khuckins joined #evergreen |
15:40 |
|
jvwoolf joined #evergreen |
16:12 |
|
jihpringle joined #evergreen |
17:00 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live/test.49.html#2019-06-27T16:58:17,850933386-0400 -0> |
17:04 |
csharp |
I look at reports I created a couple of years ago and can't figure out what I did |
17:04 |
csharp |
urg - arrow-up strikes again |
17:13 |
|
sandbergja joined #evergreen |
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 |