| 00:26 |
|
Guest33082 joined #evergreen |
| 02:39 |
|
collinanderson joined #evergreen |
| 05:06 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:25 |
|
Newziky joined #evergreen |
| 07:26 |
|
TaraC joined #evergreen |
| 07:50 |
|
Shae joined #evergreen |
| 09:13 |
dbs |
jcamins++ |
| 09:13 |
dbs |
also, printing-- |
| 09:14 |
Stompro_home |
kmlussier, doh, didn't see that column, nevermind. |
| 09:15 |
jcamins |
dbs: ooh, you're testing the new Java compilation mode? Compile-to-paper? Run a print-out of a .class file through a scanner and you can run your Java application on any non-Linux, non-BSD, non-Windows, non-Mac computer. |
| 09:16 |
jcamins |
(this weekend I helped a coworker get a Java program running on his new laptop; I have lots of excess hostility toward Java now) |
| 09:16 |
csharp |
java-- |
| 09:16 |
csharp |
@karma java |
| 09:16 |
pinesol_green |
csharp: Karma for "java" has been increased 0 times and decreased 2 times for a total karma of -2. |
| 09:16 |
dbs |
jcamins++ # you need the karma |
| 09:16 |
dbs |
berick++ # for figuring _some_ sort of solution for centralized printing |
| 09:18 |
dbs |
csharp: so do you think OpenJDK + OpenJFX will work on any platform, or is it a matter of "must use Oracle's proprietary Java distribution"? |
| 09:20 |
csharp |
dbs: I'd love to test on Ubuntu - I was actually just going to ask for a spare laptop from one of our IT staff to try |
| 09:22 |
csharp |
screw it, I'll just use virtualbox (for its dead-simple network bridging capabilities) |
| 09:22 |
jeff |
printing-- indeed. |
| 09:22 |
mrpeters |
did i hear someone mention recently that there were scripts to auto-build master on regular intervals? |
| 09:22 |
jeff |
our "print from the opac" setup uses a network receipt printer, an HTTPS call, and CUPS. It takes about 4 seconds at present from click to print. |
| 09:53 |
|
terran left #evergreen |
| 09:54 |
|
terran joined #evergreen |
| 09:59 |
Stompro_home |
Those sandboxes worked great, kmlussier++ mobius++ Bmagic++ |
| 10:00 |
kmlussier |
mmorgan: We should make it a regular thing. :) |
| 10:00 |
kmlussier |
Stompro_home++ #testing |
| 10:02 |
kmlussier |
Stompro_home: On your signoffs, if you're not doing the git signoff, could you add the language that I sent out in the Sandbox email? |
| 10:02 |
* kmlussier |
will update the Bug Squashing Day spreadsheets with Stompro_home 's signoffs. :) |
| 10:03 |
bshum |
Stompro_home: later today, time permitting, I'm hoping to get some more action on the next round of Jessie bugs |
| 10:03 |
Stompro_home |
Sure, I'll do that in 20 min. |
| 10:04 |
* kmlussier |
probably should have added the code from bug 1435938 on the Sandbox that is being used to test bug 1431055 :( |
| 10:04 |
pinesol_green |
Launchpad bug 1435938 in Evergreen "New Feature: Allow Staff to clear Added Content cache" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1435938 |
| 10:04 |
pinesol_green |
Launchpad bug 1431055 in Evergreen "Content Cafe opens in a new window" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1431055 |
| 10:05 |
kmlussier |
OK, I think I need help with this Sandbox. http://mlnc2.mvlcstaff.org/eg/opac/home |
| 10:31 |
csharp |
Bmagic++ |
| 10:33 |
csharp |
@who wishes vim was installed by default on all the major distros |
| 10:33 |
pinesol_green |
jeff_____ wishes vim was installed by default on all the major distros. |
| 10:37 |
berick |
StomproJ: i was about to test bug #1449709 and related bugs (1452366 1452352), but I see you are assigned. are you actively testing? |
| 10:37 |
pinesol_green |
Launchpad bug 1449709 in Evergreen "support caching of compiled Template Toolkit templates" (affected: 1, heat: 8) [Wishlist,New] https://launchpad.net/bugs/1449709 - Assigned to Josh Stompro (u-launchpad-stompro-org) |
| 10:37 |
pinesol_green |
[evergreen|Lynn Floyd] Docs: New chapter for Library Settings Editor - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=578fd40> |
| 10:37 |
pinesol_green |
[evergreen|Remington Steed] Docs: Fix spelling errors in Library Settings docs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=57bd96b> |
| 10:40 |
Bmagic |
Has anyone out there changed the series index fields? Can we include both 440 and 490? |
| 10:40 |
Dyrcona |
Is SIP now doing something different if the client does not explicitly log out? |
| 10:41 |
mrpeters |
Bmagic: i think there is some stuff on the random magic spells page to do that |
| 10:41 |
berick |
StomproJ: in either case, i'll continue testing, since you're not assigned to the other tickets. let me know how your testing goes... |
| 10:41 |
StomproJ |
berick, I tested #1449709 and it seemed to work well, I was just about to update the ticket. |
| 10:41 |
|
jwoodard joined #evergreen |
| 10:42 |
berick |
StomproJ: great, thanks |
| 10:43 |
|
alynn26 joined #evergreen |
| 02:32 |
|
eby joined #evergreen |
| 03:18 |
|
dcook joined #evergreen |
| 03:38 |
|
collinanderson joined #evergreen |
| 04:52 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:48 |
|
terminalfool joined #evergreen |
| 07:15 |
|
mrpeters joined #evergreen |
| 07:36 |
* csharp |
returns from 5-day weekend |
| 09:50 |
|
Dyrcona joined #evergreen |
| 09:58 |
bshum |
jboyer-isl: I hate it when that happens to my /boot too :( |
| 09:59 |
Dyrcona |
eeevil: Seeing as the unless(exists $self->{account}) is in MsgType.pm and MsgType.pm has no account field, and is not a subclass of the server, I think tsbere's check is correct. |
| 10:03 |
* kmlussier |
doesn't want to get her hopes up too high, but is happy to report that she just completed two successful tests on the negative balances branch. |
| 10:08 |
|
Newziky left #evergreen |
| 10:09 |
jeff |
does conditional negative balances and payments by billing type still completely disagree on everything? |
| 10:09 |
* jeff |
will make time to look |
| 10:34 |
jeff |
I like this much better than trying to teach Every Single Thing about future billings. |
| 10:35 |
jeff |
(like yesterday's example of mmpbbt, which iirc pre-dates the future-billing era) |
| 10:35 |
jeff |
Hrm. That could cloud the upgrade script a bit -- the fact that some databases will have billings that were not actually future-dated. |
| 10:42 |
tsbere |
jeff: Dunno if you saw my comment from last night. |
| 10:42 |
tsbere |
eeevil: After more thought I have decided you were partially correct, what I changed the unless test to was not what I wanted. I have now added another commit to the branch to correct that. |
| 10:53 |
|
mtj_ joined #evergreen |
| 11:07 |
pastebot |
"berick" at 64.57.241.14 pasted "combined test branch for bug squashing day" (10 lines) at http://paste.evergreen-ils.org/64 |
| 11:07 |
berick |
FYI, we'll be poking at the branch tomorrow. pasting in case anyone else can use the branch for testing |
| 11:08 |
|
sandbergja joined #evergreen |
| 11:15 |
|
bmills joined #evergreen |
| 11:31 |
kmlussier |
berick++ |
| 14:50 |
mrpeters |
great, thanks jeff |
| 14:50 |
mrpeters |
sorry for the trouble |
| 14:50 |
jeff |
you're welcome! |
| 14:52 |
* tsbere |
sees a pile of emails about keys and testing now |
| 14:52 |
mrpeters |
:( sorry tsbere |
| 14:52 |
tsbere |
mrpeters: At least we know it is working now :D |
| 14:52 |
berick |
mrpeters: cool, will take a look |
| 16:24 |
|
collinanderson joined #evergreen |
| 16:38 |
jeffdavis |
Is anyone here in the habit of purging deleted bib records (i.e. removing them from the database altogether)? If so, how do you do it? |
| 16:40 |
kmlussier |
jeffdavis: C/W MARS has talked about doing this, but I don't think they've found a good solution yet. If you come up with anything, I know they'll be interested in hearing about it. |
| 16:50 |
bshum |
jeffdavis: about a year ago, Dyrcona helped us write a script to help us truly delete bib records that were hanging about for no reason (i.e. never attached copies, never used, etc.) |
| 16:50 |
bshum |
We didn't actually run it yet, cause the process took too long on a test server attempt. |
| 16:51 |
bshum |
But yeah, the idea's been batted around a bit. |
| 16:51 |
bshum |
The trick as I understand it is finding all the places where bibs might hang to something. For us it got interesting with things like acquisitions |
| 16:54 |
Dyrcona |
Yep. |
| 16:55 |
Dyrcona |
Lots of stuff you have to delete when you want to really delete bibs. |
| 16:57 |
bshum |
And triggers to disable. |
| 10:54 |
Bmagic |
berick: It's tripping over loading the Org unit dropdown menu I think |
| 10:56 |
berick |
Bmagic: does it render OK if you load another UI like the Billing Types UI? |
| 10:59 |
jeff |
Dyrcona: ah. drat. and alas, there are no protocol-level headers to tell you this. :-) |
| 10:59 |
kmlussier |
dkyle1: We have some people who were interested in trying your Smart Float branch at bug 1305964. Is that something that's ready for testing or are you still working on it? |
| 10:59 |
pinesol_green |
Launchpad bug 1305964 in Evergreen "Smart Float: self balancing floating collections" (affected: 1, heat: 8) [Wishlist,Triaged] https://launchpad.net/bugs/1305964 - Assigned to Doug Kyle (dkyle) |
| 11:04 |
jeff |
rebase from 2.2 era opac templates to 2.7 era opac templates went off without complaint or catastrophe. hooray! |
| 11:09 |
dkyle1 |
kmlussier: the Smart Float branch is ready for testing, and I'm not working on it at the moment, it has been stable for GRPLs needs. Do you know if those interested have the same shelving locations across orgs that want to Smart Float? |
| 11:10 |
kmlussier |
dkyle1: I'll defer to mmorgan |
| 11:12 |
mmorgan |
dkyle1: Our shelving locs generally are not consistent, but for the items that will float, they potentially could be, if required. |
| 11:12 |
Bmagic |
berick: yes, billing types loads fine |
| 11:16 |
|
mllewellyn joined #evergreen |
| 11:21 |
dkyle1 |
mmorgan: homogeneous shelving locs would be best, but I had some stuff in my generic version to map various org/locs into single smart float configs. I think it was lightly tested working but I was not totally happy with the speed of that function. It has been a while, I need to revisit and look for any uncommited changes. |
| 11:26 |
kmlussier |
Seems to load cleanly on master. |
| 11:27 |
kmlussier |
dkyle1: I'm loading it on a server where mmorgan can take a look at it. But you might want to remove yourself as the assignee on the bug and add a pullrequest tag if you think it's ready. |
| 11:27 |
berick |
Bmagic: no idea what the problem is :( if it were me, i'd have to start digging into the code at this point |
| 11:27 |
* kmlussier |
shifts her attention to all the Sanbox requests we received. :) |
| 11:29 |
mmorgan |
kmlussier: Thanks! |
| 11:30 |
mmorgan |
dkyle1: Thanks, I'll poke at it on kmlussier's test server. |
| 11:37 |
dkyle1 |
kmlussier: I really don't know how ready a feature should be for a pullrequest tag, for example, it has no client side exposure |
| 11:37 |
berick |
dkyle1: pullrequest means you think it's done |
| 11:38 |
berick |
and ready for merging into master |
| 12:07 |
kmlussier |
Bmagic: On bug 1194860 , it looks like we have a signoff, but you have assigned it to yourself. Are you planning to do further work on it? |
| 12:07 |
pinesol_green |
Launchpad bug 1194860 in Evergreen ""You have permission to override some of the failed holds." appearing when it should not for patrons in the OPAC" (affected: 8, heat: 36) [Medium,Confirmed] https://launchpad.net/bugs/1194860 - Assigned to Blake GH (blake-j) |
| 12:08 |
Bmagic |
kmlussier: no, I just saw people assigning things and I figured it was protocol to have it assigned |
| 12:09 |
kmlussier |
Bmagic: Only if you're planning to work on it or test it. I can add a signedoff tag to it, which might increase its visibility the next time a core committer is looking to merge code. |
| 12:10 |
Bmagic |
kmlussier: Ok, do I need to remove myself? |
| 12:10 |
kmlussier |
Bmagic: Sure. |
| 12:17 |
dkyle1 |
mmorgan: a speed issue would be seen at checkin. the main function to time is smart_float.destination. this issue was when using the smart_float.loc_or_group function in the destination function - if I recall, have not had time to revisit yet. |
| 12:34 |
bshum |
Probably two or three times |
| 12:34 |
kmlussier |
I guess I didn't like it as much as your dad did. ;) |
| 12:35 |
* bshum |
actually reads the bug and tries to do something real for the community instead of quoting nonsense. |
| 12:36 |
kmlussier |
OK, my last question inspired by the bug squashing requests... |
| 12:37 |
kmlussier |
Bmagic: We have a request to test bug 1440148 . I was planning to load it on a MassLNC server, but it looks like the code is actually combined with bug 1331174? |
| 12:37 |
pinesol_green |
Launchpad bug 1440148 in Evergreen "Long overdue Items out TPAC OPAC display My Account" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1440148 - Assigned to Michele Morgan (mmorgan) |
| 12:37 |
pinesol_green |
Launchpad bug 1331174 in Evergreen "Long Overdue processing needs org unit settings separate from Lost Processing" (affected: 4, heat: 18) [Wishlist,Confirmed] https://launchpad.net/bugs/1331174 |
| 12:37 |
bshum |
kmlussier: Based on my read of that bug, I would set it to confirmed/triaged for status and remove jeff as the worker, since Bmagic's done some reworking at that point. |
| 12:41 |
Dyrcona |
oops. missed it was already in the channel. |
| 12:41 |
Dyrcona |
too busy to keep up. |
| 12:41 |
Bmagic |
bshum: which bug are you referring to? Also, is mmorgan working on 1440148 ? |
| 12:41 |
kmlussier |
Bmagic: She was the one who requested the Sandbox to test it. |
| 12:43 |
bshum |
Bmagic: Oh I was referring back to kmlussier's bug she mentioned earlier in the scrollback, bug 1174498 |
| 12:43 |
pinesol_green |
Launchpad bug 1174498 in Evergreen "Payment by billing type breakdown" (affected: 7, heat: 38) [Wishlist,Triaged] https://launchpad.net/bugs/1174498 |
| 12:46 |
|
Shae joined #evergreen |
| 12:52 |
jeff |
mmpbbt needs work, i think. i can take a look at what Bmagic has found. |
| 12:52 |
jeff |
because i suspect that we're each running it in production in different versions. |
| 12:53 |
jeff |
and i know that there are issues with regard to future-dated billings (overdues) which may or may not have been addressed in Bmagic's version. |
| 12:54 |
kmlussier |
Bmagic: OK, what I'll do is load the code from working/user/blake/LP1440148_Long_overdue_Items_out_TPAC_OPAC_display_My_Account so that mmorgan can test it. However, once it goes in, I think you'll need to rebase the other branch. |
| 12:57 |
jeff |
overall, i don't know if the best approach is to teach everything to special-case future-dated billings, or to eliminate them. |
| 12:57 |
jeff |
at this point, I don't know which will be more painful. :P |
| 12:59 |
|
bmills joined #evergreen |
| 13:27 |
berick |
and i thought everythign was using checkout.full now |
| 13:27 |
dbs |
and this is using checkout.full |
| 13:28 |
dbs |
request open-ils.circ open-ils.circ.checkout "session-key", {"barcode":"30012000047398","patron":132422},1 |
| 13:28 |
mmorgan |
Bmagic: kmlussier: So is there no need then to test 1440148, since 1331174 fixes it? Should 1440148 be marked as a duplicate? |
| 13:28 |
dbs |
err, no |
| 13:28 |
dbs |
heh |
| 13:29 |
dbs |
I had fallen back to trying plain .checkout because .checkout.full was failing with ye olde "*Network or server failure" in the client |
| 14:53 |
mmorgan |
kmlussier: Bmagic: Yes, that makes perfect sense. |
| 14:53 |
Dyrcona |
Only 3M clients are not working. |
| 14:53 |
jboyer-isl |
Over TCP via carrier pigeon |
| 14:55 |
jeff |
Dyrcona: Can you share the relevant details of your SIP setup? I might be able to make time to test here -- where i can control both the client and the server. |
| 14:55 |
jeff |
Dyrcona: time and ability to pull a selfcheck unit from normal operation would be the only potential blockers there. |
| 14:56 |
Dyrcona |
jeff: We basically run stock on Ubunutu 14.04. We mad a profile for self checks, a profile for PC res, and a profile for a delivery application. |
| 14:56 |
Dyrcona |
jeff: The self check profile is basically the example profile. |
| 14:57 |
Dyrcona |
Here's the thing: a non-3M self check client works just fine. |
| 14:58 |
Dyrcona |
No. |
| 14:58 |
Dyrcona |
Other than, it worked fine until we set up the new servers last night. |
| 14:58 |
Dyrcona |
We've only used PreFork, and we even removed the multiplex code for a bit, but it made no difference. |
| 14:59 |
Dyrcona |
I've been jumping around so much today that I haven't had time to test everything. |
| 14:59 |
bshum |
jboyer-isl: Sigh, so now CollectionHQ is asking me about adding in-house use circ to the counts. |
| 14:59 |
* jeff |
nods |
| 14:59 |
Dyrcona |
I also have 36 libraries, so I can't just up and restart it whenever I feel like it. |
| 17:03 |
|
kbutler joined #evergreen |
| 17:04 |
jeff |
tsbere: can you elaborate on "one of"? which symptom did that fix? |
| 17:04 |
jeff |
(and what other symptoms did you encounter -- since I think I only saw one mentioned. :-) |
| 17:10 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:11 |
|
mmorgan left #evergreen |
| 17:32 |
Bmagic |
berick: Back on that web based column picker. I can have the UI load the copy ID instead of the count and it clues me in that it's "sort of working" see http://slides.mobiusconsortium.org/blake/bill.html |
| 17:36 |
berick |
Bmagic: did you try removing the oils_persist:virtual="true" from the holds_count <field> ? |
| 12:14 |
dbwells |
no, you have to tell ezproxy to not bounce proxy requests to itself, but to allow a login->redirect |
| 12:14 |
dbwells |
sorry, ignore that |
| 12:15 |
dbwells |
When you say "same problem", you still get no login? Or you login and then get the 404? |
| 12:15 |
gsams |
I do not appear to be getting a login at all, it leads to the same address with a 404. |
| 12:15 |
gsams |
though I should probably reset or test at a different computer at this point |
| 12:16 |
gsams |
yeah, 404 no login option given |
| 12:17 |
hopkinsju |
jboyer-isl: Any update on those Ansible playbooks? I'm interested in working on that, but I'd like to have something to serve as a starting point. |
| 12:19 |
dbwells |
gsams: when I visit the URL I pasted above, I get the login prompt. It's possible you have cached redirect? |
| 12:21 |
gsams |
That is possible, I just attempted to request an item from a different computer instead to double check. I'm fixing that now on this computer with that link |
| 15:55 |
Stompro |
I haven't heard from Yamil for a while, Hopefully he is just on vacation. |
| 15:57 |
|
dMiller_ joined #evergreen |
| 16:54 |
Stompro |
Is there a guideline for when working git branches should be purged? I'm assuming that once something gets committed the working branch on git.evergreen-ils.org should be deleted? |
| 17:03 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:06 |
dbs |
Stompro: that's a good assumption, but in practice very little ever gets purged |
| 17:12 |
Stompro |
dbs, I just thought of one reason not to purge, it would make it harder for someone that is looking at an old resolved bug, that wants to see details of a working branch. Rather than clicking on the link to the working branch they would have to track down the commit manually. |
| 17:18 |
|
bmills joined #evergreen |
| 05:06 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:14 |
csharp |
bshum: no biggie - I just got a pinesol_green alert and was checking if it was still up |
| 07:17 |
|
mrpeters joined #evergreen |
| 07:31 |
|
Newziky joined #evergreen |
| 10:38 |
csharp |
yep - it did |
| 10:38 |
csharp |
yay! |
| 10:40 |
mmorgan |
csharp++ |
| 10:44 |
csharp |
okay - so now that I know this process, I'm wondering how it could be improved... |
| 10:45 |
csharp |
the problem in my case was that the vendor didn't get the EDI message because we were testing with berick's testing edi_pusher script, which is configured to exit before actually sending anything |
| 10:45 |
csharp |
but there could be many reasons why that would fail, and there needs to be ways to recover from errors |
| 10:46 |
csharp |
e.g., a "Re-Send Order to Vendor" button somewher |
| 10:46 |
csharp |
e |
| 10:47 |
csharp |
I'm pretty sure I was creating new debits each time I re-activated the PO - that obviously shouldn't need to happen to fix a technical mistake |
| 10:55 |
Bmagic |
yeah, if that was on production, you might take a look at the debits for sure |
| 10:55 |
Bmagic |
csharp++ |
| 10:55 |
csharp |
fortunately we're still on a test server, but these are real orders |
| 11:03 |
Bmagic |
Anyone know where to find the logic that displays the columns in the web based staff client? (for grids) |
| 11:04 |
berick |
Bmagic: start w/ the tt2 for the UI |
| 11:04 |
berick |
it sets the behavior for each grid |
| 11:23 |
Bmagic |
right |
| 11:24 |
berick |
IOW, don't use the copy id as the field through which you access the hasholdscount class |
| 11:24 |
Bmagic |
yeah, I think that is my problem |
| 11:24 |
berick |
create a new holds_count (or whatever) field on the copy |
| 11:25 |
berick |
after you get it set up and restart services, I also suggest testing your IDL changes via srfsh queries first |
| 11:25 |
berick |
jumping straight to the web code creates a lot more opportunities for things to fail up front |
| 11:26 |
Bmagic |
right on |
| 11:27 |
Bmagic |
I tested it via srfsh against a new opensrf call I put into the perl, that is working |
| 11:28 |
berick |
e.g. retrieving a copy w/ fleshed call_number http://pastie.org/10221783 |
| 11:28 |
Bmagic |
ah, that helps |
| 11:28 |
Bmagic |
berick++ |
| 15:50 |
|
mrpeters1 joined #evergreen |
| 15:51 |
|
ericar_ joined #evergreen |
| 15:52 |
Dyrcona |
If it turns out to not work as is, we can always change it in the future. |
| 15:52 |
gmcharlt |
FWIW, I've started putting in test plans in my OpenSRF patches |
| 15:53 |
Dyrcona |
gmcharlt++ # I noticed and would have tried it out, but the meeting came up. |
| 15:54 |
gmcharlt |
in other news |
| 15:54 |
gmcharlt |
#action gmcharlt and eeevil to organize a webstaff client hacking day in July |
| 15:56 |
kmlussier |
terran: That's awesome! |
| 15:57 |
|
ericar_ joined #evergreen |
| 15:57 |
kmlussier |
If anyone needs a Sandbox, try to get the requests in by the end of the week so that we have a bit of time to get them ready. |
| 15:57 |
terran |
I'd really appreciate it if someone would test this fix I posted for bug squashing day: https://bugs.launchpad.net/evergreen/+bug/1454871 |
| 15:57 |
pinesol_green |
Launchpad bug 1454871 in Evergreen "KPAC Hold Notifications - SMS" (affected: 1, heat: 6) [Undecided,New] |
| 15:59 |
bshum |
terran: I'll keep my eye on that one, but probably not till next week. Maybe that'll be something we can test during bug day. |
| 15:59 |
bshum |
KPAC loves misery. |
| 15:59 |
bshum |
Err, misery loves company. |
| 15:59 |
terran |
bshum +1 |
| 16:00 |
bshum |
(also, regrets that I'm late and mostly missed the meeting) |
| 16:00 |
berick |
@who loves misery? |
| 16:53 |
gsams |
I'm pretty sure the config is all correct for this purpose, but I have no idea on the user, and further no idea why I'm getting 404 for requests. |
| 17:14 |
|
mmorgan left #evergreen |
| 17:18 |
dbwells |
gsams: what starting point URL are you trying to visit? |
| 17:26 |
jjk` |
I've upgraded a test system code+schema from 2.3.5 -> 2.7.4. I'm expecting to find instructions on how to rebuild indexes and whatnot in the documentaiton but don't see it. I've started the reingest_2.6_bib_recs.sql which I suspect should take quite some time. Should I be able to search & view any records in the opac at this point? |
| 17:35 |
jjk` |
Okay, I'm starting to see some results now. I guess I wasn't being patient enough. |
| 17:48 |
gsams |
dbwells: texasgroup.worldcat.org, if I understand your meaning |
| 17:49 |
gsams |
dbwells: They would go through the catalog to find an item, then request it. They'd then select their library (Roanoke, in my case) and be presented with the authentication, but it 404s instead. |
| 17:54 |
dbwells |
gsams: I don't completely understand your use case, but based on what I've seen in your configs and what you've said, your SPU should be something like: https://catalog.northtexaslibraries.org:2443/login?url=http://texasgroup.worldcat.org Does that allow you to proxy, or is that where you get the 404? |
| 03:27 |
|
jboyer-isl joined #evergreen |
| 03:29 |
|
jboyer_isl joined #evergreen |
| 03:42 |
|
jboyer-isl joined #evergreen |
| 04:51 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:43 |
|
jboyer-isl joined #evergreen |
| 07:59 |
kmlussier |
Good morning #evergreen! |
| 07:59 |
kmlussier |
@weather 02771 |
| 11:36 |
hopkinsju |
We do that when all copies are under age based hold protection (and we changed that message to be more clear) but I'm feeling like we need to add something for on order records also |
| 11:39 |
Dyrcona |
Yeah, I think we just have the language when age hold protection comes into play. |
| 11:39 |
mmorgan |
Yes, that's true for us as well. No special language for on order items. |
| 11:39 |
Dyrcona |
berick++ # I have been testing the kill circ script branches this morning. |
| 11:40 |
berick |
Dyrcona: sweet |
| 11:40 |
jboyer-isl |
berick: I've specifically removed everything from our db servers over the years. They don't run anything now except the base system and postgres. We used to generate notices and payment reports directly on them, but that's been gone for some time. |
| 11:40 |
Dyrcona |
Basically, just doing circulations and placing holds. |
| 14:39 |
Dyrcona |
I just clicked on the big downloads graphic, didn't choose anything from a menu. |
| 14:42 |
Dyrcona |
I wonder if the two lines devoted to OpenSRF on the egdownloads matrix/table should be changed to one, with a link to the OpenSRF downloads page. |
| 14:42 |
dbs |
Windows failure was undoubtedly my fault for trying to just slide my VBox image over into virt-manager |
| 14:52 |
csharp |
yeah - I'm trying to convert my .vdi into a working .qcow2 with no success yet - the working instance was installed from scratch |
| 15:04 |
|
ericar joined #evergreen |
| 15:56 |
csharp |
@test |
| 15:56 |
pinesol_green |
csharp: What do you mean? An African or European swallow? |
| 16:00 |
bshum |
csharp: Am I spamming you with my experiments? |
| 16:10 |
bshum |
I was toying briefly with seeing how the Cast plugin operated. Freebase API is going away though end of this month, so meh |
| 17:01 |
kmlussier |
jboyer-isl++ |
| 17:01 |
kmlussier |
@quote random |
| 17:01 |
pinesol_green |
kmlussier: Quote #104: "<jeff> that's it. we're all switching to koha, right meow." (added by gmcharlt at 01:16 PM, January 02, 2015) |
| 17:07 |
ohiojoe |
so I *think* I'm ticklishly close to having an evergreen sandbox installed here.. |
| 17:08 |
ohiojoe |
however, when I do the srfsh test, I'm getting "Received no data from server" |
| 17:10 |
|
mmorgan left #evergreen |
| 17:11 |
ohiojoe |
wait a minute |
| 17:11 |
ohiojoe |
settings-tester is telling me that the libdbi PostgreSQL driver was not found in the shared library path |
| 17:30 |
dbs |
ohiojoe: that test in settings-tester should probably have been removed a long time ago |
| 18:16 |
|
wongon joined #evergreen |
| 19:15 |
|
buzzy joined #evergreen |
| 19:41 |
bshum |
@later tell Dyrcona I forgot, did we ever do anything with https://bugs.launchpad.net/evergreen/+bug/1413336 ? Maybe we should add that towards the next series. |
| 08:17 |
|
ericar joined #evergreen |
| 08:28 |
kmlussier |
devi_: You can't import records from a CSV files. You need to import MARC records. |
| 08:29 |
devi_ |
how to obtain MARC records? |
| 08:31 |
kmlussier |
devi_: If you're setting up a test system to see how it works, there is a test dataset called Concerto that can be used. |
| 08:31 |
devi_ |
I have other system with data and want to migrate to new server |
| 08:32 |
kmlussier |
devi_: OK, there is some info in this email thread here, but basically you would be looking to export the records out of your old system into a MARC format. http://markmail.org/message/ojwvigqpldn6wtsg |
| 08:33 |
kmlussier |
devi_: A lot of it depends on what system you were previously using and how easy it is to obtain the records. But most library systems will already have those records in the MARC format. |
| 12:47 |
Dyrcona |
It might have been in a private conversation. |
| 12:47 |
Dyrcona |
We have a few quotes that lack context in the logs. |
| 12:51 |
kmlussier |
I feel really sad that I haven't had a chance to experience the Armenian staff client yet if it is indeed that pretty. I was hoping I might find a link to a screenshot along with the quote. |
| 12:53 |
bshum |
I don't have a copy of all my IRC logs from that time on this laptop, but Dyrcona is probably right that it was a PM I sent or some other remark. |
| 12:54 |
bshum |
Looking at the log of the day it was added, it was during 2.1's development testing and I think I was testing all the languages for the staff client |
| 12:54 |
bshum |
Trying to figure out an i18n error. |
| 12:54 |
bshum |
That was preventing login or something |
| 12:54 |
bshum |
But I might have gotten my bugs and stories mixed up. |
| 12:57 |
* bshum |
grabs a stock 2.8 client to use to get a screenshot for kmlussier |
| 12:58 |
kmlussier |
bshum: Well, I'm not *that* sad. You don't need to go to the trouble. |
| 12:58 |
bshum |
Ouch |
| 12:58 |
bshum |
Yeah that won't work :) |
| 15:59 |
* pinesol_green |
grabs some of mllewellyn's Cupcakes for kmlussier |
| 16:26 |
alynn26 |
Everybody have a good weekend. |
| 16:37 |
|
bmills joined #evergreen |
| 17:17 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 20:10 |
|
wongon joined #evergreen |
| 22:00 |
jeff_ |
Bad Friday for he.net / Linode |
| 22:02 |
|
akilsdonk joined #evergreen |
| 13:22 |
Dyrcona |
bshum++ |
| 13:22 |
|
jwoodard joined #evergreen |
| 13:23 |
Dyrcona |
Bmagic: I'm talking about open-ils.circ.actor.user.checked_out, which is in Circ.pm. I'm probably barking up the wrong tree. |
| 13:24 |
jeff |
Dyrcona: what kinds of tests (if any) do you want to see for selfcheck/jspac/craftsman/script-based removal? Just "release notes + live tests / manual testing as appropriate"? |
| 13:25 |
Dyrcona |
jeff: Yeah, I think release notes + live tests (if possible) plus manual testing should do it. |
| 13:25 |
jeff |
Good deal. |
| 13:25 |
Dyrcona |
If anyone can come up with live tests for these, they may make good models to follow in the future. |
| 13:27 |
jeff |
And I'll reply in-bug, but yes -- that jspac removal branch is intended to be sequential, remove legacy self checkout, remove old bbags interface, remove jspac. The bbags interface and/or dtree removal can be their own bugs. |
| 13:27 |
jeff |
I didn't want to get too bug-happy. |
| 13:27 |
jeff |
But I also didn't want it to be one massive "remove all this" commit either. |
| 13:28 |
bshum |
jeff just wants separate karma bumps for each job well done ;) |
| 13:28 |
bshum |
jeff++ # because he's awesome |
| 13:29 |
jeff |
The karma's nice, but having a cleaner codebase is nicer. :-) |
| 13:30 |
* bshum |
likes testing one thing at a time anyways. |
| 13:30 |
jeff |
*nod* |
| 13:31 |
Dyrcona |
heh |
| 13:31 |
berick |
jeff: i'm sure you saw, but I rebased and cleaned up a bunch in bug #1312308 |
| 13:36 |
berick |
ah, cool |
| 13:40 |
Bmagic |
Dyrcona++ |
| 13:40 |
|
ericar_ joined #evergreen |
| 13:44 |
kmlussier |
So test plans for bug fixes go in the commit message? Should they be put on the LP bug too? |
| 13:52 |
|
buzzy joined #evergreen |
| 14:37 |
gmcharlt |
kmlussier: good question, and I think it would be a good to do experiment informally |
| 14:37 |
gmcharlt |
I lean towards putting them in the LP too as a way of further explaining the bug |
| 14:37 |
* kmlussier |
is in the middle of writing her test plan in a commit message and hopes the experiment involves that particular step. |
| 14:38 |
kmlussier |
Yeah, that's where I was leaning. |
| 14:41 |
eeevil |
kmlussier: my thought is, since the author will have the commit message, they could just cut/paste the whole thing. I do that often (laziness being a virtue) |
| 14:45 |
|
Stompro_Home joined #evergreen |
| 15:45 |
|
akilsdonk_ joined #evergreen |
| 16:53 |
kmlussier |
Would there be any objection to my moving bug 1403966 from wishlist to bug? |
| 16:53 |
pinesol_green |
Launchpad bug 1403966 in Evergreen "Search results for metarecord search should exclude publication-specific information from the display" (affected: 1, heat: 6) [Wishlist,New] https://launchpad.net/bugs/1403966 |
| 16:55 |
jeff |
kmlussier: none here |
| 16:55 |
kmlussier |
My main goal at the moment is to get in the list of things that can be tested for Bug Squashing Day. If I keep it at wishlist, it's excluded. :) |
| 16:57 |
* kmlussier |
hears the thunder rumble in the distance and decides to leave before the storm arrives |
| 17:00 |
Dyrcona |
Too late. Storm's here. |
| 17:02 |
|
akilsdonk joined #evergreen |
| 17:02 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:08 |
|
mnsri joined #evergreen |
| 17:09 |
|
bmills joined #evergreen |
| 17:43 |
gsams |
Dyrcona: What sort of items get that sort of protection? That seems really short. |
| 05:04 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:23 |
|
mtj_ joined #evergreen |
| 07:27 |
|
Callender_ joined #evergreen |
| 07:35 |
|
jboyer-isl joined #evergreen |
| 09:23 |
|
montgoc1 joined #evergreen |
| 09:55 |
kmlussier |
One of our sites is planning to upgrade to 2.8 soon. I looked through the LP bugs and didn't see anything that warranted waiting for the next point release. But I thought I would check with everyone here in case I'm missing something. |
| 09:55 |
kmlussier |
I don know if anyone else is on 2.8 yet other than bshum. |
| 09:56 |
pgardella |
We've upgraded to 2.8.1 in our development environment and are going live with it next week in production. So far, we've not any any issues with 2.8. I was using it extensively at the conference, and we've had two of our libraries testing it. |
| 09:58 |
kmlussier |
pgardella: Thanks! That sounds promising. :) |
| 09:58 |
csharp |
RoganH: what version did you upgrade SCLENDS to? |
| 09:59 |
RoganH |
chsarp: 2.7.5 |
| 11:40 |
mrpeters |
nothing to my apache error logs today, other_vhosts_access.log just looks like normal activity, lots of 200 HTTP requests |
| 11:41 |
jeff |
mrpeters: browser console is where i'd look |
| 11:42 |
jboyer-isl |
mrpeters: This will make a difference, I'm just looking at webby, are you troubleshooting a local install? |
| 11:42 |
mrpeters |
a PINES test server |
| 11:42 |
mrpeters |
it is publicly accessible |
| 11:42 |
jboyer-isl |
ok, never mind me then; I haven't given this a shot yet to know what even can go wrong. |
| 11:42 |
mrpeters |
yeah thats what im trying to learn :P |
| 11:43 |
mrpeters |
interesting |
| 11:54 |
mrpeters |
yes, it is -- |
| 11:54 |
mrpeters |
sorry, was experimenting |
| 11:58 |
berick |
hm, i'm able to override websocket cert problems w/ chrome without using --ignore-certificate-errors |
| 11:58 |
jboyer-isl |
mrpeters: from the look of that section you might be better off using chrome for your testing so long as you have a self signed cert. I don't know if you can tell FF to ignore cert issues for that connection. (maybe if you tried to connect directly?) |
| 11:59 |
mrpeters |
i have certs, so we're all good |
| 11:59 |
mrpeters |
and i wasn't ignoring the docs jeff -- i just happened to do my experimenting before i read them :P |
| 11:59 |
mrpeters |
we are in the mix now! thanks jeff, jboyer-isl |
| 13:18 |
|
jihpringle joined #evergreen |
| 13:32 |
|
pgardella joined #evergreen |
| 13:42 |
Dyrcona |
Fun with git merge: Make a change on a custom branch, decide to cherry-pick that commit into your master branch, merge the custom branch with master, get the new feature commit showing up twice in git log. |
| 13:42 |
csharp |
yep, I've seen that |
| 13:45 |
|
graced joined #evergreen |
| 13:46 |
|
dbwells joined #evergreen |
| 13:46 |
|
buzzy joined #evergreen |
| 14:51 |
|
Newziky left #evergreen |
| 14:52 |
|
maryj_ joined #evergreen |
| 15:08 |
|
wongon joined #evergreen |
| 15:31 |
csharp |
we're reviewing bug 885270 and have applied jboyer-isl 's fix on a test server (about to apply to production)... what I'm not understanding is what is the use case for having the "Patron Registration: Cloned patrons get address copy" setting at all? Isn't the lack of that logic causing the bug in the first place? |
| 15:31 |
pinesol_green |
Launchpad bug 885270 in Evergreen "Delete User Aborts on Shared Address" (affected: 5, heat: 26) [Medium,Confirmed] https://launchpad.net/bugs/885270 |
| 15:32 |
csharp |
in other words, shouldn't that setting be removed and jboyer-isl's script be added as an optional upgrade script? |
| 15:34 |
jboyer-isl |
jeff has made the point in the past that some users may perfer the old way which can be made to work, but requires more work in the purge user functions. We had no desire to keep the old functionality at all, so I didn't research that very much. |
| 04:24 |
|
pinesol_green joined #evergreen |
| 04:25 |
|
egbuilder joined #evergreen |
| 04:25 |
|
goood joined #evergreen |
| 05:04 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:50 |
|
rjackson_isl joined #evergreen |
| 07:52 |
|
collum joined #evergreen |
| 08:02 |
pgardella |
kmlussier++ for catching my typo |
| 10:33 |
Dyrcona |
Could be a bug with calculating/maintaing mbts.... |
| 10:34 |
Dyrcona |
maintaining, even. |
| 10:34 |
|
pgardella joined #evergreen |
| 10:34 |
berick |
Dyrcona: any chance you could paste/email your test JEDI? |
| 10:34 |
Dyrcona |
berick: Yes, if it fails again. |
| 10:35 |
Dyrcona |
I just built a fresh vm to make 100% sure. I just have to install OpenSRF and Evergreen, etc. |
| 10:35 |
mmorgan |
Hmm. Eyeballing these, looks like they are mostly all backdated checkins. |
| 11:16 |
kmlussier |
dbwells: You must be more human than me. :) |
| 11:17 |
* dbwells |
*more* human than someone? First time for everything :) |
| 11:17 |
kmlussier |
OK, it's me. Apparently, I have something that automatically logs me into that site, which worked fine until we added the math checks. I can disable that. |
| 11:19 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "JEDI I'm testing with" (1 line) at http://paste.evergreen-ils.org/57 |
| 11:19 |
Dyrcona |
berick ^^ |
| 11:20 |
|
dMiller_ joined #evergreen |
| 11:21 |
berick |
thanks Dyrcona |
| 13:08 |
jboyer-isl |
(apparently it is) |
| 13:09 |
bshum |
Heh |
| 13:12 |
Dyrcona |
:) |
| 13:30 |
bshum |
eeevil++ # I'll add your latest patch to our test server for the TT caching |
| 13:31 |
eeevil |
bshum: cool, thanks |
| 13:31 |
bshum |
eeevil: So far, so good anyways. I do feel like it's faster :) |
| 13:32 |
Dyrcona |
I should test that branch out, too. |
| 13:32 |
Dyrcona |
My dev system is pretty slow. |
| 13:32 |
eeevil |
you'll really want http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/gmcharlt/lp1452366_preinit_context_loaders plus my last commit on http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/gmcharlt/lp1449709-TT-caching-by-egweb |
| 13:33 |
bshum |
eeevil: Yeah I merged all of those, plus all the sprint2 so far published into the same test branch and rolled that out to our main test server. |
| 13:34 |
bshum |
Fun to try things out with a copy of our data :P |
| 13:34 |
eeevil |
rad. the former incorporates the latter, and one more that helps a bunch at apache worker startup |
| 13:43 |
bshum |
eeevil: Hmm, adding those changes breaks my system with an internal server error. |
| 13:44 |
bshum |
From ctx to r anyways |
| 15:00 |
kmlussier |
But during the OpenSRF configuration, I already copied those opensrf files and edited the opensrf_core.xml . |
| 15:05 |
jeff |
you copied different opensrf config files. |
| 15:05 |
Stompro |
kmlussier, the OpenSRF install is not specific to Evergreen, it just gets OpenSRF up and running. (even though it targest the /openils/ dir). When you install Evergreen you are installing new config files. |
| 15:06 |
jeff |
there are example opensrf config files in the opensrf archive which set up basic services designed just to test opensrf |
| 15:06 |
jeff |
there are example opensrf config files in the Evergreen archive which set up evergreen. |
| 15:06 |
kmlussier |
And the two are different? That makes sense. |
| 15:06 |
kmlussier |
jeff++ Stompro++ |
| 15:07 |
jeff |
if you don't install the opensrf config files that come with evergreen, then when you start "all opensrf services" you will get no evergreen opensrf services, you will only get the opensrf services that came with opensrf itself. |
| 15:09 |
dbs |
at one point the docs had a very emphatic "Yes, we know you just did this for OpenSRF. You really do have to do this again for Evergreen." |
| 15:09 |
dbs |
(or something like that |
| 15:10 |
kmlussier |
One of the things I'm doing while running through the install is noting down places where the instructions could be clearer. |
| 15:10 |
dbs |
kmlussier: you committed thoughtcrime |
| 15:10 |
dbs |
thoughtmistake :) |
| 15:10 |
dbs |
"Please refer back to the OpenSRF README and, as the opensrf Linux account, edit the Evergreen version of the opensrf_core.xml file using the same Jabber users and domains as you used while installing and testing OpenSRF.: |
| 15:10 |
dbs |
is the current version of that note |
| 15:11 |
* kmlussier |
probably commits thoughtmistake on an hourly basis |
| 15:12 |
* dbs |
goes into fullblown reallifemistake typically |
| 15:13 |
dbs |
Maybe rather than putting the stuff about "cp -b" in the note in that section of the docs, the "No, really. You have to do this for Evergreen now." should be the called-out note. |
| 10:02 |
pinesol_green |
jeff always wants pancakes. |
| 10:02 |
berick |
Dyrcona++ # RM hat in the ring |
| 10:03 |
jeff |
Dyrcona++ |
| 10:04 |
RoganH |
So, I'm trying to grok how detailed we want pg_tap tests in the non-concerto tests. Do we want tests that ultimately would test for all the tables, indexes, etc...? |
| 10:06 |
bshum |
Hmm, opinions on https://bugs.launchpad.net/evergreen/+bug/1454879 -- bug or new feature? (I'm leaning towards new, since it never displayed that information before, and if so, we should put in release note entry and add it towards 2.next, aka, 2.9) |
| 10:06 |
pinesol_green |
Launchpad bug 1454879 in Evergreen "Account Expiration Date in My Account" (affected: 2, heat: 10) [Undecided,New] |
| 10:08 |
berick |
bshum: i'd call it new as well |
| 10:37 |
pinesol_green |
jwoodard: The current temperature in Nipe Ranch, Krugerville, Texas is 56.5°F (9:36 AM CDT on May 21, 2015). Conditions: Light Rain. Humidity: 90%. Dew Point: 53.6°F. Pressure: 30.19 in 1022 hPa (Rising). |
| 10:38 |
jwoodard |
It was just 85°F and sunny yesterday... |
| 10:38 |
dbs |
timely article on release management stresses in PostgreSQL: http://lwn.net/SubscriberLink/645020/15f0367e0d5affff/ |
| 10:40 |
pgardella |
Hi, all. Trying to track down why many of our action triggers don't work. Namely overdue notices. Our hook=longoverdue.auto ones work. The hook=checkout.due ones do not, not even the example seed one. The action_trigger.event.state is "invalid" when I try to test the action trigger from the staff client. Nothing gets put into action_trigger.event_output, and the gateway.log only has osrf_http_translator 2015-05-21 14:37:42 [ACT:18040:./osrf_htt |
| 10:40 |
dbs |
we still use OpenSRF python for our custom LDAP-based auto-population of actor.usr & friends |
| 10:42 |
pgardella |
Any thoughts on how to debug it further? |
| 10:44 |
kmlussier |
Dyrcona++ # dusting off constrictor. |
| 11:15 |
jboyer-isl |
jonadab: provided you can properly excersize it. We (I!) have issues with that, and that's before you even get to things like race conditions / bugs that lie in wait until the load spikes. |
| 11:16 |
jonadab |
True. |
| 11:16 |
krvmga |
git++ |
| 11:16 |
jonadab |
Although a project like Postgres is widespread enough to have a lot of people testing even the bleeding-edge code. |
| 11:17 |
jboyer-isl |
git++ # in any case though. |
| 11:17 |
bshum |
jonadab: Well, a project like Evergreen occasionally has... bleeding code |
| 11:17 |
bshum |
And bleeding adopters |
| 11:17 |
bshum |
But that's besides the point. |
| 11:17 |
jonadab |
Yes, Evergreen would have more of a problem getting new stuff tested. |
| 11:17 |
bshum |
I forgot what I was trying to say. |
| 11:17 |
bshum |
I just see blood now. |
| 11:19 |
jboyer-isl |
I don't know if Pg is on the list of projects that huge companies are now throwing money at (OpenSSL is where that started) but they probably should be. |
| 13:38 |
bshum |
Or maybe the type of browser you've got |
| 13:38 |
bshum |
Or weird caching |
| 13:39 |
bmills |
bshum: all in https. in firefox now. |
| 13:42 |
bshum |
bmills: Hmm, that sounds suspicious. |
| 13:42 |
bshum |
Unfortunately we do not require passwords for our selfchecks |
| 13:42 |
bshum |
So I don't think I've tested it lately. |
| 13:43 |
bmills |
we only have one library interested in that aspect. otherwise.. |
| 13:52 |
bshum |
csharp: Every time I get a PGCon-announce email, I think to myself, (1) I wish I was going to hear the talks, and (2) I want poutine!!! :( :( |
| 13:52 |
bshum |
csharp: Just a little while to go, you'll have to share all the cool things you see and learn |
| 13:53 |
bshum |
bmills: I'm firing up one of our test servers to see if I can duplicate the problem you see. |
| 13:54 |
bshum |
Assuming of course, I can figure out which setting it is... whee! |
| 13:54 |
* bshum |
sets both settings to TRUE for giggles |
| 13:55 |
RoganH |
bshum: can we give karma to poutine? |
| 13:56 |
yboston |
heads up, the IRC practice time will start at 2 PM EST |
| 13:56 |
bshum |
RoganH: I would.... then I'd eat it. |
| 15:19 |
gsams |
well, one of those |
| 15:19 |
bshum |
bmills: That sounds like it might be a worthy goal... |
| 15:19 |
bshum |
bmills: I haven't encountered it personally, but I guess I don't check out that slowly :) |
| 15:19 |
tsbere |
gsams: I would call the iptables route more tested, though setcap kindof helps to ensure nothing else will use the port instead... |
| 15:20 |
bshum |
I'd say Launchpad that idea, and if you can mock up a quick proof of concept on code, that'd be cool. : P |
| 15:21 |
bmills |
bshum: thanks. mainly encountered the issue with the self check in kids. the piles can get big there |
| 15:21 |
bmills |
bshum++ |
| 15:23 |
gsams |
Now I just have to figure out what went wrong with ezproxy... |
| 15:24 |
* tsbere |
really needs to see about getting his "proxy straight in evergreen" stuff set up for testing somewhere... |
| 15:24 |
tsbere |
I mean, I know it works in theory. I haven't actually tested with real services, though. |
| 15:24 |
jboyer-isl |
gsams: I' |
| 15:26 |
jboyer-isl |
I'd recommend looking into what tsbere mentioned re: iptables and redirection. That way you don't have to run the server as root. We actually have our firewall doing that before requests hit our z39.50 server, so that's another option. (And much more appealing since I think IPtables looks like a social experiment in gaslighting sysadmins...) |
| 15:27 |
jboyer-isl |
Finally reading the rest of the scrollback, that's what he's doing anyway. Ah, well. |
| 15:47 |
tsbere |
Megakeen: I actually wrote a database function to fill "new materials" bookbags based on various criteria for our members. |
| 15:48 |
Megakeen |
I'm looking at a ppt about bookbag buckets now. I'll see what I can come up with. |
| 15:49 |
Megakeen |
My local director expects miracles when I don't have access to anything at the consortium level--nothing on the back end. D: |
| 15:51 |
makohund |
Megakeen: a test server with real data in it that you do have access to would be a nifty thing |
| 15:51 |
Megakeen |
Okay, from what I'm reading it looks like user lists created in-browser in the catalog can be viewed/edited as buckets in the client? |
| 15:52 |
Dyrcona |
Yes, that is true. |
| 15:52 |
Megakeen |
I think that solves my issue, then. The powers that be requested an easier way to add/remove items from the new lists 'cause doing so from the web interface is clunky. |
| 16:43 |
bshum |
And so they give you back junk |
| 16:43 |
bshum |
For us, I think they use specific hostnames to verify that we are who we are. |
| 16:43 |
bshum |
And that their content is allowed on our pages. |
| 16:44 |
gsams |
Yeah, they were planning to pull the eg_vhost file from another site and the award.tt2 file from another site to see if we could figure it out |
| 16:44 |
gsams |
I decided to take a shortcut |
| 16:44 |
gsams |
but I think I know what's wrong, gonna test it |
| 16:45 |
bshum |
Do you have multiple eg_vhost entries for your different virtualhosts? |
| 16:45 |
bshum |
Maybe the variables aren't getting up to the right level |
| 16:46 |
gsams |
The lines they sent me for those two variables had a colon in it that should have been a space |
| 17:04 |
pgardella |
tbere++ |
| 17:11 |
mmorgan |
Hey! NOBLE got karma and I missed it? |
| 17:14 |
|
mmorgan left #evergreen |
| 17:18 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:34 |
|
dkyle1 left #evergreen |
| 17:40 |
|
wongon joined #evergreen |
| 19:05 |
kmlussier |
tsbere++ #Making up for the typo above :) |
| 10:38 |
bshum |
Looking at that line in Circulate.pm, I find that it's attempting something with the dont_change_lost_zero |
| 10:38 |
jeff |
can you reproduce on a test system and try with and without that setting enabled? |
| 10:39 |
Bmagic |
When we migrate lost items, we make the status "missing" |
| 10:39 |
bshum |
jeff: I'll see if I can find the same item in our test system. Not sure if it's synced enough |
| 10:40 |
Dyrcona |
bshum: I believe the key is in your 3rd line. |
| 10:40 |
Dyrcona |
I'd just change the copy status to missing and try checking it in again. |
| 10:41 |
Dyrcona |
Bmagic++ |
| 11:14 |
mmorgan |
bshum: kmlussier: We migrated "billed" items to a Lost status, but I think we migrated associated transactions for those. |
| 11:15 |
mmorgan |
We haven't run into bshum's issue that I'm aware of. |
| 11:15 |
kmlussier |
Even if it is a flaw in the data migration, I'm worried that there may be several sites that have that flaw. How hard would it be to do a fix so that those flawed migrated items are handled better? |
| 11:16 |
* bshum |
lets his test database churn on a query while he drives over to the office for the next round of meetings... |
| 11:19 |
Bmagic |
bshum: does this help identify the situation you are in? select * from asset.copy where status=3 and id not in(select target_copy from action.circulation) |
| 11:20 |
Dyrcona |
Bmagic: He's doing that one already. Thinks he's missing an index, 'cause it's taking forever. |
| 11:20 |
Bmagic |
I see |
| 11:21 |
mmorgan |
... and found 131 items :-( |
| 11:21 |
* kmlussier |
personally thinks a bug should be filed. |
| 11:21 |
Dyrcona |
I ran this: select acp.id from asset.copy acp where acp.status = 3 and not acp.deleted and acp.id not in (select target_copy from action.circulation) |
| 11:21 |
Dyrcona |
Took 9 seconds on my test database the first time. |
| 11:21 |
* mmorgan |
agrees with kmlussier |
| 11:22 |
jeff |
kmlussier: to answer your question, i don't know -- haven't looked. no objection to a bug being filed as a next step to getting an eye on it. |
| 11:22 |
Bmagic |
yeah, my test db returned 2100 rows in 10 seconds |
| 11:25 |
Dyrcona |
I get 807, and after pulling out dates and doing some sorting, looks like all but 6 come from migration. |
| 11:26 |
Dyrcona |
Most recent one is from July of 2013. |
| 11:27 |
|
bmills joined #evergreen |
| 16:15 |
bshum |
So yeah |
| 16:15 |
bshum |
A sequential scan on 27 million rows of action.circulation apparently takes awhile to work |
| 16:17 |
dbs |
hah |
| 16:18 |
bshum |
I left our test DB running with the query to try finding all the bad "lost" items and it was still running this afternoon when I went to check on it. Around 4+ hours later. |
| 16:18 |
bshum |
So.... I'll think about better ways of finding that faster. |
| 16:18 |
jeff |
what was your query, again? |
| 16:19 |
bshum |
jeff: Mine was a very generic SELECT COUNT(*) FROM asset.copy WHERE status = 3 AND deleted = FALSE AND id NOT IN (SELECT target_copy FROM action.circulation); |
| 16:19 |
bshum |
The scan on getting target_copy from action.circulation is what's slowing me down |
| 16:33 |
bshum |
jeff: Yes, that works, and invokes the index |
| 16:33 |
bshum |
And voila, magic fast |
| 16:34 |
bshum |
Just 35682 copies to deal with... huzzah |
| 16:34 |
collum |
yep. Just ran the same query on my test machine. It runs exponentially faster. |
| 16:34 |
Dyrcona |
Takes only about 1 second less on my data, but that's still an improvement. :) |
| 16:34 |
|
buzzy joined #evergreen |
| 16:34 |
jeff |
yeah. completes in 623ms for me on a very very underpowered test instance. |
| 16:34 |
bshum |
2244 ms. Vs. how 4+ hours and incomplete? Yeah seems like a win. |
| 16:35 |
jeff |
http://i.imgur.com/IW8simF.gif |
| 16:35 |
bshum |
jeff++ |
| 16:58 |
bshum |
And run them whatever |
| 16:58 |
bshum |
Well, edit and run them |
| 16:59 |
jeff |
i'd go with that, yes. |
| 17:03 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:07 |
bshum |
I should add to the README |
| 17:07 |
bshum |
Little things |
| 17:08 |
bshum |
Like install libemail-sender-perl |
