| 00:34 |
pinesol_green |
[evergreen|Kyle Huckins] LP#1534787 Patron Message Center port - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a6f1a4f> |
| 03:08 |
|
abowling joined #evergreen |
| 05:02 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:03 |
bshum |
jetlag-- |
| 07:03 |
bshum |
breakfast++ |
| 07:17 |
|
rjackson_isl joined #evergreen |
| 09:51 |
* pinesol_green |
brews and pours a cup of Ethiopia Yirgacheffe Koke, and sends it sliding down the bar to Bmagic |
| 09:52 |
* Bmagic |
sits up at attention |
| 09:52 |
Bmagic |
Ethiopia knows what they are doing |
| 09:53 |
Dyrcona |
Hmm.. I just setup opensrf on a test VM. Services are up and running, but when I ran srfsh, I got this "Unable to bootstrap client for requests" |
| 09:56 |
Dyrcona |
log says it can't authenticate with jabber... |
| 09:57 |
* csharp |
suspects the ejabberd nightmare he experienced a couple of weeks ago |
| 09:57 |
Dyrcona |
Nope. Simpler than that. |
| 09:57 |
Dyrcona |
I was put the password in for the router user when I wanted the opensrf user's password, in .srfsh.xml. |
| 09:57 |
csharp |
ah |
| 09:58 |
Dyrcona |
And I got 4 for the opensrf.math test, so that works. :) |
| 09:59 |
Dyrcona |
Next, I get to transpose our Apache 2.2 config to Apache 2.4. |
| 10:02 |
* Dyrcona |
is preparing to upgrade to Debian 8. |
| 10:02 |
berick |
csharp: thanks! taking a look |
| 10:49 |
dbs |
JBoyer++ |
| 10:49 |
Dyrcona |
dbs++ |
| 10:50 |
Dyrcona |
JBoyer++ |
| 10:50 |
Dyrcona |
I usually use localhost on my test VMs. |
| 10:50 |
Dyrcona |
I used the FQDN of the local machine in production. |
| 10:51 |
Dyrcona |
So, think I'll switch to localhost. |
| 10:53 |
Dyrcona |
Fun thing: I have 3 config branches: 2.10, 2.11, and master, so that's a couple of git checkout; git cherry-pick to keep them all in sync. |
| 13:22 |
Dyrcona |
And, a search worked. This is promising. :) |
| 13:22 |
|
mllewellyn joined #evergreen |
| 13:29 |
Dyrcona |
All right, I don't know why logger complained like that. |
| 13:30 |
Dyrcona |
Maybe I need the full path? I'll try that after I test a z39.50 search. |
| 13:34 |
|
pgardella joined #evergreen |
| 13:35 |
Dyrcona |
Well, I guess the little machine is struggling. It timed out after 30 seconds. |
| 13:39 |
Dyrcona |
This doesn't look right: "searches":{"author":{"term":"coelho"},"keyword":{"term":"eg."}}, Looks like part of the index name ends up as a search tem. |
| 13:39 |
Dyrcona |
s/tem/term/ |
| 13:41 |
Dyrcona |
That comes from this Z search: find @attr 1=1003 coelho |
| 13:41 |
pgardella |
Good afternoon, everyone! I'm trying to restore a backup of the evergreen database onto another server for testing, and have run into some errors I've not hit before. Namely, functions not existing: |
| 13:41 |
pastebot |
"pgardella" at 64.57.241.14 pasted "missing functions" (8 lines) at http://paste.evergreen-ils.org/45 |
| 13:42 |
pgardella |
this was with a -Fc backup of our live DB |
| 13:43 |
pgardella |
Anyone seen this before? |
| 05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:15 |
|
NawJo joined #evergreen |
| 07:19 |
|
rjackson_isl joined #evergreen |
| 07:23 |
|
book` joined #evergreen |
| 07:35 |
bshum |
We'll be putting comments on there and adding links to stuff |
| 07:35 |
NawJo |
Yes! |
| 07:36 |
|
JBoyer joined #evergreen |
| 07:39 |
bshum |
NawJo: Okay, emailed you a reply with some instructions about the DCO. |
| 07:39 |
bshum |
I'll play with the git changes later today, but look forward to testing everything out |
| 07:40 |
NawJo |
thank you a lot! I just received the mail :) |
| 07:41 |
bshum |
NawJo++ |
| 08:29 |
NawJo |
@bshum I've just emailed git admins. requesting the permission to commit to the Evergreen repository :) |
| 13:55 |
Dyrcona |
Rather, git rebase says no changes.... |
| 13:55 |
Dyrcona |
Anyway, git rebase --skip fixes it if you ever run into that. |
| 14:15 |
jeffdavis |
bug 1662297 |
| 14:15 |
pinesol_green |
Launchpad bug 1662297 in Evergreen "Install directory hardcoded in web client build and tests" [Undecided,New] https://launchpad.net/bugs/1662297 |
| 14:17 |
jeffdavis |
^ not sure how critical this is, but it looks like web client won't build out of the box unless you have installed in /openils ? |
| 14:18 |
jeffdavis |
It built for me with "Done, without errors." at the end, but there were warnings related to the above issue and the web client doesn't actually work |
| 14:23 |
gmcharlt |
kmlussier: because of the reingest, I'm not inclined to backport it |
| 16:20 |
|
jvwoolf joined #evergreen |
| 16:36 |
|
mmorgan joined #evergreen |
| 16:44 |
|
rlefaive joined #evergreen |
| 17:02 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:06 |
|
mmorgan left #evergreen |
| 18:27 |
|
abneiman_ joined #evergreen |
| 18:46 |
|
ejk joined #evergreen |
| 19:08 |
|
ats-jc joined #evergreen |
| 19:45 |
|
rlefaive joined #evergreen |
| 20:52 |
|
jvwoolf joined #evergreen |
| 22:45 |
pinesol_green |
[evergreen|Kyle Huckins] LP#1537217 Precat Checkout Circ Modifier - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=79fafc2> |
| 01:54 |
|
ATS-JC joined #evergreen |
| 02:04 |
|
gsams_ joined #evergreen |
| 04:09 |
|
abowling joined #evergreen |
| 05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:29 |
|
rjackson_isl joined #evergreen |
| 07:33 |
|
agoben joined #evergreen |
| 07:53 |
|
kmlussier joined #evergreen |
| 09:46 |
csharp |
kmlussier: I just removed myself - thanks for the poke |
| 09:47 |
kmlussier |
csharp: OK, I think I'm going to apply a 2.12 milestone to that one. See if we can get it in for the upcoming release. |
| 09:47 |
* csharp |
would love to see that feature implemented (though Canceled Transit may remove the urgency for it) |
| 09:49 |
* mmorgan |
would like to see that go in, too, and may try to carve out some time to test it. |
| 09:53 |
csharp |
mmorgan: I intentionally separated out the "Abort -> Cancel" changes into the second commit so they can be tested separately (since they're really not the same issue), just adding context for testing (if you get around tuit) |
| 09:55 |
|
dteston joined #evergreen |
| 09:57 |
mmorgan |
csharp: Gotcha. We love the new status, but would also like to be able to identify the source and destination of the canceled transits when necessary. |
| 10:09 |
* berick |
adds a note to 1347774 |
| 10:16 |
|
ATS-JC joined #evergreen |
| 10:20 |
bshum |
As a general musing... if we were trying to take action on https://bugs.launchpad.net/evergreen/+bug/697926 to change the locale name for ar-AR to ar-JO.... |
| 10:20 |
pinesol_green |
Launchpad bug 697926 in Evergreen "change ar-AR to ar-JO for more accurate locale" [Low,Confirmed] - Assigned to Ben Shum (bshum) |
| 10:20 |
bshum |
I was thinking that we should just be able to rename all the directory and files in git and then sync it back. |
| 10:20 |
bshum |
I don't think there's any way to really test it though, given the limitations of how things sync with Launchpad translations. |
| 10:20 |
bshum |
Anyone object if we just proceed and do cleanup if it goes wrongly? :) |
| 10:21 |
bshum |
(I was thinking to ask the translators to pause their work before the sync so that we make sure to capture all the new strings prior to moving things around) |
| 10:24 |
kmlussier |
bshum: Would all translators need to pause their work or just the person working on the arabic files? |
| 10:25 |
bshum |
kmlussier: I want to say only arabic since that's the one we want to move |
| 10:26 |
bshum |
But this is new to me so I'm not sure :) |
| 14:19 |
berick |
the user no longer has to accept the permissions at run time |
| 14:19 |
* jeff |
defers to berick again |
| 14:19 |
berick |
it happens when the app is installed |
| 14:19 |
kmlussier |
berick: Oh, good. I'll carry on with testing then. |
| 14:19 |
jeff |
i don't like that Hatch gets such permissions, but that might be for another time. |
| 14:19 |
berick |
note to self: fix docs |
| 14:20 |
berick |
jeff: agreed, but at this point, if it works for someone besides me, i'm throwing a party |
| 14:20 |
Dyrcona |
jeff: Everything wants the keys to the kingdom these days. |
| 14:20 |
berick |
kmlussier: consider me on call for your testing :) |
| 14:20 |
kmlussier |
Ooh! A party? |
| 14:20 |
berick |
well, it is friday |
| 14:21 |
berick |
@bartender hatch-testers |
| 14:21 |
* pinesol_green |
fills a pint glass with Magic Hat Hocus Pocus, and sends it sliding down the bar to hatch-testers (http://beeradvocate.com/beer/profile/96/292) |
| 14:35 |
kmlussier |
Not sure I should be testing anything after drinking something called Hocus Pocus. |
| 14:36 |
JBoyer |
*Biipity-Boppity-Broken!* |
| 14:46 |
Dyrcona |
:) |
| 14:52 |
sandbergja |
The DIG meeting will start in about 8 minutes |
| 15:16 |
kmlussier |
But I can give anyone access who needs it too. |
| 15:16 |
kmlussier |
We aren't stingy with WP credentials. :) |
| 15:16 |
rhamby |
yep, both are accurate as well as kmlussier |
| 15:16 |
Christineb |
it is also possible for me to add collaborators on the list so others can add videos - testing required |
| 15:16 |
kmlussier |
Sorry, meant to say I can give access *to anyone* who needs it. |
| 15:17 |
Christineb |
if anyone is interested in being a collaborator let me know and I will email you the invite so we can test it out |
| 15:17 |
remingtron |
rhamby: kmlussier: thanks for confirming |
| 15:17 |
sandbergja |
Anyone up for getting WP credentials and/or adding this link? |
| 15:18 |
Christineb |
I can add it |
| 16:30 |
|
kmlussier joined #evergreen |
| 16:31 |
berick |
windows doesn't like you either |
| 16:31 |
kmlussier |
berick: Sorry, that disconnect was not a response to your question. |
| 16:31 |
berick |
kmlussier: ok, try this please: open a console, then cd C:\\Program Files (x86)\Hatch |
| 16:31 |
berick |
you may have use quotes on the directory names, tab-complete should help |
| 16:32 |
berick |
once your there do: hatch.bat test |
| 16:34 |
berick |
well, probably it's just C:\Program... |
| 16:34 |
berick |
not c:\\ |
| 16:36 |
* berick |
launches a windows vm |
| 16:37 |
kmlussier |
berick: Sorry, distractions. Unfortunately, I'm going to have to look at this Monday morning. |
| 16:37 |
berick |
kmlussier: ok, no worries, I'll be around |
| 16:37 |
kmlussier |
berick: Thanks! And have a nice weekend! |
| 16:37 |
berick |
kmlussier++ |
| 16:38 |
berick |
you too |
| 16:38 |
berick |
csharp: any more hold targeter issues? |
| 17:01 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 17:04 |
jeff |
open-ils.cstore 2017-02-03 16:35:23 [ERR :11276:oils_sql.c:2522:] open-ils.cstore ERROR inserting config::copy_status object using query [INSERT INTO config.copy_status (holdable,id,name,opac_visible,copy_active,restrict_copy_delete,is_available) VALUES (DEFAULT,1,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT);]: 0 ERROR: null value in column "name" violates not-null constraint |
| 17:05 |
* jeff |
compares last success to see which of the 12 are the 3 expected errors. |
| 17:06 |
jeff |
ah, yup. ignore my paste. that's expected. |
| 01:14 |
|
abneiman joined #evergreen |
| 05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:16 |
|
rjackson_isl joined #evergreen |
| 08:01 |
|
collum joined #evergreen |
| 08:46 |
|
mmorgan joined #evergreen |
| 10:53 |
jeff |
i think people also have stronger opinions on the per-hold booleans vs the per-hold notification targets. in our environment, we've done away with both. |
| 10:54 |
jeff |
your notification settings at the time that the hold goes available are how you are notified for that hold. |
| 10:54 |
jeff |
(with one or two theoretical corner cases that i've on my list to hunt down) |
| 10:55 |
* berick |
tests the tpac, sees that it forces patrons to use the email on the account and provides no way to change the email value |
| 10:56 |
berick |
that kind of renders the whole feature useless, doesn' it? |
| 10:56 |
jeff |
berick: because there is no per-hold email string, just a bool for yes/no. |
| 10:56 |
jeff |
but unlike email, there are per-hold phone_notify and sms_notify (and sms_carrier) settings. |
| 10:57 |
jeff |
which function as both bool and target, iirc. |
| 12:26 |
|
jvwoolf joined #evergreen |
| 12:32 |
|
bmills joined #evergreen |
| 12:38 |
|
mmorgan joined #evergreen |
| 12:46 |
* mmorgan |
catches up |
| 12:52 |
mmorgan |
jeffdavis: Hard to say if the fix for 1086458 made the problem go away entirely. Many variables changed - OSs, workstation hardware, etc. Have not done another concise test since, but my current unscientific impression is that there are still some 'memory leak' issues related to patron searches. |
| 12:54 |
jeffdavis |
mmorgan: understood, thank you |
| 12:59 |
miker |
csharp: re the desire for "stacked" validators and such from the other day, the module loading logic is built such that if you can toss a perl module anywhere that perl can find it for "use", you can create your own validators (and reactors, etc). So if you created a module called, say, PINES::AT::Validators and in there you had subs (like "sub sms_validate {...}' that pulled in and used stock validators in the order you wanted, and did other |
| 12:59 |
miker |
validations as well, you could configure A/T to use them. Just add a validator module (via staff client config) for, say, PINES::AT::Validators::sms_validate and make use of it |
| 13:37 |
miker |
ah, ok ... NOTHING TO SEE HERE! |
| 13:37 |
JBoyer |
:) |
| 13:40 |
miker |
csharp: huh... well, ws should be the id of the workstation, obv, not a string ... recent changes to the staff client? or missing/local changes to the idl? |
| 13:40 |
JBoyer |
csharp, I suppose it's too much to hope that you're testing some toolbar changes on that install? |
| 13:41 |
csharp |
I rebuilt the staff client just in case it was my older local one |
| 13:41 |
csharp |
if someone can easily confirm that it's happening or not, that would help :-) |
| 13:41 |
csharp |
JBoyer: nope :-/ |
| 16:50 |
berick |
in circ, self->retarget is a list |
| 16:50 |
* berick |
patches |
| 16:57 |
|
khuckins_ joined #evergreen |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:06 |
berick |
csharp: _bott_: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=320cc9fe56d38c79da2da064a68fec746ae3385e |
| 17:06 |
berick |
pushed to same branch |
| 17:07 |
|
mmorgan left #evergreen |
| 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 |
| 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 |
