| Time |
Nick |
Message |
| 06:32 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:51 |
|
jvwoolf joined #evergreen |
| 07:50 |
|
rjackson_isl joined #evergreen |
| 07:50 |
|
rjackson_isl_ joined #evergreen |
| 07:51 |
|
rjackson_isl joined #evergreen |
| 08:12 |
|
rjackson_isl joined #evergreen |
| 08:33 |
|
idjit joined #evergreen |
| 08:40 |
|
Dyrcona joined #evergreen |
| 08:55 |
|
mmorgan joined #evergreen |
| 09:10 |
|
mmorgan1 joined #evergreen |
| 09:13 |
|
mmorgan2 joined #evergreen |
| 09:44 |
|
sard joined #evergreen |
| 10:34 |
|
Christineb joined #evergreen |
| 10:35 |
|
stephengwills joined #evergreen |
| 10:53 |
* dbs |
dropped back and punted on the rel_2_12 rebase of our customizations branch, ran a git diff and have identified the files that he needs to add / change, will go back and pick those onto a clean rel_2_12, and hopefully have a clean rebase onto rel_3_1 |
| 10:54 |
dbs |
or at least I won't have to deal with ~700 commits with the same conflicts on the same files over and over again :) |
| 10:57 |
Dyrcona |
dbs: Ever tried my quickpick script for git? |
| 10:57 |
csharp |
yeah - rebase can be super annoying |
| 10:58 |
csharp |
we're *just* custom enough that most TT2 templates require some sort of conflict resolution |
| 10:59 |
csharp |
and since I'm often not the author of the changes, I have to either guess or check with the author to understand why they added an extra set of parens, say |
| 10:59 |
Dyrcona |
Well, I always expect conflicts when rebasing something based on branch A onto branch B. |
| 11:00 |
Dyrcona |
It's better to base things on master, then split your rel_[whatever] branch when the rel branch is pushed. |
| 11:01 |
Dyrcona |
Well, "better" is subjective, but I find it easier that way. |
| 11:02 |
Dyrcona |
I've also taken to naming my branches something like feature/[remote base branch]. |
| 11:03 |
Dyrcona |
So: config/master and config/rel_3_0 exist locally. |
| 11:03 |
Dyrcona |
Then I can batch rebase periodically with a bash for loop :) |
| 11:06 |
dbs |
I don't think I need a "quickpick" script |
| 11:07 |
Dyrcona |
Suit yourself. Some find it useful. |
| 11:10 |
|
stephengwills joined #evergreen |
| 11:13 |
|
jaswinder joined #evergreen |
| 11:30 |
dbwells |
berick++ # RM hat tossing |
| 11:36 |
mmorgan |
berick++ |
| 11:36 |
Dyrcona |
berick++ |
| 11:38 |
* mmorgan |
wonders if the local ice cream stand has betas as well as slushes and freezes ;-) |
| 11:40 |
|
mmorgan1 joined #evergreen |
| 11:46 |
jeff |
jeffdavis++ for bug 1764542 |
| 11:46 |
pinesol_green |
Launchpad bug 1764542 in Evergreen "Incorrect format on config.metabib_field insert results in segmentation fault" [High,Confirmed] https://launchpad.net/bugs/1764542 - Assigned to Galen Charlton (gmc) |
| 11:49 |
csharp |
berick++ |
| 11:56 |
JBoyer |
berick++ |
| 12:03 |
|
jeff_ joined #evergreen |
| 12:45 |
dbs |
Down to 14 commits, not including tpac template variations. Much cleaner. |
| 12:46 |
Dyrcona |
dbs++ |
| 12:46 |
Dyrcona |
It's good to squash commit every now and then, but I suppose you made new ones? |
| 12:47 |
Dyrcona |
Is there a way to test EDI translator with the template_output from an event? |
| 12:48 |
Dyrcona |
I ask because we're getting this in email from EDI pusher: ERROR: attempt_translation failed for event 77147623, PO 22586, template_output 26832945 |
| 12:48 |
Dyrcona |
I have a suspicion what is wrong, but I'd like to confirm it. |
| 12:53 |
|
mmorgan joined #evergreen |
| 12:55 |
dbs |
Dyrcona: yeah, I did a git diff between our branch and rel_2_12 to find all the files that had been changed, then determined which changes we actually want |
| 12:56 |
dbs |
I think our cherry-pick workflow causes major churn as we backport between releases |
| 12:57 |
Dyrcona |
It does. |
| 12:59 |
Dyrcona |
And, after looking at the template output more closely, I have no idea what's wrong. :) |
| 13:06 |
Dyrcona |
I found test_edi_translator.pl, but it does add much insight. Just tells me what I already know. |
| 13:08 |
Dyrcona |
But, I did find the error message in the logs after... Looks like a stray carriage return. |
| 13:21 |
Dyrcona |
Except that search the document by octal codes turns up no carriage returns or stray line feeds. :( |
| 13:56 |
|
kmlussier joined #evergreen |
| 13:57 |
Dyrcona |
Ah ha! Stray tab characters.. #012 is misleading in that error message. |
| 14:00 |
stephengwills |
if I add a logger line into the code, say, CircCommon.pm, do I have to reboot the server to have it execute my change? |
| 14:01 |
pinesol_green |
[evergreen|Remington Steed] Docs: Update several chapters for web client - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cebafde> |
| 14:01 |
csharp |
stephengwills: you do need to restart opensrf (or at least the perl services) |
| 14:02 |
stephengwills |
nod. thanks, makes sense. |
| 14:02 |
remingtron |
I forgot to mention in the git commit, some of those screenshots are from Kevin Tran, our student worker. Thanks Kevin! |
| 14:04 |
Dyrcona |
stephengwills: I'd just restart open-ils.circ before restarting everything. |
| 14:04 |
stephengwills |
thanks |
| 14:05 |
Dyrcona |
If the minimum works, then why disrupt everything? |
| 14:14 |
Bmagic |
Can anyone confirm that deleting a copy tag from a copy doesn't work? Watching the network console on the browser, I find that clicking "remove" for the tag does nothing other than remove it from the GUI. It doesn't talk to the server. 3.0.2 |
| 14:17 |
jeff |
in rsyslog documentation for a configuration parameter related to escaping special characters, the default character used to escape characters seems to have been improperly escaped and therefore eaten somewhere along the line in the docs generation process. |
| 14:17 |
jeff |
this amuses me. |
| 14:28 |
Dyrcona |
:) |
| 15:00 |
JBoyer |
Bmagic, did you "Save and Exit" the item after that? Until then all it's supposed to do is remove it from the gui. |
| 15:01 |
JBoyer |
(Same with stat cats I believe) |
| 15:01 |
Bmagic |
yeah, I saved and exited |
| 15:01 |
Bmagic |
the tag remained |
| 15:02 |
Bmagic |
Now I am attempting to delete the row from asset.copy_tag_copy_map and I am encountering a new problem. ERROR: record "new" is not assigned yet |
| 15:02 |
JBoyer |
I wonder if it's missing some of the processing done to stat cats then. (Haven't had time to investigate it, just trying to help with spitballing) |
| 15:02 |
JBoyer |
Oh! |
| 15:02 |
Bmagic |
DETAIL: The tuple structure of a not-yet-assigned record is indeterminate. |
| 15:02 |
JBoyer |
That's a trigger error. That I thought I had addressed. Maybe I changed some things or misremembered that one being changed? |
| 15:03 |
Bmagic |
fixed in 3.0.2 ? |
| 15:03 |
JBoyer |
Ooh, maybe. It was a long time back and I was losing my mind keeping up with fixes when we moved to 3.0. |
| 15:04 |
Bmagic |
got LP number? |
| 15:04 |
JBoyer |
Not handy but I can look since it should show up under my account's Bugs page. |
| 15:05 |
Bmagic |
Thanks! |
| 15:06 |
JBoyer |
Ah, yes. it's bug 1724223 |
| 15:06 |
pinesol_green |
Launchpad bug 1724223 in Evergreen "Unable to delete copy notes / remove items from buckets, etc." [Medium,Fix released] https://launchpad.net/bugs/1724223 |
| 15:06 |
JBoyer |
Doesn't reference copy tags, but they are addressed in the changes. |
| 15:06 |
Bmagic |
that might explain why I couldn't find it when searching. |
| 15:06 |
Bmagic |
Jboyer++ |
| 15:07 |
Bmagic |
Hmmm. The date on the release looks like it was before 3.0.2 was cut |
| 15:07 |
JBoyer |
probably hit master before that, but it lists 3.0.2 as the milestone. |
| 15:08 |
Bmagic |
confirmed that I have the patch in my installation |
| 15:08 |
JBoyer |
Oh nuts. I suppose it's possible there's another trigger using NEW when TG_OP = DELETE. |
| 15:09 |
JBoyer |
Oh, but if you do a \d asset.copy_tag_copy_map, when are the two inherit_* triggers applied? Should only be after insert or update |
| 15:11 |
Bmagic |
inherit_asset_copy_tag_copy_map_copy_fkey AFTER INSERT OR UPDATE ON asset.copy_tag_copy_map DEFERRABLE INITIALLY IMMEDIATE FOR EACH ROW EXECUTE PROCEDURE asset_copy_tag_copy_map_copy_inh_fkey() |
| 15:11 |
Bmagic |
inherit_copy_tag_copy_map_copy_fkey AFTER INSERT OR DELETE OR UPDATE ON asset.copy_tag_copy_map DEFERRABLE INITIALLY IMMEDIATE FOR EACH ROW EXECUTE PROCEDURE asset_copy_tag_copy_map_copy_inh_fkey() |
| 15:12 |
JBoyer |
There you go. Get that DELETE out of there for the second. |
| 15:12 |
Bmagic |
I see |
| 15:12 |
Bmagic |
weird that it's there but whatever |
| 15:13 |
JBoyer |
What I think is weird is that I'm not sure it's not a dupe trigger. :/ Aside from the name it looks the same as first, though I have both also. |
| 15:13 |
JBoyer |
And my patch only changes one... |
| 15:14 |
JBoyer |
And they are identical, huh. Must have had a name change somewhere along the line. |
| 15:14 |
Bmagic |
Should I run the upgrade file? DROP TRIGGER IF EXISTS inherit_copy_bucket_item_target_copy_fkey ON container.copy_bucket_item; DROP TRIGGER IF EXISTS inherit_import_item_imported_as_fkey ON vandelay.import_item; DROP TRIGGER IF EXISTS inherit_asset_copy_note_copy_fkey ON asset.copy_note; |
| 15:15 |
JBoyer |
It's possible you have but it missed the 'inherit_copy_tag_copy_map_copy_fkey' trigger. |
| 15:15 |
Bmagic |
The name is not exactly the same |
| 15:15 |
Bmagic |
as you pointed out |
| 15:16 |
JBoyer |
I believe in this case it's safe enough to simply drop that trigger and stop |
| 15:16 |
Bmagic |
inherit_copy_tag_copy_map_copy_fkey versus inherit_asset_copy_tag_copy_map_copy_fkey |
| 15:16 |
JBoyer |
Yeah, and since both of them run the same function at the same time I'd just throw inherit_copy_tag_copy_map_copy_fkey away and forget about it. |
| 15:17 |
Bmagic |
I see, yep |
| 15:18 |
Bmagic |
worked like a charm |
| 15:18 |
Bmagic |
I bet that is a bug |
| 15:18 |
Bmagic |
somewhere in the upgrade change *.sql files, it's referred to by a different name |
| 15:19 |
* Dyrcona |
wouldn't be surprised. |
| 15:28 |
JBoyer |
in 1063 the initial inherit_* triggers are built dynamically via string concatenation, in 1081 they're all listed specifically, so it |
| 15:29 |
JBoyer |
s hard to say when the split showed up |
| 15:29 |
Bmagic |
ah, that explains why my grep command turned up bubkis |
| 15:40 |
|
kmlussier joined #evergreen |
| 15:49 |
kmlussier |
I was playing around with stop words on a test system. I was able to successfully configure postgres so that it doesn't index any words in my stopword dictionary. However, if a user enters the stopword, search doesn't ignore it. |
| 15:49 |
kmlussier |
Am I correct in assuming that development would be needed to get search to ignore any stop words entered as part of the query? |
| 15:50 |
kmlussier |
Also, I don't really want to implement stop words on a live system, so there's no need to tell me why I shouldn't use them. I'm just trying to see how it works. :) |
| 15:56 |
Dyrcona |
heh. |
| 15:58 |
dbs |
kmlussier: when you say "search doesn't ignore it", you mean something like the Perl code doesn't strip it out before it gets passed on to the SQL SELECT statement? |
| 15:59 |
kmlussier |
dbs: Yes, I guess so. |
| 15:59 |
berick |
maybe an addition to public.search_normalize() is needed |
| 15:59 |
* berick |
just guessing |
| 16:00 |
dbs |
Or do you want it to short-circuit before it even reaches the Perl code? We've configured Apache to ignore searches that are just "the" and "canada" and the like |
| 16:00 |
kmlussier |
Initially, I thought postgres might handle it somehow, since stop words are only useful if they are ignored both sides: when the record is indexed and when the search is entered. |
| 16:00 |
Dyrcona |
Does it matter if the stop word is sent in the query, though? |
| 16:00 |
dbs |
It shouldn't matter if the stop word is sent in the query, no |
| 16:01 |
Dyrcona |
dbs: What about "the the?" I need to search for '80s music! :P |
| 16:01 |
Dyrcona |
j/ |
| 16:01 |
Dyrcona |
j/k |
| 16:01 |
dbs |
Dyrcona: I know, that and "It" are my reasons for not wanting stopwords :) |
| 16:02 |
kmlussier |
Yes, like I said, I don't need convincing on the arguments against using stopwords. |
| 16:02 |
kmlussier |
"to be or not to be" is another one. |
| 16:02 |
Dyrcona |
Right. I'm just joking around. :) |
| 16:02 |
dbs |
The reason we ignored searches for "canada" was because of the broad search timeout issue |
| 16:02 |
Dyrcona |
Yeah, that makes sense. |
| 16:03 |
berick |
kmlussier: have you confirmed having the stop word in the search affects the search? |
| 16:03 |
kmlussier |
berick: Yes, this is my test search - http://mlnc1.noblenet.org/eg/opac/results?query=girl+on+a+train&qtype=keyword&fi%3Asearch_format=&locg=1&detail_record_view=0 |
| 16:04 |
kmlussier |
Right now, the only words being indexed in the metabib title table are 'girl train' |
| 16:04 |
Dyrcona |
Nifty! |
| 16:05 |
Dyrcona |
"girl train" finds it. |
| 16:05 |
dbs |
huh. that's unexpected. |
| 16:05 |
Dyrcona |
"girl on a train" or "girl on the train" do not. |
| 16:05 |
kmlussier |
Dyrcona: Yes, so in that sense, I've actually made search worse by adding the stopword dictionaries. |
| 16:05 |
* dbs |
hasn't looked at the search code for a while but wonders if it's the relevancy test for phrase similarity |
| 16:06 |
Dyrcona |
Well, there's reason #1 not to use stop words. :P |
| 16:06 |
Dyrcona |
Don't mind me. :) |
| 16:06 |
dbs |
Yeah, there's something else going on there |
| 16:06 |
Dyrcona |
I tried with title, too, and the same thing happens. |
| 16:07 |
* mmorgan |
wonders why it's unexpected that the search would fail if the stop words weren't stripped out of the search terms. |
| 16:07 |
|
foobarrel joined #evergreen |
| 16:08 |
dbs |
Normally PostgreSQL will see the search terms in the incoming query and just ignore any of the stop words |
| 16:10 |
|
jaswinder joined #evergreen |
| 16:10 |
kmlussier |
OK, that was my expectation, so it's good to hear my expectation wasn't wrong. In that case, I guess I answered dbs' first question incorrectly about stripping stop words at the perl layer. |
| 16:10 |
kmlussier |
I wonder if there is something else I should be doing in the postgres config then. |
| 16:11 |
dbs |
Yeah, I just fired up my minimalist postgresql full-text search app and added "girl on a train" to the examples (https://github.com/dbs/postgresql-full-text-search-engine) |
| 16:13 |
dbs |
The default stopwords for "on", "a", etc are in place, and searching for "girl on a train" returns the expected one result. |
| 16:13 |
kmlussier |
huh |
| 16:21 |
dbs |
Is it possible the full-text search config you used to add the stopwords for indexing doesn't match the full-text search config used for the queries? |
| 16:21 |
dbs |
That's about all I can come up with. |
| 16:23 |
pastebot |
"dbs" at 64.57.241.14 pasted "Differences in stopwords in the query based on default configs" (11 lines) at http://paste.evergreen-ils.org/2554 |
| 16:23 |
kmlussier |
dbs: Yes, I think that's what it was. I was just heading down that path when you asked the question. Works for me now. :) |
| 16:24 |
dbs |
yayz |
| 16:25 |
kmlussier |
Either that, or restarting everything made it work for me. In either case, yay! |
| 16:25 |
kmlussier |
dbs++ Dyrcona++ berick++ |
| 16:28 |
kmlussier |
Exploring further, I think it was my failures to restart something that caused the initial problem. Once I restarted postgres, memcached, opensrf services and apache, it worked as expected. |
| 16:29 |
* kmlussier |
now needs to decide if she wants to show people how to do this in her search talk with lots of warnings on why it might be a bad idea or if she should just skip it. |
| 16:32 |
|
jaswinder joined #evergreen |
| 16:33 |
stephengwills |
i have to build a 2.8 server should I drop back to trusty or can I do it on a xenial slice? |
| 16:33 |
stephengwills |
I don’t see xenial in the Makefile |
| 16:35 |
|
jaswinder joined #evergreen |
| 16:40 |
bshum |
stephengwills: I don't think installation pre-reqs packages have changed a ton actually |
| 16:40 |
bshum |
So it's theoretically possible to install a 2.8 on Xenial |
| 16:41 |
bshum |
Though stuff like the PG version you'd have to tweak by hand, etc. |
| 16:41 |
bshum |
It's certainly simpler to use supported distros for older versions |
| 16:41 |
stephengwills |
apache2-mpm-prefork is now part of the apache package so opensrf install barfs out of the gate it turns out. :) |
| 16:42 |
bshum |
Well sure, there'll be some stuff like that, or distro specific steps you have to follow |
| 16:42 |
stephengwills |
this is what I get for taking a multi-year break from evergreen LOL! |
| 16:44 |
bshum |
My brain is only tracking master (kind of), so I don't even quite remember what all happens in previous versions of Evergreen's Makefiles anymore :D |
| 16:45 |
bshum |
Plenty of stuff has changed I guess |
| 16:45 |
bshum |
Especially with the web client building process |
| 16:46 |
bshum |
It might be "easier" to just use Trusty :) |
| 16:46 |
bshum |
Though hey, always a good opportunity to upgrade to new stuff too |
| 16:46 |
stephengwills |
I finally have enough time to get into this, y’all just gonna have to put up with a bunch of n00b questions. |
| 16:47 |
stephengwills |
I built a 3.0 server but they are still on 2.8 and I have a bug to fix, so, gotta build me one |
| 16:47 |
stephengwills |
we arn’t hot fixing production today ;-) |
| 16:47 |
bshum |
Well I think the quippy answer is "upgrade to a community supported version of Evergreen" and you'll be fine :) |
| 16:48 |
berick |
and beware master installer won't install some stuff 2.8 needs, spidermonkey stuff being one IIRC |
| 16:55 |
jeff |
This bug is... neat. Install of Debian 9 on a VM fails to auto partition if the VM has 16 GB of RAM, works without issue if the VM has 2 GB of RAM. Haven't toyed to see where the actual break is. |
| 16:56 |
bshum |
jeff: curious, which virtualization platform are you using with that? |
| 16:59 |
jeff |
VMware |
| 17:08 |
|
mmorgan left #evergreen |
| 17:22 |
jeff |
Ah. Found it. Doesn't seem to be VMware specific. |
| 17:23 |
jeff |
It fails because the disk is too small to contain the unreasonably large swap partition it has decided to create. |
| 17:58 |
* jeffdavis |
learns the hard way that forcing a reingest on an unmodified existing record does not modify vis_attr_vector |
| 18:05 |
|
jvwoolf joined #evergreen |
| 18:32 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:35 |
stephengwills |
for future surfers: I dropped back to ubuntu 14.04 (Trusty) and the opensrf-2.4.2 installed perfectly. |
| 20:21 |
|
stephengwills left #evergreen |
| 20:33 |
|
jaswinder joined #evergreen |
| 22:48 |
|
jaswinder joined #evergreen |
| 23:04 |
|
jaswinder joined #evergreen |
