Evergreen ILS Website

Search in #evergreen

Channels | #evergreen index




Results

Result pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138

Results for 2016-12-05

02:45 Stompro joined #evergreen
03:26 artunit_ joined #evergreen
03:30 artunit_ joined #evergreen
05:04 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
07:09 rjackson_isl joined #evergreen
07:12 JBoyer joined #evergreen
07:32 agoben joined #evergreen
12:06 jihpringle joined #evergreen
12:13 mmorgan joined #evergreen
12:26 jvwoolf joined #evergreen
13:00 csharp berick: FYI, I'm finally testing your new hold targeter on our test server - so far so good
13:00 csharp I like --verbose mode
13:02 brahmina joined #evergreen
13:02 kmlussier joined #evergreen
13:10 kmlussier @coffee
13:48 bshum There's just more of them now since I started adding more folders of files for translation in more recent releases.
13:48 bshum But for the catalog, they're all under the "tpac" PO file for all of it
13:49 mmorgan joined #evergreen
13:49 berick csharp: great.  should be a good test, then.
13:51 bshum Interesting...
13:51 JBoyer Still called opac, unless there are two. I'm pointing the es_es local at /openils/var/data/locale/opac/es-ES.po
13:51 bshum Well yes, it's relabeled from tpac to opac by the makefile job
16:21 Dyrcona More than that will likely work, but I wouldn't go over 100 or so. :)
16:30 kmlussier joined #evergreen
17:00 mmorgan1 left #evergreen
17:00 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
17:17 jvwoolf left #evergreen
17:45 csharp 85a470ef
17:45 pinesol_green csharp: [evergreen|Dan Pearl] LP#1501781 - Make patron name search diacritic/space insensitive. - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=85a470e>

Results for 2016-12-04

01:57 phasefx joined #evergreen
03:37 Stompro joined #evergreen
03:57 StomproJ joined #evergreen
05:01 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
06:12 Stompro joined #evergreen
17:00 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
17:46 Christineb joined #evergreen
20:51 StomproJ joined #evergreen
21:02 Stompro joined #evergreen

Results for 2016-12-03

05:02 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
05:52 StomproJ joined #evergreen
10:14 Dyrcona joined #evergreen
10:15 Dyrcona Probably no one around to pay much attention, but I want to share something.
10:49 Dyrcona It is significantly harder to do that with MARC::Batch.
11:22 Dyrcona Ah, well. Going out, so putting the laptop to sleep.
13:22 bmills1 joined #evergreen
17:01 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
22:41 drigney joined #evergreen
22:59 Stompro joined #evergreen
23:17 serflog joined #evergreen

Results for 2016-12-02

00:30 Stompro joined #evergreen
02:45 StomproJ joined #evergreen
02:56 Stompro joined #evergreen
05:00 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
06:40 rlefaive joined #evergreen
07:12 rjackson_isl joined #evergreen
07:32 agoben joined #evergreen
11:12 pinesol_green Dyrcona: DBI broke Evergreen.
11:14 * Dyrcona doesn't like unnecessary warnings.
11:15 Dyrcona Of course, $dbh->selectcol_arrayref documentation doesn't actually say that, selectall_arrayref does....
11:16 * Dyrcona changes method calls to test.
11:17 Dyrcona man DBI: You lie to me!
11:19 Dyrcona Hmm... What if I treat the function like a table?
11:22 * tsbere wonders what Dyrcona is fighting with now
15:16 dbs Uhh, I've given up on a lot of things, to be honest
15:16 csharp yeah, the fact that laurentian is working is why we have confidence that it *should* work :-)
15:16 bshum csharp: Are you using the same cache source for all your heads?
15:16 csharp we also have it working on a non-clustered test server
15:17 csharp bshum: the same 2 servers, yes
15:17 csharp hmm
15:17 csharp so 2 non-redundant memcache servers - could that be the issue?
15:17 bshum I'm thinking about OILSWebCompiledTemplateCache
15:17 bshum But uh, dunno
15:20 bshum if that wasn't shared I would expect it to be compiling and showing potentially different looking pages on different app heads.  But not necessarily a bad thing.   And probably shouldn't have anything to do with the cookie reading for locales... hmm
15:29 csharp berick: it's the whole page coming back in English when the html header shows it to be es-es
15:29 csharp not just specific elements
15:36 berick csharp: and the locale selector says the page is English?
15:39 bshum When I tested it on his server, it looked like the selector said Spanish, but the page was showing all english
15:39 bshum Well, his URL anyways
15:39 * bshum waits to try again when csharp adds back the second app server
15:40 * tsbere wonders if it is something like "the language is defined, but someone forgot to make sure that the actual strings were on all the servers"
15:41 bshum Worth double checking what tsbere said too :)
15:41 bshum Given what happened the first time 'round
16:43 berick Dyrcona: yep
16:43 berick well, profile dir or on the server
16:43 Dyrcona berick++ For answering late on a Friday.
17:00 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
17:06 mmorgan left #evergreen
17:10 jvwoolf left #evergreen
17:30 bmills joined #evergreen

Results for 2016-12-01

