Evergreen ILS Website

IRC log for #evergreen, 2013-06-11

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

Time Nick Message
00:31 misilot joined #evergreen
00:56 Mark__T joined #evergreen
01:01 ktomita joined #evergreen
01:19 stevenyvr2 joined #evergreen
01:19 stevenyvr2 left #evergreen
01:59 Bamba705 joined #evergreen
01:59 Bamba705 left #evergreen
02:25 ktomita_ joined #evergreen
02:53 VGFAA228 joined #evergreen
02:53 VGFAA228 left #evergreen
03:04 VGFAA582 joined #evergreen
03:04 VGFAA582 left #evergreen
03:19 jdouma_ joined #evergreen
03:23 VGFAA677 joined #evergreen
03:23 VGFAA677 left #evergreen
03:35 VGFAA637 joined #evergreen
03:35 VGFAA637 left #evergreen
05:29 b_bonner- joined #evergreen
05:30 b_bonner- joined #evergreen
05:43 VGFAA778 joined #evergreen
05:43 VGFAA778 Want to take someone offline Friends, Game Servers, Website? Join iBooter ! ibooter.me
05:43 VGFAA778 left #evergreen
06:04 b_bonner joined #evergreen
06:04 b_bonner_ joined #evergreen
06:23 timhome joined #evergreen
07:44 BigRig_ joined #evergreen
08:21 Hagerstown_Staff joined #evergreen
08:28 kbeswick joined #evergreen
08:29 mrpeters joined #evergreen
08:29 BigRig joined #evergreen
08:42 ericar joined #evergreen
08:44 akilsdonk_ joined #evergreen
08:46 tspindler joined #evergreen
08:52 kmlussier joined #evergreen
09:15 bkuhn joined #evergreen
09:25 senator pinesol_green: ping
09:25 pinesol_green pong
09:27 jcamins Does anyone know of any EG sites that use MARC-AMC?
09:27 jcamins Or whatever we're calling it these days.
09:28 jcamins Bonus points if you can think of a site that uses both collection-level and item-level records instead of just collection-level.
09:29 jcamins Double bonus points if the library uses TPAC.
09:33 csharp I don't know of any libraries that do much in the way of archives using EG
09:34 csharp yboston (Yamil Suarez) works for a music library, so that may be close (but I don't know that ;-) )
09:35 jcamins I will poke their catalog a bit and see if I can figure it out.
09:35 jcamins Assuming I can find their library on the website.
09:35 jeff aren't all the cool kids using ArchivesSpace now? :-)
09:35 jcamins jeff: probably.
09:36 jcamins Woohoo! It's TPAC!
09:36 csharp yay
09:36 jcamins Does anyone know how to search by LDR/06 in Evergreen?
09:39 collum joined #evergreen
09:40 dbs jcamins: On our catalogue, I think that would be advanced search -> Item Type search filter (but you still need at least a keyword)
09:40 dbs http://laurentian.concat.c​a/eg/opac/advanced?loc=105 for example
09:40 jcamins dbs: so if my desired item type isn't listed, it probably isn't in the catalog?
09:40 jcamins Thanks.
09:41 dbs jcamins: well, all LoC item types valid for LDR//06 are represented in the filter, but yeah. that, or the search timed out.
09:42 Dyrcona joined #evergreen
09:43 dbs jcamins: as a truly advanced user, you could directly add "item_type(j)" to your query to limit to musical recordings (as that's what the advanced UI effectively does)
09:43 jcamins dbs: yeah, once you clued me in to the limit, I started trying that.
09:43 jcamins And it worked! :D
09:46 dbs glorious
09:46 * paxed tries to create his own search filters, once again...
09:47 jcamins dbs: I presume you won't mind if I provide a link to your OPAC as an example of how Evergreen handles archival records just fine?
09:47 dbs jcamins: not at all
09:47 dbs we might be upgrading over the weekend, but otherwise we're pretty stable :)
09:49 jcamins And, final question: there are no technical impediments to using OCLC/Worldcat with Evergreen, are there? I should probably ask before I blithely assure catalogers that "Evergreen will work with OCLC out-of-the-box as well."
09:50 dbs Depends on what you mean by "work with OCLC" - I've exported records for inclusion in WorldCat, but we don't catalogue via OCLC. I know other sites do, though.
09:51 * dbs out for a bit
09:51 jcamins That answers my question. Thanks.
09:51 csharp jcamins: our catalogers work in OCLC connexion then import the records from OCLC into EG via z39.50
09:52 bshum jcamins: There's also some tool that can stream marc imports from connexion into Evergreen directly.  (though we don't use it, because our catalogers like importing the old fashioned way)
09:52 csharp jcamins: we're working on getting marc_export working to send batch holdings updates to them too
09:52 bshum tool/script
09:52 Dyrcona csharp jcamins Our catalogers currently do the same, but we're working on alternatives.
09:53 Dyrcona bshum: do you think bug 965656 should be targeted at  2.3 and 2.4 as well as master/2.5?
09:53 pinesol_green Launchpad bug 965656 in Evergreen "Close transactions after fines are voided, " (affected: 7, heat: 38) [Medium,Confirmed] https://launchpad.net/bugs/965656
09:54 bshum Dyrcona: Probably.
09:54 bshum Dyrcona: There's alot of old bugs that need refreshing of series targets.
09:55 Dyrcona bshum: Yep. I'm also working on that one this morning, at least one aspect of it.
10:10 Dyrcona paxed++ #busy making i18n branches
10:11 paxed only if i did those right :P
10:14 paxed also, those seemed like something i could do, and doing those will get it fixed faster...
10:33 * Dyrcona disappears into OpenILS::Application::Circ::*
10:34 * csharp calls the OpenILS::Application::Circ::Dyrcona subroutine
10:36 bshum dbwells: I've been thinking we've got less bug churn now that we're not actively moving milestones for bugs that don't have actual code being reviewed yet.  The 2.5-m1 milestone still does have targeted bugs with no code, but it's the only milestone that does.
10:36 bshum dbwells: So bug churn has been significantly reduced already.
10:36 bshum But we can think more on that if you'd like.
10:39 bshum I guess what I would have done would be to move all m1 bugs with unfinished pullrequests to m2.  And then untarget m1 bugs with no retargeting to m2 if they don't have active working code on them yet.
10:41 zerick joined #evergreen
10:43 dboyle joined #evergreen
10:50 bshum senator: re bug 1172373, we're playing vacation tag on this one (Mary is out this week) so I might not get everything sorted till later.
10:50 pinesol_green Launchpad bug 1172373 in Evergreen 2.4 "Acq: In EDI invoices, avoid taking reference to PO too seriously" (affected: 2, heat: 12) [Medium,Triaged] https://launchpad.net/bugs/1172373
10:51 senator bshum: understood. no pressure as far as i'm concerned. thanks.
10:51 bshum senator: That said, I think the issue is as you've described, B&T slipped in order data from sources outside of Evergreen
10:52 bshum Turns out something like the selection list name in Evergreen was being used by the library to create a purchase order in B&T's side of things.
10:52 dbwells bshum: Part of what I have asked people to do is to deliberately target bugs at future milestones as a planning mechanism.  That suggestion implies targetting things without code.  Should I rethink that?
10:52 bshum And some of that data made its way into the EDI data
10:53 gmcharlt dbwells: well, targetting a bug to a milestone doesn't in and of itself mean that anybody will take it up
10:54 bshum dbwells: I think if people make the move to target their bug to a particular milestone (and not us - the wranglers) then that's good faith commitment from them to try working on the bug.  And if it doesn't end up with code on it and we end up shifting it along, that's fine.
10:55 dbwells gmcharlt: I don't mean assignment, I mean as an (loose) promise of the person doing the targetting.
10:55 bshum But there are plenty of bugs that got assigned to m1 that were just shifted from 2.4 alpha as part of my moving things a couple months back before I came to the understanding of using more proactive series targeting.
10:55 dbwells i.e. I am working on such-and-such, and expect it to land here.
10:56 dbwells Maybe it is enough to say that bugs get targeted when there is either code or a strong intention of code :)
10:56 bshum dbwells: In the case of "I am working on such and such, it might be helpful to use the bug assignments to indicate ownership of the bug then.  In addition to milestone targeting.
10:57 gmcharlt dbwells: OK, that's along the lines of what I was thinking (i.e., somebody who is working on or expecting to work on it doing the initial targeting)
10:57 bshum That way we know there are people supposedly paying attention to them.
10:57 bshum For those of us wrangling
10:58 phasefx and if a bug needs advocacy, not having a milestone gives some impetus
10:58 pinesol_green [evergreen|Angela Kilsdonk] Edits to documentation - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=3087ab4>
11:01 bshum Okay, for an example of the kind of bug I'm reluctant to assign back to a milestone without more action...
11:01 bshum https://bugs.launchpad.net/evergreen/+bug/1084732
11:01 pinesol_green Launchpad bug 1084732 in Evergreen "tpac: copy location filter missing from tpac" (affected: 4, heat: 24) [Wishlist,Confirmed]
11:01 bshum Has been kicking around since reported and shifted from milestone to milestone without any takers
11:02 bshum That's the sort of bug I'd like to see removed from active milestones unless someone takes active interest in it.
11:02 bshum If only because we always shuffle them along because yes they're important, but no, nobody writes new code to address it.
11:03 dbwells Okay, thanks for the clarifications, everyone.  So a bug is only targeted if a) it has a valid pullrequest or b) it is assigned to (i.e. claimed by) someone, and that someone has set the target themselves to communicate expectations.
11:06 jdouma joined #evergreen
11:06 dbwells I'll go ahead and make the current m1 targetted bugs conform to this, and that will greatly reduce the mindless zombie bugs which wander from target to target indefintely.
11:08 bshum dbwells: That sounds like a good summary of the new approach we're trying with the bugs.  Thanks!
11:08 bshum dbwells++
11:12 pastebot "Dyrcona" at 204.193.129.146 pasted "finish fines and voiding" (23 lines) at http://paste.evergreen-ils.org/17
11:13 Dyrcona berick: Can you tell me the reason for line 2782 in OpenILS::Application::Circ::Circulate.pm? It has your name on it. It also runs counter to what is desired in lp 965656.
11:13 pinesol_green Launchpad bug 965656 in Evergreen "Close transactions after fines are voided, " (affected: 7, heat: 38) [Medium,Confirmed] https://launchpad.net/bugs/965656
11:14 Dyrcona I've pasted the whole function in the paste above. The line in question is the call to reopen the xact.
11:16 Dyrcona I just want to know before I go changing things.
11:16 ktomita joined #evergreen
11:19 acoomes joined #evergreen
11:22 berick Dyrcona: can check in a bit
11:22 bshum @hate apostrophes in search
11:22 pinesol_green bshum: The operation succeeded.  bshum hates apostrophes in search.
11:22 tsbere @hate search
11:22 pinesol_green tsbere: The operation succeeded.  tsbere hates search.
11:22 tsbere My hate is more general ;)
11:23 bshum tsbere++
11:36 DPearl joined #evergreen
11:45 DPearl Help! I'm installing opensrf on a new machine and it is not starting up.  The srfsh test failed with "unable to bootstrap client".  It looks like the router is failing.
11:46 DPearl I have checked and rechecked the ejabber users, and they look fine.
11:47 DPearl The .srfsh.xml is fine.
11:47 phasefx if you grep your osrfsys.log for ERR, what's the first hit there?
11:49 DPearl opensrf 2013-06-11 11:03:25 [ERR :13433:osrf_system.c:228:] Unable to bootstrap for host localhost from configuration file /openils/conf/opensrf_core.xml
11:51 tsbere I would check that the xml file in question exists and is valid XML
11:51 * Dyrcona was about to suggest the same.
11:52 Dyrcona Also that the user that runs opensrf can read it.
11:52 phasefx and if you used -l with osrf_ctrl.sh, then your opensrf.xml should also have a <localhost> entry under <hosts>
11:52 DPearl Lots to check.  Standby..
11:56 berick Dyrcona: the comment for Circulate.pm:2782 is misleading.  it should be more like, "make sure the circ isn't closed if voiding these fines caused the transaction to go from balance_owed == 0 to balance_owed != 0"
11:56 * berick notes that CircCommon->reopen_xact will only reopen a transaction if it's supposed to be open
11:57 Dyrcona berick: The reality is backdated checkins that void fines are never closed.
11:57 Dyrcona berick: So I could add a line or two to say if the xact is open and balance == 0 and then close the xact?
11:59 berick Dyrcona: that sounds sane to me.
11:59 berick i.e. forcing the xact into the correct state, regardless of the state it's in
11:59 Dyrcona ok will do.
12:00 berick i've long thought we should push the xact_close-setting logic into a DB trigger
12:00 berick i bugs me how spread through the code that stuff is
12:00 Dyrcona me, too.
12:00 berick s/i/it/
12:00 ldwhalen joined #evergreen
12:00 Dyrcona I told bshum in private earlier that I have to fight the urge to refactor Circulate.pm
12:01 berick indeed, it has grown into a very awkward teenager
12:01 ktomita_ joined #evergreen
12:01 jdouma joined #evergreen
12:02 Dyrcona So, I'll add a couple of lines to check for 0 balance and close the xact if it is open below the reopen xact call.
12:02 bkuhnIdl` joined #evergreen
12:02 Dyrcona We can figure out an overall reorganization of the circ code later. :)
12:02 paxed eeevil: re the search filters... i just can't it to work.
12:02 DPearl tsbere: xml files are still valid xml
12:03 DPearl phasefx: localhost present
12:03 berick Dyrcona: fwiw, Money.pm:_check_open_xact() will do both, open or close as necessary.  could move that into AppUtils or some such and replace reopen_xact w/ that.  just a thought
12:04 berick and w/ that, i'll leave it in yr capable hands
12:04 Dyrcona berick: Ok.
12:04 tsbere DPearl: Who owns the xml file and what is the mode string on it? You haven't mentioned if it can be read by the right user yet ;)
12:05 DPearl I went to the user and cat-ted the file.
12:06 csharp_ joined #evergreen
12:06 Dyrcona berick: I'll move _check_open_xact to AppUtils and make the appropriate changes.
12:06 berick Dyrcona++
12:07 DPearl tsbere: opensrf/opensrf owns the .xml files and rights are 644
12:09 DPearl tsbere: ejabberd complains only of auth. of "router" user.  The opensrf user is ok.   I(<0.585.0>:ejabberd_c2s:508) : ({socket_state,gen_tcp,#Port<0.1871>,<0.584.0>}) Failed le gacy authentication for router@private.localhost/router
12:11 tsbere DPearl: Check passwords! ;)
12:12 DPearl tsbere: I'll try it again ;-{
12:12 phasefx DPearl: stay away from special characters in the passwords
12:13 DPearl phasefx:  My passwords were just ascii letters, alas.
12:13 bshum You could try purging ejabberd (and its config) and then starting over with just that piece of it.
12:14 edoceo joined #evergreen
12:14 * bshum tended to do that whenever he mucked up hostnames or passwords
12:14 DPearl bshum: Not quite sure how to do that.  I have restarted ejabberd regularly, but it didn't help
12:16 bshum DPearl: This is a bad shotgun approach, but it's something like "apt-get purge ejabberd" and then "apt-get install ejabberd" and then re-run through config changes and re-registering user/pass.
12:17 bshum (there may be better ways, but if you're starting over anyways...)
12:17 DPearl bshum: Wow! You don't mess around!  I'll try it.
12:19 gmcharlt DPearl: on Debianish, stopping ejabberd, clearing out the contents of /var/lib/ejabberd, then starting and reregistering has the same effect
12:20 gmcharlt and saves you a step of redoing your ejabberd.cfg changes
12:21 DPearl gmcharlt: Thanks
12:25 mcooper joined #evergreen
12:28 pastebot "DPearl" at 204.193.129.146 pasted "router.log output" (17 lines) at http://paste.evergreen-ils.org/18
12:29 DPearl Still no joy..
12:30 ktomita joined #evergreen
12:31 jihpringle joined #evergreen
12:35 pastebot "DPearl" at 204.193.129.146 pasted "opensrf.log" (51 lines) at http://paste.evergreen-ils.org/19
12:36 bkuhn joined #evergreen
12:42 DPearl phasefx: For fun, I changed passwords...again.  Same authentication errors.
12:47 pastebot "DPearl" at 204.193.129.146 pasted "ejabberd log" (189 lines) at http://paste.evergreen-ils.org/20
12:47 mmorgan1 joined #evergreen
12:54 mmorgan1 left #evergreen
12:55 mmorgan joined #evergreen
12:58 acoomes_ joined #evergreen
13:04 kmlussier joined #evergreen
13:11 yboston joined #evergreen
13:15 csharp joined #evergreen
13:16 csharp bshum: re: apostrophes in search, what are you seeing happen?
13:17 bshum csharp: Today's new fun was somebody complaining about using "matches exactly" against a title search
13:17 csharp ah - I think we've heard that too
13:17 bshum The terms they used included an apostrophe, so we're wondering if that affected it.
13:17 bshum But matches exactly is wacky weird anyways
13:17 csharp right
13:18 csharp DPearl: this is your key line: "opensrf 2013-06-11 12:28:56 [ERR :2118:osrf_system.c:228:] Unable to bootstrap for host localhost from configuration file /openils/conf/opensrf_core.xml"
13:18 bshum csharp: The one that's more troublesome is unresolved bug 1187433
13:18 pinesol_green Launchpad bug 1187433 in Evergreen "apostrophe search issues in 2.4" (affected: 1, heat: 6) [Medium,Confirmed] https://launchpad.net/bugs/1187433
13:19 csharp bshum: so that's with the new QP in place, yes?
13:19 bshum But that's a 2.4 issue where using the term without the apostrophe (or space) breaks
13:19 bshum Correct, new QP introduced in 2.4
13:19 * csharp sees dbs's comment that shows that 2.3 doesn't have the problem
13:20 bshum Right.
13:22 bshum csharp: Are you seeing oddness with apostrophe searching too?
13:25 DPearl csharp: So what problem do you suspect?
13:29 stevenyvr2 joined #evergreen
13:41 mjingle joined #evergreen
13:46 csharp DPearl: can you cleanse /openils/conf/opensrf_core.xml and /etc/ejabberd/ejabberd.cfg of passwords/other sensitive info and pastebin them?
13:48 tspindler left #evergreen
13:50 DPearl csharp: will do
13:52 pastebot "DPearl" at 204.193.129.146 pasted "ejabberd cfg" (644 lines) at http://paste.evergreen-ils.org/21
13:53 csharp that looks okay to me
13:54 pastebot "DPearl" at 204.193.129.146 pasted "opensrf core" (161 lines) at http://paste.evergreen-ils.org/22
13:55 csharp DPearl: can you also pastebin /openils/conf/opensrf.xml?
13:55 DPearl csharp: The only changes I made to the core file is log level and usernames/passwords
13:55 csharp k
13:59 bshum kmlussier++ # screencast for bug 1187993
13:59 pinesol_green Launchpad bug 1187993 in Evergreen "Auto suggest causes significant accessibility issues for using basic search in some browsers" (affected: 1, heat: 8) [Undecided,New] https://launchpad.net/bugs/1187993
14:00 kmlussier bshum: I thought it would be easier to follow than the novel I wrote in my initial report. :)
14:00 * bshum wishes for more soothing voices.
14:00 csharp kmlussier++
14:00 ericar joined #evergreen
14:02 paxed perhaps the autosuggest could be set to "always on", "disabled", "let patron choose, default to off", "let patron choose, default to on" in YAOUS
14:02 * bshum dislikes that
14:03 bshum For many reasons.
14:03 ktomita joined #evergreen
14:04 kmlussier I like the idea of letting the patron choose because some users love autosuggest and some hate it.
14:05 kmlussier But, if you were promoting the autosuggest feature, you would probably want the default to be "on" (otherwise, how would a patron know to turn it on?), so you still would come across the accessibility issue.
14:06 dbs we should probably default to "off" for anything known to introduce an accessibility issue as serious as that
14:08 paxed detection via User Agent?
14:08 paxed or whatever?
14:09 dbs We should just turn it off until we have a properly working version available.
14:09 bshum dbs: +1
14:10 bshum paxed: I'm not fully up to speed with the details, but I think the screen reader just works alongside the browser, so there's no clear indication whether they're using one or not vs. just using a browser.
14:10 paxed bshum: ah... right.
14:10 kmlussier Yup. I was using standard browsers in my own testing.
14:12 senator if dijit removes the aria-label attribute, can the problem be solved by adding it back to some <span> element surrounding the input widget?  or is there more to it than that?
14:13 * dbs looks at Driver/Pg/QueryParser.pm and wonders if line 311/312 is where the pain in apostrophe searching arrives
14:13 * bshum peruses
14:13 dbs this code could use some comments, and maybe some more expressive var names. $c looks pretty important, just have to figure out what it is
14:14 dbs a boolean for "is combined" I guess
14:15 akilsdonk_ kmlussier: it looks like all the new documentation has been processed into 2.4 now.
14:17 kmlussier senator: I don't know much about the code, but I wouldn't be surprised if the problem goes beyond the arial-label attribute.  2.2 catalogs didn't use the arial-label attribute, and, if autosuggest wasn't enabled, you could still identify the correct form elements by tabbing or using the JAWS commands. But that was just my uneducated gut feeling when I was testing.
14:18 kmlussier akilsdonk_++ Thanks! Of course, now that it's displaying, I now see I neglected to make some changes to the root file.
14:20 akilsdonk_ kmlussier: Yeah, I had to make a few changes too. :)  Thank you!
14:20 akilsdonk_ kmlussier++ dbs++ rsoulliere++  We have docs!
14:20 kmlussier http://www.nomensa.com/blog/2011/h​ow-do-you-detect-a-screen-reader/ tells us we can't detect screen readers.
14:20 dbs akilsdonk++
14:28 ldwhalen joined #evergreen
14:31 ldw joined #evergreen
14:32 paxed apart from eeevil, does anyone else know about making your own search filters?
14:35 eeevil paxed: my ears just started burning ... AND! I have a few minutes to look at your server, if you still want
14:36 paxed eeevil: go ahead. i recreated the filter stuff and reingested the bibs, and no worky.
14:37 dbs Oh, hello. I just noticed that the queries for 2.4 search use the 'simple' text configuration. Which means no stemming algorithm gets applied. Which means "mens" stays as "mens", not "men". Which may be pertinent.
14:37 * eeevil ssh's
14:38 bshum dbs: Sounds important.
14:38 eeevil dbs: that's only in weigh-slot A. slot C should be using the english snowball stemmer, without a stopword list
14:39 eeevil dbs: if you're /not/ seeing weight C lexems, there's an issue (and the search terms should get the same treatment, sans actual weighting, of course, because tsquery's don't have weights)
14:40 dbs eeevil: there is a very significant issue
14:40 eeevil tsbere: let's loop you into what dbs is seeing
14:42 * tsbere is hereish but wasn't paying a lot of attention to IRC
14:43 eeevil dbs: mind pasting some contents from, say, metabib.title_field_entry?
14:44 kmlussier1 joined #evergreen
14:45 dbs eeevil: man, I've posted this to the bug already
14:45 dbs like a week ago
14:46 eeevil do you have the bug # handy?
14:46 dbs And I've just confirmed that to_tsquery('simple', blah(blah('mens')) returns "mens" which will _not_ match fe.index_vector, whereas to_tsquery('english_nostop',  blah(blah('mens')) returns "men" which does match fe.index_vector
14:46 dbs which of course does contain both stemmed and non-stemmed versions of "men's" in different weights
14:47 dbs bug 1187433
14:47 pinesol_green Launchpad bug 1187433 in Evergreen "apostrophe search issues in 2.4" (affected: 1, heat: 6) [Medium,Confirmed] https://launchpad.net/bugs/1187433
14:47 dbs I'll add a sample of the full query that gets generated by QP
14:54 dbs On the bright side, this suggests that 2.4 sites don't need to reindex again. We just need to figure out where in the twisty maze of QP 'simple' should be replaced by 'english_nostop' or the like appropriately.
14:54 dbs Oh, I think I see it. We set the class_ts_config to 'english_nostop' to begin with, then promptly stomp on it with 'simple'
14:54 eeevil it should be getting both simple /and/ stemmed ||'d together
14:55 eeevil IIRC
14:55 eeevil hrm... maybe not
14:55 * eeevil thinks more
14:55 dbs Check line 583 of Driver/Pg/QueryParser.pm
14:55 tsbere dbs: Isn't that the *test* setup, where we don't have a DB to pull things from?
14:56 dbs tsbere: I dunno, I'm just trying to unravel this!
14:58 dbs so "config_metabib_class_ts_map" should bring us DB-based config?
14:59 dbs I have simple -> A, english_nostop -> C in my test config.metabib_class_ts_map table. Doesn't seem to be resulting in any english_nostop in the actual queries.
14:59 tsbere we *do* assume "just simple" if we don't have any info, so if something is broken on the "fetch from DB" side of things that would be the only thing we got...
15:00 dbs Sounds like something might be broken (quite consistently) then.
15:00 dbs As this has been confirmed on all sites running 2.4
15:01 dbs 1427 lines of gnarly code, with about 1 comment every 50 lines :/
15:02 dbs Only Publisher/metabib.pm attempts to set config_metabib_class_ts_map it seems.
15:10 * eeevil suspects a typo in the initialization code (simply due to a gut feeling and another instance of that from before)
15:10 tsbere dbs: Sometimes no comments are better than out of date or otherwise incorrect comments.....
15:11 dbs tsbere: Getting punched in the face is better than getting stabbed, too!
15:12 dbs But I don't want either to happen to me :)
15:12 tsbere dbs: I would rather try and understand code with good, up to date comments. This is followed by no comments at all. Understanding code with out of date and incorrect comments is a headache inducer and usually results in me running a "remove all the comments" script and starting over ;)
15:15 jcamins dbs: I recommend against belonging to a cat in that case. In the past two days I have been both stabbed *and* punched in the face by my owner in protest over the way I was trying to type instead of paying attention to him.
15:18 dbs meanwhile, actually looking at the code, the comment leading into good old line 1249 gives us the clue: "    # Assume we want exact if none otherwise provided.
15:18 dbs # Because we can reasonably expect this to exist
15:18 dbs $ts_configs = ['simple'] unless (scalar @$ts_configs);
15:18 dbs swap 'simple' out with 'english_nostop' and "mens health" matches "men's health". Thank you, comment!
15:21 isl-JBoyer joined #evergreen
15:22 mrpeters welcome isl-JBoyer ;)
15:22 isl-JBoyer Hey
15:22 mrpeters for those who don't know....isl-Jboyer is a wicked talented Evergreener
15:23 isl-JBoyer In small doses, babysteps, etc.
15:23 eeevil dbs: right, but the problem is that ~1238 isn't finding english_nostop for the keyword class. (for those playing along at home)
15:23 dbs eeevil: yes, pretty much exactly what my comment in the bug just said
15:24 dbs For those playing along in the future.
15:24 eeevil dbs: sorry, looking here and the code instead of hitting refresh on the bug
15:24 eeevil ;)
15:24 eeevil thinking_of_the_future++
15:25 jeff_ isl-JBoyer++ welcome!
15:26 dbs eeevil: actually, note that all of my tests have been against the 'title' field
15:27 eeevil dbs: consider it noted
15:27 dbs hmm, and config.metabib_field_ts_map is devoid of rows on our test database
15:27 eeevil using_the_same_words_for_testing++
15:27 eeevil well... that's something
15:28 eeevil if, with those, it still fails ... it be code problems.
15:28 eeevil well, no
15:28 eeevil that's only used for fielded searches. title|proper: foo
15:28 tsbere dbs: You want config.metabib_class_ts_map, I think...
15:29 dbs tsbere: yeah, that's populated
15:29 dbs per 14:59 < dbs> I have simple -> A, english_nostop -> C in my test config.metabib_class_ts_map table. Doesn't seem to be resulting in any english_nostop in the actual queries
15:29 dbs and 15:02 < dbs> Only Publisher/metabib.pm attempts to set config_metabib_class_ts_map it seems.
15:31 ldwhalen joined #evergreen
15:39 eeevil found it...
15:39 dbs yay
15:39 eeevil we're not loading the class->ts mapping
15:39 eeevil the calling code in open-ils.search calls the fts wrapper
15:40 eeevil the wrapper has an initialize block instead of using _initialize($parser)
15:40 eeevil once /any/ initialization has occurred, we never reinitialize the parser singleton (well, effective singleton)
15:41 eeevil and the wrapper's block does not do the class and field to ts config mapping
15:42 eeevil dbs: I'll toss a patch on the bug for you to test, if you want
15:44 * bshum has been watching quietly and can help test too.
15:44 bshum If I don't get carried away by flood waters that is.
15:44 bshum Crazy rain.
15:46 eeevil bshum: it's attached now
15:52 * tsbere is not surprised he missed that when figuring out the parser initializations
15:56 dbs eeevil++
15:59 bshum eeevil++
16:08 dbs Looks like it works in my limited tests
16:10 bshum Likewise
16:11 bshum Or at least, we get results where we didn't before.
16:14 * dbs added more details to the bug
16:25 * eeevil adds some more...
16:42 eeevil I'll toss up a branch with that patch embedded
16:52 eeevil pullrequested branch with targets for 2.4+
17:04 evergreen joined #evergreen
17:05 cr-ver joined #evergreen
17:09 mmorgan left #evergreen
17:13 mrpeters left #evergreen
17:29 jeffdavis anyone have experience using automatic updates to update staff clients remotely during a major version upgrade to 2.4?
18:00 dbwells joined #evergreen
18:37 acoomes joined #evergreen
18:58 ldwhalen joined #evergreen
19:21 mjingle left #evergreen
19:27 bshum jeffdavis: We have used auto update for all upgrades since we first got onto a version that made use of them.
19:28 bshum jeffdavis: As far as I'm aware, most everything "just works". Though there's always the few stragglers who don't have admin rights to perform the update (schools with locked down IT, etc.)
19:29 bshum One time I messed up the chain of upgrade, and it forced everybody to redownload the full client to reacquire the new chain of upgrades.
19:29 ldwhalen joined #evergreen
19:30 jeff meanwhile, we use wpkg for deploying our updates.
19:30 bshum Otherwise, it wasn't bad. And we did upgrade our folks from master to master builds, including the big code bits that went from 2.3 to 2.4. (well, and 2.2)
19:30 jeff mostly since we've been doing that since 1.2 days, and because we operate in an environment where user accounts are not local administrator accounts.
19:55 stevenyvr2 left #evergreen
20:58 ldwhalen joined #evergreen
21:48 ldwhalen joined #evergreen
22:37 ldwhalen joined #evergreen
22:44 ldwhalen_mobile joined #evergreen
23:11 jeffdavis hm, not sure what I'm doing wrong
23:12 jeffdavis any variant on 'make updates' results in this:
23:12 jeffdavis Making full update
23:12 jeffdavis external/make_updates.sh: line 182: /home/sitkastaff/evergreen/Open-I​LS/xul/staff_client/external/mar: No such file or directory
23:12 jeffdavis yet that file exists, is world-readable and world-executable

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat