| 01:31 |
|
sandbergja2 joined #evergreen |
| 01:32 |
|
RBecker joined #evergreen |
| 03:00 |
|
StomproJ joined #evergreen |
| 05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 05:46 |
|
Stompro joined #evergreen |
| 06:02 |
|
wsmoak joined #evergreen |
| 07:10 |
|
rjackson_isl joined #evergreen |
| 13:26 |
jihpringle |
then we can have the days in the calendar before the end of December |
| 13:26 |
sandbergja |
that would be excellent |
| 13:26 |
dluch |
jihpringle++ |
| 13:27 |
sandbergja |
#info yboston will email Galen to give remingtron and sandbergja access to DIG test server |
| 13:27 |
sandbergja |
This is done. |
| 13:27 |
sandbergja |
yboston++ gmcharlt++ |
| 13:27 |
sandbergja |
Thanks for the updates, everyone! |
| 13:27 |
sandbergja |
#topic Progress on documenting new features in Evergreen 2.11 |
| 13:27 |
sandbergja |
I think we have this pretty well sorted out, so I'll move on. |
| 13:28 |
sandbergja |
#topic Finding a new DIG Facilitator |
| 13:28 |
sandbergja |
Let me start out by saying :-( |
| 13:28 |
sandbergja |
And that I miss yboston already! |
| 13:29 |
sandbergja |
What should the process be for finding a new DIG Facilitator? |
| 13:29 |
sandbergja |
Should we put a call out to the email lists, similar to what kmlussier is doing for the DIG release coordinator? |
| 13:30 |
kmlussier |
In some ways, I'm inclined on holding off on my call until we have a DIG facilitator. I think it's more important that we find someone to lead the group first. |
| 13:32 |
kmlussier |
I just looked at the e-mail list archive to see how it was handled before. It looks like Karen tapped yboston to be facilitator before she notified that she had to step down. |
| 13:32 |
kmlussier |
No, wait, I'm wrong on that. |
| 13:51 |
sandbergja |
These are by no means complete, just conversation starters to get people excited about the project again. :-) |
| 13:51 |
sandbergja |
Here's a manual for local sysadmins: |
| 13:51 |
kmlussier |
Yay! sandbergja++ |
| 13:51 |
sandbergja |
#link http://docs-testing.evergreen-ils.org/docs/reorg/staffclient_sysadmin/ |
| 13:51 |
sandbergja |
And a small one for front-line circ staff: |
| 13:52 |
sandbergja |
#link http://docs-testing.evergreen-ils.org/docs/reorg/circulation/ |
| 13:52 |
sandbergja |
I'm hoping to get the Docs Reorg group back together at some point to look these over, and try to figure out where to go from here |
| 13:53 |
sandbergja |
But am also more than happy to take suggestions now as well. :-) |
| 13:54 |
|
bmills joined #evergreen |
| 13:54 |
kmlussier |
At a first glance, it looks good, but I would need more time to look at it before giving specific feedback. |
| 13:55 |
sandbergja |
That makes sense. :-) |
| 15:08 |
gmcharlt |
kmlussier++ |
| 15:09 |
gmcharlt |
and as it's a carry-over |
| 15:09 |
Bmagic |
#info Bmagic = Blake GH, MOBIUS |
| 15:09 |
gmcharlt |
#gmcharlt and Dyrcona to create guidelines on the wiki to determine what is a bug fix vs. new feature. |
| 15:09 |
gmcharlt |
-- in particular, to suggest guidelines for what should be backported |
| 15:09 |
gmcharlt |
so, I think that does it for action items from back in the mists of time |
| 15:09 |
gmcharlt |
so moving on |
| 15:10 |
gmcharlt |
#topic OpenSRF release info |
| 15:10 |
gmcharlt |
#info OpenSRF 2.5 alpha to be cut on 7 December |
| 15:10 |
gmcharlt |
so, with respect to the alpha, there are some things in particular I'd like to request testing for |
| 15:10 |
gmcharlt |
1. the proxy configurations |
| 15:10 |
jeff |
TZ changes? |
| 15:10 |
gmcharlt |
2. bundling and chunking |
| 15:10 |
jeff |
er, you're listing. |
| 15:15 |
gmcharlt |
on the plus side, we have time before 2.12 |
| 15:16 |
gmcharlt |
any other questions or thoughts on OpenSRF? |
| 15:16 |
berick |
yeah, and fwiw I've been using the osrf proxy for a while now and that's the only issue i've run into |
| 15:16 |
gmcharlt |
cool |
| 15:16 |
gmcharlt |
the haproxy config will require more testing, but it's what I"ll be running |
| 15:17 |
gmcharlt |
ok, |
| 15:17 |
gmcharlt |
moving on |
| 15:17 |
gmcharlt |
#topic Evergreen releases |
| 15:17 |
bshum |
Would it be good to make websockets required, rather than just optional in a future OpenSRF release? |
| 15:17 |
bshum |
oops heh |
| 15:17 |
dbwells |
One other questions related to chunking/bundling, Bmagic a few weeks back hit what appeared to be an incompatibility with that change in EG master. It's probably possible to fix in a backwards compat. way, but regardless, are we assuming OSRF 2.5 will be recommended for EG 2.12+, or do we need it to work with other current releases? |
| 15:30 |
pinesol_green |
Launchpad bug 1646166 in Evergreen "Hatch 2.12 Omnibus" [Undecided,New] - Assigned to Bill Erickson (berick) |
| 15:30 |
jeff |
I'm still quite interested in that. |
| 15:30 |
jeff |
So, I'll volunteer my eyes. |
| 15:30 |
kmlussier |
I can test installing on Linux |
| 15:30 |
berick |
i have one final note to add to the install docs, the final "here's how you actually use it" bit |
| 15:31 |
gmcharlt |
I can take a look at OS X installation |
| 15:31 |
berick |
but that'll just take a sec |
| 16:37 |
|
abneiman joined #evergreen |
| 16:45 |
|
barbara joined #evergreen |
| 16:51 |
|
bmills1 joined #evergreen |
| 17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:06 |
|
mmorgan left #evergreen |
| 17:14 |
|
rlefaive_ joined #evergreen |
| 17:21 |
|
jvwoolf left #evergreen |
| 02:54 |
|
StomproJ joined #evergreen |
| 03:31 |
|
Stompro joined #evergreen |
| 03:59 |
|
StomproJ joined #evergreen |
| 05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:02 |
|
Stompro joined #evergreen |
| 07:07 |
|
StomproJ joined #evergreen |
| 07:18 |
|
rjackson_isl joined #evergreen |
| 09:50 |
kmlussier |
Looks like we have a dev meeting scheduled for tomorrow. |
| 09:52 |
kmlussier |
yboston: Would you be able to add tomorrow's DIG meeting to the DIG calendar? It's at 1 p.m. Eastern. |
| 09:52 |
* kmlussier |
doesn't have the keys to that calendar yet. |
| 10:00 |
JBoyer |
Looks like our ids just went wherever whenever during the 2011 transition to SVF values. After some dev testing I'm going to experiment with dropping all of the ccvm values with id < 10000 and reload them. A full reingest is only around 14 hours, it's worth a shot and I don't plan to keep playing musical chairs with values for the rest of my career. |
| 10:02 |
miker |
JBoyer: Open-ILS/src/sql/Pg/version-upgrade/2.0-2.1-upgrade-db.sql:1447 may be useful to you as a starting point to fix the translations. won't work directly, though |
| 10:05 |
yboston |
kmlussier: I just added it. PM the email I shoudl use to give you DIG calednar access |
| 10:10 |
JBoyer |
miker, I found that earlier. I wouldn't have thought that unions would have allowed multiple tables to mix, but that's how it looks now. |
| 11:47 |
Dyrcona |
There's only so much UNIX we can teach in the README, I'm afraid. |
| 11:47 |
* Dyrcona |
does not mean that to beat up on DPearl, but to hopefully illustrate the situation for the logs and those who may come later. |
| 11:48 |
* bshum |
loves "sapling" :) |
| 11:48 |
Dyrcona |
Yeah, that's a good name for a test server/vm. |
| 11:48 |
bshum |
My trees never made it past "acorn" stage I guess. |
| 11:49 |
Dyrcona |
I name mine for the Linux distro of the vm. |
| 11:50 |
bshum |
That's what I do now. "ubuntu16" I hate you so.... |
| 12:38 |
|
jvwoolf joined #evergreen |
| 12:47 |
csharp |
berick: I've run the hold targeter v2 script several times now and all looks normal from this end of things (action.hold_copy_map looks as normal as I expect it to look - no errors when running the script against all our holds) - anything specific to try/look out for? |
| 12:51 |
|
jihpringle joined #evergreen |
| 12:56 |
berick |
csharp: great! nothing specific. the hope is it behaves the same as before when no new options are used. |
| 12:57 |
berick |
csharp: i am curious if you compared timing, though, to the current targeter |
| 12:57 |
berick |
or if you'd be willing to do so |
| 12:58 |
berick |
reset all active holds prev_check_time, run current targeter, then repeate with new targeter (or with --target-all) |
| 12:58 |
berick |
csharp: also, I pushed a small speed-up fix yesterday as you were testing. pulling that in would be good |
| 12:59 |
berick |
csharp++ |
| 13:00 |
csharp |
berick: I pulled in the fix before running it today - I'll run the other for a comparison, sure |
| 13:10 |
Dyrcona |
csharp++ # I never got around to looking at those changes. |
| 13:13 |
|
rhamby joined #evergreen |
| 16:06 |
* bshum |
needs to hunt down some snacks now |
| 16:17 |
|
mmorgan joined #evergreen |
| 17:01 |
|
mmorgan left #evergreen |
| 17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:41 |
|
bmills joined #evergreen |
| 17:45 |
gmcharlt |
@hate iframes |
| 17:45 |
pinesol_green |
gmcharlt: The operation succeeded. gmcharlt hates iframes. |
| 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> |
| 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 |
| 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 |
| 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 |
| 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 |
| 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/Open-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 |
| 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> |
| 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 |
| 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/OpenILS/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 |
| 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,"chunk_size":null,"sort":["acplo.position","prefix","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 |
| 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 :) |
| 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 |
| 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 |