03:04 Stompro joined #evergreen
03:22 dcook__ joined #evergreen
04:59 StomproJ joined #evergreen
05:01 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
05:43 rhamby joined #evergreen
05:43 gmcharlt joined #evergreen
05:45 StomproJosh joined #evergreen
16:04 Bmagic oh boy, this is weird. Now in leu of that user being in the config, it chose another one..... I am very sure now that this is not users that are really logging in from SIP
16:06 Bmagic I wonder if this has something to do with the workstation not* being included in the auth
16:06 Dyrcona I'm not sure that I understand the situation at this point.
16:07 Bmagic I setup a server just to test this situation. I gave the IP address to this one library. This one library in theory is the only library that knows about this server
16:08 Bmagic and I was seeing authentications for another user... Odd, but whatever.... now with these extra clues. I decided to remove the unexpected user from the oils_sip.xml, then I started seeing a totally different user in the logs
16:09 jihpringle joined #evergreen
16:11 Dyrcona Does the IP address have an associated hostname? Have you ever used the IP address for SIP before?
16:58 Bmagic ah
16:59 Bmagic What keeps bothering me is, this was working without a problem before we upgraded to 2.11
17:00 jeff open-ils.auth login types are opac, staff, temp, or persist
17:01 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
17:01 jeff What were you on before?
17:02 jeff And what version and flavor of SIPServer were you running?
17:02 Dyrcona jeff: It has always been opac.
17:26 Bmagic dbs: no problem at all!
17:26 dbs (and we're only on 2.10 still, fwiw)
17:28 Bmagic so.... how did this break between 2.9 and 2.11?
17:36 Bmagic Dyrcona: We know that the session change fixed it because we tested the server through each of those changes and nothing fixed it until the session expire time was extended
17:37 Dyrcona Bmagic: If the auth.opac_timeout for the library was 10 minutes, that's too low.
17:37 Dyrcona It might be all right for people using the OPAC in the library, but for people signed in from home, it is way too short.
17:38 Bmagic Dyrcona: it was set to 10 minutes when we were on 2.9.1, didnt have this SIP issue

Results for 2016-11-30

01:25 Stompro joined #evergreen
03:47 StomproJ joined #evergreen
05:01 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
05:22 serflog joined #evergreen
05:22 Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged: http://irc.evergreen-ils.org/evergreen | Large pastes at http://paste.evergreen-ils.org
06:26 StomproJ joined #evergreen
15:03 mmorgan1 joined #evergreen
15:36 bmills joined #evergreen
16:49 mmorgan joined #evergreen
17:01 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
17:04 mmorgan left #evergreen
17:38 abowling left #evergreen
19:02 Stompro joined #evergreen

Results for 2016-11-29

02:12 StomproJ joined #evergreen
03:02 Stompro joined #evergreen
03:52 StomproJ joined #evergreen
05:00 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
05:06 Stompro joined #evergreen
05:31 StomproJ joined #evergreen
06:33 Stompro joined #evergreen
10:50 Stompro Dyrcona++ for the no-op checking floating fix.  That is a daily issue for us.
10:51 Dyrcona Stompro: You are most welcome. It's not daily here, but happens often enough to be an annoyance.
10:51 Dyrcona If you'd care to sign off on the fix, that would be much appreciated. :)
10:51 Stompro Dyrcona, I'll try and test as soon as I can.
10:52 Dyrcona Cool.
10:55 Dyrcona Now, I'm wondering if I need to join metabib.record_attr_vector_list twice if I want to look up bibs by item_type and item_form....
10:55 Dyrcona I'll try it with it joined once to see what happens.
16:34 Dyrcona Maybe I should have a look at Encode.pm.
16:45 bmills joined #evergreen
16:53 Dyrcona Nope. Not gonna be simple to recover from this. I'll have to rethink the logic of my program.
17:00 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
17:32 sandbergja joined #evergreen
17:51 jvwoolf joined #evergreen
17:55 jvwoolf left #evergreen

Results for 2016-11-28

00:38 StomproJ joined #evergreen
03:02 Stompro joined #evergreen
05:01 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
05:35 StomproJ joined #evergreen
07:18 JBoyer joined #evergreen
07:22 rjackson_isl joined #evergreen
14:31 bwicksall joined #evergreen
14:45 Bmagic when it comes to overdue items related to billing, we might need to include deleted items, which is the senario here
15:01 csharp for a report like that, I might *not* filter on deleted but possibly display it
17:00 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
17:04 mmorgan left #evergreen
19:50 jyorio joined #evergreen
20:22 hbrennan joined #evergreen

Results for 2016-11-27

02:59 Stompro joined #evergreen
05:00 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
13:22 bshum o.O okay, Arabic has gotten a big push since last I looked at the translations...
13:23 bshum 89.4% done; tpac is 100%, wow.
13:23 bshum Guess we should shake the trees on the right to left translation quirks...
13:28 bshum Hmm, I have a feeling we're going to need to check on some of the variable translations.
13:28 bshum Well, maybe not.  Might be okay.
13:28 * bshum will test some of that later :)
13:32 * bshum doesn't think TPAC will swing RTL when using arabic settings.... hmmmm
15:49 ldw joined #evergreen
17:01 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>

Results for 2016-11-26

05:01 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
13:07 bmills joined #evergreen
17:00 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
19:09 ldw joined #evergreen
20:21 StomproJ joined #evergreen
22:25 catherinedevlin joined #evergreen

Results for 2016-11-25

01:26 StomproJ joined #evergreen
03:47 Stompro joined #evergreen
05:00 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
08:20 Dyrcona joined #evergreen
12:03 Christineb joined #evergreen
12:22 jihpringle joined #evergreen
13:47 brahmina joined #evergreen
16:25 brahmina joined #evergreen
16:32 jihpringle joined #evergreen
17:01 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>

Results for 2016-11-24

00:52 StomproJ joined #evergreen
01:04 Stompro joined #evergreen
05:01 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
12:15 catherinedevlin joined #evergreen
12:54 jeffdavis joined #evergreen
13:02 Christineb joined #evergreen
13:24 catherinedevlin joined #evergreen
13:33 dbs joined #evergreen
15:49 catherinedevlin joined #evergreen
17:00 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
19:05 StomproJ joined #evergreen
21:24 Stompro joined #evergreen

Results for 2016-11-23

05:02 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
07:31 agoben joined #evergreen
08:29 Callender joined #evergreen
08:30 mmorgan joined #evergreen
16:18 * pinesol_green grabs some Supreme Brownie Sundae for Dyrcona
16:18 * Dyrcona studies up on PostgreSQL tuning, again. :)
16:18 Dyrcona Looks like they took my pgtune away.
16:20 Dyrcona I inherited a server with RAID already configured to use as a test/development db server.
16:20 Dyrcona "RAID 5 is not a very good option for databases unless you have more than 6 disks in your volume."
16:21 Dyrcona Fortunately, for me, the RAID 5 has 8 disks. :P
16:22 Dyrcona I'm not expecting it to be blazing fast, anyway, but we'll need to replace the production database server sooner or later.
16:50 jeff berick++ thanks!
16:51 berick jeff++ right batch atcha.  I think this is a much nicer approach.  plus, we get to put a little Hatch icon in the browser -- makes it look official ;)
16:52 berick now we just need some icon art
17:01 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
17:03 mmorgan left #evergreen
17:56 dcook joined #evergreen
21:48 Stompro joined #evergreen

Results for 2016-11-22

00:00 * bshum didn't test the feature, but wonders idly how it aligns with the action_trigger_runner script and various timings
00:00 bshum It seems to have a 5 min delay after the checkout, so I would expect it to take that long before it did anything, and also only happen when the actiontrigger runner script runs
00:00 * bshum might have to play and learn how it's supposed to work :)
05:00 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
07:30 rjackson_isl joined #evergreen
08:14 collum joined #evergreen
08:22 kmlussier joined #evergreen
09:44 jeff I'd be interested in hearing more details about the "client would suddenly behave like they were logged into a different workstation at a different branch" part.
10:00 tsbere That almost sounds like either corruption of memcache's memory space or something isn't acting properly when things can't be returned
10:05 jeff or a re-prompt for auth using au.home_ou instead of workstation ou, etc.
10:34 miker Bmagic: where (and how many times) are you running memcache?
10:35 miker kmlussier: I've tested rebasing the sprint4 branch against master ... it applies cleanly. do you have any desire to merge some of the webstaff bug fixes into the collab branch, and then merge the whole shebang into master soon-ish?
10:36 pinesol_green [evergreen|Kyle Huckins] LP1537214 Staff Initials in Patron Notes - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=1fbaa1d>
10:38 kmlussier miker: I could test and merge what's there now. Did that last commit mess up your rebase?
10:38 miker no, it didn't. it happened after my rebase test :)
10:39 kmlussier OK, I'll take a look at it now then. I've already tested most of what's in the collab branch, so it shouldn't take too long. As long as I don't get distracted.
10:40 miker I actually was thinking more about the outstanding LP pullrequests
10:40 miker fwiw
10:41 miker pulling those into the collab branch, and then shoving the lot into master
10:48 Bmagic miker: memcache is running on a single machine with 4096 as the limit. 3 bricks.
10:56 sandbergja joined #evergreen
10:59 miker kmlussier: but either way is fine. we may just find we're fixing collab code instead of pullrequest code if there's conflict
11:00 kmlussier miker: OK, I'm testing a couple of small things to possibly put in the collab branch before I look at the larger branch.
11:01 miker kmlussier: one situation that might go the other way would be obviously backportable fixes ...
11:04 kmlussier miker: Yeah, I haven't been backporting as much based on brief discussion with berick last week http://irc.evergreen-ils.org/​evergreen/2016-11-16#i_276134
11:04 kmlussier It seemed best to focus efforts on trying to get web client code into 2.12 sooner.
13:11 genpaku joined #evergreen
13:38 bmills joined #evergreen
13:38 terran joined #evergreen
13:50 terran Hi gang - I'm trying to figure out how to enable Spanish on a 2.11.1 test server. I've updated eg_vhost.conf so the dropdown appears, but nothing happens when I try to use it - can someone push me in the right direction?
13:51 bshum terran: Hi Terran!  Spanish you say?  Fascinating :)
13:51 terran bshum: I saw you were working on that :)
13:52 bshum terran: So when you say you have a dropdown for the language picker, what languages show up there?  And you select and hit the change button and nothing?
14:19 * berick has some rebasing to do
14:19 bshum So maybe it's not copying over the locale files right during the install phase
14:19 terran bshum: sure thing, I'll let you know what he says
14:19 bshum terran++ # testing things
14:19 * csharp appears just at that moment
14:20 csharp oh - spanish, I see
14:21 bshum To get things rolling, I think it should be as simple as "mkdir /openils/var/data/locale" and Then "cp /home/wherever/Evergreen-ILS-2.11.1/O​pen-ILS/src/data/locale/opac/es-ES.po /openils/var/data/locale/es-ES.po"
16:31 JBoyer Happy Thanksgiving #evergreen!
16:34 kmlussier Yes, Happy Thanksgiving all!
16:34 mmorgan Happy Thanksgiving!
17:00 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
17:03 mmorgan left #evergreen
19:52 StomproJ joined #evergreen

Results for 2016-11-21

03:50 akilsdonk joined #evergreen
05:01 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
07:14 rjackson_isl joined #evergreen
07:18 JBoyer joined #evergreen
07:33 agoben joined #evergreen
16:51 Dyrcona I asked, 'cause it doesn't purge patrons, AFAICT.
16:53 dbwells Well, I will throw something on LP to record the idea of purge-on-merge behavior, as it seems desirable to at least some present folk.
16:54 berick dbwells++
17:01 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
17:01 jvwoolf left #evergreen
17:03 mmorgan left #evergreen
17:54 abowling left #evergreen

Results for 2016-11-20

05:00 pinesol_green News from qatests: Test Failure <http://testing.evergreen-ils.org/~live>
06:12 wetekplay joined #evergreen
06:22 wetekplay joined #evergreen
07:27 wetekplay joined #evergreen
07:33 wetekplay joined #evergreen
07:44 wetekplay joined #evergreen
13:37 Christineb joined #evergreen
17:01 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
19:38 egbuilder joined #evergreen
20:08 phasefx joined #evergreen
21:57 jeff______ joined #evergreen

Results for 2016-11-19

05:01 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
12:01 pinesol_green [evergreen|Jane Sandberg] Docs: consolidating some duplicate language - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=4408878>
14:26 bmills joined #evergreen
17:00 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>

Results for 2016-11-18

05:00 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
07:20 rjackson_isl joined #evergreen
07:21 agoben joined #evergreen
08:13 collum joined #evergreen
16:32 berick it's positively tepid outside
16:32 berick (and smokey, which is a little concerning)
16:38 Dyrcona @weather 01844
16:38 pinesol_green Dyrcona: Methuen, MA :: Clear :: 61F/16C | Friday: Clear. Lows overnight in the upper 30s. Friday Night: A clear sky. Low 38F. Winds light and variable.
17:01 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
17:03 mmorgan left #evergreen
19:16 jvwoolf joined #evergreen
19:50 bmills joined #evergreen

Results for 2016-11-17

00:07 tsbere_ joined #evergreen
05:00 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
07:05 agoben joined #evergreen
07:12 rjackson_isl joined #evergreen
08:11 collum joined #evergreen
12:01 Dyrcona Yeah, that decode_utf8 is part of the problem.
12:02 Bmagic so, blanket the whole thing, removing all calls to decode_utf8. got it
12:05 Dyrcona I'd try that. You might find you need to put some back, but I don't know for sure.
12:05 Dyrcona I've not tested SIP extensively on 16.04, but I suppose that I should.
12:06 Dyrcona Trouble is, my day job has me doing other things, and I'm not that motivated to continue working on Evergreen in all of my free time. :)
12:06 dbs Bmagic: I can tell you where we have clean_text for our many french users and items - although we're on ubuntu 14.04, there were clean_text() calls we had to add, not take away
12:06 Bmagic Dyrcona++
12:09 dbs Dyrcona: yeah, I really don't know about Perl 5.20.
12:09 Dyrcona Bmagic: It is worth looking into.
12:09 Dyrcona Merging records is one thing that I know I did not do on 16.04.
12:10 dbs is it clear that the same problem does not impact perl 5.18? https://bugs.launchpad.net/evergreen/+bug/1542495 mentions testing with 16.04 and Jessie, nothing about ubuntu 14.04
12:10 pinesol_green Launchpad bug 1542495 in SIPServer "OpenILS::SIP::clean_text() can crash" [Undecided,Confirmed] - Assigned to Jason Stephenson (jstephenson)
12:11 Bmagic well, I removed that single call to decode in Sip.pm and boom, it's working
12:12 Bmagic All of the other modules have no mention of decode
15:48 berick no worries
16:11 bmills joined #evergreen
16:43 berick @band add Hamburger Hatch
16:43 pinesol_green berick: <shaggy>We're, like, doomed.</shaggy>
16:44 mmorgan joined #evergreen
16:45 afterl left #evergreen
17:00 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
17:39 bmills joined #evergreen
17:57 bmills1 joined #evergreen
20:04 pinesol_green [evergreen|Jane Sandberg] Docs: documenting new authority features - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=f0de98b>
20:20 pinesol_green [evergreen|Kyle Huckins] LP#1528916 Patron Holds Ready/Total - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=8defb7f>
20:44 bmills joined #evergreen
21:30 pinesol_green [evergreen|Billy Horn] LP#1621799: disable checkout for inactive patrons - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=2652801>
23:30 pinesol_green [evergreen|Jane Sandberg] Docs: Incorporating overlay/merge profiles documentation from Evergreen in Action + new 2.11 feature - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=4c1146f>

Results for 2016-11-16

05:01 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
05:58 kmlussier joined #evergreen
05:58 kmlussier @coffee
05:58 * pinesol_green brews and pours a cup of Kenya Mamuto, and sends it sliding down the bar to kmlussier
12:36 pinesol_green Launchpad bug 1488655 in Evergreen 2.10 "Metarecords are not being maintained properly" [Medium,Confirmed] https://launchpad.net/bugs/1488655
12:36 gmcharlt csharp: thanks
12:50 * csharp notices rhamby's comment on the bug indicating his signoff
12:50 rhamby csharp: yeah, I tested it ... last week?  time is blurring together into an endless wave of projects ....
12:52 Dyrcona "Time keeps on slippin', slippin', slippin' into the future..."
12:54 kmlussier That is not a song I want in my head.
12:55 kmlussier Too late
13:38 bshum Packager just contains all the stuff for asciidoc building and i18n
13:38 kmlussier OK, thanks for confirming bshum!
13:38 kmlussier bshum++
13:38 bshum I've been thinking about adding a new make target to split i18n away from packager too
13:38 bshum So that I can install stuff more quickly to test that piece.
13:38 sandbergja joined #evergreen
13:41 Dyrcona I mentioned to bshum (yesterday? Monday?) that sounded fine to me as long as packager depended on the new i18n target.
13:44 kmlussier Yay! The root user wasn't required for npm install this time. Progress.
14:56 dbs best I could come up with was to add a Direct Charge on the invoice for the second part of the payment, with a note on the direct charge reflecting that it was a split payment
14:57 dbs With a separate Funding Source -> Fund -> Invoice path for the second part of the payment to at least link the two funding sources through the invoice piece
14:58 dbs (this is for big ticket items like databases or journal suites that often are shared costs between departments or separate institutions)
14:59 pinesol_green [evergreen|Galen Charlton] LP#1488655: regression test for metarecord remapping - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=31108a7>
14:59 pinesol_green [evergreen|Galen Charlton] LP#1488655: fix MR remapping upon fingerprint change - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=a27eaba>
15:00 pinesol_green [evergreen|Galen Charlton] LP#1488655: stamp schema upgrade script - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=ab51669>
15:07 pinesol_green [evergreen|Galen Charlton] updates to 2.11.1 release notes - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=ab807aa>
15:08 pinesol_green [evergreen|Galen Charlton] update 2.10.8 release notes - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=166aa9e>
15:12 gmcharlt OK, after checking with miker, I'm declaring rel_2_10 and rel_2_11 "done" with respect to substantive changes for the 2.10.8 and 2.11.1 releases
15:13 gmcharlt dbwells: I believe you're building the 2.11.1 tarball, right?
15:13 dbwells gmcharlt: yes sir
16:45 Dyrcona gmcharlt++ dbwells++
16:58 bmills joined #evergreen
16:58 jvwoolf left #evergreen
17:01 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
17:03 mmorgan left #evergreen
17:16 gmcharlt OK, post ready to go when 2.11.1 is
17:36 dbwells gmcharlt: everything is in place, downloads page is updated

Results for 2016-11-15

01:42 gsams joined #evergreen
05:01 pinesol_green News from qatests: Test Failure <http://testing.evergreen-ils.org/~live>
07:21 rjackson_isl joined #evergreen
07:21 agoben joined #evergreen
08:20 collum joined #evergreen
10:59 Bmagic another issue with 2.11 we are finding Uploading PO MARC throws an error
10:59 Bmagic ERROR:  new row for relation "lineitem" violates check constraint "picklist_or_po"
10:59 Dyrcona I don't know of any where in the interface that we leak user ids via URL, which is what I had in mind.
11:02 kmlussier Bmagic: Do you have any details on what options were selected when they were uploading the PO?
11:03 * kmlussier can fire up a VM to test a PO upload.
11:04 Bmagic acq.lineitem.create id= selector=201704 picklist= purchase_order= provider=18 create_time=now edit_time=now........
11:05 Bmagic shouldn't there be a purchase_order there?
11:09 tsbere Bmagic: According to the DB it isn't required?
11:51 csharp and works in Chrome for me too
11:52 mmorgan Not sure if this might an example of bug 1546128
11:52 pinesol_green Launchpad bug 1546128 in Evergreen "eg.hatch.required not parsed correctly" [Undecided,New] https://launchpad.net/bugs/1546128
11:52 kmlussier mmorgan: I tested workstation registration the other day, but I can't recall if I tested FF. I would add a comment to the workstation registration bug.
11:52 * kmlussier doesn't have the bug number at her fingertips.
11:54 mmorgan This one? lp 1467663
11:54 pinesol_green Launchpad bug 1467663 in Evergreen "Cannot login to web staff client if work station does not exist in database" [Medium,Fix committed] https://launchpad.net/bugs/1467663
11:54 csharp "Firefox can’t establish a connection to the server at wss://localhost:8443/hatch."
12:02 csharp huh - it works for me now (even in private browsing)
12:02 csharp I was using private browsing in an attempt to get around cache issues
12:02 mmorgan kmlussier: No, not in private browsing mode.
12:03 kmlussier mmorgan: Try clearing your cache and then re-test?
12:03 krvmga joined #evergreen
12:04 JBoyer Are you waiting long enough? I tried it out in my FF (49.something) private window, and it took a good while for the workstation dropdown to appear, but once it did I was able to signin using the new workstation I had just created.
12:07 mmorgan JBoyer: Stared at it for a good long time, but didn't actually time it. Must've been at the login screen for at least a couple of minutes and the dropdown didn't show up.
12:36 kmlussier Yeah, I think you all should take the keys to that account away from me and give them to somebody else who can better handle the responsibility. ;)
12:37 csharp @intervention kmlussier
12:37 pinesol_green csharp: Sorry, that command is only available to Evergreen Premium™ Subscribers. Please upgrade your subscription ASAP!
13:33 Bmagic Importing marc acq records works bus the resulting line items in the purchase order do not link to the catalog. The import settings had a match profile and "import non-matching records" checked. All of the 8 records in my test do not match, but they are not imported.
13:34 Bmagic I take that same file and use on batch import, and it works fine.
13:39 kmlussier Bmagic: Has the order been activated yet?
13:40 Bmagic no
13:54 Bmagic I think I'm onto something
14:08 kmlussier Bmagic: As I mentioned earlier, when I load records, I'm getting a hanging progress bar, but the PO is created with lineitems. In my case, the lineitems are not linked to the catalog either.
14:09 Bmagic ah, interesting
14:09 kmlussier I saw the same behavior on master and on the community demo server, which I loaded with the 2.10 release branch yesterday, so it's pretty much 2.10.7 with a few additional branches that have recently been merged.
14:10 kmlussier However, when testing on a 2.10.5 server, the upload performed as expected. The non-matching records were imported.
14:18 kmlussier I get an error message that says: Caught error from 'run' method: Can't locate object method "max_chunk_count" via package "OpenSRF::AppRequest" at /usr/local/share/perl/5.18.2/O​penILS/Application/Vandelay.pm line 904.
14:19 Bmagic hmmm, different
14:20 Bmagic we are on 16.04 which is why we installed OpenSRF from master
14:20 Bmagic which could* be playing a role in this
14:21 dbwells Bmagic: looking that above errors, sounds like a good guess to me
14:21 Bmagic dbwells: I'm running through installation on another server to test it against 2.4.1 tarball
14:21 kmlussier tsbere could confirm, but I'm guessing my VMs are installing OpenSRF from master too.
14:34 collum joined #evergreen
14:34 dbwells kmlussier: looks like "chunking" was renamed to "bundling" in 01f95834835bed94 in OpenSRF.  It seems like references to "max_chunk_count" in Vandelay may need to move to "max_bundle_count" to work with OpenSRF master.
14:37 Bmagic so, now, is there anyone here running OpenSRF 2.4.1 on Ubuntu 16.04?
14:37 dbwells Bmagic: just a hunch, but I see that alt_holds_print.js references "chunk_size", so maybe new OpenSRF was the cause of that issue as well?
14:37 Bmagic it sure could be!
14:38 Bmagic Which explains why it was working on my test machine and not on production
14:38 Bmagic my test machine was Ubuntu 14.04 and therefore it could run 2.4.1, so I didnt have a need to run OpenSRF master
14:38 kmlussier dbwells++ # Good sleuthing!
15:02 mmorgan1 joined #evergreen
15:20 bmills joined #evergreen
16:49 tsbere Stompro: In non-reporter queries I tend to string_agg them together, just so you know.
16:50 * tsbere doesn't usually use the flat view though, as there shouldn't ever be uncontrolled versions of composites
16:53 BigRig joined #evergreen
17:01 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
17:03 kmlussier Huzzah!
17:05 mmorgan left #evergreen
17:51 Bmagic Stompro: select string_agg(value,$$,$$) from metabib.record_attr_flat where attr=$$icon_format$$ and id=$bibid

