| 10:29 |
|
maryj joined #evergreen |
| 10:37 |
|
jvwoolf left #evergreen |
| 10:53 |
dbs |
Does the new password security approach take the password passed in for auth_proxy (e.g. LDAP) and store the salted hashed version of that in the actor.passwd table? |
| 10:59 |
* tsbere |
has found 3 different ways to *not* modify USMARC.pm, all of which he figured out before he finished making the changes |
| 11:00 |
|
Christineb joined #evergreen |
| 11:14 |
|
sandbergja joined #evergreen |
| 11:42 |
* tsbere |
hopes he isn't missing something in his testing now that he has code he thinks may work |
| 11:58 |
tsbere |
gmcharlt: I have barely tested it, and it is lunchtime so I am off to get lunch. But if you want to see my fix attempt: https://github.com/tsbere/marc-perl/commit/1b46cde3c76cd1dc6943010de98ac6d172d97b1c |
| 12:03 |
miker |
grabbing 0985 |
| 12:04 |
|
brahmina joined #evergreen |
| 12:07 |
pinesol_green |
[evergreen|Dan Wells] LP#1588543: Speed up record attribute ingest - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cf3bd14> |
| 12:07 |
pinesol_green |
[evergreen|Galen Charlton] LP#1588543: further speed up record attribute ingest - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6cc1d1e> |
| 12:07 |
pinesol_green |
[evergreen|Galen Charlton] LP#1588543: tests for verifying correct generated of record attributes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f668201> |
| 12:07 |
pinesol_green |
[evergreen|Galen Charlton] LP#1588543: schema update script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=982472f> |
| 12:07 |
pinesol_green |
[evergreen|Mike Rylander] Stamping upgrade for reingest speedup - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4b5b791> |
| 12:15 |
pinesol_green |
[evergreen|Jason Boyer] LP 1481441: Improve Hold Failure Messages - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=54e21a0> |
| 12:15 |
|
jvwoolf joined #evergreen |
| 12:24 |
* tsbere |
wonders if he should be adding his name and adjusting years in the MARC::Record README file while he is making code changes, or if gmcharlt would take care of that later. |
| 12:24 |
bshum |
miker: It occurs to me that the stuff we're pushing right now probably should get a milestone target of 2.11-beta (which has yet to be created). |
| 15:33 |
remingtron |
Christineb: any idea if your docs video links have been clicked? |
| 15:33 |
Christineb |
I will get click stats for next meeting |
| 15:34 |
Christineb |
we only added the specific video links during our last upgrade (May) |
| 15:35 |
yboston |
did we want to pick a particualr section to test out addign the links? |
| 15:37 |
yboston |
we can decide later too |
| 15:38 |
remingtron |
I guess I'd rather focus on making sure features from 2.10 and 2.11 are covered, and maybe try to add a video link while we're in there. |
| 15:38 |
Christineb |
maybe the patron related videos? |
| 15:38 |
Christineb |
remingtron++ |
| 15:55 |
sandbergja |
(and a few bits that would need to be written) |
| 15:56 |
yboston |
one thign that is not a concer is that it looks liek the web client will not be “ready” in a couple of weeks, because it if was that would have an impact on the re-org |
| 15:56 |
sandbergja |
and some functional requirements and some survey feedback |
| 15:56 |
yboston |
we also have a test server that could be used for dispalying re-org experiments |
| 15:59 |
yboston |
I would suggest that we again try another re-org specific meeting and/or a new email list thread |
| 15:59 |
yboston |
thoguh of course that is soemthign you have done before |
| 15:59 |
remingtron |
sandbergja: it wouldn't take much work to create a new root.txt just for that new book, generate the html, and go from there |
| 15:59 |
remingtron |
yboston: does anyone else have access to the new DIG test server? |
| 15:59 |
yboston |
Right now I think only Galen adn I have access. |
| 16:00 |
yboston |
try reaching out to him for access, and of course tell him I can verify that we want to give you access |
| 16:00 |
sandbergja |
Well, why don't we get a new root.txt file onto that server somehow, generate a sysadmin-from-the-staff-client manual using our ToC, and use that to generate some excitement |
| 16:02 |
sandbergja |
:-P |
| 16:02 |
|
mmorgan joined #evergreen |
| 16:03 |
remingtron |
yboston: right, a working repo branch could work |
| 16:03 |
yboston |
not sure how the DIG test serve is set up. I know it is pulling from our main Git repo a cuple of times a day |
| 16:03 |
yboston |
I can email Galen |
| 16:03 |
sandbergja |
Thanks, yboston! |
| 16:03 |
yboston |
#action yboston will email Galen to give remingtron and sandbergja access to DIG test server |
| 16:04 |
remingtron |
yboston: thanks! |
| 16:04 |
yboston |
#link docs-testing.evergreen-ils.rog |
| 16:05 |
remingtron |
yboston: typo, should be ".org" |
| 08:46 |
pinesol_green |
[evergreen|Dan Scott] LP#1608711: Update schema.org property name from "seller" to "offeredBy" - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b55b3ca> |
| 08:47 |
JBoyer |
dbs, indeed, it's great. |
| 08:47 |
JBoyer |
Dyrcona++ |
| 08:52 |
bshum |
dbwells: I vaguely remember seeing something in IRC last week or earlier about 2.11 alpha cutting from you. Curious if you guys noticed a lot of string change that would necessitate a POT sync for translations. I saw some churn for the webstaff, but I don't get to peruse the files as often as I'd like anymore. |
| 08:52 |
|
mmorgan joined #evergreen |
| 08:53 |
bshum |
Either way, I'd recommend we do an i18n sync at some point. |
| 08:54 |
bshum |
I'll put together a local test later to see how much stuff actually changed myself. |
| 08:54 |
* bshum |
wanders off |
| 09:01 |
|
bos20k joined #evergreen |
| 09:02 |
|
Dyrcona joined #evergreen |
| 09:20 |
|
mrpeters joined #evergreen |
| 15:47 |
|
bos20k_ joined #evergreen |
| 15:58 |
JBoyer |
That figures. Thanks. |
| 15:59 |
JBoyer |
At least there's (probably) nothing setup wrong in my NCIPServer config. |
| 15:59 |
jeff |
that was fun when trying to debug incipit. |
| 15:59 |
jeff |
"wait, the state server is sending you WHAT in that field?" |
| 16:00 |
jeff |
"that's completely different from the value that they were sending us, which is completely different from the value that they were sending the original developers while testing, which is different from what's in the standard..." |
| 16:02 |
JBoyer |
And I'm using mod_dumpio to be able to see them at all, which is really great for log size. |
| 16:09 |
JBoyer |
and readability. |
| 16:09 |
jeff |
do you have a dedicated endpoint so that you can at least be selective about that, or are you dumping all traffic on a live system? |
| 16:10 |
JBoyer |
well, "live," it's a testing server but technically open to the world to see. Dumpio appears to be all or nothing though, I'd have preferred to only dump the NCIP traffic. |
| 16:11 |
* jeff |
nods |
| 17:11 |
|
mmorgan left #evergreen |
| 18:19 |
|
gsams joined #evergreen |
| 14:13 |
bshum |
Or bad reasons |
| 14:13 |
phasefx |
I was thinking maybe keeping alive some legacy system's way of having a family or classroom group; but I can't think of a better reason |
| 14:14 |
Bmagic |
I could imagine a scenario where the patron lost their old card, got a new one, then found the old one |
| 14:14 |
tsbere |
phasefx: Off the top of my head I can think of a couple. "School" accounts with multiple teachers carrying cards (so you can turn one off without affecting them all) is the best of them. |
| 14:15 |
tsbere |
phasefx: Worst of them is "I want to access more than one library's subscription for a third party service that uses barcode prefix to authenticate, so I need multiple cards!" - Though a single "test account" with a pile of cards for such a thing is less of a bad thing IMO. |
| 14:16 |
phasefx |
mmm |
| 14:16 |
phasefx |
thanks! |
| 14:17 |
tsbere |
I have also heard of "I want my secretary to have a card on my account so that she can pick my holds up for me" and "parent wants a card for each kid so they can pick the holds up, but we don't have a duplicator so we needed new numbers" |
| 15:31 |
jeff |
but in both of those cases, it was pre-speed-fixes and pre-popularity-metric |
| 15:31 |
jeff |
(though i don't know without looking if the popularity metric bits would affect an attr-only ingest at all) |
| 15:32 |
dbwells |
worth noting that the "speed fixes" only get us back close to where we were circa 2.7 or 2.8, so slow -> slower -> yay, we're slow again |
| 15:32 |
* dbs |
is trying to do the 2.11 thing, both for providing actual testing and because this is probably our last upgrade for quite a while. upgrading from 2.7 |
| 15:32 |
dbs |
dbwells__ |
| 15:32 |
dbs |
dbwells++ # i meant! |
| 15:34 |
jeff |
heh |
| 15:34 |
jeff |
and then there's that moment when i confuse a mozilla bugzilla browser tab for a text editor window... |
| 15:36 |
dbs |
at least we have time-based releases, I'm dealing with another project that's still feature-based and holy hell is it madness. "Yes we've merged part of this feature but there's 10 blockers associated with it needing volunteers before we can cut the next release" |
| 15:37 |
dbs |
heh |
| 15:38 |
gsams |
I'm hoping to make the jump from 2.7 upward by the end of the year, as long as things fall in place properly. |
| 15:57 |
miker |
dbs: popularity metric shouldn't interact with reingest at all |
| 16:01 |
* Dyrcona |
doesn't recall any reingest for testing popularity matrix. |
| 16:02 |
Dyrcona |
berick has suggested making pingest a standard bin. I'm for it, but my version and his have diverged a bit. |
| 16:02 |
Dyrcona |
To the point where a merge is nontrivial. |
| 16:16 |
jeff |
looking at 2.8-2.10 docs, minimum supported postgresql version has been 9.1 for a while, with the readme/install recommending 9.3 (though the 2.10 release notes recommend "9.2 or later" in mild conflict with the readme/install). this does leave us with Evergreen 2.9 and 2.10's required minimum PostgreSQL version (9.1) going EOL before the Evergreen release itself is out of support, but... we're getting better. :-) |
| 16:23 |
bshum |
Right direction. |
| 16:23 |
bshum |
KILL IT WITH FIRE! |
| 16:29 |
* Dyrcona |
recalls needing to look at some branches that remove support for Precise Pangolin. |
| 16:41 |
dbs |
miker: yeah, just noting the currency of our test server's database schema |
| 17:07 |
|
mmorgan left #evergreen |
| 17:10 |
|
jvwoolf left #evergreen |
| 18:21 |
|
gsams_ joined #evergreen |
| 12:00 |
jeff |
"As can be expected, this can produce extreme volumes of data" |
| 12:00 |
|
jihpringle joined #evergreen |
| 12:07 |
|
maryj joined #evergreen |
| 12:24 |
_bott_ |
I've got a test 2.10 install, and while logged into the web client, I'm getting multiple calls to open-ils.auth.session.retrieve per second while the session is sitting idle. If left sitting, it quickly logs thousands of requests. |
| 12:25 |
berick |
that sounds familiar.. |
| 12:25 |
berick |
maybe something to do with the auth timeout setting |
| 12:29 |
tsbere |
that, to me, sounds like background updating of something going nuts |
| 12:32 |
berick |
_bott_: http://irc.evergreen-ils.org/evergreen/2016-06-14#i_253093 |
| 12:36 |
_bott_ |
berick:++ |
| 13:21 |
jeff |
ack. I didn't file a bug on that one. |
| 13:22 |
* jeff |
does so |
| 13:26 |
jeff |
really not liking that i seem to get hung apache processes when testing webstaff stuff. |
| 13:26 |
|
sarabee joined #evergreen |
| 13:26 |
berick |
jeff: are they regular apache procs or websocket procs? |
| 13:27 |
jeff |
i don't think it's a problem with mod_websocket, because it's the main apache instance... but it could be something that's only encountered on a system that sits idle. |
| 13:27 |
berick |
k |
| 13:28 |
berick |
the browser client is leveraging (regular) apache a whole lot less than the tpac, but still based on the same TT processing code |
| 13:29 |
berick |
i'm a little surprised it would be the cause of apache probs |
| 13:30 |
jeff |
when this happened on another more test-only system, it was something i could usually reproduce. at this very moment i'm having trouble reproducing. |
| 13:31 |
jeff |
nevermind, got it. |
| 13:31 |
jeff |
well, "reproduced" |
| 13:38 |
jeff |
it seemed to be an apache child getting stuck, and just not responding at all to the client. |
| 13:39 |
jeff |
at this point, the server sees no tcp session, and the client (Chrome on OS X) is sitting spinning with a blank page, thinking that it's waiting on the server. |
| 13:39 |
jeff |
at this point i only have one side of the tcp session, i'm gathering more data. |
| 13:40 |
jeff |
one thing i'm trying to keep in mind is that this may not be the same as the previous time i had similar symptoms. trying not to combine observations. :-) |
| 13:41 |
|
terran joined #evergreen |
| 13:42 |
|
tspindler joined #evergreen |
| 13:45 |
berick |
on an unrelated note, anyone doing any audit table maintenance / cleanup? |
| 15:07 |
terran |
And to put something on my dune buggy sunburn |
| 15:07 |
kmlussier |
terran: Enjoy! |
| 15:09 |
jihpringle |
kmlussier: hi |
| 15:09 |
kmlussier |
jihpringle: Hello! :) |
| 15:09 |
kmlussier |
I was just testing jeffdavis 's fix for bug 1589586. |
| 15:09 |
pinesol_green |
Launchpad bug 1589586 in Evergreen master "Acquisitions: Cannot prorate charges on invoice" [Undecided,Confirmed] https://launchpad.net/bugs/1589586 |
| 15:10 |
kmlussier |
It's working well for me, but, while testing, I tried adding direct charges on a PO rather than an invoice. |
| 15:10 |
kmlussier |
I found the same issue occurs there with prorated direct charges. But it seems to also happen on 2.9. I was wondering if you know if that's always been an issue on the PO? |
| 15:11 |
|
tspindler left #evergreen |
| 15:11 |
jihpringle |
we stopped using charges on POs several versions ago because they never seemed to work quite right |
| 15:11 |
kmlussier |
I don't know if our users ever add direct charges from the PO, so maybe it's a non-issue. |
| 15:12 |
kmlussier |
jihpringle: Ah, ok. Thanks. |
| 15:12 |
jihpringle |
I think the only PO charges we've tested recently are for blanket orders and those are working (but aren't prorated |
| 15:13 |
* kmlussier |
nods |
| 15:13 |
kmlussier |
I may dig further, but since it appears to be a preexisting condition, I think the current fix is good to go in. |
| 15:15 |
Christineb |
kmlussier++ |
| 15:15 |
Christineb |
Thank you for testing! |
| 15:16 |
kmlussier |
Christineb++ #Thanks for finding the problem before our libraries upgraded to 2.10! |
| 15:17 |
jihpringle |
kmlussier: I though there was a direct charge/po related bug on launchpad but I couldn't find it |
| 15:17 |
kmlussier |
Oh, you know what? I bet you the problem on the PO occurs for the same reason it was happening on the invoice. Because the charges on the PO are encumbered. |
| 12:13 |
|
brahmina joined #evergreen |
| 12:19 |
|
jihpringle joined #evergreen |
| 12:33 |
Dyrcona |
Oh, the query finished some time ago, btw. It produced a 596MB output file. |
| 12:34 |
Dyrcona |
In case anyone is curious....It's a test of a Novelist On-the-Shelf extract. |
| 12:37 |
Dyrcona |
tsbere++ # For pointing out the -P footer=false psql option to me today. |
| 13:06 |
|
mmorgan joined #evergreen |
| 13:19 |
kmlussier |
Is there a git command I can use to find the branches I signed off on during a certain time period? |
| 14:23 |
|
bmills1 joined #evergreen |
| 14:23 |
mmorgan |
kmlussier: Dyrcona: Yes, we ended up with Stripe. |
| 14:24 |
Dyrcona |
Where I am presently uses PayPal, but they're looking at POS systems that use other processors and for reasons would like to keep everything on the same processor. |
| 14:25 |
mmorgan |
We did all our initial testing with PayPal. Switching to Stripe at the last minute was surprisingly easy. |
| 14:27 |
Dyrcona |
Yeah. My hope is that if I can find Business::OnlinePayment::<Processor> that the set up won't be too difficult. |
| 14:28 |
jeff |
setup generally is less of an issue than PCI DSS scope |
| 14:29 |
mmorgan |
Dyrcona: To switch from paypal to stripe, we just switched the library settings |
| 15:02 |
miker |
JBoyer: the former is unpossible |
| 15:03 |
berick |
JBoyer: i worked for me about 18 months ago. never looked back ;) |
| 15:04 |
Dyrcona |
Oh R'lyeh? |
| 15:04 |
JBoyer |
I suppose that goes without question. I may have overestimated the awfulness of installing what Evergreen needs for EDI. :) The edi_webrick.rb daemon is running without complaint, I guess I just need to test it. |
| 15:05 |
Dyrcona |
I've never had a good time installing anything that required Ruby because versions. |
| 15:05 |
JBoyer |
Dyrcona, Yes, R'lyeh |
| 15:05 |
JBoyer |
That's why I'm skeptical that it appears to be functional. |
| 15:24 |
Dyrcona |
Probably. I couldn't get it to install on Ubuntu 16.04, but I didn't spend more than 45 minutes on it. |
| 15:41 |
|
jihpringle joined #evergreen |
| 16:20 |
|
bmills joined #evergreen |
| 16:27 |
jeff |
Is anyone aware of more than one company making use of open-ils.collections API calls? |
| 16:27 |
jeff |
Anyone using them internally for other than testing, or anyone using them with a third party other than Unique? |
| 16:39 |
jeffdavis |
I had never even noticed that service before |
| 16:42 |
|
mmorgan joined #evergreen |
| 16:44 |
Dyrcona |
jeff: I'm not aware of anyone other than Unique using it. |
| 11:58 |
tsbere |
First was Republic Wireless, the new one is Google Fi |
| 11:59 |
Dyrcona |
Might be worth it. Republic is popular with AARP members, 'cause they give 'em discounts. |
| 12:00 |
* bshum |
really enjoyed Project Fi from Google for the brief months he used it |
| 12:00 |
tsbere |
Admittedly, I haven't been able to test either myself, but I imagine that technically applies to the majority of the entries in that table |
| 12:12 |
tsbere |
Not interested enough to Launchpad it, but if someone else wants to go to that effort: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/tsbere/sms_carriers |
| 12:14 |
* Dyrcona |
is killing connectby with fire this time. |
| 12:32 |
* berick |
chuckles at firing up 13 parellel hold targeters and processing the concerto data set in 7 seconds. |
| 12:32 |
|
gsams_ joined #evergreen |
| 12:43 |
StomproJ |
tsbere, if you add an SMS carrier, want to remove Alltel, they seem to no longer exist. |
| 12:46 |
tsbere |
StomproJ: I add based on people telling me patrons asked about them. Removal would require research. ;) |
| 13:01 |
bos20k |
Hello. I am creating relative proximity adjustments. We are using the item_circ_lib and hold_pickup_lib when creating them. This is in a consortium. My question is, can I use the org unit ids from the system level, or do I need to use the org unit ids from the branch level? I would like to use the system level org unit ids but I am thinking it won't work right unless I use the branch level ones. |
| 13:04 |
Dyrcona |
Lots of problems with tests using Perl 5.22. |
| 13:10 |
bshum |
bos20k: If it works like most things, I would expect the more specific you are, the more exact it'll match up with the org unit for behavior. If you're specific to the branch, then it should treat it only when dealing with those branches. if system, then it ought to apply to that level and all its children. |
| 13:11 |
bshum |
If memory serves, most of the time we used system level rules, we wanted it to apply to that location and all underlying branches. |
| 13:11 |
bshum |
That being said, I don't recall exactly how relative proximity adjustments operate. |
| 14:38 |
Dyrcona |
@later tell bshum Yes, I did use admin demo123, unless I typoed it. |
| 14:38 |
pinesol_green |
Dyrcona: The operation succeeded. |
| 14:41 |
Dyrcona |
Yep, I did. Just logged in to make sure. |
| 14:50 |
Dyrcona |
live_t/17-lp1579225_new_patron_passwords.t .... Dubious, test returned 25 (wstat 6400, 0x1900) |
| 14:51 |
Dyrcona |
We're also getting this with Perl 5.22 on two tets: Possible precedence issue with control flow operator at /home/opensrf/Evergreen/Open-ILS/src/perlmods/blib/lib/OpenILS/SIP/Patron.pm line 353. |
| 14:51 |
Dyrcona |
I'm guessing that is code that I wrote. |
| 14:52 |
Dyrcona |
So, with clean master on Xenial, that one test fails and two others spit out a message. |
| 14:54 |
Dyrcona |
Nope. Not my code. |
| 14:54 |
Dyrcona |
I figured it was 'cause I recently edited that file. |
| 14:58 |
bshum |
Okie dokie :( |
| 15:10 |
|
jvwoolf left #evergreen |
| 15:20 |
bshum |
Hmm, my trusty VM exploded on part of negative balances live perl test, and then utterly died with the patron password test |
| 15:20 |
bshum |
I'll reload my DB and double check |
| 15:27 |
Dyrcona |
For the benefit of the channel, I'm only failing on the patron password test after 3 or 4 times reloading the database. |
| 15:30 |
berick |
Dyrcona: does reloading the DB mean dropping and re-create the EG db, then adding concerto? |
| 15:31 |
Dyrcona |
berick: Yes, that is what it means. I used eg_db_config to recreate the database. |
| 15:31 |
Dyrcona |
There's a field in the use that is an arrayref, and that doesn't look right to me. The error is from trying to update a user. |
| 15:32 |
Dyrcona |
I'd expect a fleshed object. |
| 15:32 |
Dyrcona |
I'm going to try the pgtap tests, next. |
| 15:32 |
Dyrcona |
just have to install the extension. |
| 15:36 |
bshum |
Dyrcona: Fresh Xenial VM with concerto, etc. Neg balances works fine, but that patron password test still dies horribly |
| 15:36 |
bshum |
So that's now four attempts with fresh DBs where that test blows up consistently for me |
| 15:36 |
Dyrcona |
That's what I see, too. |
| 15:37 |
Dyrcona |
I'm going to try pgtap tests with the right db credentials, this time. :) |
| 15:39 |
Dyrcona |
not much typing the password over and over again. :) |
| 15:39 |
|
rjackson_isl_ joined #evergreen |
| 15:39 |
Dyrcona |
not much fun that is. |
| 15:41 |
|
mnsri_away joined #evergreen |
| 15:42 |
|
b_bonner joined #evergreen |
| 15:43 |
|
pastebot joined #evergreen |
| 15:43 |
Dyrcona |
pgtap tests and live tests are all successful. |
| 15:43 |
Dyrcona |
t/regress also pass. |
| 15:44 |
|
eady joined #evergreen |
| 15:44 |
|
jeff joined #evergreen |
| 15:50 |
bshum |
Well, fwiw, Dyrcona, I can't replicate yours and bott's issue with patron registration on my Xenial VM running EVG master and PG 9.5. I'll try again later and also maybe try out the working branch further to really kill connectby() stuff. It'll be good regardless. |
| 15:52 |
Dyrcona |
I haven't mentioned the branch on the LP bug, yet. I'm gonna fix it up prettier later. |
| 16:02 |
|
jlitrell joined #evergreen |
| 16:03 |
bshum |
Right, I'm just saying I can't get patron editor to break so far. |
| 16:03 |
bshum |
I did test the function call though and that is broken for sure. |
| 16:03 |
bshum |
So whatever we do to kill connectby is +1 from me :) |
| 16:03 |
bshum |
Maybe it's a browser thing |
| 16:04 |
* bshum |
uses Chrome |
| 16:11 |
StomproJ |
Can someone show me an example of a srfsh request for a service with multiple arguments please, I'm having trouble figuring it out. |
| 16:12 |
StomproJ |
I'm trying something like (test system, so not worried about the auth key) request open-ils.actor open-ils.actor.invalidate.email "ec144954b1df8f1d09894fc81ebf322c",'','','',"natcho taco.com" |
| 16:13 |
tsbere |
StomproJ: I think you can space-delimit instead of comma-delimit |
| 16:14 |
StomproJ |
Thanks, I wonder why the srfsh help screen for request says "so add commas if there is more than on param"? |
| 16:15 |
* tsbere |
isn't sure he has ever actually looked at that help screen <_< |
| 10:30 |
tsbere |
berick: I can confirm that the "# TODO: Should this include 'R' holds? ..." comment regarding parts should be a "no, it should not be included there". F and R should be treated identically at the targeter level. |
| 10:31 |
berick |
tsbere: thanks! I'll remove that comment |
| 10:32 |
* tsbere |
wonders how difficult it would be to do the "potential copies" dance once for multiple holds (same type/target/pickup location/selection ou/selection depth?) to speed some things up... |
| 10:35 |
csharp |
berick++ |
| 10:35 |
csharp |
we're gonna start testing that on a test server in the next week or so |
| 10:37 |
berick |
tsbere: yeah i could see that.. have the batch mode group by target+type and churn over the same initial copy set (minus any that get targeted in the process). |
| 10:37 |
berick |
csharp++ |
| 10:38 |
tsbere |
berick: Well, you would need the ones targeted in the process for potentials still, and the selection ou/depth would need to be included as well. |
| 11:16 |
JBoyer |
Usually around upgrade time though. (WHY U NO WORK? Oh, already did that a while back...) |
| 11:18 |
jeff |
oh, in terms of trying to apply a local patch/branch? :-) |
| 11:20 |
tsbere |
I love it when I conflict with my own code in a customization branch (customized patch in branch, uncustomized made it into master...) |
| 11:24 |
JBoyer |
jeff, Sometimes, more excitingly when testing db upgrades. |
| 11:31 |
Dyrcona |
I love it when two customizations conflict with each other...... |
| 11:31 |
csharp |
jwl: there are probably pre-built tools out there, but you might look into MARC::Record if you want to write perl scripts around creating/manipulating MARC |
| 11:31 |
Dyrcona |
Even after rebasing.... |
| 11:36 |
Bmagic |
StJoesCollege: yes, the action trigger stuff requires a server side cron job |
| 11:36 |
tsbere |
StJoesCollege: Do you have an email system in place on the servers? Are you running the example cron jobs? Are the A/T event definitions enabled? |
| 11:37 |
StJoesCollege |
we do have an email system |
| 11:37 |
StJoesCollege |
it works, ive tested the email from inside the evergreen client. |
| 11:38 |
|
brahmina joined #evergreen |
| 11:38 |
Bmagic |
StJoesCollege: Generally you designate one of your app servers to do the work. http://wiki.evergreen-ils.org/doku.php?id=evergreen-user:action_trigger |
| 11:39 |
dbwells |
StJoesCollege: Here is some more polished documenation for notices, though perhaps less complete: http://en.flossmanuals.net/evergreen-in-action/sending-gentle-reminders-to-your-users/ |
| 15:28 |
mmorgan |
bmills: By default, the normalizers active in Evergreen change apostrophes into spaces. |
| 15:28 |
bmills |
some example bits http://pastebin.com/7PkNGMth for this guy: http://catalog.sage.eou.edu/eg/opac/record/1178516 |
| 15:30 |
* mmorgan |
looks for more info |
| 15:31 |
bmills |
tsbere: was hoping to not have to do a mass re-index, but that could be it. restored our db into a test vm and the normalization issues don't seem to be occurring there.. |
| 15:31 |
* jeff |
raises an eyebrow |
| 15:32 |
* tsbere |
has also raised an eyebrow as he didn't think a restored DB would be re-indexed, so the normalization issues should still be there |
| 15:33 |
bmills |
maybe i'm mistaken, but it was from a pg_dump of the database. don't the indexes get recreated in that process? |
| 15:35 |
jeff |
on both the restored db and on production? |
| 15:36 |
bmills |
jeff: just checked. only the one there too |
| 15:37 |
jeff |
good! |
| 15:40 |
mmorgan |
We plan to change our production database to use NACO normalization rather than the default Search normalization with our next upgrade. We've been testing it on our training system and like what we're seeing for the most part. |
| 15:41 |
mmorgan |
On our training server, "I've got our number" gets hits. |
| 15:41 |
bmills |
mmorgan: thanks for looking! we did an in place upgrade to 9.3 not too long ago, wondering if something might happened there.. |
| 15:42 |
mmorgan |
bmills: It's not a postgres thing, but an Evergreen config. |
| 15:44 |
bmills |
mmorgan: i've done some searches on other evergreen catalogs that i'm assuming are using the default search_normalize and the "i've got your number" and "all these things i've done" titles seem to pull up ok in title searches. so i think it's us being borked somewhere |
| 15:45 |
jeff |
bmills: same results with title and keyword searches? |
| 15:45 |
jeff |
i suppose i could test that part myself. |
| 15:46 |
bmills |
jeff: keyword brings up those title just fine |
| 15:47 |
Bmagic |
same here "I've got your number" works |
| 15:54 |
bmills |
jeff++ mmorgan++ tsbere++ thanks! i'll keep at it |
| 11:17 |
jeff |
(which is obviously not the way to correct the problem long-term) |
| 11:17 |
kmlussier |
It looks like the perl live tests started failing on May 31? |
| 11:18 |
Dyrcona |
jeff: I would think configure would pick those up. |
| 11:19 |
Dyrcona |
Do the tests actually relink/recompile code? |
| 11:20 |
Dyrcona |
kmlussier: Those live test failures could be because the database was not rebuilt. |
| 11:20 |
kmlussier |
Yeah, I was just coming around to that. |
| 11:20 |
Dyrcona |
Many of the tests fail after being run once. |
| 11:21 |
* Dyrcona |
tries to write his so that they can be run more than once on the same database, but may not always succeed. |
| 11:24 |
|
bmills joined #evergreen |
| 11:27 |
jeff |
Dyrcona: i think "make check" compiles and links things that are not normally built -- somewhat similar for perl tests would be if Test::More could not be found, etc. |
| 11:28 |
jeff |
it compiles and links some small test binaries. |
| 11:29 |
Dyrcona |
OK. I've not looked at it very much. I often just run the pgtap or perl tests individually. |
| 11:29 |
Dyrcona |
I haven't run make check in a while. |
| 11:32 |
dbs |
Yeah, 'make check' is for C tests |
| 11:37 |
jeff |
okay, i'm done testing bug 1592565 and i'm ready to write release notes and pick to master and rel_2_10. Am I correct in thinking that I only need to put release notes in master and they'll be backported to rel_2_10 just prior to the next point release being cut? |
| 11:37 |
pinesol_green |
Launchpad bug 1592565 in Evergreen "2.10 Login code lost key activity log message" [High,In progress] https://launchpad.net/bugs/1592565 - Assigned to Jeff Godin (jgodin) |
| 11:40 |
Dyrcona |
jeff: Point release is today, but I haven't heard anything from gmcharlt today, so don't know what he thinks about pushing something in right now. |
| 11:41 |
jeff |
or am I off and bugfixes get zero release notes, and are just summarized manually... looks like that's the case. |
| 12:39 |
bshum |
Looks like rlefaive had a similar issue on http://irc.evergreen-ils.org/evergreen/2016-04-26#i_243991 ; I wonder if it's something based on the Ubuntu image |
| 12:39 |
bshum |
sam_l: What 14.04 image did you use? The 64-bit server edition? |
| 12:40 |
* bshum |
checked the logs but didn't see a resolution noted by rlefaive or others on later days |
| 12:45 |
jeff |
gmcharlt: bug 1592891 is also a candidate for 2.10.5. i can write tests also, if you'd like. |
| 12:45 |
pinesol_green |
Launchpad bug 1592891 in Evergreen "SIP2 failures with certain kinds of user standing penalties" [High,New] https://launchpad.net/bugs/1592891 - Assigned to Jeff Godin (jgodin) |
| 12:45 |
|
jihpringle joined #evergreen |
| 12:46 |
kmlussier |
Release notes are done, but I'll hold off on merging the 2.10 notes until I hear back on whether the SIP2 fix makes it in. |
| 12:48 |
sam_l |
bshum: Yep, 64-Bit Server. |
| 12:48 |
Dyrcona |
jeff: Good catch on that penalties bug. |
| 12:49 |
jeff |
Dyrcona: thanks! sorry i didn't bug it until now -- sorta' fell into a SIP2 rabbit hole. |
| 12:59 |
gmcharlt |
jeff: I agree it's a candidate. go forth and write tests! |
| 12:59 |
jeff |
doing so! :-) |
| 13:06 |
sam_l |
bshum: rebooted the server instance, and it's now running properly. |
| 13:07 |
bshum |
sam_l: Oh cool, I was just about to suggest restarting apache |
| 13:48 |
jeffdavis |
I have a use case that requires a site-specific one right now though. |
| 13:48 |
Dyrcona |
If you have some spare hardware, you could try what I mentioned earlier and set up a self-contained Evergreen instance just for z39.50. |
| 13:49 |
jeffdavis |
Our Z39.50 service is hosted on a separate utility server, not the main ones that are hit when people use the OPAC or staff client. |
| 13:49 |
jeff |
gmcharlt, Dyrcona, anyone else interested: tests pushed and pullrequest tag added to bug 1592891 |
| 13:49 |
pinesol_green |
Launchpad bug 1592891 in Evergreen "SIP2 failures with certain kinds of user standing penalties" [High,New] https://launchpad.net/bugs/1592891 - Assigned to Jeff Godin (jgodin) |
| 13:49 |
Dyrcona |
OK. That's the best way to set it up. |
| 13:50 |
jeff |
and... removing myself from assigned. |
| 13:50 |
Dyrcona |
jeff: Thanks. I will not have time to test it today. |
| 13:50 |
jeff |
Dyrcona: no problem. didn't mean to imply that expectation by mentioning you. :-) |
| 13:51 |
Dyrcona |
jeffdavis: Z searches go through multiple layers, so I expect it to be a little slower than regular search. |
| 13:51 |
Dyrcona |
jeff: NP. Just saying.... |
| 13:52 |
jeff |
Dyrcona++ for writing tests worth copying, also. |
| 13:52 |
Dyrcona |
jeffdavis: Is your zurl pointing at the utility server or back to your OPAC? |
| 13:53 |
JBoyer |
I wondered about that, because we also run the Z stuff on a separate machine, but it currently points right back to the OPAC, which I'm planning to change soon. |
| 13:53 |
Dyrcona |
The simple2zoom service is very lightweight. I found the supercat searches to be the real resource hogs. |
| 14:01 |
kmlussier |
@marc 775 |
| 14:01 |
pinesol_green |
kmlussier: The entry for another available edition of the target item (horizontal relationship). When a note is generated from this field, the introductory phrase Other editions available: may be generated based on the field tag for display. (Repeatable) [b,c,d,e,f,g,h,i,k,m,n,o,r,s,t,u,w,x,y,z,6,7,8] |
| 14:01 |
Dyrcona |
I have a script to monitor the number of drones on the drone server, but haven't set it up on the zurl target. |
| 14:01 |
Dyrcona |
And, look at that: I have a 2.9.6 tarball to test. |
| 14:03 |
* Dyrcona |
should really document the z stuff |
| 14:35 |
|
krvmga joined #evergreen |
| 14:48 |
|
collum joined #evergreen |
| 14:54 |
jeff |
force pushed a fixup commit to the tests on bug 1592891 (noticed a function was unnecessary, edited comments a bit) |
| 14:54 |
pinesol_green |
Launchpad bug 1592891 in Evergreen "SIP2 failures with certain kinds of user standing penalties" [High,New] https://launchpad.net/bugs/1592891 |
| 15:15 |
pinesol_green |
[evergreen|Jason Stephenson] Forward port 2.9.5 to 2.9.6 upgrade script. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e1853b2> |
| 15:17 |
Dyrcona |
gmcharlt: FYI: 2.9.6 tarball is uploaded to the server, but not in place, yet. |
| 15:20 |
gmcharlt |
yeah |
| 15:26 |
|
jlitrell joined #evergreen |
| 15:27 |
Dyrcona |
I've put the downloads files in place, except the readme and release notes. |
| 15:39 |
jeff |
gmcharlt: are you intending / able to test and merge the sip bugfix, or would you like me to solicit a willing co-conspirator? |
| 15:40 |
gmcharlt |
jeff: I am willing and able, but even happier if you find a willing co-conspirator to test and signoff first |
| 15:43 |
jeff |
also, since i remember we had at least one time that we duplicated perl live test numbers, should i leave tests unnumbered? |
| 15:43 |
jeff |
or rely on the merging party to re-number if needed at that time? |
| 15:46 |
jeff |
in this case i numbered the test. just wondered if we had a general concensus on that for next time. |
| 15:52 |
|
kmlussier joined #evergreen |
| 15:53 |
kmlussier |
I don't think we have a general consensus. I would go with numbering for now. |
| 15:56 |
Dyrcona |
Yeah, I agree. |
| 18:19 |
|
gsams joined #evergreen |
| 19:05 |
|
pinesol_green` joined #evergreen |
| 19:07 |
|
phasefx_ joined #evergreen |
| 19:10 |
jeffdavis |
I have run out of time to finish testing and signing off on bug 1592891; I'll try to get to it in a couple hours unless someone else gets to it, but not sure I'll make gmcharlt's cutoff for 2.10.5 :( |
| 19:10 |
pinesol_green` |
Launchpad bug 1592891 in Evergreen "SIP2 failures with certain kinds of user standing penalties" [High,New] https://launchpad.net/bugs/1592891 |
| 19:11 |
jeffdavis |
biab |
| 19:19 |
|
egbuilder joined #evergreen |
| 19:32 |
jeff |
jeffdavis++ thanks for trying -- i know it was last minute! |
| 19:35 |
gmcharlt |
I'll start work on the release shortly, and will give that patch a fair look |
| 20:22 |
gmcharlt |
jeff: jeffdavis: patch suits me; it will be in the release |
| 20:24 |
pinesol_green` |
[evergreen|Jeff Godin] LP#1592891: Tests - SIP2 standing penalty failures - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=56cc12e> |
| 20:24 |
pinesol_green` |
[evergreen|Galen Charlton] LP#1592891: tweak tests - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=22536d1> |
| 20:24 |
pinesol_green` |
[evergreen|Jeff Godin] LP#1592891: Fix SIP2 standing penalty failures - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5e0c9b3> |
| 20:27 |
jeffdavis |
gmcharlt++ |
| 20:27 |
|
jonadab joined #evergreen |
| 20:30 |
pinesol_green` |
[evergreen|Kathy Lussier] Docs: Adding 2.10 Release Notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=67c6b2a> |
