| 00:28 |
|
dcook joined #evergreen |
| 00:33 |
|
dcook__ joined #evergreen |
| 05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:46 |
|
genpaku joined #evergreen |
| 07:14 |
|
rjackson_isl joined #evergreen |
| 07:17 |
|
dteston joined #evergreen |
| 11:24 |
pinesol_green |
csharp: Thank you csharp! But our princess is in another castle! |
| 11:24 |
csharp |
@bartender berick |
| 11:24 |
* pinesol_green |
fills a pint glass with Samuel Adams Black Lager, and sends it sliding down the bar to berick (http://beeradvocate.com/beer/profile/35/21300) |
| 11:25 |
berick |
csharp: but did you test it yet? :) |
| 11:25 |
csharp |
doing so now |
| 11:25 |
csharp |
:-) |
| 11:25 |
Dyrcona |
I don't think you have to test that. It will fix the problem. ;) |
| 11:26 |
Dyrcona |
I was ready to commit it after just eyeballing it. :) |
| 11:27 |
* Dyrcona |
wonders what's for lunch. |
| 11:30 |
csharp |
no errors - now going to wait a little while for more events to accumulate and run a bigger batch at once |
| 12:32 |
miker |
csharp: is there an LP bug to attach this to? |
| 12:33 |
miker |
nm, found it |
| 14:55 |
|
mmorgan1 joined #evergreen |
| 15:38 |
csharp |
miker: oops - I left out the "next;" in my git branch - it was added to my local file :-/ |
| 15:41 |
csharp |
miker: I'll test your branch in a bit and let you know how it goes |
| 15:45 |
|
agoben joined #evergreen |
| 15:55 |
|
khuckins_ joined #evergreen |
| 15:59 |
csharp |
miker: so putting aside the functionality of the patch(es), you're saying that it's "wrong" to group on a field that is nullable (in this case, sms_notify on action.hold_request)? I see that all other notices group on usr, but I'm assuming we group on sms_notify since that's a per-hold setting... |
| 16:00 |
csharp |
that is to say, if there's a better way to do this in the first place, I'm game :-) |
| 16:01 |
jeff |
can you articulate why you were grouping by sms_notify and not usr? how do the stock phone / pbx A/T event defs group? |
| 16:02 |
berick |
i'm fairly certain it is because sms_notify is per-hold and not per-user |
| 16:02 |
berick |
(a topic I know jeff loves) |
| 16:38 |
stephengwills |
in my case it appears as if the xact_finish date == the date the item was checked in. the bills are all unpaid. not even partial payments on them |
| 16:51 |
|
mmorgan joined #evergreen |
| 16:56 |
|
khuckins__ joined #evergreen |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:02 |
|
mmorgan left #evergreen |
| 17:15 |
jeffdavis |
Are folks around these parts experiencing memory leak issues with the staff client? |
| 17:17 |
jeffdavis |
there are some reports of this kind of thing in bug 1110817 (and in bug 1086458 which was "fixed" circa 2.5) but I'm not sure of prevalence of that kind of issue |
| 05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:20 |
|
rjackson_isl joined #evergreen |
| 07:23 |
|
JBoyer joined #evergreen |
| 08:40 |
|
mmorgan joined #evergreen |
| 12:27 |
|
jihpringle joined #evergreen |
| 12:33 |
miker |
_bott_: I just marked your bug as private and security related ... as it happens, it's a duplicate of one I entered last week that has patches already :) |
| 12:33 |
_bott_ |
patches would be very welcomed! |
| 12:35 |
miker |
I've attached you to the other bug. I'm going to mark yours as dup and put patches (instead of branch names in a repo you can't get to...) there so you can test 'em |
| 12:36 |
|
genpaku joined #evergreen |
| 12:37 |
|
jihpringle joined #evergreen |
| 12:41 |
|
jvwoolf joined #evergreen |
| 14:17 |
dteston |
berick: So existing salts are pulled from actor.passwd, but new salts are created from that function once per user? |
| 14:21 |
berick |
dteston: existing MD5 hashed passwords [ just MD5('password123') ] are pulled from actor.passwd. all passwords, migrated and new, get new salts from actor.create_salt() |
| 14:22 |
berick |
dteston: see also actor.migrate_passwd() db func |
| 14:22 |
_bott_ |
miker: patches in and brief testing yields positive results |
| 14:27 |
dteston |
berick: post-migration though, the only salt that's used to authenticate my password will be on actor.passwd, right? |
| 14:28 |
berick |
dteston: yes |
| 14:29 |
berick |
it's the only salt, but passwords going forward also do the 2 rounds of md5 hashing |
| 15:25 |
|
gsams joined #evergreen |
| 15:27 |
|
dteston joined #evergreen |
| 16:04 |
|
mmorgan joined #evergreen |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:10 |
|
jvwoolf left #evergreen |
| 17:10 |
|
mmorgan left #evergreen |
| 17:23 |
Stompro |
mmorgan++ Thanks for the response to my list question! |
| 05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 09:50 |
|
genpaku joined #evergreen |
| 14:49 |
|
Dyrcona joined #evergreen |
| 15:57 |
|
kenstir joined #evergreen |
| 16:44 |
Dyrcona |
yeah, I looked at syslog-ng's documentation and I'm not sure you can do this with syslog-ng, either. :) |
| 16:44 |
Dyrcona |
Anyway, I'm blocking sites that try non-existent accounts or accounts that do not receive email immediately. |
| 16:45 |
Dyrcona |
If you try a legit account, you get blocked after so many failures in a certain time period, hence the dbm file. |
| 16:46 |
Dyrcona |
I tested it by deliberately messing up my password. |
| 16:46 |
Dyrcona |
I've been getting attacked every couple of weeks from Romania, Belize, and Ukraine mostly. |
| 16:53 |
kenstir |
It's annoying, but as soon as you bring up a server on a public IP it gets probed. |
| 16:56 |
Dyrcona |
Yeah. |
| 16:56 |
Dyrcona |
And my script works, 'cause I managed to fail enough times to get blocked in my firewall. :) |
| 16:58 |
Dyrcona |
I guess my first attempt at configuring it didn't have the program name filter correct, and my second attempt had the wrong level. |
| 16:59 |
Dyrcona |
I wonder if it works if I move it to the bottom of the file? |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:00 |
Dyrcona |
Yes, apparently, so that wasn't my problem before. |
| 17:00 |
Dyrcona |
Anyway, enough about that. |
| 22:07 |
dbs |
@later tell kenstir https://example.org/opac/extras/supercat/retrieve/marcxml-full/record/907278 to get the MARCXML + holdings + URIs for record 907278, per https://wiki.evergreen-ils.org/doku.php?id=backend-devel:supercat:examples |
| 05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:20 |
|
kmlussier joined #evergreen |
| 06:20 |
* kmlussier |
yawns |
| 07:07 |
|
rjackson_isl joined #evergreen |
| 10:01 |
_adb |
yea.. hold is captured, but before 'hold shelf delay status' time has passed |
| 10:02 |
tsbere |
aka, it is in the "on hold shelf" status with a shelf time, but within that delay period? |
| 10:03 |
jeff |
_adb: i thought that that was a known and fixed issue a while back. maybe there's still an open bug and it's not been merged. looking. |
| 10:03 |
_adb |
i think so? the hold shows up in the staff client as "reserved/pending", but i'm not sure what the item status is during this time. i'd have to test. |
| 10:04 |
|
remingtron joined #evergreen |
| 10:04 |
jeff |
bug 1195428 |
| 10:04 |
pinesol_green |
Launchpad bug 1195428 in Evergreen "TPAC reports hold "ready for pickup" before hold_shelf_status_delay expires" [Medium,Confirmed] https://launchpad.net/bugs/1195428 |
| 10:09 |
berick |
jeff: bonus, it's not prompting for any permissions. it almost seems too good to be true, though. |
| 10:10 |
jeff |
that does seem a bit too good to be true... hrm. |
| 10:10 |
_adb |
how long is the timeout before notifications sent and hold is marked as ready for pickup if it's captured as transit? |
| 10:10 |
jeff |
berick: have you tested with a fresh copy of chrome and potentially a fresh google account to confirm that there's nothing going on like "oh, you granted some permissions to this a while ago"? |
| 10:11 |
tsbere |
_adb: You still need to check it in again to end the transit, so "until staff take action, plus whatever is configured then" |
| 10:11 |
jeff |
_adb: depends on a few variables, including how often you run the action trigger script with the granularity in question, and the delay configured in the A/T definition... |
| 10:11 |
_adb |
ah, ok, thank you |
| 10:14 |
|
Dyrcona joined #evergreen |
| 10:15 |
|
bos20k joined #evergreen |
| 10:15 |
|
jvwoolf joined #evergreen |
| 10:16 |
berick |
jeff: i'm going to clean up my test code, get it into the working repo, then try it on a few other machines today. i'll update the bug. other eyes would be awesome, though |
| 10:16 |
berick |
jeff: for now, the fact that you didn't say "that's insane" is what I was looking for ;) |
| 10:17 |
jeff |
it got a raised eyebrow and a "that doesn't sound like it should work", but I'm not planning to make any further assertions without testing. :-) |
| 10:25 |
|
mmorgan1 joined #evergreen |
| 10:32 |
|
Christineb joined #evergreen |
| 10:39 |
|
Callender joined #evergreen |
| 10:51 |
|
mdriscoll joined #evergreen |
| 10:54 |
berick |
jeff: oh, i missed your earlier comment.. when viewing the details of the extension, it does say "Read and change all your data on the websites you visit" -- however, it already said that. |
| 10:55 |
berick |
first test passed, installing under a different "person" in chrome. trying on a different machine now.. |
| 11:07 |
|
sandbergja joined #evergreen |
| 11:08 |
|
dbwells joined #evergreen |
| 11:14 |
|
khuckins joined #evergreen |
| 11:17 |
|
remingtron joined #evergreen |
| 11:17 |
berick |
jeff: fyi, installed on another machine (mac) where i've never installed it before, on a different chrome "person" (not logged into google) and all is well. this is after trimming the manifest even more. http://git.evergreen-ils.org/?p=working/Hatch.git;a=blob;f=extension/app/manifest.json;hb=collab/berick/lp1646166-native-messaging-2.12-omnibus |
| 11:17 |
* berick |
updates lp |
| 11:19 |
jeff |
berick: does the extension still show "Read and change all your data on the websites you visit"? |
| 11:19 |
jeff |
and it didn't display that permission as being granted when the extension was installed? |
| 11:20 |
berick |
jeff: it does display that message when viewing the extension details. it doesn't inform me of that during install, presumably because I'm installing in developer mode. |
| 11:59 |
|
brahmina joined #evergreen |
| 12:01 |
|
bmills1 joined #evergreen |
| 12:03 |
|
jihpringle joined #evergreen |
| 12:18 |
kmlussier |
berick++ jeff++ # Continued hatch work and testing. |
| 12:19 |
jeff |
i'm just listening today. :-) |
| 12:20 |
JBoyer |
berick++ |
| 12:21 |
JBoyer |
It sounds like hatch is coming along nicely. I've finally got a notebook running Linux so I'll be able to take part in more testing and so on. (Not putting Java on any machines I actually like, so it's been a no-go at home until now, and work doesn't like it either. :/ ) |
| 12:22 |
jeff |
berick++ indeed |
| 12:32 |
Bmagic |
Is there a way to ask SIP weather a patron can circulate without trying to circulate an item? |
| 12:33 |
Bmagic |
It looks like we are getting 'Y' in the 3rd position on the 64 responses. AKA "64 Y " - which means block right? The problem is, that 'Y' seems to shows up no matter what penalties or no penalties |
| 12:41 |
JBoyer |
I can't tell that it's actually looking at penalties that block CIRC, only that there are some penalties. barring the patron (the checkbox on the Edit screen) or letting them expire are the only sure-fire ways to set that to Y |
| 12:42 |
Bmagic |
thanks for the help, I will keep digging |
| 12:42 |
Bmagic |
$u->standing_penalties and @{$u->standing_penalties} |
| 12:43 |
Bmagic |
If the result of that test is true, then circ is blocked, which results in the first position 'Y' ? |
| 12:44 |
jeff |
might want to start with "why do you think the patron should be blocked?" |
| 12:44 |
JBoyer |
Yes, but I can't tell what that's actually testing. first, that there are standing penalties, but I'm not sure what @{$u->standing_penalties} is actually testing. |
| 12:44 |
Bmagic |
if the penalty they have blocks CIRC |
| 12:45 |
Bmagic |
if you look at the code for renew_ok - $renew_block_penalty = 't' if $_->standing_penalty->block_list =~ /RENEW/; |
| 12:45 |
Bmagic |
probably need something similar in charge_ok ? |
| 12:50 |
Dyrcona |
That check is check that we have something, and that they arrayref has 1 or more memberes. |
| 12:50 |
Dyrcona |
@{[]} is 0 or false in scalar context |
| 12:50 |
pinesol_green |
Dyrcona: Error: "" is not a valid command. |
| 12:52 |
Bmagic |
the test is then "penalties exist and there are more than 0" ? |
| 12:55 |
Dyrcona |
Bmagic: Yeah. |
| 12:55 |
Bmagic |
I'm thinking there needs to be a penalty block check for charge_ok and hold_ok just like renew_ok, do you think? |
| 12:55 |
Dyrcona |
It's done that way to avoid warnings about undefined values. |
| 13:23 |
Bmagic |
I suppose I will create a new bug unless you can think of one that is already there ( I really don't want to make a duplicate) |
| 13:25 |
jeff |
either start with a "this might be the same thing" as a comment on that bug, or a new ticket with "this might be a duplicate" and either a new bug can be created or the new bug can be marked as a duplicate if so. |
| 13:25 |
Bmagic |
I would like to mention that our system is not setting that first position 'Y' when they have penalties. Therefore, I can conclude that "$u->standing_penalties and @{$u->standing_penalties}" doesn't seem to be returning correctly |
| 13:25 |
jeff |
i would err on the side of getting a clear explanation of what you found and how you think it should be different into launchpad over worrying about comment vs new bug too much. :-) |
| 13:26 |
jeff |
(i say this because i've let that prevent me from getting info into launchpad before) |
| 13:27 |
jeff |
also helpful is some background on what the actual practical effect of the current behavior is, as not everyone has the same SIP clients to test with, or uses SIP in the same way. |
| 13:36 |
Dyrcona |
In my experience, a number of SIP vendors treat a Y in any field as blocked for everything. |
| 13:36 |
Dyrcona |
It's rare to find one that actually checks the specific field. |
| 13:38 |
Dyrcona |
As for Bmagic's comment about it returning correctly, I'd have to look at the code in question, but when dealing with arraryrefs, that's a common way to check if it has members. |
| 16:23 |
|
rlefaive joined #evergreen |
| 16:52 |
|
khuckins_ joined #evergreen |
| 17:00 |
|
jvwoolf left #evergreen |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:10 |
|
mmorgan left #evergreen |
| 17:12 |
pinesol_green |
[evergreen|Bill Erickson] LP#1655399 webstaff: User perm editor grantable fix - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a2e9d7a> |
| 17:30 |
|
khuckins__ joined #evergreen |
| 17:44 |
|
kmlussier joined #evergreen |
| 17:45 |
pinesol_green |
[evergreen|Kyle Huckins] LP#1621947: webstaff address alert functionality - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5a3e0dd> |
| 17:59 |
pinesol_green |
[evergreen|Kyle Huckins] LP#1657466 - Edit Due Date Doesn't Submit - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=117d164> |
| 18:03 |
* kmlussier |
just set 2.11.2 and 2.10.9 as milestones and then thought, wait, didn't we just release those? |
| 18:26 |
* kmlussier |
would love to see checkboxes on this page - https://launchpad.net/evergreen/2.11/2.11.2 - with an actions menu to perform batch updates on the bugs. |
| 19:05 |
|
rlefaive joined #evergreen |
| 03:48 |
|
jonadab joined #evergreen |
| 05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:10 |
|
rjackson_isl joined #evergreen |
| 07:17 |
|
agoben joined #evergreen |
| 08:06 |
|
rlefaive joined #evergreen |
| 14:46 |
berick |
lot of people out there using PG 9.5? |
| 14:48 |
Dyrcona |
berick: Considering upgrading to 9.5 from 9.2 next month. |
| 14:49 |
berick |
Dyrcona: good to know. trying to figure out where to upgrade to.. also on 9.2 here. |
| 14:49 |
csharp |
berick: I'm planning to start testing in PINES for 2.12/Labor Day upgrade |
| 14:49 |
berick |
csharp: *nod* |
| 14:49 |
Dyrcona |
berick: I believe NOBLE just upgraded to 9.4. |
| 14:49 |
csharp |
I'm using 9.5 on a standalone EG server for the governor's mansion and I haven't seen problems, but it's a tiny dataset |
| 14:49 |
csharp |
and no transaction load |
| 14:50 |
csharp |
9.4 rox |
| 14:50 |
berick |
i have it on my test vm's. been fine, but yeah, no load |
| 14:51 |
Bmagic |
berick: we are on 9.5 atop 16.04 |
| 14:52 |
berick |
Bmagic: cool, no issues? |
| 14:52 |
csharp |
just pay attention to the posix/THP issue that I hit last year: http://libmail.georgialibraries.org/pipermail/open-ils-general/2016-February/012736.html (plus miker's caveats in that thread) |
| 14:52 |
csharp |
heh |
| 14:53 |
Bmagic |
transparent huge pages are turned off for us as well |
| 14:54 |
Bmagic |
otherwise, we haven't done any of the other things mentioned on that thread from csharp |
| 14:54 |
miker |
basic testing of 9.6 shows it should work fine, too, fwiw. parallel seq scans! tsearch phrases! faster on big boxen! |
| 14:55 |
Bmagic |
parallel seq scans sounds nice! |
| 14:58 |
csharp |
JBoyer: miker: http://pastebin.com/qfL43KAS |
| 14:58 |
* csharp |
transits himself from office to home - will check back from there |
| 14:59 |
kmlussier |
miker or others: Is bug 1485374 something that can be merged rather soonish? It has a signoff from Dyrcona, but when I asked about it at the hack-a-way, my recollection was that it wasn't ready to go in yet. |
| 14:59 |
pinesol_green |
Launchpad bug 1485374 in Evergreen "Use client TZ in the database when supplied to the server" [Wishlist,Confirmed] https://launchpad.net/bugs/1485374 |
| 15:05 |
|
mmorgan1 joined #evergreen |
| 15:06 |
miker |
kmlussier: it looks good to me, and will cause testing :) |
| 15:07 |
miker |
merging will cause testing, I mean |
| 15:07 |
JBoyer |
This isn't necessarily a discussion I'm eager to have now, but has there ever been any discussion of only ever storing UTC in the db and only applying a TZ on the client? |
| 15:14 |
|
maryj joined #evergreen |
| 15:22 |
* csharp |
returns |
| 15:41 |
Dyrcona |
Well, looks like we don't have wunder any more. |
| 16:18 |
|
JBoyer joined #evergreen |
| 16:55 |
|
mmorgan joined #evergreen |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:08 |
|
mmorgan left #evergreen |
| 21:11 |
pinesol_green |
[evergreen|Jane Sandberg] Docs: authority_control_field script --days-back feature - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3b36b46> |
| 23:56 |
|
abowling1 joined #evergreen |
| 01:23 |
|
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 |
| 03:50 |
|
abowling joined #evergreen |
| 04:34 |
|
jonadab joined #evergreen |
| 05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:14 |
|
rjackson_isl joined #evergreen |
| 07:16 |
|
agoben joined #evergreen |
| 07:56 |
|
lualaba joined #evergreen |
| 10:09 |
berick |
mmorgan: ohh, right, i was not considering all-day closing |
| 10:14 |
kmlussier |
gmcharlt / miker / dbwells: Are we still planning for a point release today? |
| 10:15 |
miker |
kmlussier: checking, but I think a couple of patches are yet to be merged ... and, I've got a fix for a vandelay-via-acq issue on opensrf master (which I think you said you had problems with) when activating a PO |
| 10:17 |
kmlussier |
miker: Any specific patches you want me to look at? The issue I had was related to the bundling / chunking thing, I think. |
| 10:17 |
* kmlussier |
can look at that one. |
| 10:22 |
|
jvwoolf joined #evergreen |
| 10:23 |
kmlussier |
Has anyone running the web client noticed a lot of log bloat? I've found that the two MassLNC VMs that are running the web client run out of space very quickly. I never have any problem on the VMs that are webby free. |
| 10:26 |
kmlussier |
I reduced the log level to 2 last week, but it's still a problem. I suppose I can reduce the log level even further, but that won't be an option for production servers. |
| 10:31 |
kmlussier |
Ah, I see. The earlier bundling / chunking fix only addressed the pull list issue. miker: are you planning to add the vandelay fix to the same branch as the pull list fix? If so, I'll hold off on testing. |
| 10:31 |
csharp |
hmm - I'm curious about the types of messages that are causing that |
| 10:31 |
JBoyer |
kmlussier, can you post some samples somewhere so we can try to see what kinds of messages you're getting and if they can be fixed/toned down? |
| 10:31 |
miker |
kmlussier: I can, if that's easier for you |
| 10:32 |
kmlussier |
JBoyer: Sure, but I just cleared them out this morning. I'll post something later when they've had some time to grow. |
| 10:33 |
JBoyer |
kmlussier++ |
| 10:33 |
miker |
kmlussier: well, it's less work for me to not create a new bug, so I'll add to the same branch :) |
| 10:34 |
kmlussier |
Works for me |
| 10:39 |
kmlussier |
Is anyone actively testing the latest branch at bug 1657237? |
| 10:39 |
pinesol_green |
Launchpad bug 1657237 in Evergreen "Trigger function maintaining hold-target mapping not well constrained" [Critical,Confirmed] https://launchpad.net/bugs/1657237 |
| 10:41 |
miker |
kmlussier: I know of several sites that are actively using it in production ... so, yes? |
| 10:41 |
kmlussier |
miker: I was thinking of somebody who could add a signoff to it. :) |
| 10:50 |
|
bos20k joined #evergreen |
| 11:02 |
miker |
kmlussier: branch at http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp1657885-alt-pull-list-print updated (this does fix PO activation for some broken cases) |
| 11:02 |
miker |
updating the LP ticket now |
| 11:02 |
kmlussier |
OK, thanks. I'll test it now. |
| 11:03 |
JBoyer |
miker, merge away! It fixed up the migration and dev servers that I had heretofore ignored with no problems. |
| 11:04 |
miker |
JBoyer: thanks! |
| 11:11 |
|
khuckins joined #evergreen |
| 11:33 |
pinesol_green |
[evergreen|Mike Rylander] LP#1657237: Rewrite the hold target cache - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cbe4cae> |
| 11:50 |
|
bmills joined #evergreen |
| 12:13 |
|
sandbergja joined #evergreen |
| 12:22 |
kmlussier |
miker: I noticed when testing Vandelay imports on OpenSRF 2.4, I'm not getting the usual updates on progress. Looking at your comments in the commit, I'm guessing that's expected? |
| 12:22 |
miker |
kmlussier: it is ... does the import succeed? |
| 12:24 |
miker |
kmlussier: I'll see if I can think of a good way to retain the behavior for 2.4 |
| 12:24 |
kmlussier |
miker: Yes, it does. But for a larger one, the progress bar never went away when the import was complete. When importing a smaller set of records, that wasn't a problem. |
| 12:25 |
miker |
kmlussier: gotcha. I'll see what I can do. do updates show up with opensrf master? (or are you not testing that yet?) |
| 12:25 |
kmlussier |
miker: Yes, they do in opensrf master. And they also work in opensrf master, so that's a big improvment. :) |
| 12:26 |
miker |
:) |
| 12:37 |
miker |
kmlussier: the branch is updated ... that should bring back the update stuff for 2.4 |
| 16:56 |
pinesol_green |
Launchpad bug 1392396 in Evergreen "Wishlist: Action Trigger for new user creation" [Wishlist,Fix released] https://launchpad.net/bugs/1392396 |
| 16:59 |
berick |
hah, there is already an 'au.create' even fire in the patron update API |
| 16:59 |
berick |
*event |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:08 |
|
mmorgan left #evergreen |
| 17:23 |
gmcharlt |
I've uploaded 2.10.9 and updated the downloads page |
| 17:23 |
gmcharlt |
I'll check in later this evening for 2.11.2 and to do the release announcement |
| 05:02 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:47 |
|
tspindler joined #evergreen |
| 06:57 |
|
agoben joined #evergreen |
| 07:13 |
|
rjackson_isl joined #evergreen |
| 09:58 |
* JBoyer |
feels for Dyrcona. Many are the LPs in my head, but faster are the workarounds and more work waits. :( |
| 10:22 |
|
Christineb joined #evergreen |
| 10:28 |
Dyrcona |
Great....The two servers where I've tried yaz-client get connection refused, but someone is connecting because the number of simple2zooms > 1. |
| 10:28 |
Dyrcona |
I just wanted to test the configuration, but I don't remember from where I tested it successfully last time. |
| 10:29 |
Dyrcona |
Maybe the training server? |
| 10:52 |
|
jvwoolf joined #evergreen |
| 11:23 |
|
abowling joined #evergreen |
| 14:53 |
jeff |
i see some queries involving auditor.asset_copy_history in your future. |
| 14:56 |
|
collum joined #evergreen |
| 14:59 |
Dyrcona |
Hmm... Can I tell psql to fill a variable from a file, one line at a time? Something tells me, "No." |
| 15:00 |
berick |
recently vacuum-full'ed auditor.asset_copy_history on a test server after removing old entries... table size went from 127G to 11G. woot. |
| 15:00 |
berick |
in less than 20 minutes, no less |
| 15:02 |
|
mmorgan1 joined #evergreen |
| 15:03 |
csharp |
@love vacuum full |
| 15:03 |
pinesol_green |
csharp: The operation succeeded. csharp loves vacuum full. |
| 16:54 |
Dyrcona |
It apparently has no concept of keep alive packets. |
| 16:55 |
phasefx |
Stompro: it's the staff client doing that; the web staff client isn't so zealous. Look at patron/search_form.js, line 372 |
| 16:57 |
phasefx |
Stompro: you could comment that out on the server-side and be okay, I think |
| 17:02 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:08 |
|
mmorgan left #evergreen |
| 17:12 |
Stompro |
Thanks, I'm trying to figure out why this is done. it would be one thing if names starting/ending with numbers couldn't be registered... |
| 17:19 |
Stompro |
Pre commit f7db7f578e6f numbers were allowed, then it was changed to allow unicode characters but to exclude digits. I wonder if that was on purpose or not? |
| 03:41 |
|
serflog joined #evergreen |
| 03:41 |
|
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 |
| 05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:15 |
|
rjackson_isl joined #evergreen |
| 07:29 |
|
agoben joined #evergreen |
| 08:01 |
|
kmlussier joined #evergreen |
| 10:50 |
kmlussier |
rjackson_isl: There are times when account adjustments are used even if those library settings are not enabled, but it's not for lost item returns. |
| 10:53 |
rjackson_isl |
kmlussier++ |
| 10:53 |
kmlussier |
rjackson_isl: More detail here: http://docs.evergreen-ils.org/2.9/_circulation_4.html. But it looks like those adjustments are always applied, regardless of settings, when overdue fines are adjusted after marking an overdue item lost. |
| 10:57 |
al-muradi |
hey thanks for replies. yes the server we are testing on is a bit weak.. just 3GB of RAM |
| 10:59 |
al-muradi |
but it is a fresh debian installation and nothing else is running on it.. |
| 11:03 |
phasefx |
al-muradi: if you're doing a full stack on one server (database, apache, memcached), then you want it to be beefy. But if you're just playing with it, and aren't going to have multiple concurrent users, then it'll probably be okay |
| 11:04 |
* phasefx |
uses 4GB minimum for his virtual machines |
| 11:06 |
al-muradi |
m. i see.. |
| 11:08 |
al-muradi |
so there is no threads or amounts that one can cut on somewhere in the eg.conf or ejabberd confs.. at least for testing |
| 11:09 |
phasefx |
al-muradi: there's all sorts of tuning one can do, but I don't know what would be best for you given your constraints and your intended uses. The number of Apache children to spawn at startup is configurable |
| 11:09 |
berick |
3G ram is plenty for testing |
| 11:09 |
phasefx |
berick++ |
| 11:10 |
phasefx |
al-muradi: I think the real test is to see how it performs while you're using it |
| 11:10 |
berick |
using a default install, i would expect apache to start up in a matter of seconds on a 3G ram server. if it's not, something is probably not right.. |
| 11:10 |
al-muradi |
why does one need so many apache children, actually? |
| 11:11 |
berick |
al-muradi: how many is it starting? |
| 11:13 |
berick |
ps ax | grep apache |
| 11:13 |
al-muradi |
no |
| 11:14 |
al-muradi |
they are all apache2 -k start |
| 11:14 |
berick |
i'm currently working on a 2G ram test server. I have 14 total apache processes. half of them are apache-websockets. |
| 11:14 |
berick |
ok |
| 11:14 |
berick |
well, in any event, 18 is more than I would epxect, but it's not that high |
| 11:15 |
berick |
try changing the apache StartServers config to 5, see if that helps at all |
| 11:16 |
al-muradi |
like in the mpm prefork thing |
| 11:16 |
al-muradi |
? |
| 11:16 |
berick |
in /etc/apache2/mods-enabled/mpm_prefork.conf |
| 11:16 |
berick |
yeah |
| 11:19 |
al-muradi |
mmm seems the same |
| 11:20 |
al-muradi |
also memory is still just using 1500mb.. cpu usage is 100% |
| 11:20 |
berick |
hm, ok |
| 11:21 |
berick |
sounds like something is wrong, then. have you tested in 'srfsh' yet? |
| 11:21 |
al-muradi |
it gets stable more quickly now, tho |
| 11:21 |
berick |
so, like phasefx asked.. does it work after it stabililizes? |
| 11:21 |
al-muradi |
just two minutes.. |
| 11:22 |
berick |
how many cpu cores? |
| 11:22 |
al-muradi |
to see what happens.. |
| 11:22 |
al-muradi |
2 cores |
| 11:23 |
berick |
hm, 2 cores might have something to do with it. |
| 11:24 |
berick |
i generally use 4 cores for my VM's. haven't tested on 2 in some time. |
| 11:24 |
berick |
don't know how it compares |
| 11:25 |
berick |
when apache first starts, there is a lot of CPU churning |
| 11:27 |
al-muradi |
ah allright. so it might just be that. will try and get a better machine to compare.. |
| 11:27 |
berick |
if raising the cpu core count is not an option, i'd lower StartServers to 2 |
| 11:28 |
berick |
but that may just be offsetting the delay, depending on how busy the test server gets |
| 11:29 |
bshum |
"Some thousand records" to be added... might want more memory down the road too. |
| 11:30 |
bshum |
3 GB is what I'd call bare minimum for concerto-sized test systems. With anything more real, I'd want more memory to avoid weirdness. |
| 11:30 |
|
mmorgan1 joined #evergreen |
| 11:43 |
|
al-muradi joined #evergreen |
| 11:51 |
|
bmills joined #evergreen |
| 12:01 |
|
brahmina joined #evergreen |
| 12:01 |
al-muradi |
uhm and anybody has seen this error before, when logging in with a client? Method [open-ils.storage.actor.org_unit.descendants.atomic] not found for OpenILS::Application::Storage |
| 12:16 |
phasefx |
al-muradi: have you tweaked your org hierarchy at all? or are you using stock concerto test data? |
| 12:17 |
al-muradi |
stock data |
| 12:20 |
|
jihpringle joined #evergreen |
| 12:20 |
phasefx |
al-muradi: this is a little out of date, but it's my general strategy for troubleshooting: https://wiki.evergreen-ils.org/doku.php?id=troubleshooting:checking_for_errors The OpenSRF commands need to replaced with their osrf_control equivalents |
| 12:46 |
al-muradi |
happened before during installation, for some reason some cpan modules were not installed |
| 12:47 |
al-muradi |
thanks a lot for the quick answers. |
| 12:47 |
phasefx |
al-muradi: you're welcome |
| 12:48 |
kmlussier |
al-muradi: I hope your Evergreen testing goes well! |
| 12:48 |
phasefx |
I sometimes think we need to set up mirrors for every dependency, and rig the build process to fallback on those if needed |
| 12:49 |
al-muradi |
I didnt have this problem with the 64 bit version, though |
| 13:04 |
csharp |
al-muradi: 32-bit OSes aren't well-tested nowadays - I think 64-bit is pretty much assumed |
| 13:06 |
al-muradi |
abandonware-ils |
| 13:17 |
bshum |
csharp: "aren't well tested" meaning perhaps, "not tested at all" |
| 13:17 |
bshum |
:) |
| 13:21 |
rhamby |
I think it means "wait, we still release that?" |
| 13:26 |
bshum |
I guess it doesn't explicitly say to use 64-bit editions in the README |
| 13:26 |
bshum |
On the downloads page, it does say that for Ubuntu |
| 14:36 |
* kmlussier |
agrees with berick that it was funny. |
| 14:45 |
|
dteston joined #evergreen |
| 16:40 |
|
gmcharlt joined #evergreen |
| 17:02 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 17:03 |
phasefx |
speaking of dependencies... |
| 17:04 |
phasefx |
npm ERR! cb() never called! |
| 17:06 |
|
mmorgan left #evergreen |
| 00:50 |
|
Mark__T joined #evergreen |
| 05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:12 |
|
agoben joined #evergreen |
| 07:54 |
|
collum joined #evergreen |
| 08:11 |
|
kmlussier joined #evergreen |
| 08:40 |
|
mmorgan joined #evergreen |
| 08:51 |
|
yboston joined #evergreen |
| 08:52 |
|
rhamby joined #evergreen |
| 09:09 |
pinesol_green |
[evergreen|Jeanette Lundgren] LP#1494362 Docs: oversized screenshot - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cb07714> |
| 09:28 |
jeff |
like like actor_usr_family_name_unaccent_idx may have an unqualified function call that presents a pg_restore challenge. |
| 09:29 |
* jeff |
looks |
| 09:29 |
* Bmagic_ |
wakes |
| 09:50 |
JBoyer |
csharp++ |
| 09:50 |
JBoyer |
I suppose I can start that process too, need to update our mig server anyway. |
| 09:51 |
jeff |
in my case, this was a fresh db on pg 9.4 created with evergreen 2.11.1 tarball eg_db_config |
| 09:51 |
* csharp |
uses -Fd to take advantage of multiple cores on test DB server |
| 09:53 |
* jeff |
nods |
| 09:54 |
jeff |
doing a pg_dump with -Fd and -j32 is always fun to see run. |
| 09:54 |
csharp |
-j48 here |
| 09:54 |
csharp |
(64 cores) |
| 09:54 |
jeff |
also fun last night was turning a test aws instance into a BIG test aws instance just to run pingest. |
| 09:54 |
csharp |
:-) |
| 09:57 |
jeff |
(and then remembering to turn it off again when i was done) |
| 10:00 |
csharp |
heh |
| 13:35 |
|
afterl joined #evergreen |
| 13:41 |
csharp |
berick++ - thanks |
| 13:42 |
|
tspindler joined #evergreen |
| 13:44 |
berick |
csharp++ terran++ # testing |
| 13:44 |
berick |
well, using |
| 13:44 |
* berick |
is planning to roll out the new targeter after our 2.9 upgrade |
| 13:46 |
|
rgagnon joined #evergreen |
| 13:46 |
terran |
berick++ for such a quick fix! |
| 13:50 |
|
ohiojoe joined #evergreen |
| 16:02 |
remingtron |
kmlussier: thanks! |
| 16:18 |
kmlussier |
Bah! I need to re-read the grammar in my LP comments before I hit submit. |
| 16:31 |
miker |
kmlussier: :) ... responded. it's the full fix |
| 16:32 |
kmlussier |
miker: Ok, thanks! |
| 16:32 |
* kmlussier |
will try to look at it today if nobody beats her to it because it's been causing her headaches on her test VMs. |
| 16:42 |
miker |
kmlussier: thanks! |
| 16:42 |
miker |
kmlussier: have you been using opensrf master on your VMs? |
| 16:42 |
miker |
because I don't think it should be causing problems on opensrf 2.4 or before |
| 16:44 |
|
mmorgan joined #evergreen |
| 16:44 |
kmlussier |
And then I try to upload a bunch of records and the upload hangs. |
| 17:00 |
|
afterl left #evergreen |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:00 |
|
jlundgren left #evergreen |
| 17:01 |
|
khuckins__ joined #evergreen |
| 17:04 |
csharp |
JBoyer: jeff: I can confirm that the same thing happens on our production data: http://pastebin.com/YR7EfSGb |
| 00:43 |
|
bmills joined #evergreen |
| 05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 05:21 |
|
gmcharlt joined #evergreen |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:14 |
|
rjackson_isl joined #evergreen |
| 10:06 |
berick |
csharp: iirc, it's pulling data from aged_circulation now |
| 10:07 |
csharp |
right - and action.circulation and action.aged_circulations are huge and are getting seq scans |
| 10:10 |
berick |
got the original query and/or analyze? |
| 10:10 |
csharp |
I'm running an explain analyze now on our test server - coming soon (or not) |
| 10:10 |
csharp |
argh - it's not giving me any useful data |
| 10:11 |
csharp |
http://pastebin.com/SHumZdwj |
| 10:11 |
JBoyer |
You'll likely have to run some of the queries inside it by hand to see what's really happening. postgres really doesn't explain functions. :/ |
| 10:12 |
berick |
yeah... |
| 10:14 |
csharp |
it's action.all_circ_chain, and it contains 2 loops |
| 10:39 |
berick |
caching should not be any different w/ the new auth code. (it all uses the same C cache client) |
| 10:39 |
JBoyer |
Shoot. Well, you said you wanted to get through circ anyway, I'll stop grasping at straws. |
| 10:40 |
berick |
running out of children is, of course, a problem |
| 10:41 |
bshum |
krvmga: If there's an email text gateway for the SMS config, i don't see why not. |
| 10:42 |
bshum |
But I haven't tested it personally in any way. |
| 10:42 |
bshum |
And who knows with google voice, vs. I assume you mean something like Project Fi users |
| 10:42 |
berick |
csharp: were you also seeing no-children for both open-ils.auth and auth_internal? it may just be that the login process takes longer now, just enough to throw off the delicate balance of max_children |
| 10:42 |
csharp |
berick: just auth, not auth_internal |
| 10:42 |
berick |
ok |
| 10:46 |
bshum |
krvmga: yeah I just read over this article about Project Fi integration for SMS/email - https://support.google.com/fi/answer/6356597?hl=en |
| 10:47 |
bshum |
But I kind of hate it, given the precarious nature of hangouts vs. sms vs. google voice vs. whatever else google is doing under the hood with all that. |
| 10:47 |
krvmga |
yes, thanks. i was looking at the same. |
| 10:47 |
bshum |
They keep changing their minds over there. |
| 10:47 |
|
Christineb joined #evergreen |
| 10:48 |
bshum |
Live testing, whee |
| 10:54 |
csharp |
berick++ # adding the parent_circ index to aged_circulation works - now waiting for index creation to finish on our overloaded live DB :-) |
| 10:54 |
berick |
awesome! |
| 10:54 |
berick |
csharp: if you open a bug (when you have time) i'll pitch in |
| 16:23 |
david___ |
Thanks for the input... |
| 16:24 |
|
david___ left #evergreen |
| 16:50 |
|
tsadok joined #evergreen |
| 17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:04 |
|
mmorgan left #evergreen |
| 18:08 |
|
rlefaive joined #evergreen |
| 19:25 |
|
_adb joined #evergreen |