Results for 2016-11-14

05:00 pinesol_green News from qatests: Test Failure <http://testing.evergreen-ils.org/~live>
07:18 rjackson_isl joined #evergreen
07:18 agoben joined #evergreen
07:21 Callender joined #evergreen
10:52 Dyrcona Maybe the user's work_ou is not set properly?
10:52 Bmagic hmmm
10:52 * Dyrcona just speculates. I don't know that part of the staff client.
10:53 Bmagic It's happening everywhere, all branches. Im digging. It's working on my test server....
10:55 Dyrcona Hmm. Maybe changes for the browser staff client or something happened during the upgrade?
10:56 Bmagic alt_holds_print.js are identical
10:57 Dyrcona Well, that's the end of my speculations.
11:06 Bmagic how about this
11:06 Bmagic File does not exist: /openils/var/web/js/dojo/fieldmapper/OrgLasso.js
11:07 Dyrcona That might be it.
11:08 Bmagic hmm, well that file is missing on the test server too
11:19 kmlussier Bmagic: I don't know if this is what your users are seeing, but I just tried to use the alternate strategy on a VM with master. I just get a progress bar that hangs, and no titles load.
11:19 Bmagic that is what we are seeing
11:19 Bmagic however, my test machine with the exact same data has no issues.....
11:20 kmlussier There was one test in which 10 of the 41 titles did load successfully, but the progress bar hung after that.
11:20 Bmagic Obviously, my test machine has a different set of code on it, I'm digging to find the differences
11:21 kmlussier If you end up filing a bug, I can confirm it. I'm not sure where you saw that error, so I don't know if we get the same error.
11:22 Christineb joined #evergreen
11:23 Bmagic kmlussier: thanks
11:28 Bmagic ok, my test server used rel_2_11 and the production machine used tags/rel_2_11_0
11:41 csharp Bmagic: my 2.11.0 test server just pops up with an alert that says "No Results"
11:42 Bmagic csharp: yeah, you need to have at least one item on the pull list
11:43 csharp trying a branch with items
11:45 csharp Bmagic: yep - same behavior - same errors in the osrfwarn.log
11:48 csharp 2.11.0
11:48 csharp (the tarball release)
11:55 Bmagic I see
11:56 Bmagic Somehow it's not broken on my test machine. But I will report the bug on launchpad after this conference call
12:04 csharp Bmagic: here's the call I see: open-ils.circ open-ils.circ.hold_pull_list.print.stream "<authtoken>", {"org_id":null,"limit":null,"offset":null,"ch​unk_size":null,"sort":["acplo.position","pref​ix","call_number","suffix","request_time"]}
12:04 jihpringle joined #evergreen
12:04 csharp "org_id":null seems to be the relevant part
15:43 dbs Bmagic++
15:57 RBecker joined #evergreen
16:57 jvwoolf left #evergreen
17:00 pinesol_green News from qatests: Test Failure <http://testing.evergreen-ils.org/~live>
17:04 mmorgan left #evergreen
17:05 phasefx incidentally, I tried to build a clean wheezy install I could run an actual report on (to test the last fix for the failure above), and ran into different issues with libdbi (where the debian-jessie way of doing it should work).  Will still revisit
20:33 makohund joined #evergreen
20:56 hbrennan joined #evergreen
21:00 makohund left #evergreen

