| 11:55 |
|
bmills joined #evergreen |
| 12:06 |
|
jihpringle joined #evergreen |
| 12:40 |
|
DPearl joined #evergreen |
| 14:10 |
jeffdavis |
I'm thinking about live tests for bug 1541559 |
| 14:11 |
pinesol_green |
Launchpad bug 1541559 in Evergreen "OneClickdigital API integration" [Wishlist,New] https://launchpad.net/bugs/1541559 - Assigned to Jeff Davis (jdavis-sitka) |
| 14:11 |
jeffdavis |
The module is modeled after AddedContent, so there is a main EbookAPI module and separate handler sub-modules for the different vendor APIs (OneClickdigital, OverDrive) |
| 14:13 |
jeffdavis |
I don't think we can hard-code any tests that actually talk to those APIs, so I am thinking of having a "Test" handler that doesn't do any HTTP lookups, just responds correctly to the various ways that the main module can use a handler sub-module. It could also serve as a kind of reference implementation for future handlers. |
| 14:13 |
jeffdavis |
Does that make sense, or is it overkill? |
| 14:16 |
jeffdavis |
"HTTP lookup" is not the right way to put that, hope my technical solecisms don't confuse things too much :) |
| 14:21 |
phasefx |
jeffdavis: you could mockup a web server using expect |
| 14:21 |
phasefx |
and point to localhost and some port instead of an actual third-party host for the config |
| 14:22 |
phasefx |
well, if not using SSL, that is |
| 14:27 |
jeffdavis |
Is that what we want to do for automated testing? |
| 14:28 |
phasefx |
:-/ |
| 14:29 |
jeffdavis |
sorry, afaik we aren't doing anything like that so far, and I don't know enough about tests to know if I'm stepping into a minefield that way |
| 14:29 |
phasefx |
might be easier but more brittle |
| 14:29 |
tsbere |
I think the "Test" module is a good idea, overall, for testing things that would call out to third parties. Though setting up a general test service somewhere that said module could poke at might work too. |
| 14:29 |
tsbere |
At least you get better coverage of some of the code paths with the test module, right? |
| 14:31 |
phasefx |
you tie the test to the implementation with a module, but that's probably okay. But if you ever want to reimpliment, a black box test service could be useful |
| 14:34 |
jeffdavis |
This would have been a good thing to ask about if I were going to the hackaway :) |
| 14:35 |
* phasefx |
had never been in the habit of writing tests when he was more active with coding, so this is all thought exercise for him. "Grain of salt also advised :) |
| 14:38 |
jeffdavis |
all advice and suggestions are appreciated :) |
| 11:55 |
Dyrcona |
dans-datalogics: Sometimes, just quitting the client and starting it over again fixes that. |
| 11:55 |
|
Callender joined #evergreen |
| 11:55 |
dans-datalogics |
i'm also still a bit worried by the fact that almost all 2 GB of RAM on the server is taken. |
| 11:56 |
Dyrcona |
dans-datalogics: Yeah, 2GB is a bit slim, I prefer 4GB as a minimum or concerto data and 6-8 GB if I'm using production data on a test vm. |
| 11:57 |
dans-datalogics |
Dyrcona: ah, well i can bump it up to 4 then. the system requirements said only 1 GB was needed, so i figured 2 was safe. |
| 11:57 |
dans-datalogics |
also, restarting the client is now giving me a failed status check. i might chalk that up to the memory issue. |
| 11:57 |
Dyrcona |
dans-datalogics: Where are these system requirements? They should be changed, I think. |
| 11:58 |
|
brahmina joined #evergreen |
| 11:58 |
dans-datalogics |
http://docs.evergreen-ils.org/dev/_system_requirements.html |
| 11:58 |
|
Christineb joined #evergreen |
| 11:59 |
bshum |
Change is good. |
| 11:59 |
bshum |
Change is very good. |
| 12:00 |
|
barbara joined #evergreen |
| 12:03 |
* bshum |
feels like 4 GB of RAM is a good "test server" these days |
| 12:03 |
bshum |
And hey, probably at least 2 GB or more of RAM for a client workstation too. 512 MB? No...... |
| 12:04 |
* bshum |
drops the line for "XP, Vista, or 7" |
| 12:07 |
|
jihpringle joined #evergreen |
| 12:08 |
bshum |
Doc change pushed to master and backported to rel_2_11 and rel_2_10 (as the two most recent versions) |
| 12:09 |
bshum |
dans-datalogics++ # thanks for the pointer |
| 12:10 |
pinesol_green |
[evergreen|Ben Shum] Docs: Update base system requirements for Evergreen - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1b92116> |
| 12:17 |
bshum |
Maybe 2 GB is too conservative and I should have changed that to 4 GB too for clients. |
| 12:18 |
bshum |
https://wiki.evergreen-ils.org/doku.php?id=system_requirements is ancient too |
| 08:40 |
pinesol_green |
csharp: As great as you are man, you'll never be greater than yourself. |
| 08:42 |
gmcharlt |
quick heads up - part or all of Dyn.com's DNS services are experiencing a DDoS |
| 08:43 |
gmcharlt |
and this might effect resolution of evergreen-ils.org -- will be curious to know whether anybody is experiencing difficulties there |
| 08:43 |
tsbere |
gmcharlt: Quick test tells me that yes, I am experiencing difficulties there |
| 08:44 |
jeff |
resolves immediately for me. |
| 08:45 |
tsbere |
I don't think anyone here has requested the domain for a few days, thus making it so that our DNS server's cached entries expired |
| 08:45 |
jeff |
also immediate nxdomain as appropriate when requesting a non-existant host within the domain. |
| 08:49 |
|
bos20k joined #evergreen |
| 09:03 |
|
Dyrcona joined #evergreen |
| 09:10 |
Dyrcona |
So, SIPServer question.... With Socket::Linux installed, it looks like SIPServer gets a 2 minute timeout on idle TCP connections? |
| 09:12 |
jeff |
I can look and test, but: is there an additional question lurking in the shadows? |
| 09:14 |
tsbere |
Dyrcona: I think it might also depend on timeout values in the SIP config, but without knowing why you are asking... |
| 09:15 |
jeff |
Dyrcona: if you're basing the question off of the setsockopt() call that sets TCP_KEEPIDLE to 120 -- that's (i did have to look it up) " The time (in seconds) the connection needs to remain idle before TCP starts sending keepalive probes, if the socket option SO_KEEPALIVE has been set on this socket." |
| 09:15 |
Dyrcona |
jeff | tsbere: I think I misunderstood the TCP_KEEPIDL option. I now think that corresponds to tcp_keepalive_time, yes? |
| 09:59 |
tsbere |
Dyrcona: At that point I would be tempted to just add to the config file. Or make a local customization. |
| 09:59 |
gmcharlt |
Dyn is saying that they've mitigated the DDoS, by th eway |
| 10:00 |
Dyrcona |
Well, the quick thing is to make a local customization. New config options would be the way to go for a working/enhancement branch. |
| 10:00 |
tsbere |
gmcharlt: And, testing again, I can load things now. So yay! |
| 10:01 |
* Dyrcona |
wonders if the DDOS had to do with the SASL authentication failures... |
| 10:01 |
Dyrcona |
Or is that not to do with Freenode this time? |
| 10:02 |
tsbere |
DNS DDOS was causing issues with evergreen-ils.org for some percentage of the internet |
| 11:15 |
|
cgreen joined #evergreen |
| 11:21 |
|
dans-datalogics joined #evergreen |
| 11:30 |
|
jvwoolf joined #evergreen |
| 11:36 |
cgreen |
Hello, all -- we have an Ubuntu server running Evergreen and the database, and it's lately been acting flaky when one tries to log in or connect to Evergreen. "Re-test[ing] the server" on the web client sometimes takes ages to successfully verify; other times, the server returns a 500 Internal Server Error. We have noticed that it tends to use up quite a bit of memory on our server, even though we have met or exceeded the recommend |
| 11:36 |
cgreen |
It was working well for a week or so. Is there a configuration we may have incorrectly set? Any insight is appreciated, and thank you! |
| 11:37 |
|
Christineb joined #evergreen |
| 11:40 |
miker |
berick: for human use, it works close to that. it drops you into the authority list as close to the bib value as possible. your example should be usable. but, you're talking about machine matching, aren't you :) |
| 11:41 |
miker |
(and not blowing away $v Drama, as well, I suppose) |
| 12:31 |
berick |
gmcharlt: websockets + nginx -- did you encounter roadblocks there or was it more a case of missing tuits? |
| 12:32 |
gmcharlt |
berick: tuits - will be working on it next week as part of 2.5.0-beta, but certainly wouldn't mind if you want to try your hand at it |
| 12:32 |
berick |
Perry Mason and The Case of the Missing Tuits |
| 12:32 |
phasefx |
dans-datalogics: there are scripts that will install an EG test instance on, for example, Debian Wheezy, without all the manual steps |
| 12:32 |
berick |
gmcharlt: ok, good to know, thanks |
| 12:34 |
berick |
may have time to help on that soon |
| 12:39 |
dans-datalogics |
phasefx: i must've missed those. do they install opensrf as well? |
| 17:26 |
miker |
datetime... no :s |
| 17:26 |
berick |
miker: agreed. was just poking around there |
| 17:26 |
|
bmills joined #evergreen |
| 17:28 |
miker |
(my worry is the possibility of moving everything to the db. not because that's bad, but because the current code is so heavily tested) |
| 17:30 |
berick |
yeah, i'm right there with you |
| 17:33 |
miker |
or, just tell patrons that, yeah, you lose a day in the fall but you get it back in the spring! ;) |
| 17:33 |
|
finnx left #evergreen |
| 11:59 |
pinesol_green |
Launchpad bug 1373690 in Evergreen "Direct EDI generation for ACQ orders -- AKA kill ruby webrick" [Undecided,New] https://launchpad.net/bugs/1373690 - Assigned to Bill Erickson (berick) |
| 11:59 |
berick |
reminds me.. I should rebase that before the hackaway |
| 11:59 |
kmlussier |
berick: That's still out there? For some reason, I thought we had merged that one. :) |
| 11:59 |
* berick |
dons his rebasin' britches |
| 11:59 |
berick |
no, alas, it's a pretty big change. needs lots of eyes and testing. |
| 12:01 |
Dyrcona |
berick: This template? /openils/var/templates/acq/po/edi_messages.tt2 |
| 12:02 |
berick |
Dyrcona: action/trigger template ID 23 |
| 12:02 |
berick |
event_def, i mean |
| 12:06 |
Dyrcona |
But, I couldn't remember the branch. |
| 12:06 |
Dyrcona |
I should have just left the ruby alone. :) |
| 12:08 |
* Dyrcona |
searches for orders made since the webrick shutdown and start. |
| 12:08 |
* Dyrcona |
will be more than happy to test the above branch during the hackaway, once we work out how to test it. |
| 12:11 |
Dyrcona |
So, an Ingram order from 10:17 am shows the invoice id. |
| 12:12 |
Dyrcona |
An Ingram order from 11:41 hasn't been processed, yet. |
| 12:15 |
* Dyrcona |
starts to wonder if switching out the webrick didn't break it more. |
| 12:16 |
berick |
Dyrcona: aha, there's a test plan in the bug |
| 12:17 |
Dyrcona |
berick: OK. |
| 12:19 |
berick |
hm, looks like I need to copy the upgrade sql to the schema. i'll do that too.. |
| 12:36 |
csharp |
berick: I'm very interested in continuing testing/work on bug 1373690 at the hackaway |
| 12:36 |
pinesol_green |
Launchpad bug 1373690 in Evergreen "Direct EDI generation for ACQ orders -- AKA kill ruby webrick" [Undecided,New] https://launchpad.net/bugs/1373690 - Assigned to Bill Erickson (berick) |
| 12:37 |
csharp |
(if not before) |
| 12:47 |
|
jihpringle joined #evergreen |
| 11:32 |
|
bmills1 joined #evergreen |
| 11:32 |
|
bmills1 joined #evergreen |
| 12:08 |
|
sandbergja joined #evergreen |
| 12:10 |
berick |
wow. just realized I wrote a series of perl live tests based on data I thought came from concerto, but must have come from me. |
| 12:11 |
* berick |
adds to concerto |
| 12:11 |
jeff |
heh. |
| 12:15 |
|
brahmina joined #evergreen |
| 12:25 |
|
jvwoolf joined #evergreen |
| 15:12 |
* csharp |
agrees |
| 15:12 |
gmcharlt |
yup |
| 15:12 |
* abowling |
agrees, too |
| 15:13 |
gmcharlt |
next up - web client sprint 3 testing... is underway |
| 15:13 |
gmcharlt |
and finally, here I am, leading the September^W October development meeting |
| 15:13 |
gmcharlt |
so, I think that does it for action items |
| 15:13 |
kmlussier |
:) |
| 15:13 |
gmcharlt |
so, let's move on |
| 15:14 |
gmcharlt |
#topic OpenSRF release info |
| 15:24 |
gmcharlt |
so, on to maintenance releases |
| 15:25 |
gmcharlt |
miker: dbwells: y |
| 15:25 |
gmcharlt |
y'all are prepared to do a 2.11.1 later this month? |
| 15:25 |
miker |
I will be out of pocket on the normal date ... if I'm to be involved it'll need to slip a week |
| 15:26 |
miker |
which, really, isn't terrible -- there are several bug fixes to test and pull in, and .0 is not a brown bag |
| 15:26 |
dbwells |
I should be available to handle 2.11.1. |
| 15:26 |
dbwells |
If need be. |
| 15:27 |
dbwells |
10/19? |
| 16:01 |
dbwells |
gmcharlt++ |
| 16:02 |
kmlussier |
Bmagic++ |
| 16:02 |
Dyrcona |
gmcharlt++ |
| 16:02 |
* phasefx |
wants to throw out one thing post-meeting, live tester is showing some failed tests: http://testing.esilibrary.com/~live/ I can scrutinize later, but someone may get the itch sooner |
| 16:03 |
kmlussier |
phasefx: csharp had thoughts on the transit status failure yesterday afternoon. |
| 16:03 |
phasefx |
rock |
| 16:03 |
Dyrcona |
paper |
| 16:03 |
phasefx |
rock bug paper |
| 16:04 |
kmlussier |
Speaking of live tests, did we ever figure out why the results aren't posting to the channel anymore? Was it related to the RSS feed? |
| 16:04 |
jeff |
I think it was something along those lines. I can volunteer to look into it again. |
| 16:04 |
gmcharlt |
dbs: your key is in place now - sorry abou the delay |
| 16:05 |
dbs |
gmcharlt++ |
| 16:05 |
jeff |
I think it came down to supybot not thinking that the new test results were new. |
| 16:05 |
dbs |
thank you |
| 16:05 |
Dyrcona |
I meant to fix that one Perl test some time ago, but new job got me sidetracked. |
| 16:20 |
kmlussier |
@quote random |
| 16:20 |
pinesol_green |
kmlussier: Quote #159: "< jeff> Oh honey, he's teasing you. Nobody has two library card numbers." (added by csharp at 10:09 AM, August 25, 2016) |
| 16:21 |
kmlussier |
I think I was on vacation for that one. |
| 09:56 |
|
Dyrcona joined #evergreen |
| 09:57 |
Dyrcona |
And now, I remember one of the reasons that I always used to use a separate partiton for /home.... |
| 09:59 |
Dyrcona |
You can't safely fsck a mounted volume, and you can't unmount / if you want to run fsck, so I need to make a recovery disk. |
| 10:00 |
Dyrcona |
I ain't got time for that, so at the risk of having corrupted files, I continue with testing my 2.9.5 to 2.10.7 upgrade. |
| 10:28 |
StomproJ |
Ahhhahh, my memcache server is hitting a openvz tcprcvbuf limit, causing connections to fail. |
| 10:31 |
* Dyrcona |
uses kvm, so wouldn't know about that. :P |
| 10:34 |
StomproJ |
Proxmox has moved away from openvz, so I won't use it in the future either. |
| 13:32 |
* Dyrcona |
drives his wife nuts. :) |
| 13:33 |
Dyrcona |
NCIP isn't a standard so much as it a smorgasboard of options. That's why "profiles" exist, though NCIPServer was not written to target any specific profile. |
| 13:34 |
Dyrcona |
I was given some documentation and "sample" messages. |
| 13:34 |
Dyrcona |
Spent several months coding, then got it to actually work with the vendor once testing starting. |
| 13:35 |
Dyrcona |
Changes have accrued while it is in production and real things happen. |
| 13:35 |
|
ssieb joined #evergreen |
| 13:35 |
* kmlussier |
feels sympathy for Dyrcona's wife. |
| 14:05 |
|
Christineb joined #evergreen |
| 14:21 |
Dyrcona |
Can someone see what's wrong with this: [% date.format(helpers.format_date(circ.due_date), '%A, %B %d, %Y') %] |
| 14:21 |
Dyrcona |
I put that in a template and it is erroring out with invalid date format, but that looks correct to me. |
| 14:22 |
Dyrcona |
I don't have a quick way to test it, unfortunately. |
| 14:27 |
berick |
Dyrcona: see if circ.due_date is null |
| 14:27 |
dbs |
is it an invalid input date perhaps? |
| 14:28 |
Dyrcona |
In every single courtesy notice for the past week? |
| 14:35 |
bshum |
pinesol_green is wise to keep its opinion to itself... |
| 14:35 |
pinesol_green |
bshum: I am only a bot, please don't think I'm intelligent :) |
| 14:35 |
pinesol_green |
bshum: Down time is a fact of business when you're a poor 501c3 corporation. |
| 14:38 |
* Dyrcona |
pines for a test environment. |
| 14:39 |
* jeff |
uses PINES for a test environment |
| 14:39 |
Dyrcona |
:) |
| 14:39 |
jeff |
(not really, but i couldn't let that pun opportunity go to waste) |
| 14:46 |
* jeff |
sends out a few emails in an attempt to gather iNCIPit forks |
| 15:37 |
csharp |
@karma karma karma karma karma chameleon |
| 15:37 |
pinesol_green |
csharp: karma karma karma chameleon has neutral karma. |
| 15:38 |
berick |
chameleon++ |
| 15:40 |
csharp |
@who is using PINES as a test environment? |
| 15:40 |
pinesol_green |
Stompro is using PINES as a test environment. |
| 15:40 |
miker |
whew! I thought pinesol was about to rat me out... |
| 15:41 |
miker |
CRAP ... I said the quiet part loud again |
| 15:41 |
kmlussier |
@blame miker |
| 15:41 |
pinesol_green |
kmlussier: miker stole bradl's tux doll! |
| 15:41 |
csharp |
@blame inner monologues |
| 15:41 |
pinesol_green |
csharp: inner monologues musta been an Apple employee. |
| 15:41 |
berick |
wait, we're not supposed to be using PINES as a test environment? |
| 15:42 |
miker |
berick: define "supposed" .... |
| 15:42 |
miker |
also, define "test" |
| 15:42 |
berick |
hah |
| 16:13 |
Bmagic |
csharp: was it you who used the TTP-247 barcode printers for replacing barcodes during migration? |
| 16:19 |
|
jvwoolf joined #evergreen |
| 16:52 |
kmlussier |
We're getting some test failures on the purge-user-activity tests. http://testing.evergreen-ils.org/~live/test.html |
| 16:53 |
kmlussier |
And on the abort transity copy status live test. |
| 16:53 |
* kmlussier |
misses the twice daily test results that used to post in channel. |
| 16:57 |
csharp |
Bmagic: nope, not me |
| 16:57 |
Bmagic |
cool, no biggie |
| 17:01 |
csharp |
kmlussier: I see what's happening with the perl test - it's expecting the copy status to be "Reshelving" after transit abort and it's now "Canceled Transit" |
| 17:01 |
|
mmorgan joined #evergreen |
| 17:03 |
kmlussier |
csharp: Ah, ok. So is that the one Dyrcona did for his fix before your new feature went in? |
| 17:03 |
csharp |
right |
| 17:31 |
csharp |
Bmagic: the first example's supposed to happen - the transit stores the status it was in when it went into transit so it can resume that status when it gets to its destination |
| 17:32 |
csharp |
and the second problem can have multiple causes, including "checkout fills related hold"-type stuff (probably the most common) |
| 17:32 |
Bmagic |
csharp: right, I understand that part. Missing items are being reported as being on the pull list. Would the hold targeter target missing items? Perhaps it wasn't missing when the targeter ran? |
| 17:32 |
csharp |
oh - yeah, it shouldn't target missing copies |
| 17:33 |
csharp |
auditor.asset_copy_history might help know what happened |
| 17:36 |
csharp |
dbs: are you still managing buildbot/testing.evergreen-ils.org? |
| 17:36 |
* csharp |
would like to create a few new builders on mundungus |
| 17:40 |
dbs |
csharp: I might still be able to! |
| 17:41 |
dbs |
Trying to prep for a hands-on Angular 2 session that I'm supposed to be leading in 1.25 hours atm though |
| 17:41 |
csharp |
dbs: no prob - it will take a while to set up the VMs anyway |
| 17:41 |
csharp |
thanks! |
| 17:41 |
dbs |
Really should have carved out some time before... |
| 17:42 |
dbs |
Looks like my ssh key might have gone dead on testing.evergreen-ils.org |
| 17:43 |
csharp |
ok, I'll see if phasefx_ or miker or someone can get me going |
| 17:57 |
dbs |
gmcharlt used to be my partner in crime for testing.evergreen-ils.org |
| 17:58 |
|
jvwoolf left #evergreen |
| 18:03 |
gmcharlt |
dbs: send me the current one(s) and I'll get you set up again |
| 18:03 |
* gmcharlt |
goes poof, braves Atlanta traffic |
| 08:23 |
jeff |
dbs: regarding your conversation with Apache this morning: is the server_status count showing requests and not connections, while MaxConnectionsPerChild is counting connections not requests? |
| 08:26 |
jeff |
(where one connection may serve up to MaxKeepAliveRequests requests) |
| 08:27 |
* jeff |
starts to wonder if he's running a config different from that which is on disk. short of hijacking a configured perl handler with code that would attempt to read config settings, i'm not sure if there's a way to check that. |
| 08:51 |
StomproJosh |
csharp, re bug 1616220 - There are a bunch of dojo related warnings that my fix doesn't touch. So it doesn't get rid of all the warnings, just reduces the number of them. I can provide some specific examples to make testing easier. |
| 08:51 |
pinesol_green |
Launchpad bug 1616220 in Evergreen "XUL Staff Client CSS Fixes" [Undecided,New] https://launchpad.net/bugs/1616220 |
| 09:02 |
|
bos20k joined #evergreen |
| 09:07 |
|
mmorgan joined #evergreen |
| 09:27 |
dbs |
but the server_status display shows an "Acc" column of 0/85/1186 and I was interpreting the "85" as # requests (per the legend at the bottom "Acc: Number of accesses this connection / this child / this slot") |
| 09:28 |
dbs |
But yeah, maybe I was interpreting it wrong, and now that I'm dropped KeepAlive to 2 from 5 there are more connections turning over |
| 09:28 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1623955: Keep periods in subject links - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f4c7efc> |
| 09:32 |
csharp |
Stompro: thanks - I'll re-test with your new info when you post them :-) |
| 09:33 |
csharp |
Stompro: re: staff initials, at least one of our libraries uses patron stat cats for that |
| 09:36 |
Stompro |
csharp, thanks for the staff initials info. |
| 09:42 |
JBoyer |
Stompro, csharp, I was going to say, initials for patron reg wasn't ringing any bells for me, but csharp's stat cat idea is a good one. I'd poll your members and see if it's worth making a consortium wide stat cat rather than trying to talk a lot of libs through it through it. |
| 09:44 |
|
kmlussier joined #evergreen |
| 08:01 |
|
collum joined #evergreen |
| 08:07 |
|
tspindler joined #evergreen |
| 08:30 |
|
remingtron joined #evergreen |
| 08:31 |
csharp |
hmm, I'm trying to generate the log warnings for bug 1624491, but I'm not able to and I'm not seeing the prox_cache uninitialization warnings on PINES production or test servers :-/ |
| 08:32 |
pinesol_green |
csharp: Error: Could not gather data from Launchpad for bug #1624491 (https://launchpad.net/bugs/1624491). The error has been logged |
| 08:32 |
csharp |
pinesol_green: why not? |
| 08:32 |
pinesol_green |
Factoid 'why not?' not found |
| 09:57 |
jeff |
we're running with... 0? that's surprising to me. |
| 09:58 |
dbs |
The only two modules that I can think of that we run that most sites probably don't run are open-ils.resolver and open-ils.auth_proxy |
| 10:00 |
dbs |
Not sure if there's an easy way to figure out where a memory leak is occurring in apache with a bunch of c and perl mods |
| 10:00 |
jeff |
in test systems earlier this year, i could trigger high memory utilization in apache children. setting MaxConnectionsPerChild seemed to be a solid workaround, and i did have to set it pretty low. |
| 10:01 |
dbs |
jeff: interesting - but you don't need that workaround any more? |
| 10:01 |
jeff |
i'd have to look at notes, but first thing i'd try would be comparing things handled by EGCatLoader with something like static files. |
| 10:02 |
|
jlundgren joined #evergreen |
| 10:36 |
jeff |
if nothing else, in the interest of improving logging / error handling / avoiding this myself. ;-) |
| 10:36 |
Dyrcona |
If I use a barcode from a copy other than the ones I added, I get a response in less than 1 second. I think I'm missing something in the database. |
| 10:37 |
jeff |
yeah. |
| 10:37 |
Dyrcona |
jeff: I can paste it. I was thinking of adding these to concerto for testing purposes in the future. |
| 10:37 |
Dyrcona |
I'll bet there is some setting not switched on in concerto that I'm used to having on and that's my issue. |
| 10:38 |
dbs |
Dyrcona: any chance the bib / volume / copy ingest triggers are failing or aren't running? |
| 10:38 |
jeff |
ideally data that postgres allows you to insert wouldn't cause SIP to fail like that, but maybe the marcxml or something is to blame. |
| 10:42 |
Dyrcona |
Yes. |
| 10:42 |
Dyrcona |
Since I discovered that SIPServer won't start on Ubuntu 16.04, I'm going to move on to a branch for that and then come back to this after that. |
| 10:42 |
jeff |
isn't this expected to fail on recent Encode.pm? |
| 10:43 |
Dyrcona |
jeff: Yes. That was what I was testing, but this is not a recent Encode AFAIK. |
| 10:43 |
jeff |
ah. |
| 10:43 |
Dyrcona |
It failed on 16.04, and I'm testing 14.04 for duplication, etc. |
| 10:44 |
jeff |
my guess right now is that you're running into the bug where sipserver doesn't properly flush the buffer on the socket. |
| 10:44 |
jeff |
because it's not counting bytes. |
| 10:44 |
Dyrcona |
Encode is 2.49... |
| 10:51 |
dbs |
coffee++ |
| 10:51 |
|
Christineb joined #evergreen |
| 10:52 |
csharp |
NOBLE++ |
| 10:55 |
Dyrcona |
I'm going to test and push Bmagic's branch on Lp 1613326. (I think I promised to do that last month, and never found my tuit.) |
| 10:55 |
pinesol_green |
Launchpad bug 1613326 in SIPServer "SIPServer UNIVERSAL removed" [Undecided,New] https://launchpad.net/bugs/1613326 |
| 10:56 |
berick |
noble++ kmlussier++ |
| 10:56 |
jeff |
Dyrcona: pretty sure user/jeff/fix_universal_can will fix your "I want to fix the UNIVERSAL does not export anything message on Ubuntu 16.04" issue |
| 11:08 |
Dyrcona |
I'll add Bmagic's bug number and give him some credit in commit message. How's that? |
| 11:08 |
jeff |
i'll push a new branch with a reasonable commit message and comment on the bug. |
| 11:10 |
Dyrcona |
OK. I'll wait. |
| 11:13 |
Dyrcona |
dbs | jeff: I'm convinced my solution to the Encode issues is not optimal. I haven't even really tested it yet, either. |
| 11:23 |
|
brahmina joined #evergreen |
| 11:29 |
Dyrcona |
jeff++ |
| 11:29 |
Bmagic |
jeff++ |
| 12:19 |
Dyrcona |
Y'know. I may just try putting clean_text() on autoload Item fields and see what that does. |
| 12:20 |
Dyrcona |
But first, I'll finish lunch. |
| 12:20 |
jeff |
title/author with mangled characters were the most common trigger for us. i think that's due to a different issue in how MODS transforms are being done. |
| 12:25 |
terran |
Bug Squashing Day Update: 6 patches have been tested & signed off on, and 3 new patches have been submitted! |
| 12:34 |
jeff |
Dyrcona: bug 1628995 |
| 12:34 |
pinesol_green |
Launchpad bug 1628995 in SIPServer "SIPServer can incorrectly calculate output message length, which can lead to clients hanging" [Medium,New] https://launchpad.net/bugs/1628995 - Assigned to Jeff Godin (jgodin) |
| 12:37 |
dbs |
jeff++ # different fun with encodings (bytes vs. length), heh |
| 12:54 |
* Dyrcona |
adds use bytes; before POSIX::write to see if that makes a difference. |
| 12:55 |
Dyrcona |
Bingo! We have a winner! |
| 12:56 |
Dyrcona |
pysip2 doesn't choke on the multi-byte call number. |
| 12:56 |
csharp |
@blame testing the wrong git branch |
| 12:56 |
pinesol_green |
csharp: testing the wrong git branch WILL PERISH UNDER MAXIMUM DELETION! DELETE. DELETE. DELETE! |
| 12:58 |
Dyrcona |
I'm inclined to fix the length calculation as its own bug and not mix it up with the Encode changes. |
| 12:58 |
jeff |
i don't know that that's the best / long term fix, but i'll amend my commit message and push that branch. we've been using it in production for a while. |
| 12:59 |
Dyrcona |
Where'd you put the use bytes; out of curiosity. |
| 12:59 |
Dyrcona |
? |
| 13:06 |
dbs |
makes sense to keep it locally scoped to the length() call, to avoid having any other side effects |
| 13:07 |
* dbs |
greps to see 15 length() calls to audit to see whether use bytes would be warranted or not |
| 13:07 |
Dyrcona |
yeah, in my test, I did the same. |
| 13:09 |
dbs |
+1 to fixing this one little bug first |
| 13:10 |
* miker |
thinks `require bytes; ... bytes::length()` may be better? |
| 13:10 |
Dyrcona |
miker: It may be better. |
| 13:23 |
Dyrcona |
lines 95, and maybe 179 and 199 |
| 13:24 |
Dyrcona |
I misspoke about SIPServer.pm abov. |
| 13:24 |
Dyrcona |
above. |
| 13:29 |
abowling |
i've tackled this before, but i've slept and forgotten. trying to get a test server up and running to get rid of these darned bugs, and getting: /usr/bin/ld: cannot find -ldbdpgsql |
| 13:29 |
abowling |
anyone have any suggestions/memories? |
| 13:29 |
abowling |
i have installed 9.3 |
| 13:36 |
berick |
abowling: what's the output of: cat /etc/ld.so.conf.d/evergreen.ld.conf |
| 13:39 |
abowling |
berick: might be part of my probelm |
| 13:39 |
abowling |
cat: /etc/ld.so.conf.d/evergreen.ld.conf: No such file or directory |
| 13:40 |
jeff |
miker, others: opinions on "require bytes" being in the same lexical scope as the POSIX::write / bytes::length call? I'm tempted to put it in the Sip package itself, since 1) "require bytes" shouldn't have any side effects and 2) there is a slight possibility we may find other calls to length() that should be bytes::length() before we're done. |
| 13:40 |
abowling |
berick: root evergreen-2-10-6-test:/etc/ld.so.conf.d# cat /etc/ld.so.conf.d/eg.conf |
| 13:40 |
abowling |
/usr/local/lib/dbd |
| 13:41 |
berick |
abowling: is there stuff in /usr/local/lib/dbd/ ? |
| 13:42 |
abowling |
berick: there is, but nothing for psql |
| 13:42 |
berick |
k, you should see libdbdpgsql.so |
| 14:34 |
pinesol_green |
Launchpad bug 1482757 in Evergreen "Loading records with located URIs should not delete and recreate call_numbers" [Undecided,Confirmed] https://launchpad.net/bugs/1482757 |
| 14:38 |
miker |
Dyrcona: mess away |
| 14:39 |
Dyrcona |
miker: Will do, as bug manager. |
| 15:04 |
mmorgan |
dbwells: I'm testing lp 1422379 and see mention of a less onerous upgrade script than originally proposed https://bugs.launchpad.net/evergreen/+bug/1422379/comments/13 |
| 15:04 |
pinesol_green |
Launchpad bug 1422379 in Evergreen "Move money.billing timestamps back to moment of fine" [Medium,Triaged] - Assigned to Michele Morgan (mmorgan) |
| 15:05 |
mmorgan |
, but don't see the alternate upgrade script, but agree that it sounds much less onerous. |
| 15:06 |
kmlussier |
@praise bug squashers |
| 15:06 |
* pinesol_green |
bug squashers goes to eleven |
| 15:06 |
kmlussier |
Bad grammar. |
| 15:06 |
mmorgan |
I've done a lot of testing, generating a lot of fines for hourly as well as daily loan periods and finesk and it looks good so far. |
| 15:08 |
mmorgan |
Did I really say that??? Been a long day... |
| 15:11 |
|
ethomsen joined #evergreen |
| 15:22 |
jeff |
mmorgan: were you able to do any testing on a system with billings dating back a long ways, to Evergreen 1.2.x.x and such? |
| 15:23 |
mmorgan |
jeff: no, I don't have access to such a system. |
| 15:24 |
mmorgan |
Is the only concern there the upgrade script for such systems? |
| 15:26 |
jeff |
i wouldn't say it's my *only* concern, no. :-) |
| 16:50 |
|
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 |
| 17:01 |
terran |
Dyrcona: Yes, I counted the bugmaster changes that I saw |
| 17:01 |
|
jvwoolf left #evergreen |
| 17:09 |
dbwells |
mmorgan: Thanks for testing that branch! I pushed a rebased version with the reworked upgrade script just now: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbwells/lp1422379_move_billing_timestamps_rebase_v3 |
| 17:16 |
abowling |
berick++ |
| 17:16 |
abowling |
berick: you led me down the trail. the fix is this: cp -R /usr/lib/i386-linux-gnu/* /usr/lib/x86_64-linux-gnu/ |
| 17:16 |
abowling |
after that, make runs fine |
| 07:38 |
pinesol_green |
csharp: [evergreen|Dan Scott] Support Apache 2.4 configuration directives - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d4f6bf8> |
| 07:39 |
csharp |
375054cf |
| 07:39 |
pinesol_green |
csharp: [evergreen|Bill Erickson] Collections user balance API / batch file output - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=375054c> |
| 08:05 |
csharp |
okay, so I just now learned about the collections batch file feature that's been around for years, and I'm looking to enable it. If I browse to /collections/, I'm prompted to log in and I get a 404, but if I create a test file and browse to it it works. Is that the expected behavior, that the file works but the directory doesn't? |
| 08:15 |
|
kmlussier joined #evergreen |
| 08:18 |
* kmlussier |
yawns |
| 08:18 |
kmlussier |
@coffee [someone] |
| 10:09 |
Dyrcona |
rhamby is safe, then. :) |
| 10:09 |
* Dyrcona |
is readying his xenial VM for bug squashing day tomorrow. |
| 10:10 |
rhamby |
:) |
| 10:10 |
* Dyrcona |
believe he will test his new and improved SIP branch. |
| 10:11 |
Dyrcona |
jeff: Do you mind if I start working on a branch to remove clean_text from the Evergreen sip code? |
| 10:12 |
jeff |
if you have lots of free time go for it. i'll take it off my list for today. |
| 10:12 |
jeff |
and i'll be happy to test. |
| 10:13 |
jeff |
or counter, if i'm feeling particularly opinionated. |
| 10:13 |
Dyrcona |
I'll see if I can get to it today.. :) |
| 10:14 |
Dyrcona |
First, I want to make sure that the SIPServer changes don't hose a more-or-less stock master installation. |
| 10:14 |
Dyrcona |
But, so I can test removing clean_text, I'll at least start a branch today. |
| 10:23 |
|
TARA joined #evergreen |
| 11:52 |
|
bmills joined #evergreen |
| 12:11 |
|
bos20k joined #evergreen |
| 12:41 |
* Dyrcona |
checks |
| 12:43 |
Dyrcona |
Nope. |
| 12:44 |
Dyrcona |
Once I set that up, maybe I'll make a Lp bug to have it added to the seed data for concerto. |
| 12:46 |
dbs |
Dyrcona: it doesn't look like there are any users with non-ASCII characters in their names or other data, either. |
| 12:46 |
dbs |
which would be really helpful for testing |
| 12:47 |
Dyrcona |
dbs: Yeah, I was going to look into that, too. I can get some records to load if need be. |
| 12:47 |
Dyrcona |
I think I still have a small file of vietnamese records hanging around somewhere. |
| 12:48 |
dbs |
yep, /[^\d0-\d127] says no match |
| 14:41 |
* JBoyer |
is also distracted by other projects, so isn't really checking the EI db.. |
| 15:03 |
mmorgan |
DPearl: kmlussier: Looks like this can happen when transferring volumes as described in lp 1411422 |
| 15:03 |
pinesol_green |
Launchpad bug 1411422 in Evergreen 2.10 "Copy details repeated in search results when item/volume moved with parts attached" [Medium,Confirmed] https://launchpad.net/bugs/1411422 |
| 15:04 |
kmlussier |
mmorgan: I tried transferring volumes on a test system, but I didn't see the problem occur. |
| 15:05 |
* mmorgan |
didn't try and reproduce, but remembered it being a problem in the past. |
| 15:12 |
kmlussier |
Speaking of that bug, Bmagic_ did you see my comments on bug 1411422 regarding old parts being left behind and the possibility of a regression test? |
| 15:12 |
pinesol_green |
Launchpad bug 1411422 in Evergreen 2.10 "Copy details repeated in search results when item/volume moved with parts attached" [Medium,Confirmed] https://launchpad.net/bugs/1411422 |
| 15:12 |
* kmlussier |
would love to see that bug fix merged. |
| 15:38 |
Dyrcona |
So, I just inserted some copies with SQL and a SIP2 request for item info times out. |
| 15:44 |
|
Bmagic joined #evergreen |
| 15:44 |
Dyrcona |
So, if we had upgraded to Jessie, instead of crashing the vendor's software, these records would crash ours. :( |
| 15:45 |
dbs |
We're on Ubuntu 14.04, fwiw |
| 15:46 |
Dyrcona |
We're on Squeeze in production and I'm testing on Ubuntu 16.04. |
| 15:46 |
Dyrcona |
Ubuntu 14.04 does not exhibit this problem. |
| 15:47 |
Dyrcona |
Well, Perl < 5.20 doesn't exhibit this problem. |
| 15:49 |
jeff |
by nature of including the affected version of Encode.pm |
| 16:02 |
StomproJosh |
jeff, I'm going to start a bug on stacking/multiple AT validators. I've wondered a few times about not being able to have several validators. It would be nice to always include a UsrHasEmail validator for an email notice, along with any others. |
| 16:02 |
dbs |
my hypothesis for the reason that i needed to remove clean_text() for item info was that supercat started encoding the incoming data properly |
| 16:03 |
Dyrcona |
dbs: Could be. Looks like Supercat and SIP are the only modules that call decode_utf8 |
| 16:04 |
Dyrcona |
Wel, I'll remove clean_text() (should be easy) test SIP, and then see what happens with Supercat look ups of these two records I have that break SIP. |
| 16:04 |
dbs |
so if you try to decode it twice now, boom, whereas before decode_utf8() was safe to call multiple times on the same data |
| 16:05 |
jeff |
supercat and/or unapi exhibit other non-crashy encoding issues. |
| 16:05 |
Dyrcona |
Well, I find it breaks on utf-8 data, period. |
| 12:22 |
* kmlussier |
will also recheck the page one last time to make sure I didn't miss any other glaring errors. |
| 12:23 |
csharp |
berick: cstore does see the call |
| 12:23 |
csharp |
which is 405466 bytes |
| 12:23 |
berick |
csharp: ok.. so maybe tsbere is on to something. it's easy to test that one.. sec |
| 12:23 |
csharp |
ok |
| 12:25 |
berick |
csharp: mind seeing what happens if you add this line (and restart trigger) -- maybe on a dev server if possible |
| 12:25 |
berick |
https://gist.github.com/berick/f4e1ac051ac8860faaf72816d867b460 |
| 12:27 |
berick |
yeah, exactly |
| 12:29 |
|
mmorgan1 joined #evergreen |
| 12:36 |
* berick |
steps away for a bit |
| 13:02 |
csharp |
ugh - now I'm in a rabbit hole of trying to get logging working properly on my acq testing server :-/ |
| 13:11 |
|
sandbergja joined #evergreen |
| 13:17 |
* tsbere |
dislikes finding 42 bib records with a bad type character |
| 13:18 |
tsbere |
If anyone wants the query I used to *find* said bib records I am willing to share |
| 13:20 |
|
rlefaive joined #evergreen |
| 13:29 |
dbwells |
kmlussier: Took me a second, but I see the heading you are talking about now. Sure, I can regenerate/repost them when ready. |
| 13:31 |
kmlussier |
dbwells: Thanks! I've also caught a few typos that I missed on previous proofreading. Making the changes now. |
| 13:36 |
csharp |
berick: same behavior after that change |
| 13:38 |
csharp |
I was hopeful when a PO on our test server with 212 items printed, but the 313-long one that triggered the helpdesk ticket is still timing out |
| 13:39 |
berick |
csharp: ok, mind trying one more thing? |
| 13:39 |
csharp |
sure |
| 13:39 |
kmlussier |
Do we have a 2.11 release branch yet? |
| 15:15 |
dbs |
csharp berick: thank you for doing this work, it seems very very similar to what we're seeing (albeit more with checkins than triggers) |
| 15:16 |
dbs |
because it seems superweird for a simple checkin to time out in the database |
| 15:17 |
* dbs |
was wondering if networking issues (like ipv6 routing madness from years past?) might also be playing a role |
| 15:17 |
kmlussier |
Bmagic: I'm unable to test the web client to see if I can replicate it, but there was a recent small fix to the patron search form that might be a starting point for your investigation. |
| 15:17 |
kmlussier |
ee711968 |
| 15:17 |
pinesol_green |
kmlussier: [evergreen|Galen Charlton] LP#1436987: webstaff - fix patron search form - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ee71196> |
| 15:17 |
Bmagic |
thanks! |
| 15:21 |
Dyrcona |
csharp: That would indicate that the call to create the trigger in the database failed. |
| 15:21 |
Dyrcona |
Or timed out along the way, which you already know. :( |
| 15:22 |
Dyrcona |
Well, the event output, rather. |
| 15:22 |
berick |
dbs: well, this one is a problem with the size of the data, a blob of text way larger than any normal processing (unless you're bib records are .3 Megabytes in size) |
| 15:22 |
pinesol_green |
[evergreen|Dan Scott] Add a simple Item Information test for SIP server - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9dd9dca> |
| 15:29 |
csharp |
Dyrcona: stock as of 2.9.2 |
| 15:29 |
berick |
csharp: still on ubuntu 14.04? |
| 15:29 |
csharp |
berick: yep |
| 15:35 |
* Dyrcona |
hands out BLOBs. |
| 15:36 |
Bmagic |
kmlussier: phew - it turned out to be some sort of browser caching issue - opened incognito and violla |
| 15:36 |
kmlussier |
Bmagic: Glad to hear it! |
| 15:38 |
csharp |
I'm going to have to stop working on this until I get my test server updated - I'm monkeying around too much on the prod servers :-/ |
| 15:40 |
Dyrcona |
@bartender |
| 15:40 |
* pinesol_green |
fills a pint glass with Cantillon Saint Lamvinus, and sends it sliding down the bar to Dyrcona (http://beeradvocate.com/beer/profile/388/8954) |
| 15:43 |
|
maryj joined #evergreen |
| 10:46 |
dbs |
current status: what the hell happened to take our nice "running with 5GB of free RAM for a full day" into an OOM situation just a few hours later in the middle of the night |
| 10:53 |
Dyrcona |
A bot? A book on an enter key? A ridiculous search query? |
| 11:04 |
Dyrcona |
JBoyer: This looks like the list of services required for SIP on a 2.9 installation: http://pastebin.com/MmVxGC9j |
| 11:04 |
Dyrcona |
NOTE: I have not tested that on a VM or anything, so something might be missing. |
| 11:05 |
Dyrcona |
That just looks like the things that could actually get used by the calls that the SIP driver makes. |
| 11:06 |
JBoyer |
Dyrcona, I'm running on tuit fumes currently, but I've got a couple places I could test that out eventually. I'll admit trigger is a surprise, but I realize there are the occasional interdependencies that aren't always clear. |
| 11:07 |
Dyrcona |
JBoyer: Well, circ could end up making a call to trigger. It probably won't but it wasn't totally clear. |
| 11:08 |
JBoyer |
Ah, that makes sense for some of the active events. |
| 11:09 |
Dyrcona |
I also could have spent more time on it. :) |
| 11:51 |
dbs |
the Apache drones and their 150M of memory per process :/ |
| 11:52 |
Dyrcona |
miker: I can always take a look when I get the chance, which has not been very often lately. |
| 11:53 |
* dbs |
was tempted to start working with nginx or a similar caching proxy again to try and offload some of that weight, but also doesn't want to add another layer of complexity |
| 11:53 |
Dyrcona |
I've also had a hard time reproducing this myself on a test environment. |
| 11:53 |
dbs |
miker: ah that's what I was thinking of, didn't realize it hadn't been merged yet |
| 11:54 |
miker |
in particular, a pile-up occurs when we get a spew of requests that take a long time to process. the apache backends wait for the opensrf request to finish, even if the client side has gone away. the branch attempts avoid that wait, by checking at 1s intervals for client connectedness when it's inside modperl |
| 11:54 |
miker |
dbs: well, we have had same-search guards for a long time ... 2.5, maybe? ... but that only saves the middle layer and the db |
| 16:58 |
Dyrcona |
A new feature might be to add a command in the staff client to recalculate penalties. |
| 16:58 |
phasefx |
the Refresh button triggers the api call for refreshing penalties |
| 16:59 |
phasefx |
checking something in or out should also do it |
| 17:01 |
mmorgan |
Hmm. On production system, 2.9, penalties are recalculating when I refresh. |
| 17:01 |
mmorgan |
On 2.10.5 test system, penalties don't recalculate when I refresh. |
| 17:01 |
phasefx |
mmorgan: are the org depths the same on the penalty definitions? |
| 17:02 |
phasefx |
between systems |
| 17:02 |
Dyrcona |
And all this time I thought that Refresh only retrieved the patron information again. |
| 17:02 |
phasefx |
wasn't really joking when I suggested org units :) |
| 17:04 |
mmorgan |
So on production system, PATRON_EXCEEDS_FINES has null org_depth |
| 17:04 |
mmorgan |
test system has 0 |
| 17:04 |
phasefx |
what I don't have a good handle on is the behavior with org depths, I just remember they can cause problems |
| 17:04 |
mmorgan |
but it's a consortium wide penalty |
| 17:05 |
* mmorgan |
guesses this won't get solved today will revisit on Monday;-) |
| 17:05 |
phasefx |
mmorgan: I bet if you make it null on the test system it'll work |
| 17:05 |
mmorgan |
Will try that next, but have to run. Have a good weekend, all! |
| 17:05 |
|
mmorgan left #evergreen |
| 17:20 |
|
Stompro joined #evergreen |
| 11:22 |
|
maryj joined #evergreen |
| 11:26 |
Stompro |
Thanks all for the damaged item nfo. Now that I think about it more it is probably a bad idea to combine them, they are two seperate situations that get treated differently in our state law. If we notify about damaged items we will send a seperate notice. |
| 11:35 |
* Dyrcona |
wonders at the usefulness of an interface to undelete patrons. I guess it would only work here because the client doesn't do the obliteration dance on delete for ... reasons. |
| 11:42 |
* kmlussier |
updates the MassLNC community demo server to 2.10.6 early because she had to test something on 2.10 anyway. |
| 11:42 |
kmlussier |
For now, then, we're going to have 2 community demo servers on the same major release. |
| 11:46 |
|
bmills joined #evergreen |
| 12:00 |
Dyrcona |
"hello, headache, my old friend...I feel you've come to me again." |
| 12:00 |
Dyrcona |
"it's just the pain of sinus..." |
| 14:10 |
pinesol_green |
csharp: [evergreen|Bill Erickson] LP#1464709 Rename checkout_ok to is_available - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2c40b84> |
| 14:15 |
Bmagic |
miker: sorry for the delay - The SIP server is working as expected on 2.11rc |
| 14:16 |
Bmagic |
my copy of production database was 2.9.1 and that did not work |
| 14:16 |
miker |
Bmagic: sweet, thanks for testing! |
| 14:16 |
miker |
oh? how did it break? |
| 14:16 |
Bmagic |
I had to raise the db to 2.11rc (to match the Evergreen code) - auth errors otherwise - db functions missing |
| 14:17 |
Bmagic |
I didn't try the SIPServer against 2.9.1 evergreen |
| 14:17 |
miker |
oh, the db was 2.9.1 but the evergreen code was 2.11 |
| 14:17 |
Bmagic |
right |
| 14:17 |
Bmagic |
I suppose the SIPServer will work against older Evergreen installs? |
| 14:18 |
miker |
it should |
| 14:18 |
Bmagic |
I think I can test that as well if needs be |
| 14:18 |
miker |
old drivers should ignore the new parameter |
| 14:18 |
miker |
JBoyer: did you test the new sip stuff (passing a workstation) against old evergreen that doesn't expect to receive that? |
| 14:21 |
rjackson_isl |
miker: the boss is off to one of his many meetings currently so he will get back to you! |
| 14:21 |
miker |
rjackson_isl: heh, thanks :) |
| 14:27 |
|
yboston_ joined #evergreen |
| 14:28 |
miker |
right, that's my reading too |
| 14:29 |
* tsbere |
glares at the glare on his screen as well as the ineffective blinds that are full of intentional holes |
| 14:29 |
|
maryj joined #evergreen |
| 14:31 |
csharp |
kmlussier: I just pushed a probable fix to bug 1624025 to http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/csharp/lp1624025_copy_status_missing_field - are you able to easily test it? I'm not in a place at the moment where I can test it on my own server |
| 14:31 |
pinesol_green |
Launchpad bug 1624025 in Evergreen "Hold targeting weirdness in 2.11" [High,New] https://launchpad.net/bugs/1624025 |
| 14:33 |
kmlussier |
csharp: Yes, berick shared the same fix earlier (up above around the time I was complaining about comcast). It does indeed work. |
| 14:33 |
csharp |
oh great :-) |
