| 05:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:03 |
|
agoben joined #evergreen |
| 07:12 |
|
rjackson_isl joined #evergreen |
| 07:50 |
|
JBoyer joined #evergreen |
| 11:15 |
Bmagic |
gmcharlt: wow! How long has it been? I can't remember that going down. |
| 11:16 |
gmcharlt |
Bmagic: a bit too long, let's just say :) |
| 11:16 |
Bmagic |
:) |
| 11:16 |
csharp |
hah |
| 11:16 |
csharp |
Bmagic: I have the same question re: adding a config.metabib_field - I'm guessing a reingest is required? |
| 11:17 |
csharp |
we're testing the field mmorgan suggested to fix the 245c display issue |
| 11:17 |
Bmagic |
The virtual index release notes and documentation make it sound like you only need to restart the services |
| 11:17 |
|
bos20k joined #evergreen |
| 11:17 |
|
collum joined #evergreen |
| 11:23 |
|
jvwoolf joined #evergreen |
| 11:26 |
|
khuckins joined #evergreen |
| 11:30 |
Bmagic |
mmorgan: post upgrade to 3.1, the default virtual index on title is blank. Which (I think) means that the search method will continue to function the old way. But when introducing a single entry for "Main Title" - it should switch to using the virtual index method when searching? |
| 11:32 |
Bmagic |
Dyrcona: what would we lose if we switched to github? Working repo linkage? Automatic tests? Or maybe nothing? We would just have to do a bunch of work to make the transition? |
| 11:33 |
Dyrcona |
Bmagic the automated tests have nothing to do with gitolite, i.e. they're scripted outside of git. |
| 11:34 |
Dyrcona |
We'd have to change how we work with branches, and I'd recommend losing the working repository in favor of everyone having their own. I'd make the same recommendation switching to gitlab. |
| 11:35 |
Dyrcona |
Free github accounts for users and the organization look like our best option. |
| 03:42 |
|
jeff joined #evergreen |
| 03:44 |
|
yar 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:44 |
|
tlittle joined #evergreen |
| 09:33 |
* csharp |
has mixed feelings too |
| 09:33 |
* JBoyer |
would like the ability to design attrative html mails, but only if there's a usable plaintext alt-part for the plaintexters. |
| 09:33 |
csharp |
+1 |
| 09:35 |
* Dyrcona |
is going to try websocketd 0.3.1 on his test vm. |
| 09:35 |
JBoyer |
my understanding is that it's perfectly possible even now, but you've got to insert the multipart delimiter yourself and write both segments manually, yes? I'm not expecting our SendEmail reactor to pull out the plaintext as part of the process. |
| 09:35 |
mmorgan |
JBoyer: Yes, I can get you more detail. There were issues with the punctuation around those fields, too, which we (not me personally ;-)) addressed in tt2 files. |
| 09:35 |
JBoyer |
mmorgan++ |
| 14:54 |
Dyrcona |
I seem to recall Lp not liking certain characters in tags. |
| 15:09 |
Dyrcona |
And, Email::MIME and friends allow you to make nonconforming email messages, according to RFC 2822. |
| 15:14 |
Dyrcona |
If you pass a list to $email->header_set and family, you get multiple header entries. |
| 15:15 |
Dyrcona |
The address headers are only allowed to appear once per message, though my limited testing indicates multiple To: fields "works" even though the message is strictly illegal..... |
| 15:15 |
Dyrcona |
It's never as simple as you think. :) |
| 15:16 |
Dyrcona |
It's email. How complicated could it be? :) |
| 15:16 |
* jeff |
laughs |
| 15:23 |
Dyrcona |
maybe that's i may fault... |
| 15:23 |
Bmagic |
nfBurton: ansible for restarting services post boot: https://github.com/mcoia/eg-docker/blob/master/docker_builds/generic-dockerhub/restart_post_boot.yml |
| 15:24 |
Dyrcona |
So, it was... |
| 15:24 |
Dyrcona |
My test script wasn't decoding the message, first. SendEmail.pm is already doing that, so that's why it worked in one place but not the other. |
| 15:26 |
Dyrcona |
So, looks like I have a fix for bug 1801163. |
| 15:26 |
pinesol |
Launchpad bug 1801163 in Evergreen "SendEmail A/T reactor broken for recent version of Encode::MIME::Header" [High,In progress] https://launchpad.net/bugs/1801163 - Assigned to Jason Stephenson (jstephenson) |
| 15:31 |
Dyrcona |
And, I *think* I see a different bug.... |
| 16:45 |
Bmagic |
this is starting to make sense http://docs.evergreen-ils.org/3.1/_virtual_index_definitions_2.html |
| 16:48 |
Bmagic |
I also see a "fix me" at the top of https://wiki.evergreen-ils.org/doku.php?id=documentation:indexing |
| 16:58 |
|
bdljohn joined #evergreen |
| 17:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:02 |
|
bdljohn left #evergreen |
| 17:04 |
|
mmorgan left #evergreen |
| 17:16 |
|
jvwoolf left #evergreen |
| 00:09 |
|
eady joined #evergreen |
| 04:20 |
|
bdljohn1 joined #evergreen |
| 05:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:37 |
|
bos20k joined #evergreen |
| 07:38 |
|
agoben joined #evergreen |
| 07:56 |
|
jvwoolf joined #evergreen |
| 13:28 |
Dyrcona |
Not sure, yet, how you'd get both HTML and plain text parts out of the reactor. |
| 13:40 |
|
derekz joined #evergreen |
| 13:51 |
|
nfBurton joined #evergreen |
| 13:54 |
nfBurton |
In response to the HTML emails. I did get them working and am currently testing (successfully) HTML emails for new patrons. Likely to be expanded after. |
| 13:54 |
Bmagic |
Dyrcona: We've got the plain and html working with the patch |
| 13:55 |
Dyrcona |
"The patch..." Which patch? |
| 13:55 |
Bmagic |
bug 1532236 |
| 13:56 |
nfBurton |
I can confirm the same patch worked for me on 3.1.5 |
| 13:57 |
Bmagic |
The sample AT template on the bug shows how to do it |
| 13:59 |
Dyrcona |
Yes. That looks straightforward enough. We'll have to see if it still works with Email::Stuffer. |
| 14:06 |
csharp |
jeffdavis: testing privacy waiver branch - when I "purge" the patron via the UI, the actor.usr_privacy_waiver rows are retained - is that what you intended? |
| 14:06 |
csharp |
I realized that they would be deleted with an actual row deletion via cascade |
| 14:06 |
csharp |
s/realized/realize/ |
| 14:08 |
* csharp |
thinks we should add a DELETE to actor.usr_purge_data to handle it |
| 14:08 |
jeffdavis |
csharp: that's an oversight, the purge function should clear out that data |
| 14:08 |
csharp |
and I'm happy to do that |
| 14:08 |
jeffdavis |
yeah, that :) |
| 14:09 |
csharp |
do you want to do it? |
| 14:09 |
jeffdavis |
sure, will do |
| 14:09 |
csharp |
awesome |
| 14:09 |
csharp |
feature works great otherwise - tested from the staff and opac view |
| 14:09 |
csharp |
once we clear the policy hurdle (possibly in May) we'll probably implement it |
| 14:10 |
csharp |
it's a commonsense thing to be able to do with the software |
| 14:10 |
jeffdavis |
thanks for testing! |
| 14:13 |
Dyrcona |
Y'know, someone from CW MARS should open another bug on actor.user_delete, because the alternate names are not touched by that function, either. |
| 14:14 |
csharp |
jeffdavis: happy to do it |
| 14:20 |
* Dyrcona |
curses Lp and the infamous "Timeout Error." |
| 15:07 |
|
jvwoolf joined #evergreen |
| 16:55 |
csharp |
relevant: https://www.reddit.com/r/ProgrammerHumor/comments/ao4opn/10yearchallenge/ |
| 16:57 |
|
jvwoolf joined #evergreen |
| 17:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:09 |
|
mmorgan left #evergreen |
| 17:33 |
csharp |
calling 1144, 1145, & 1146 |
| 17:34 |
berick |
yeehaw |
| 17:42 |
pinesol |
[evergreen|Chris Sharp] LP#1715767 - stamping upgrade scripts - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6ae2427> |
| 17:44 |
csharp |
I guess the 10-year challenge meme is timely for our community since our first conference was in 2009 :-) |
| 17:59 |
|
bdljohn1 left #evergreen |
| 18:56 |
jeffdavis |
csharp++ # thanks for testing and commit! |
| 19:35 |
|
jamesrf joined #evergreen |
| 20:18 |
|
sandbergja joined #evergreen |
| 22:52 |
|
jamesrf joined #evergreen |
| 09:14 |
|
bdljohn left #evergreen |
| 09:14 |
|
jamesrf joined #evergreen |
| 09:37 |
|
terran joined #evergreen |
| 09:50 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-02-06T09:48:51,496761679-0500 -0> |
| 09:52 |
|
yboston joined #evergreen |
| 09:58 |
|
jvwoolf joined #evergreen |
| 10:13 |
|
Stompro joined #evergreen |
| 13:46 |
|
yboston joined #evergreen |
| 13:58 |
dbwells |
jeffdavis: I think you are right, and I can see it either way. It just felt a little more on the side of "let's make this better" rather than "let's fix what's broken", especially given that the current behavior has existed for quite a while. |
| 14:05 |
jeffdavis |
I was assuming that the current behavior is unintended and it just hadn't been noticed. |
| 14:06 |
csharp |
jeffdavis: I'm interested in testing patron privacy waivers, but I'm seeing several file conflicts with master. I'm fixing them locally, but you might want to rebase with master. |
| 14:07 |
jeffdavis |
csharp: ah, branch drift. Will do, thanks. :) |
| 14:08 |
csharp |
:-) |
| 14:13 |
* csharp |
is going to have to miss the dev meeting - 3:00 is always kid-pickup hour :-/ |
| 15:08 |
gmcharlt |
berick, JBoyer, csharp: where do we stand with a Hatch release? |
| 15:08 |
JBoyer |
It lives. |
| 15:08 |
berick |
indeed |
| 15:08 |
JBoyer |
Thanks to gsams testing |
| 15:08 |
JBoyer |
gsams++ |
| 15:08 |
gmcharlt |
gsams++ |
| 15:09 |
gmcharlt |
#info New Hatch release has been made |
| 15:09 |
gmcharlt |
berick, Bmagic: where stands the Dymo branch? |
| 15:09 |
berick |
I hope to spend some time on that this and next week, in fact |
| 15:10 |
gmcharlt |
great |
| 15:10 |
gsams |
I've been testing that as well this week |
| 15:10 |
gmcharlt |
I'll just carry the action item forward then |
| 15:10 |
gmcharlt |
#action Bmagic, berick, gsams et al will poke more on the Dymo branch |
| 15:10 |
berick |
gsams++ great |
| 15:11 |
gmcharlt |
#info OpenSRF 3.1.0 was released on 2019-01-17 |
| 15:11 |
gmcharlt |
anybody seeing issues running it (and not just the websocketd stuff) in production? |
| 15:11 |
miker |
no me! :) |
| 15:12 |
csharp |
we're running it in a test environment that's pretty well-used - no complaints yet |
| 15:12 |
Dyrcona |
I haven't used it in production, but it seems to work fine on my VMs, even with Evergreen 3.0. |
| 15:12 |
csharp |
(OpenSRF 3.1.0 + websocketd) |
| 15:12 |
gmcharlt |
ok |
| 15:34 |
csharp |
+1 to de-XUL-ification |
| 15:34 |
berick |
no strong preference, but will be good to reach some consensus there, since XUL is technically usable in 3.2. Is 3.3 where it fully stops working, i guess is the question. |
| 15:34 |
JBoyer |
+1 |
| 15:34 |
* csharp |
is happy to help (at least with testing) |
| 15:34 |
Dyrcona |
Did we ever set a release for removal of XUL? |
| 15:34 |
csharp |
PINES is running 3.2 without XUL (so far) - I think that's a good indicator that we can leave it behind |
| 15:34 |
* Dyrcona |
doesn't remember. |
| 15:40 |
miker |
s/page/branch |
| 15:40 |
berick |
miker++ |
| 15:40 |
sandbergja |
jeffdavis: not sure yet; I'll do some exploration this afternoon |
| 15:41 |
jeffdavis |
Sitka was hoping to test the bookings daily schedule this week and looking forward to having it in 3.3 |
| 15:41 |
berick |
i'd say at this stage there's some flexibility |
| 15:41 |
berick |
i mean if the code is already written... |
| 15:41 |
sandbergja |
yeah, I just barely missed 3.2 :-( |
| 15:52 |
gmcharlt |
#topic Should we update or remove Python libs from OpenSRF and Evergreen? |
| 15:52 |
|
Topic for #evergreen is now Should we update or remove Python libs from OpenSRF and Evergreen? (Meeting topic: Evergreen Development Meeting, 6 February 2019) |
| 15:53 |
Dyrcona |
It's a different situation from Java, in that it builds and srfsh.py works on Ubuntu 18.04, but not Ubuntu 16.04, and IIRC, Syrup uses it, but Syrup is abandonware. |
| 15:53 |
Dyrcona |
I haven't tested it on Debian since Debian 7, so I don't know if Python works on Stretch or Jessie. |
| 15:53 |
stephengwills |
I just used marc_convert.py for an on-boarding last week. Does that require any Osrf or Eg libs? or is it stand alone? |
| 15:54 |
Dyrcona |
And, then, there's another wrinkle. Our Python libs are version 2.7 compatible, and Python 2.7 is EOL on Jan 1, 2020. |
| 15:54 |
berick |
i'm pretty sure it's not 100% with perl/c osrf, but I also have not looked at it in a long time |
| 16:05 |
JBoyer |
gmcharlt++ |
| 16:05 |
Dyrcona |
gmcharlt++ |
| 16:05 |
rhamby |
gmcharlt++ |
| 16:06 |
gsams |
berick: On testing the DYMO hatch fix, the prints are diverting to an alternate printer other than the target. This is on Windows 10, I haven't tried elsewhere. |
| 16:07 |
berick |
gsams: *nod* |
| 16:07 |
gsams |
I had a small back and forth with Bmagic about it, and he got similar results. |
| 16:11 |
|
stephengwills left #evergreen |
| 16:11 |
|
jamesrf joined #evergreen |
| 16:59 |
|
mdriscoll left #evergreen |
| 17:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:06 |
|
jvwoolf left #evergreen |
| 17:12 |
|
mmorgan left #evergreen |
| 17:20 |
|
beanjammin joined #evergreen |
| 01:41 |
|
beanjammin joined #evergreen |
| 05:00 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-02-01T04:59:57,371382073-0500 -0> |
| 07:18 |
|
rjackson_isl joined #evergreen |
| 07:28 |
|
agoben joined #evergreen |
| 07:34 |
|
bdljohn joined #evergreen |
| 14:48 |
terran |
berick++ |
| 14:49 |
mmorgan |
Oh yeah, berick++ |
| 14:50 |
|
jammin joined #evergreen |
| 14:53 |
csharp |
having trouble getting websocketd working on my master test server - does anyone know where websocketd logs by default (running as opensrf behind an nginx proxy) |
| 14:53 |
csharp |
apache2-websockets was working fine before - I've changed nothing in nginx or apache |
| 14:53 |
|
jammin joined #evergreen |
| 14:55 |
Dyrcona |
csharp: It logs to the console, so you'll have to redirect it. |
| 14:55 |
csharp |
oh -hmm |
| 14:59 |
Dyrcona |
Well, it can be https... See my previous comment. :) |
| 15:00 |
csharp |
Dyrcona: makes sense - thanks |
| 15:00 |
berick |
yeah, https def. works |
| 15:00 |
jammin |
Howdy... going nuts while testing some stuff. In what sort of scenario might some libraries (such as osrf_math.so) in /openils/lib not be found, while others (such as libopensrf.so) are? |
| 15:00 |
csharp |
jammin: try (as root) 'ldconfig' |
| 15:00 |
Dyrcona |
The options are --sslcert=/path/to/cert --sslkey=/path/to/key |
| 15:01 |
csharp |
Dyrcona: awesome - thank you |
| 15:15 |
csharp |
cool |
| 15:15 |
* Dyrcona |
has been running websocketd in production since October. I backported the OpenSRF patches. |
| 15:15 |
csharp |
ok - awesome |
| 15:15 |
berick |
we just have it on a test cluster now. no issues. |
| 15:15 |
csharp |
that's my next step - get it running in a cluster |
| 15:15 |
csharp |
and build it into our cluster-install scripts |
| 15:16 |
jammin |
Dyrcona: thanks, yeah, that looks like what I'm hitting. I've got 3.0.0 on there now, still does it, but haven't touched my config yet... heading there now |
| 15:26 |
Dyrcona |
jammin: If you've installed Evergreen, you'll need to upgrade to Evergreen 3.0, also. |
| 15:26 |
csharp |
so is OpenSRF 3.1 good for EG 3.2? |
| 15:27 |
* Dyrcona |
has been using master, but I think so, csharp. |
| 15:27 |
Dyrcona |
i.e. in my testing of 3.2 |
| 15:28 |
jammin |
Dyrcona: at one point I was doing LD_DEBUG and saw it looking right at the right lib file, but it skipped right on to the next path... I said "whaaa?" :) |
| 15:28 |
Dyrcona |
jammin: It's because of changes in GCC 6. |
| 15:28 |
gsams |
csharp: Supposedly we are running OpenSRF 3.1 on EG 3.2.3 right now. |
| 15:28 |
Dyrcona |
Rereading the bug history refreshed my memory. |
| 15:30 |
jammin |
Dyrcona: got it, thanks. my actual target here is EG 3.1.2, so yeah will be doing that |
| 15:31 |
Dyrcona |
jammin: I think OpenSRF 3.1 should work for you, too. Might as well go with the latest and greatest. :) |
| 15:31 |
jammin |
Dyrcona: was testing upgrade to stretch before upgrading to 3.1.2. I guess the result is "don't" |
| 15:31 |
Dyrcona |
:) |
| 15:32 |
jammin |
Dyrcona: so opensrf 3.1 good to go for eg 3.1.2, then? |
| 15:33 |
Dyrcona |
I don't know of any incompatibilities. |
| 15:33 |
Dyrcona |
I've kind of skipped Evergreen 3.1 in my testing, though, so take that with a teaspoon of salt. |
| 15:34 |
* csharp |
chokes down a teaspoon of salt |
| 15:34 |
Dyrcona |
I think 3.1 works with 3.0 also.... At least parts of it do, because I backported some patches to our production servers. |
| 15:34 |
jammin |
Will know in a bit, gonna take a break, roll the vm back, and give it a go |
| 15:36 |
gsams |
csharp, Dyrcona: having literally just updated this week it's been incredibly smooth. |
| 15:36 |
Dyrcona |
Our members are making use of the web client in 3.0. |
| 15:36 |
csharp |
gsams: awesome |
| 15:36 |
jammin |
Our production is 3.1.2 on opensrf 3.0.1, I'm messing around with the test server while bringing it up to speed |
| 15:36 |
Dyrcona |
My testing looks like the upgrade will be straightforward. |
| 15:36 |
gsams |
If I can get the dymo hatch printer fix in place I'll be all set I think. |
| 15:36 |
csharp |
we expected more outcry from libraries who hadn't made the transition from circ yet |
| 15:37 |
jammin |
I need to get our RFID stuff playing nicely with the web client before can move up to 3.2 |
| 15:37 |
* csharp |
has to run pick up the teenager |
| 15:37 |
Dyrcona |
jammin: When it comes to upgrading the O/S on VMs, I usually don't. I just build a new VM, but I assume you wanted to test because you plan to upgrade production hardware? |
| 15:40 |
jammin |
Dyrcona: Not sure which way I'm going to go about it yet... rebuild VMs and fresh install, or dist-upgrade and EG upgrade. Figured either way, I should figure out how to "make it work". |
| 15:41 |
jammin |
Dyrcona: If I can fix a worst case, the easy cases will be that much easier. :) |
| 15:41 |
Dyrcona |
Yes. :) |
| 15:51 |
jammin |
I'm interested in moving up to debian-buster. Am I inviting similar library insanity? |
| 15:51 |
Dyrcona |
Probably not, but I don't think anyone has worked out the prerequisites for buster, yet. |
| 15:53 |
Dyrcona |
jammin: If you'd like to do that, feel free. Patches welcome! :) |
| 15:53 |
jeff |
Do not use unreleased testing versions of Linux distributions for production. :-) |
| 15:54 |
jammin |
I'm thinking I'll finish getting this thing going on stretch & 3.1.2 like I'm supposed to. Then take another snapshot, then see how buster goes... just because. |
| 15:55 |
Dyrcona |
It should be OK to start testing with buster, soon. The full freeze is supposed to happen in March. |
| 15:55 |
jeff |
Testing with buster and reporting issues is a useful thing, and appreciated. |
| 15:55 |
jeff |
But don't run it in production. :-) |
| 15:55 |
jammin |
No, not on production! But hey, Debian testing (in soft freeze, or close to it) isn't your average unreleased testing version. :) |
| 15:56 |
* jeff |
nods |
| 16:26 |
sandbergja |
Quick indexing question: In this doc, it says that it's required to do a "service restart" after making changes to Administration > Server > MARC Search/Facet Fields (metabib fields): http://docs.evergreen-ils.org/dev/_virtual_index_definitions.html |
| 16:26 |
sandbergja |
Which services exactly need to be restarted? |
| 16:49 |
Bmagic |
I've got a sample set of commands around somewhere |
| 16:50 |
pastebot |
"Bmagic" at 64.57.241.14 pasted "restarting services" (32 lines) at http://paste.evergreen-ils.org/14398 |
| 16:51 |
sandbergja |
Oh, cool! Thanks! |
| 17:00 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-02-01T16:58:45,062820692-0500 -0> |
| 17:14 |
csharp |
opensrf 3.1.0 and websocketd are now running on our 3.2.3 test server |
| 17:14 |
csharp |
all seems fine so far |
| 17:18 |
|
mmorgan left #evergreen |
| 17:23 |
Bmagic |
csharp++ |
| 18:58 |
|
beanjammin joined #evergreen |
| 05:00 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-01-31T04:57:55,332522187-0500 -0> |
| 07:01 |
|
agoben joined #evergreen |
| 07:04 |
|
rjackson_isl joined #evergreen |
| 07:20 |
JBoyer |
gsams, were you following the build steps in Hatch/installer/windows/README.adoc ? Hatch for Windows has a 2-step build process that involves building the /lib directory and filling it with .jar's, then building the installer with makensis. |
| 10:49 |
gsams |
I've got JDK 1.8.0_201, I'm trying to build it on Windows as that is what I have to work with here, though I do have a laptop at home I could probably get it done faster on. |
| 10:49 |
gsams |
I'm also kind of new to this, so I may very well be doing something wrong. |
| 10:53 |
berick |
gsams: any reason you're not using the windows installer? |
| 10:53 |
gsams |
berick: Trying to test the firefox branch |
| 10:53 |
berick |
ah |
| 10:54 |
JBoyer |
if you just open cmd and type java what happens? There have been irritations with the java path. |
| 10:54 |
berick |
gsams: the installer (and linux compile step) fetch a json library and put it into the lib dir |
| 10:55 |
berick |
you'll have to manually fetch that |
| 10:55 |
berick |
the docs assume windows builds use the installer, so it's not mentioned |
| 10:55 |
berick |
and the linux script does it for you |
| 10:56 |
JBoyer |
Hey, that would be the part I was not paying attention to. (I built it in Ubuntu on Windows 10 and cp'd it to my desktop to test) |
| 10:56 |
gsams |
ha, that makes a ton of sense. Now I know why I had it the first run now. |
| 10:56 |
berick |
gsams: you may want to just use the windows installer |
| 10:57 |
berick |
and then rebuild the java bits using the updated code |
| 10:57 |
berick |
the insatller does more than just build the java |
| 10:58 |
berick |
the windows registry changes being the most irksome |
| 10:59 |
JBoyer |
berick, gsams, the java bits aren't what needs testing, FF support is specifically broken by hatch.bat. (so the easy way to test this gsams, would be install the hatch you can download now and cp hatch.bat from my branch over the one in C:\ProgramFiles (8x6)\Hatch\) |
| 10:59 |
gsams |
JBoyer: I can do that |
| 10:59 |
berick |
ah, even easier |
| 10:59 |
JBoyer |
I haven't touched Java since college and haven't gotten so brave as to try messing with anything in there. |
| 13:13 |
jeff |
so it's nice that it turns out the flight recorder was running during the event. |
| 13:14 |
jeff |
and now we're just following its homing beacon to the backup repository containing the data from before it rotated out of the 48 hour cicrular buffer :-) |
| 13:34 |
JBoyer |
I can't tell which parts of that are for real and which parts are Grisham novel. This SIP message gets around but was in the wrong place at the wrong time and now it's an international incident. |
| 13:37 |
jeff |
I'm just being silly, it seems: we had a problem on Jan 15 for which we've been unable to create an isolated test case / reproduction. pcap logs of SIP2 traffic would be useful, and exist, but have rotated out of the circular dumpcap buffer. backup retention for the VM in question goes back far enough that we should be able to get the pcap data from there. |
| 13:40 |
JBoyer |
jeff++ # on the case. |
| 14:03 |
|
jamesrf joined #evergreen |
| 14:13 |
Dyrcona |
So, I'm getting this 2019-01-31 14:11:42 bh5 osrf_json_gw: [INFO:7428:osrf_app_session.c:394:154896183174287] Returning NULL from app_request_recv after timeout: open-ils.actor.patron.settings.retrieve ["redacted",1698794] in the logs for 3 users. So far, nothing looks off about their settings. |
| 16:42 |
gsams |
berick: you got it |
| 16:48 |
gsams |
berick: Hopefully that was enough info, but done. |
| 16:57 |
|
jvwoolf left #evergreen |
| 17:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:15 |
mmorgan |
gsams++ |
| 17:15 |
|
mmorgan left #evergreen |
| 17:47 |
|
khuckins joined #evergreen |
| 05:00 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-01-30T04:57:51,949378057-0500 -0> |
| 06:52 |
dickreckard |
hello.. I have a question about a swollen database.. |
| 06:53 |
dickreckard |
I have run a few commands from the postgresql interface, to fix some mess with character encoding that happened during migration.. |
| 06:53 |
dickreckard |
they were UPDATEs with search and REPLACE on the whole biblio.record_entry ... |
| 11:08 |
* pinesol |
brews and pours a cup of Panama El Burro Estate, and sends it sliding down the bar to csharp (quickly) |
| 11:09 |
mmorgan |
csharp: That needs to be on a t-shirt. |
| 11:09 |
csharp |
berick++ # saving lives |
| 11:25 |
gsams |
Does hatch for firefox need any testing still? I'd like to try it out if it's in a state for that. |
| 11:26 |
dickreckard |
csharp: thanks a lot, vacuuming and cleaning up the record_history worked |
| 11:26 |
dickreckard |
csharp++ |
| 11:27 |
dickreckard |
another thing I encountered though, is there a way to cleanup the metabib.browse_entry? it seem to keep the entries for each modification of a record.. |
| 12:21 |
berick |
yeah |
| 12:23 |
JBoyer |
Hmm. except my normal build also calls npm update. Not sure why that didn't catch it earlier. :/ |
| 12:25 |
JBoyer |
And now it's complaining about jasmine. I guess I'll keep looking. |
| 12:26 |
berick |
i'm testing some hard-coded versions |
| 12:27 |
berick |
related, we really need to merge bug 1801984 sooner than later |
| 12:27 |
JBoyer |
bot is letting us down. |
| 12:28 |
pinesol |
Launchpad bug 1801984 in Evergreen "Transition to Angular version 7." [Undecided,New] https://launchpad.net/bugs/1801984 |
| 12:28 |
JBoyer |
Ah. |
| 12:50 |
* csharp |
gets frustrated when the solution to a nodejs problem is "downgrade npm" |
| 12:50 |
JBoyer |
No, I thought "maybe the Angular 7 compiler will like this code more." Then I uninstalled it and now I'm blowing away everything and starting from scratch. |
| 12:51 |
csharp |
I had that issue when building the Linux client for Google Music Desktop Player |
| 12:51 |
JBoyer |
berick, when you have time to rebase that branch I will test it asap. |
| 12:52 |
berick |
JBoyer: doing so now. and after a rebuild, errors are clear |
| 12:54 |
berick |
JBoyer: LP updated |
| 12:54 |
JBoyer |
berick++ |
| 12:56 |
gsams |
JBoyer: Ah, yes I think I see what I was doing wrong. I misunderstood the readme. |
| 13:08 |
Dyrcona |
berick: What is your threshold for merging Ang 7 into master? |
| 13:11 |
berick |
Dyrcona: threshold? |
| 13:11 |
Dyrcona |
Yeah, like how many signoffs, how many tests, etc.? |
| 13:12 |
berick |
oh, i don't see it as any different than a feature merge. (though it's almost a bug fix merge at this point). as long as the existing tests pass (they do) then I think the tests are covered. |
| 13:13 |
berick |
it doesn't introduce new code, mostly just changes to how we import certain libraries |
| 13:13 |
berick |
rxjs being the big upheaval |
| 13:13 |
berick |
oh, and, the UI should work ;) |
| 13:14 |
Dyrcona |
So, should it be backported to 3.2? |
| 13:14 |
berick |
maybe.. |
| 13:14 |
berick |
let me see if it merges/builds in 3.2 |
| 13:15 |
JBoyer |
That's basically what I'm doing now. :) I pulled it in to our locally customized rel_3_2 |
| 13:16 |
Dyrcona |
I was going to say that I could test it with rel_3_2. |
| 13:16 |
JBoyer |
And everything looks good so far. Almost ready to start with the clicky-clicky. |
| 13:16 |
Dyrcona |
:) |
| 13:16 |
berick |
Dyrcona: for 3.2 backport, an extra test/signoff would certainly be appreciated |
| 13:17 |
berick |
since we want to avoid disruption |
| 13:17 |
berick |
and we don't normally back-port version upgrades |
| 13:18 |
berick |
3.2 is working fine for me |
| 13:18 |
berick |
no big surprise, there's very little code deviation yet between master |
| 13:19 |
* berick |
updates LP |
| 13:19 |
Dyrcona |
berick++ JBoyer++ |
| 13:20 |
JBoyer |
Nice. |
| 13:20 |
JBoyer |
berick++ |
| 16:12 |
|
Dyrcona joined #evergreen |
| 16:15 |
gsams |
JBoyer: That appears to be the case in both browsers though, so I suspect that's my fault. I'll double back on it for the moment. |
| 16:26 |
|
book` joined #evergreen |
| 17:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:06 |
|
mmorgan left #evergreen |
| 17:23 |
gsams |
Post install note: refresh the page |
| 17:23 |
gsams |
only thing that hasn't fixed for me is hatch. |
| 17:30 |
Dyrcona |
berick++ Angular 7 is working for me on an "upgrade" of a VM from master to master. |
| 17:32 |
berick |
cool |
| 17:33 |
Dyrcona |
The UI looks good. I've run the Angular and AngularJS tests, Running perl live tests now, just to be sure. |
| 17:35 |
Dyrcona |
berick: So, it's OK with you if I signoff and push it to master and 3.2? |
| 17:40 |
berick |
Dyrcona: yes |
| 17:41 |
Dyrcona |
All right, then, I will do that. |
| 17:42 |
|
jvwoolf left #evergreen |
| 17:49 |
pinesol |
[evergreen|Bill Erickson] LP#1801984 Upgrading Angular 6 to Angular 7 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7e2483b> |
| 18:01 |
gsams |
JBoyer: So I went back and started over, as I was having an issue seeing printers in both Chrome and Firefox. Now I can't get installer to compile at all. It's giving me an error on line 175. |
| 20:27 |
gsams |
JBoyer:Final note, for whatever reason when I went to retry the process, the lib folder wasn't present anymore. I ported it over from the precompiled installer, just to get it going. It appears to work properly now. |
| 20:28 |
gsams |
I'm just a tad bit out of my depth on this one, so I'm not really sure what went wrong. It was there the first time I cloned the branch, but then it wasn't the next time. |
| 20:29 |
gsams |
In any case, I'm about to sign off on it as I've gotten it to work in Firefox. |
| 20:53 |
gsams |
strike that, I thought berick had done the Chrome testing, and my gut says to wait. |
| 20:53 |
gsams |
since my chrome appears to not be working, so maybe I either did something else wrong. |
| 20:54 |
gsams |
or something did break. |
| 21:30 |
|
jamesrf joined #evergreen |
| 23:41 |
|
sandbergja joined #evergreen |
| 00:25 |
|
beanjammin joined #evergreen |
| 05:00 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-01-29T04:58:02,473540238-0500 -0> |
| 05:16 |
|
beanjammin joined #evergreen |
| 07:01 |
|
agoben joined #evergreen |
| 07:09 |
|
rjackson_isl joined #evergreen |
| 10:24 |
JBoyer |
I don't have a good feel for how much they're used, but I think the reason they're not enabled by default is (potential?) user confusion. The users that know what they are and are for like them a lot. |
| 10:25 |
JBoyer |
(Also, until very recently we didn't have a good way to distinguish DVD/BR and that would cause some unhappyness. And MR holds don't mesh with parts to my knowledge, so...) |
| 10:29 |
|
Dyrcona joined #evergreen |
| 10:30 |
phasefx_ |
I think this might be a heisenbug: http://testing.evergreen-ils.org/~live/test.42.html#2019-01-29T04:58:02,473540238-0500 |
| 10:32 |
JBoyer |
Dyrcona, I think the perl EDI pusher might help in that situation (since it doesn't bother with AT at all) but if it's not happening enough to warrant the switch that may not be much help. |
| 10:33 |
berick |
JBoyer: was going to say the same... |
| 10:33 |
Dyrcona |
JBoyer: Thanks. I have not looked into it that deeply, yet. As you said, it happens may be once/month, but sometimes twice in two weeks. |
| 10:34 |
berick |
*things like newlines |
| 10:39 |
|
nfBurton joined #evergreen |
| 11:09 |
JBoyer |
phasefx_, kind of a surprising one though. I'm not sure how that could change from one run to the next? |
| 11:11 |
phasefx_ |
JBoyer: not sure, but I saw it one my test system a lot when I was working on the QA scripts, but then it didn't happen on the one we use for the website, so I stopped worrying about it, until it reappeared today |
| 11:16 |
Dyrcona |
I've had tests sometimes fail, though it seems to b related to the order of running PgTAP and Perl tests, though not always reproducible. |
| 11:17 |
Dyrcona |
phasefx_: Guess we jumped the gun on Lp 1794588. We look forward to the revised branch later this week! |
| 11:17 |
pinesol |
Launchpad bug 1794588 in Evergreen 3.2 "Web client edit single call number changes all when multiple items attached" [Undecided,Confirmed] https://launchpad.net/bugs/1794588 |
| 11:17 |
|
beanjammin joined #evergreen |
| 16:15 |
miker |
abowling: for push, or even for pull? (assuming git@ repo syntax) |
| 16:15 |
miker |
(and, I'm assuming, for the working repo?) |
| 16:48 |
jeffdavis |
Does anyone around here have access to the NCIP v1 spec? I haven't been able to dig up a copy (best I can find is a DTD). |
| 17:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:10 |
|
mmorgan left #evergreen |
| 17:26 |
|
beanjammin joined #evergreen |
| 17:37 |
|
jvwoolf left #evergreen |
| 00:23 |
|
beanjammin joined #evergreen |
| 05:01 |
pinesol |
News from qatests: Failed Installing OpenSRF pre-requisites <http://testing.evergreen-ils.org/~live/test.7.html#2019-01-27T04:36:36,134655585-0500 -0> |
| 05:01 |
pinesol |
News from qatests: Failed Building OpenSRF <http://testing.evergreen-ils.org/~live/test.9.html#2019-01-27T04:36:36,145320458-0500 -2> |
| 05:01 |
pinesol |
News from qatests: Failed Running OpenSRF build tests <http://testing.evergreen-ils.org/~live/test.10.html#2019-01-27T04:36:36,155872803-0500 -4> |
| 05:01 |
pinesol |
News from qatests: Failed creating opensrf user and environment <http://testing.evergreen-ils.org/~live/test.12.html#2019-01-27T04:36:36,166398512-0500 -6> |
| 05:01 |
pinesol |
News from qatests: Failed configuring ejabberd <http://testing.evergreen-ils.org/~live/test.15.html#2019-01-27T04:36:36,176977598-0500 -8> |
| 05:01 |
pinesol |
News from qatests: Failed creating jabber users <http://testing.evergreen-ils.org/~live/test.16.html#2019-01-27T04:36:36,187453946-0500 -10> |
| 05:01 |
pinesol |
News from qatests: Failed configuring OpenSRF <http://testing.evergreen-ils.org/~live/test.17.html#2019-01-27T04:36:36,197942981-0500 -12> |
| 05:01 |
pinesol |
News from qatests: Failed start opensrf <http://testing.evergreen-ils.org/~live/test.18.html#2019-01-27T04:36:36,208465643-0500 -14> |
| 05:01 |
pinesol |
News from qatests: Failed stop opensrf <http://testing.evergreen-ils.org/~live/test.19.html#2019-01-27T04:36:36,219023235-0500 -16> |
| 05:01 |
pinesol |
News from qatests: Failed start opensrf <http://testing.evergreen-ils.org/~live/test.20.html#2019-01-27T04:36:36,229543507-0500 -18> |
| 05:01 |
pinesol |
News from qatests: Failed test opensrf <http://testing.evergreen-ils.org/~live/test.21.html#2019-01-27T04:36:36,240078227-0500 -20> |
| 05:01 |
pinesol |
News from qatests: Failed configuring websockets <http://testing.evergreen-ils.org/~live/test.22.html#2019-01-27T04:36:36,250624553-0500 -22> |
| 05:01 |
pinesol |
News from qatests: Failed stop opensrf <http://testing.evergreen-ils.org/~live/test.23.html#2019-01-27T04:36:36,261252502-0500 -24> |
| 05:01 |
pinesol |
News from qatests: Failed Installing Evergreen pre-requisites <http://testing.evergreen-ils.org/~live/test.26.html#2019-01-27T04:36:36,271800743-0500 -26> |
| 05:01 |
pinesol |
News from qatests: Failed Installing Angular web client <http://testing.evergreen-ils.org/~live/test.29.html#2019-01-27T04:36:36,282350977-0500 -28> |
| 05:01 |
pinesol |
News from qatests: Failed Building Evergreen <http://testing.evergreen-ils.org/~live/test.30.html#2019-01-27T04:36:36,292921177-0500 -30> |
| 05:01 |
pinesol |
News from qatests: Failed Running Evergreen tests <http://testing.evergreen-ils.org/~live/test.31.html#2019-01-27T04:36:36,303413681-0500 -32> |
| 05:01 |
pinesol |
News from qatests: Failed Installing Evergreen <http://testing.evergreen-ils.org/~live/test.32.html#2019-01-27T04:36:36,313932658-0500 -34> |
| 05:01 |
pinesol |
News from qatests: Failed Change File Ownership <http://testing.evergreen-ils.org/~live/test.33.html#2019-01-27T04:36:36,324429797-0500 -36> |
| 05:01 |
pinesol |
News from qatests: Failed Installing Dojo <http://testing.evergreen-ils.org/~live/test.35.html#2019-01-27T04:36:36,335032928-0500 -38> |
| 05:01 |
pinesol |
News from qatests: Failed configure apache <http://testing.evergreen-ils.org/~live/test.36.html#2019-01-27T04:36:36,345534813-0500 -40> |
| 05:01 |
pinesol |
News from qatests: Failed configure EG OpenSRF <http://testing.evergreen-ils.org/~live/test.37.html#2019-01-27T04:36:36,356033586-0500 -42> |
| 05:01 |
pinesol |
News from qatests: Failed configure EG Action/Trigger <http://testing.evergreen-ils.org/~live/test.38.html#2019-01-27T04:36:36,366494806-0500 -44> |
| 05:01 |
pinesol |
News from qatests: Failed Create Evergreen Database <http://testing.evergreen-ils.org/~live/test.41.html#2019-01-27T04:36:36,378341674-0500 -46> |
| 05:01 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-01-27T04:36:36,389221388-0500 -48> |
| 05:01 |
pinesol |
News from qatests: Failed start opensrf <http://testing.evergreen-ils.org/~live/test.43.html#2019-01-27T04:36:36,399678885-0500 -50> |
| 05:01 |
pinesol |
News from qatests: Failed Running autogen.sh <http://testing.evergreen-ils.org/~live/test.44.html#2019-01-27T04:36:36,410167249-0500 -52> |
| 05:01 |
pinesol |
News from qatests: Failed Restarting Apache <http://testing.evergreen-ils.org/~live/test.45.html#2019-01-27T04:36:36,420721842-0500 -54> |
| 05:01 |
pinesol |
News from qatests: Failed test EG opensrf <http://testing.evergreen-ils.org/~live/test.46.html#2019-01-27T04:36:36,431285564-0500 -56> |
| 05:01 |
pinesol |
News from qatests: Failed Running pgTAP live tests <http://testing.evergreen-ils.org/~live/test.47.html#2019-01-27T04:36:36,441802938-0500 -58> |
| 05:01 |
pinesol |
News from qatests: Failed Running settings-tester.pl <http://testing.evergreen-ils.org/~live/test.48.html#2019-01-27T04:36:36,452316792-0500 -60> |
| 05:01 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live/test.49.html#2019-01-27T04:36:36,462866936-0500 -62> |
| 05:01 |
pinesol |
News from qatests: Failed Gathering log summary <http://testing.evergreen-ils.org/~live/test.50.html#2019-01-27T04:36:36,473368748-0500 -64> |
| 05:01 |
pinesol |
News from qatests: Failed Log Output: config.log <http://testing.evergreen-ils.org/~live/test.51.html#2019-01-27T04:36:36,483854091-0500 -66> |
| 07:26 |
|
sandbergja joined #evergreen |
| 08:04 |
|
sandbergja joined #evergreen |
| 11:35 |
|
sandbergja joined #evergreen |
| 13:25 |
|
beanjammin joined #evergreen |
| 15:39 |
|
beanjammin joined #evergreen |
| 17:00 |
pinesol |
News from qatests: Failed Restarting Apache <http://testing.evergreen-ils.org/~live/test.45.html#2019-01-27T16:52:05,243690778-0500 -0> |
| 17:15 |
|
sandbergja joined #evergreen |
| 04:31 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:07 |
|
rjackson_isl joined #evergreen |
| 07:09 |
|
bdljohn joined #evergreen |
| 07:39 |
|
tlittle joined #evergreen |
| 15:13 |
jeff |
oh, and... |
| 15:13 |
jvwoolf |
Thank you, I would not have thought to look in the actor schema! |
| 15:13 |
jeff |
it's actor.search_filter_group, actor.search_filter_group_entry, and actor.search_query |
| 15:16 |
Dyrcona |
So, I'm seeing ingest being a lot slower on 3.2 than on a 3.0 database. I'm going to redo my "tests" next week and get some actual timings. Just thought I'd throw that out there. |
| 15:16 |
jeff |
also, if you're working with search filter groups that rely on "non-dynamic" filters like locations(), be aware of bug 1808055 |
| 15:17 |
pinesol |
Launchpad bug 1808055 in Evergreen "Search queries containing a filter in a subquery/group may drop the filter" [Undecided,New] https://launchpad.net/bugs/1808055 - Assigned to Mike Rylander (mrylander) |
| 15:20 |
miker |
Dyrcona: well, there are about 2x cmf's now, for display fields... |
| 15:21 |
Dyrcona |
I'm skipping the display fields in this test. I'm testing my branch for bug 1813172 by just doing a record attribute reingest. |
| 15:21 |
pinesol |
Launchpad bug 1813172 in Evergreen "Add option to specify metabib record attributes for reingest to pingest.pl" [Wishlist,New] https://launchpad.net/bugs/1813172 |
| 15:22 |
Dyrcona |
But, yeah, more fields makes a difference. |
| 15:41 |
jvwoolf |
jeff: Thanks for pointing out that bug. I think that may be our problem. We are relying on shelving location searches in our kidcat. |
| 15:48 |
jvwoolf |
jeff: Are you doing any workarounds in your catalog at this point? |
| 15:48 |
jeff |
jvwoolf: that is currenty broken. miker proposed a fix, but it didn't seem to work in our environment. i have not had/made time to investigate further. |
| 15:49 |
jeff |
jvwoolf: in the one place where we were using locations() in search filter groups, we expanded to use audience and added some additional item types, but it's an imperfect solution. i'd like to revisit or get additional eyes on the bug. |
| 15:49 |
miker |
I haven't had time to dig in either ... it seemed to work in my mock testing, but I'll have to look more |
| 15:50 |
jeff |
jvwoolf: sounds like you're the second person to hit it, though -- you could mark the bug Confirmed. :-) |
| 15:51 |
jeff |
and feel free to test the fix, if you're able and willing -- it's possible that my testing was flawed. |
| 15:51 |
jvwoolf |
For sure. Thanks, jeff |
| 15:51 |
miker |
+1 |
| 15:52 |
jeff |
jvwoolf++ miker++ |
| 15:52 |
jvwoolf |
jeff++ miker++ |
| 16:20 |
|
yboston joined #evergreen |
| 16:31 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:02 |
|
mmorgan left #evergreen |
| 17:09 |
|
jvwoolf left #evergreen |
| 17:35 |
|
bos20k joined #evergreen |
| 00:34 |
|
bshum joined #evergreen |
| 04:31 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:02 |
|
agoben joined #evergreen |
| 08:03 |
miker |
mmorgan: re deleting users in batch from a bucket, that behavior is intended and documented (in the specs, at least). it's to allow rolling back a batch action, and to provide a level of accident protection. |
| 08:04 |
miker |
also Bmagic -^ |
| 13:23 |
Dyrcona |
Hmm. Apparently not... |
| 13:24 |
Dyrcona |
At least not what I suspected. Seems normal. |
| 13:32 |
csharp |
we haven't noticed any trouble since upgrading to 3.2 over the weekend |
| 13:33 |
Dyrcona |
Yeah. I'm going to try doing Lp 1813172 and testing that on a db upgraded from 3.0 to 3.2. |
| 13:33 |
pinesol |
Launchpad bug 1813172 in Evergreen "Add option to specify metabib record attributes for reingest to pingest.pl" [Wishlist,New] https://launchpad.net/bugs/1813172 - Assigned to Jason Stephenson (jstephenson) |
| 13:42 |
|
yboston joined #evergreen |
| 13:49 |
eby |
question if there is anyone that knows offhand. I think i'm not getting my keywords right. From the code and documentation it seems that shelf hold expire dates are moved ahead if they fall on a closed date but not if there is a closed date between the dates, at least in our experience. |
| 14:17 |
Dyrcona |
Something in the logs that eby shared is highly relevant to something that I've been thinking about lately. |
| 14:17 |
eby |
2013 must have been a good thought year |
| 14:20 |
Dyrcona |
Next gen. and the future and all of that. :) |
| 14:23 |
Dyrcona |
Hmm.. Back to that potential bug in metabib.reingest_record_attributes....My test run of just doing that on a 3.0 database with pingest.pl has already processed the first 8 batches. On a 3.2 database, it still hasn't finished the first batch. I started the latter first. |
| 14:26 |
Dyrcona |
I wonder if specifying the pattr_list attribute can really slow things down. That bears looking into. |
| 14:32 |
Dyrcona |
It's now up to 12 batches done on the 3.0 database... |
| 14:33 |
Dyrcona |
Could just be the luck of the draw, but the 3.2 database has now finished 5 batches. |
| 16:13 |
jeff |
Dyrcona++ sandbergja++ csharp++ berick++ |
| 16:16 |
|
Dyrcona joined #evergreen |
| 16:21 |
|
seymour joined #evergreen |
| 16:31 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:18 |
|
mmorgan left #evergreen |
| 17:32 |
|
jvwoolf left #evergreen |
| 17:34 |
|
yboston joined #evergreen |
| 04:31 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:16 |
|
rjackson_isl joined #evergreen |
| 07:27 |
|
bdljohn joined #evergreen |
| 07:53 |
|
agoben joined #evergreen |
| 09:51 |
stephengwills |
for the record: just found this from Dan Wells: https://bugs.launchpad.net/evergreen/+bug/1053397 in 2014. some kind of memory error. |
| 09:51 |
pinesol |
Launchpad bug 1053397 in Evergreen "TPAC - Missing Meta-record Level Hold" [Wishlist,Fix released] |
| 10:06 |
|
jvwoolf1 joined #evergreen |
| 10:06 |
stephengwills |
yup…seg fault on 8G test server. will increase RAM and try again. |
| 10:12 |
miker |
csharp: re your log from last night, the cstore backends are timing out waiting for a request, which means that storage (the inner-most search stuff) is doing something for longer than 6 seconds ... cstore itself isn't timing out. it could very well be the container filter code... is that a big container? |
| 10:19 |
miker |
hrm... looking at the code, I don't like that theory anymore :( |
| 11:14 |
|
collum joined #evergreen |
| 12:03 |
pinesol |
[evergreen|Bill Erickson] LP#1808268 eg2 grid rename action disable option - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9776fd8> |
| 12:09 |
|
jihpringle joined #evergreen |
| 12:13 |
pinesol |
[evergreen|Bill Erickson] LP1808268 eg2 grid action disableOnRows sanity check - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=795c2f3> |
| 12:21 |
csharp |
miker: here's another example of something where cstore stops waiting: https://pastebin.com/2U201g0c |
| 12:22 |
csharp |
my next step is to kick up the loglevel on our test server to see what it shows, but I'm consumed with personal stuff today, so it will need to be later |
| 12:24 |
csharp |
stephengwills: make sure to rule out bug 1764542 |
| 12:24 |
pinesol |
Launchpad bug 1764542 in Evergreen "Incorrect format on config.metabib_field insert results in segmentation fault" [High,Fix released] https://launchpad.net/bugs/1764542 |
| 12:24 |
* csharp |
disappears again |
| 12:37 |
|
yboston joined #evergreen |
| 15:32 |
miker |
Stompro: just make sure your index normalizer has a position > 0 so that it doesn't change the displayed values |
| 15:33 |
miker |
if you go that route |
| 15:34 |
Stompro |
miker, are you a mind reader, i was just looking at that field. |
| 15:42 |
Stompro |
Hmm, i tried just simply substituting & for and in the normalizer, and that seems like it does it in my quick testing. Miker, is there a reason I need to map & to _and_ vs just to 'and'; |
| 15:43 |
Dyrcona |
tsqueries, maybe? |
| 15:43 |
Dyrcona |
but, maybe not. |
| 15:45 |
Stompro |
we already have a synonym for and -> &, so with that change both & and 'and" exist in the series_field_entry index_vector, but the series_field_entry value does now have and vs &. |
| 15:47 |
miker |
Stompro: no reason, really. does searching for & also work then? |
| 15:52 |
Stompro |
miker, it seems like it does, but it could just be filtering out the &, the results with or without the & included seem to work. It does change the relevance ranking for the couple that I've reindexed since making the change. |
| 15:52 |
|
yboston joined #evergreen |
| 15:56 |
Stompro |
When I remove the "&" in the series from one of the items I'm testing, that title still comes up for a search with or without '&' included, but not when 'and' is used. So I think the & is being ignored. |
| 15:57 |
Stompro |
Which is fine, I just want the 'and' searches to work. |
| 16:08 |
|
jamesrf joined #evergreen |
| 16:31 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 16:36 |
Stompro |
miker, hmm, searches with quotes around them, exact match, won't work with this method... |
| 16:38 |
Stompro |
The advanced search, exact match option does still work though. |
| 16:45 |
Bmagic |
Did I see a bug (can't find it now) that said that deleting patron using user buckets does NOT remove the patron data? |
| 04:31 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:51 |
|
agoben joined #evergreen |
| 06:55 |
|
JBoyer joined #evergreen |
| 07:07 |
|
rjackson_isl joined #evergreen |
| 10:01 |
|
Christineb joined #evergreen |
| 10:03 |
|
mmorgan1 joined #evergreen |
| 10:18 |
|
nfBurton joined #evergreen |
| 10:43 |
remingtron |
berick or others: do you have instructions on the minimum steps to test a new angular branch? |
| 10:44 |
remingtron |
I'm testing bug 1749475 and don't want to do the full install process |
| 10:44 |
berick |
remingtron: in the eg2 dir: npm run test |
| 10:44 |
pinesol |
Launchpad bug 1749475 in Evergreen "wishlist: Improved email and printing from the OPAC" [Wishlist,New] https://launchpad.net/bugs/1749475 |
| 10:45 |
remingtron |
sorry, I meant "install" the code into it's production location, not "run the tests" |
| 10:45 |
berick |
ah |
| 10:45 |
berick |
before 'make install', inside the eg2 directory: ng build --prod |
| 10:47 |
remingtron |
cool. Does configure or make do anything with the eg2 bits? |
| 12:20 |
pinesol |
[evergreen|Cesar Velez] LP#1727345 - fix bibsource when importing or overlaying - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=014b62e> |
| 12:21 |
rsulejmani |
berick: ok |
| 12:21 |
rsulejmani |
I just did the psql with -h host and it returned that the database evergreen does not exist |
| 12:22 |
berick |
rsulejmani: also, FWIW, I always install with -e use_pg_96=true. it should work either way, but I never install 9.5 so it gets less testing (though I think bshum uses 9.5) |
| 12:22 |
rsulejmani |
berick: ok will do the same thanks |
| 12:22 |
Dyrcona |
I use Pg 9.5 but don't use the ansible installer. |
| 12:23 |
Dyrcona |
rsulejmani: It sounds like the database creation step failed. I can help you with that manually if it fails the second time. I'm sure berick and others can help, too. ;) |
| 13:49 |
pinesol |
berick: Must be because I had the flu for Christmas. |
| 13:49 |
berick |
makes sense pinesol |
| 13:49 |
berick |
oh, now it's back |
| 13:52 |
csharp |
our lists (bookbags) are broken, resulting in an Internal Server Error page and I'm stumped about how to trace it |
| 13:53 |
csharp |
I can see the call in the osrfsys log, but nothing directly corresponds to that threadtrace in the error log |
| 13:54 |
csharp |
2019-01-22 13:53:56 brick04-head osrf_json_gw: [perl:error] [pid 31416] [client 127.0.0.1:50480] egweb: Context Loader error: Exception: OpenSRF::DomainObject::oilsMethodException 2019-01-22T13:53:56 OpenILS::WWW::EGWeb /usr/local/share/perl/5.22.1/OpenILS/WWW/EGWeb.pm:185 <500> No active transaction to roll back\n, referer: https://gapines.org/eg/opac/myopac/lists |
| 13:55 |
|
rsulejmani joined #evergreen |
| 13:56 |
csharp |
that's within the run_context_loader subroutine, and I'm not sure what that does |
| 13:58 |
|
khuckins joined #evergreen |
| 14:07 |
|
khuckins joined #evergreen |
| 14:12 |
csharp |
crazy thing is, test server running the same code is working fine |
| 14:15 |
Dyrcona |
csharp: What that code does is look up a Perl module in the directory or other config, use the module, then call it's load method. If that throws an error, it reports it. So, it looks like your context load module is failing. |
| 14:16 |
Dyrcona |
That looks like it would be EGCatLoader. |
| 14:17 |
Dyrcona |
The tricky part, now, is figuring what part of EGCatLoader. |
| 16:20 |
yboston |
If I only wanted subfield $a, then I could again just use the metabib.full_rec view, |
| 16:20 |
yboston |
but I end up with the correct 650 subfield $a for a particular bib, but if there are other subfields like $y in that same bib but for another 650 tag, then $y is incorrectly showing up with all the $a's |
| 16:22 |
pastebot |
"yboston" at 64.57.241.14 pasted "SQL to try to pull subjects from certain bibs" (60 lines) at http://paste.evergreen-ils.org/14388 |
| 16:31 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 16:31 |
rsulejmani |
berick: I'm testing something in the source code of the evergreen system and I was wondering since I updated and saved something how do I refresh the system so the changes can show |
| 16:32 |
yboston |
I am wondering if there is another view or table I should try to use to get the correct subject data, since I can trust the list of bibs I have. Alternatively, I can export all those bibs a use a MARC programming library to go through all the bibs and then output the 6xx fields |
| 16:40 |
berick |
rsulejmani: depends a lot on what you are changing |
| 16:41 |
berick |
you can always copy your files into place then restart the whole system, but there are usually much faster ways |