Results for 2016-11-13

05:01 pinesol_green News from qatests: Test Failure <http://testing.evergreen-ils.org/~live>
06:48 dbs joined #evergreen
09:04 gsams_ joined #evergreen
15:18 gmcharlt joined #evergreen
15:29 gmcharlt joined #evergreen
17:01 pinesol_green News from qatests: Test Failure <http://testing.evergreen-ils.org/~live>

Results for 2016-11-12

05:00 pinesol_green News from qatests: Test Failure <http://testing.evergreen-ils.org/~live>
16:23 dcook joined #evergreen
17:00 pinesol_green News from qatests: Test Failure <http://testing.evergreen-ils.org/~live>
17:18 Ilie` joined #evergreen

Results for 2016-11-11

04:54 finnx joined #evergreen
04:55 finnx joined #evergreen
04:58 finnx joined #evergreen
05:01 pinesol_green News from qatests: Test Failure <http://testing.evergreen-ils.org/~live>
08:48 bos20k joined #evergreen
09:38 _adb joined #evergreen
09:51 maryj joined #evergreen
13:37 bshum So you don't have much time to get off it either.
13:38 bshum 14.04 is conservatively best choice, just cause I don't think anyone is using 16.04 in production.  But I am out of touch lately.
13:39 hbrennan yeah systemd in 16.04 is my hold up on production there
13:39 bshum Fair enough, I only helped to test the installation procedures for 16.04; I haven't used it :)
13:40 bshum at least not outside playtesting and developments
13:41 hbrennan okay holly is sounding fine with feature upgrades in 2.10 train so that's the plan 2.10.7 and hit another maintinace window in Jan/Feb
13:41 bshum For the conservatives, let's say Debian is your best bet.  If you're a little more edgy, go with Ubuntu.  And if you're crazy like dbs or csharp, there's always Fedora.
13:41 hbrennan fedora isn't around long enough for production
16:59 csharp ah
17:00 csharp yeah - it was kindof a brittle one-off that I didn't think much about forward porting
17:00 csharp probably worth grabbing a ruby version string somehow so that won't break
17:01 pinesol_green News from qatests: Test Failure <http://testing.evergreen-ils.org/~live>
17:01 csharp pinesol_green: no, you're the failure
17:01 pinesol_green csharp: have you tried local mean solar time for the named city as the reference point?
17:01 pinesol_green csharp: I am only a bot, please don't think I'm intelligent :)

Results for 2016-11-10

00:49 Christineb joined #evergreen
03:11 Mark__T joined #evergreen
05:02 pinesol_green News from qatests: Test Failure <http://testing.evergreen-ils.org/~live>
06:40 rlefaive joined #evergreen
06:43 kmlussier joined #evergreen
07:14 dcook__ joined #evergreen
09:15 dbs runtime or compile-time error?
09:16 dbs I dunno. another meeting to prep for :(
09:16 Dyrcona dbs: The assignment does happen in an eval block, but the if is outside the eval block, so if it was undefined outside of the eval, the if should still trigger.
09:19 dbs maybe the "or not $filename" normally never gets tested because the error condition occurs and so evaluation of the if condition stops at $@
09:20 dbs and maybe now you're seeing a case where the return value is undefined, without an error occurring.
09:20 dbs that _almost_ makes sense but then the "or not" should catch it! hah
09:21 * dbs really goes into meeting prep mode
09:22 Dyrcona dbs: I've tried replicating it with a smaller script, and I can't.
09:22 Dyrcona Even running it on the server that runs edi_fetcher to use the same version of Perl.
09:32 Dyrcona Oh, nice. This server is losing messages in rsyslog by the hundreds, so no wonder I can find neither success nor failure messages in the logs.
16:58 jeff also, a bug can "affect" multiple projects.
17:00 Dyrcona csharp: I think the supports section is actually used.
17:01 Dyrcona I'd have to look at the code again to be sure.
17:01 pinesol_green News from qatests: Test Failure <http://testing.evergreen-ils.org/~live>
17:02 jeff supports and policy are different things.
17:02 csharp well, either way, I indicated to the library that it's not supported and they'll just need to take them out of service when the connections aren't working (a separate issue on their end they are trying to resolve)
17:03 * csharp once again broadcasts his wish to the universe that libraries would consult with us before purchasing things and expecting them to work based on sales pitches

Results for 2016-11-09

05:00 pinesol_green News from qatests: Test Failure <http://testing.evergreen-ils.org/~live>
07:16 rjackson_isl joined #evergreen
07:21 JBoyer joined #evergreen
08:06 collum joined #evergreen
16:04 jeff Consult your /opensrf/default/email_notify/smtp_server config setting on the OpenSRF host(s) in question, go from there.
16:04 jeff If it's localhost, MTA may be eating / queueing the mail. If it's non-localhost, you might be getting firewalled or rejected (relaying denied, whatever) -- you'd likely be seeing those rejects in your logs, so firewall/routing is more likely?
16:04 Dyrcona jeff: That's the same. When we switched to GMail, I don't think I configured the drones to use a smarthost.
16:05 Dyrcona I found that the test I tried to send myself was handled on drone 2 of brick 2.
16:06 Dyrcona I'll check mail logs there.
16:08 jeff Also, info/warn opensrf logs containing "SendEmail Reactor"
16:11 Dyrcona jeff: That latter gives me what I expect: a number of entries from the drones saying that they can't send email.
16:25 Dyrcona Well, I still need to configure the smarthost on the drones. :)
16:36 Dyrcona So, slightly different plan: I'll configure the server that sends the action trigger emails to relay for the local IPs, and then configure the drones to use that server as a smarthost.
16:36 Dyrcona That cuts down on extra configuration to keep track of. This is, after all, being done in "the Debian way."
17:00 pinesol_green News from qatests: Test Failure <http://testing.evergreen-ils.org/~live>
17:04 mmorgan left #evergreen
17:13 bmills anyone had luck with getting autosuggest to stop crashing on search terms beginning with punctuation? or could point me in the right direction?
17:14 bmills thinking along the lines of lp 1161095

Results for 2016-11-08

00:19 Bmagic joined #evergreen
01:40 dteston joined #evergreen
02:16 jihpringle joined #evergreen
05:01 pinesol_green News from qatests: Test Failure <http://testing.evergreen-ils.org/~live>
07:45 collum joined #evergreen
08:36 mmorgan joined #evergreen
09:09 gmcharlt I've made a couple config changes to the wiki that may be of interest
09:30 mmorgan1 joined #evergreen
09:31 rhamby kmlussier: I vaguely remember doing that once I read it so ... sure
09:31 kmlussier rhamby: OK, thanks!
09:31 rhamby kmlussier: I wouldn't think anything between now and then in the staff client would have broken it so test away
09:33 kmlussier rhamby: I'll give jsandberg a chance to test it first, but will keep it on my radar if she doesn't have a chance to test it.
09:33 gmcharlt jeff: https://wiki.evergreen-ils.o​rg/doku.php?id=archive:start
09:33 Dyrcona I wanted that at one point recently.
09:34 gmcharlt tsbere: and yeah, you're probably right, but I'm hoping it will encourage people to get rid of outdated content, as a provides a way to ensure that it's not *forever*
09:41 jeff and of course there's always a quick journey to the files-on-disk on request/need.
09:51 jvwoolf joined #evergreen
09:54 dteston joined #evergreen
10:10 Dyrcona csharp++ # Fixing my busted tests.
10:11 Dyrcona Should that be backported to 2.11?
10:12 dbs gmcharlt++
10:12 yboston joined #evergreen
10:20 Christineb joined #evergreen
10:28 kmlussier csharp++ Dyrcona++
10:28 pinesol_green [evergreen|Chris Sharp] Fix purge_user_activity.pg live test - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=c62be18>
10:28 pinesol_green [evergreen|Chris Sharp] LP#1640153 Fix abort-transit-copy-status.t perl test. - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=2057458>
10:29 csharp now once I can get testing.evergreen-ils.org credentials for the new builder servers on mundungus, we can resume testing on multiple OS platforms/releases
10:30 Dyrcona Well, I figured tests would be easy to test. :)
10:32 * kmlussier just noticed new acq menu on webby. Hooray!
10:33 sandbergja joined #evergreen
10:34 Bmagic You all are making Evergreen great.... again
11:12 kmlussier What do we do with bugs like bug 1467663, where the code is now incorporated in the sprint4 collab branch? Is it okay to merge berick's branch, in which case I assume it should be taken out of the collab branch? Or has past practice been that we wait until the full collab branch is merged?
11:12 pinesol_green Launchpad bug 1467663 in Evergreen "Cannot login to web staff client if work station does not exist in database" [Medium,Confirmed] https://launchpad.net/bugs/1467663
11:15 jeff kmlussier: i have similar questions also.
11:21 kmlussier My inclination is to merge berick's branch sooner, because the original issue reported in the bug can be a big PITA for people testing/working on the web client if they use a test system where the database is constantly reloaded.
11:22 berick kmlussier: i don't imagine there would be any opposition to merging to master.  I find this bug to be a real PITA as well.
11:26 gmcharlt kmlussier: and from the POV of the folks maintaining the collab branch, it doesn't cause any significant problems patches are picked from it sooner
11:26 gmcharlt although it would be handy if any additions or changes to such patches existed as separate patches
11:27 kmlussier berick / gmcharlt: Ok, thanks! I want to test it outside of webby before merging. I'll try to make time to do so today.
11:40 brahmina joined #evergreen
11:41 berick kmlussier++ gmcharlt++
11:59 jihpringle joined #evergreen
16:53 Bmagic crazy
16:54 Bmagic It's showing it's face now because I have left memcached off on the app servers now
16:57 Bmagic jeff++ Dyrcona++
17:01 pinesol_green News from qatests: Test Failure <http://testing.evergreen-ils.org/~live>
17:02 jeff okay, the "report on circ counts for copies attached to titles in a shared bucket with a specially prefixed name" report works well.
17:04 mmorgan left #evergreen
17:08 bmills joined #evergreen

Results for 2016-11-07

18:15 berick tfw you realized you launched irssi w/o screen
18:15 berick joined #evergreen
18:16 berick quickly remedied
18:56 csharp hmm - so if I want to fix a test, does that warrant a bug report?  feels kinda meta
19:13 csharp b1f4d599
19:13 pinesol_green csharp: [evergreen|Bill Erickson] LP#1570909 User activity transient default - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=b1f4d59>
20:00 dteston joined #evergreen
20:39 abowling left #evergreen

Result pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138