| 00:22 |
|
abowling joined #evergreen |
| 04:53 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:18 |
|
jboyer-isl joined #evergreen |
| 07:45 |
|
graced joined #evergreen |
| 07:48 |
|
akilsdonk joined #evergreen |
| 10:37 |
|
maryj joined #evergreen |
| 10:46 |
|
sarabee joined #evergreen |
| 11:13 |
|
TaraC joined #evergreen |
| 11:44 |
* kmlussier |
is learning more than she ever wanted to know about QA. |
| 11:45 |
kmlussier |
I know we are doing build tests and some unit testing, especially after we put some of berick's guidelines from http://evergreen-ils.org/dokuwiki/doku.php?id=dev:contributing:qa into place. |
| 11:45 |
kmlussier |
But are we doing any kind of functional testing in an automated fashion? |
| 11:47 |
phasefx |
kmlussier: are you thinking UI testing? |
| 11:47 |
phasefx |
we do have the "live" tests against a running system |
| 11:48 |
kmlussier |
phasefx: No. I'm thinking, given this input the system should be returning this. |
| 11:48 |
kmlussier |
I saw the "live" tests, but wasn't exactly sure what they did. |
| 11:49 |
tsbere |
kmlussier: I think the live tests are "Given this input and a known DB state, the system should be returning this" |
| 11:50 |
kmlussier |
OK, so that's what I was looking for. I think. :) |
| 11:50 |
tsbere |
(which doesn't mean that any UI elements work, in that case, but would cover backend calls) |
| 11:50 |
phasefx |
and the unit tests are "given this input, this code chunk should always return this" |
| 11:53 |
kmlussier |
Hontestly, the way you describe it, I don't see a difference between the unit and live tests. |
| 11:55 |
tsbere |
kmlussier: The unit tests are for things that don't require the network to be up. "This utility function should always do the same thing given the same input and doesn't talk to anyone else while doing so" |
| 11:55 |
phasefx |
kmlussier: the unit tests are testing pieces of code that are very self-contained.. the live tests require a larger environment in a known state (a running system with stock test database) |
| 11:56 |
phasefx |
kmlussier: so you end up testing some interaction between multiple moving parts |
| 11:59 |
kmlussier |
phasefx: So is that the same as integration testing? |
| 11:59 |
phasefx |
kmlussier: I think so |
| 12:02 |
|
mmorgan joined #evergreen |
| 12:37 |
csharp |
damn - I can't find the problem |
| 12:37 |
csharp |
fieldmapper looks right, rocit.age_protect <-> crahp.id |
| 12:44 |
csharp |
@hates |
| 12:44 |
pinesol_green |
csharp hates dojo_hold_policies_interface; SIP; when libraries purchase third party products without testing and blame Evergreen for it not working; reports; the fact that the Base Filters is unnecessarily greyed out when applying an Aggregate Filter and vice versa; evil; reports more; reports even moar; details; reports even more; the fact that the Base Filters is unnecessarily greyed out (1 more message) |
| 12:45 |
csharp |
@more |
| 12:45 |
pinesol_green |
csharp: when applying an Aggregate Filter and vice versa even more; having to teach SIP2 client vendors about the SIP2 specification; troubleshooting reports; money reports; and marc |
| 12:45 |
|
mmorgan1 joined #evergreen |
| 15:12 |
|
julialima_ left #evergreen |
| 15:19 |
|
mmorgan1 joined #evergreen |
| 15:34 |
|
kmlussier joined #evergreen |
| 16:04 |
* jeff |
is seeing "grunt test" fail in rel_2_7 and master at present |
| 16:04 |
jeff |
since I haven't run these tests before, I'm not sure if I'm doing something wrong. |
| 16:06 |
berick |
got a paste? |
| 16:06 |
jeff |
output is here: https://gist.github.com/jeff/45f872e1899ba6217cd0 -- it obviously can't find/load angular, but i'm not sure where to start |
| 16:08 |
jeff |
oh hey, and now it works. |
| 17:06 |
mrpeters1 |
sorry, i got distracted and didn't finish my thought there -- should a 1 hour overdue have a 1 hour processing delay? |
| 17:06 |
mrpeters1 |
wouldn't that cause a notice not to be sent until it was actually 2 hours overdue? also, the Max Event Validity -- its set to 2 hours -- if a cron job failed to run to "run pending" within that 2 hour window, would that cause the notice to fail to be sent? |
| 17:10 |
|
mrpeters1 left #evergreen |
| 17:11 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:16 |
|
mmorgan1 joined #evergreen |
| 17:20 |
|
abowling joined #evergreen |
| 17:22 |
|
mmorgan1 joined #evergreen |
| 12:48 |
gmcharlt |
goood: http://git.evergreen-ils.org/?p=working/OpenSRF.git;a=shortlog;h=refs/heads/collab/gmcharlt/better_osrf_control_diagnostic |
| 13:02 |
kmlussier |
Woo hoo! Booked my hotel room for the conference. :) |
| 13:08 |
|
nhilton joined #evergreen |
| 13:13 |
phasefx |
berick: I was trying a variant of the script in bug#1268619 to test websockets prior to installing anything EG (including dojo). And I found I had to include opensrf_ws.js manually, and after calling .send(), I also had to call .session.send_ws() on the request object. Does that sound crazy? |
| 13:16 |
phasefx |
http://paste.lisp.org/display/145683 |
| 13:19 |
phasefx |
the manual part doesn't sound crazy, the path is hard-coded in opensrf.js |
| 13:21 |
phasefx |
okay <rubber ducking>, so if I change the transport from OSRF_TRANSPORT_TYPE_WS_SHARED to OSRF_TRANSPORT_TYPE_WS, I can just do req.send() and it works |
| 13:24 |
berick |
phasefx: OSRF_TRANSPORT_TYPE_WS_SHARED is currently disabled. send_ws() is the underyling handler for OSRF_TRANSPORT_TYPE_WS. |
| 13:24 |
berick |
so even though it was set to OSRF_TRANSPORT_TYPE_WS_SHARED, you were forcing it to run as non-shared by calling send_ws() directly |
| 13:25 |
berick |
when you changed to OSRF_TRANSPORT_TYPE_WS, the send_ws() was no longer needed |
| 16:28 |
|
nhilton_ joined #evergreen |
| 16:41 |
csharp |
amazing... with dbwells's fix with jboyer-isl's modifications, my nearly two-hour query dropped to 4 seconds |
| 16:45 |
|
nhilton joined #evergreen |
| 16:48 |
dbwells |
csharp: Sorry for being lazy on the COALESCE, I only did a quick test on lower ids which had a legacy_circ_count entry (which should be, I think, the only number needing a COALESCE). |
| 16:56 |
dbwells |
This should work: http://pastie.org/9893249 |
| 17:01 |
dbwells |
I also kept COUNT(*) over COUNT(distinct id) because 1) there are no joins involved, so DISTINCT doesn't do anything for us here, and 2) COUNT(*) is generally recommended when simply counting rows, as it lets the planner pick whatever it thinks is best (which will probably be 'id', but anyway... at least that's what I've been told). |
| 17:05 |
dbwells |
In any case, the changes I'm advocating will not affect performance in any measurable way, I think it just helps readability. |
| 17:06 |
|
vlewis_ joined #evergreen |
| 17:09 |
|
mmorgan left #evergreen |
| 17:16 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:30 |
csharp |
dbwells: excellent - thank you |
| 17:31 |
csharp |
I'll file a bug on this just to get it on the record |
| 17:32 |
dbwells |
sounds like a plan |
| 09:09 |
bshum |
jeff: How did those slip past? |
| 09:11 |
jeff |
bshum: staff-side patron editor has no checks for duplicate holdshelf alias. We didn't put effort into closing that loophole. |
| 09:11 |
bshum |
Ahh. |
| 09:11 |
jeff |
bshum: So at least one of each group is staff or asked staff to set their alias to that value. |
| 09:11 |
|
sarabee joined #evergreen |
| 09:12 |
jeff |
looking, the duplicate catwoman is a test/training account's alias. |
| 09:12 |
|
eeevil joined #evergreen |
| 09:18 |
mmorgan |
jeff: speaking of popular - what are you looking at to get the "most popular" titles on your stats page? Circs? Holds? A combination? |
| 09:36 |
jeff |
mmorgan: i think i owe you an email regarding that, too! |
| 10:04 |
eeevil |
pcrud.js is completely unchanged (now... I was messing with it last night) |
| 10:11 |
berick |
eeevil: ok, was able to reproduce locally |
| 10:11 |
* berick |
pokes |
| 10:12 |
eeevil |
berick: I suspect, but haven't tested, that it happens with every pcrud CUD call |
| 10:31 |
|
dreuther joined #evergreen |
| 10:34 |
|
dMiller_ joined #evergreen |
| 10:36 |
berick |
eeevil: found it. good stuff |
| 10:36 |
berick |
http://git.evergreen-ils.org/?p=working/OpenSRF.git;a=commitdiff;h=1b25f487c0acdfa000becbccac6943e24bc0ca77 |
| 10:36 |
berick |
i'll open an LP |
| 10:37 |
berick |
this code path (per-tab connections) got much less testing than the global WS connection code, which had to be disabled, because chrome started acting funky with global connections |
| 10:37 |
berick |
will have to revisit that.. |
| 10:42 |
|
mrpeters joined #evergreen |
| 10:46 |
berick |
https://bugs.launchpad.net/opensrf/+bug/1418613 |
| 10:46 |
pinesol_green |
Launchpad bug 1418613 in OpenSRF "Per-tab websocket JS connections can re-send messages" (affected: 1, heat: 6) [Undecided,New] |
| 11:01 |
bshum |
berick: I'm adjusting that entry if I can so that it points at OpenSRF 2.4.1 |
| 11:01 |
bshum |
Since 2.4.0 was already released last month |
| 12:09 |
bshum |
gmcharlt: Sorry I'll fix up 2.7.3 too and create a 2.7.4 for everyone. |
| 12:09 |
bshum |
Old, old bug. Back from my 2.0 days :( |
| 12:10 |
gmcharlt |
bshum: ah, great - thanks for catching that! |
| 12:11 |
bshum |
gmcharlt: I'm not sure if dbwells has cut 2.6.6. He might not have yet and it could still get tested and applied there. But more than likely I expect we'll keep that lock-step on bug fixes in general. |
| 12:11 |
bshum |
gmcharlt++ # poking at ancient bugs |
| 12:12 |
gmcharlt |
bshum: that's fine - that bug gets hit rarely enough, I think, that testing doesn't need to be super-rushed |
| 12:12 |
gmcharlt |
our_customers++ # running into ancient bugs and KEEPING THEM ALIVE |
| 12:13 |
bshum |
Reported by Ben Shum on 2011-12-15, zomg :( |
| 12:13 |
* bshum |
can't believe how long it's been :\ |
| 12:14 |
bshum |
Stompro++ # helping to announce new release on list with helpful notes and links! |
| 14:41 |
remingtron |
I think I did, but probably asked bshum first |
| 14:41 |
remingtron |
basically, he wrote the instructions draft, and he wants some feedback |
| 14:42 |
remingtron |
maybe he/we should ask the general and dev lists for help on that |
| 14:42 |
yboston |
ats ome point I need to build a new test server to try out the web client, I can give him some feedback at that point |
| 14:43 |
yboston |
I can put an action item to reach out to him to see if this has been included in master, and if others have been able to run his intructions |
| 14:43 |
yboston |
they look fine to me, bu I have nos tested them yet |
| 14:43 |
bshum |
It has not been added up to master yet. |
| 14:43 |
bshum |
Sorry, stepped away a sec there. |
| 14:44 |
bshum |
I'll work on it with more devs in the coming weeks. |
| 14:44 |
yboston |
I can reach out to you when I am ready to build a new VM to test the web client, to make sure I use the latest version |
| 14:45 |
yboston |
is there a git branch that has these instructions? |
| 14:45 |
bshum |
yboston: I haven't put all the changes into a git branch yet. That's also on my to-do list I think. |
| 14:45 |
yboston |
no worries |
| 14:46 |
yboston |
I can move on, but want suggestions on what action item if any we should leave for next meeting for this? |
| 15:02 |
remingtron |
kmlussier: are you able to make the wiki page for 2.8 features again? |
| 15:03 |
kmlussier |
Yes, I can. |
| 15:03 |
kmlussier |
Sorry, I was pulled into another discussion. |
| 15:03 |
* gmcharlt |
jumps in to mention that I intend to provision the doc testing server next week |
| 15:03 |
gmcharlt |
sorry for hte delay |
| 15:03 |
kmlussier |
gmcharlt++ |
| 15:04 |
yboston |
no problem, you have a lot on your olate |
| 15:04 |
yboston |
*plate |
| 15:23 |
bshum |
And it doesn't handle things like links. |
| 15:23 |
bshum |
At least, it didn't work for the text block where the other stuff lives now. |
| 15:23 |
|
Dyrcona1 joined #evergreen |
| 15:40 |
kmlussier |
eeevil / goood: I may have asked this question before, but I don't recall the answer. Is bug 1251394 ready for testing or does it still need work? |
| 15:40 |
pinesol_green |
Launchpad bug 1251394 in Evergreen "Metabib Display Fields" (affected: 3, heat: 16) [Wishlist,Triaged] https://launchpad.net/bugs/1251394 - Assigned to Mike Rylander (mrylander) |
| 15:45 |
eeevil |
kmlussier: it's just the backend components, but I think they work. nothing knows how to use them yet, though |
| 15:46 |
kmlussier |
eeevil: Ah, ok. So if we wanted something to be able to use them, it still needs work. |
| 16:27 |
|
rjackson_isl_ joined #evergreen |
| 16:39 |
|
julialima_ left #evergreen |
| 16:59 |
|
mrpeters left #evergreen |
| 17:01 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:31 |
|
chick joined #evergreen |
| 18:07 |
|
ningalls joined #evergreen |
| 19:19 |
|
graced joined #evergreen |
| 00:56 |
|
akilsdonk 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> |
| 06:02 |
|
edoceo joined #evergreen |
| 07:14 |
|
hopkinsju joined #evergreen |
| 07:15 |
|
jeff__ joined #evergreen |
| 12:33 |
bshum |
Bleh |
| 12:33 |
Dyrcona |
I'll make a fix and post it to Launchpad. |
| 12:33 |
Dyrcona |
After lunch. |
| 12:34 |
bshum |
Dyrcona++ # thanks for testing that in your system. |
| 12:55 |
|
nhilton joined #evergreen |
| 12:58 |
|
jihpringle joined #evergreen |
| 13:10 |
|
chatley_ joined #evergreen |
| 14:09 |
|
nhilton joined #evergreen |
| 14:12 |
kmlussier |
I'm guessing it's important to those sites using boundaries. |
| 14:13 |
|
mrpeters left #evergreen |
| 14:15 |
tsbere |
kmlussier: At least I saw it as important enough to test and post to launchpad, right? |
| 14:27 |
|
krvmga joined #evergreen |
| 14:36 |
bshum |
Dyrcona++ |
| 14:38 |
|
mrpeters joined #evergreen |
| 15:10 |
bshum |
Again. |
| 15:10 |
dbwells |
bshum: Is metabib.reingest_metabib_field_entries not enough? I need to check to remember what exactly it does and doesn't do. |
| 15:11 |
bshum |
dbwells: I'm unsure. |
| 15:15 |
dbwells |
It's not the right piece. |
| 15:18 |
dbwells |
I think we need metabib.reingest_record_attributes() in this case. Let me see if I can test it out a bit. |
| 15:26 |
dbwells |
bshum: based on my testing, SELECT metabib.reingest_record_attributes(id); is sufficient for this situation. Paste forthcoming... |
| 15:30 |
pastebot |
"dbwells" at 64.57.241.14 pasted "Partial Reingest Addendum For Upgrade Script" (24 lines) at http://paste.evergreen-ils.org/30 |
| 15:35 |
Dyrcona |
Is there a test script floating around to see if Python is working correctly with Evergreen? |
| 15:35 |
Dyrcona |
I did --enable-python 'cause I eventually want to see if I can get constrictor working. |
| 15:35 |
bshum |
dbwells++ |
| 15:35 |
bshum |
I'll tack that on and get the tarball finished to push up to the website |
| 15:56 |
eeevil |
and, berick, do you know of any version restrictions we need to be aware of with the version of angular we're on? |
| 15:58 |
|
nhilton joined #evergreen |
| 16:03 |
jeff |
eeevil: defaulting to jquery CDN and making it reasonably easy to override? |
| 16:03 |
berick |
eeevil: hmm, looks like we should start by testing 2.1 |
| 16:03 |
berick |
"Angular 1.3 only supports jQuery 2.1 or above. jQuery 1.7 and newer might work correctly with Angular but we don't guarantee that. |
| 16:03 |
berick |
" |
| 16:03 |
eeevil |
berick: yep. just saw that. I'm importing 2.1.3 from the cdn |
| 16:04 |
berick |
jeff: I assume we'd want to eventually deploy it ourselves, in the same manner we deploy angular and other deps |
| 16:04 |
eeevil |
jeff: it's just a template ... so, as long as it loads |
| 16:04 |
berick |
.. so we can scrunch it all into a single file |
| 16:06 |
berick |
we'd probably have to deploy it locally for unit tests, too |
| 16:06 |
berick |
i'm sure there's a bower target for jquery, though, so that's easy enough |
| 17:06 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:32 |
|
nhilton_ joined #evergreen |
| 17:54 |
csharp |
Dyrcona: using 14.04 on our DBs but 12.04 everywhere else |
| 17:55 |
Dyrcona |
csharp: Thanks. |
| 21:37 |
Dyrcona |
I also think unwrap_perl suffers from extra recursion. |
| 21:59 |
Dyrcona |
Ah, crazy. |
| 22:00 |
Dyrcona |
Apparently, I am making it into the open-ils.actor.patron.update method, but it is blowing up on addresses. |
| 22:00 |
Dyrcona |
I didn't flesh addresses, 'cause I just wanted to change the name for a test. |
| 22:05 |
Dyrcona |
Interesting. It's blowing up on the user object that it pulled from the database and not the one that I passed in via XML-RPC. |
| 22:08 |
Dyrcona |
Also, unwrap_perl seems to be making a proper Fielmapper::actor:_user object from what I am giving it via XML-RPC. |
| 22:08 |
Dyrcona |
Not as neat as taking what the server gives me, modifying that, and handing it back. |
| 10:54 |
* csharp |
is seeing high RAM on PINES' sip servers and was assuming the fixes for bug 1339190 would help resolve it, but doesn't want to bring on a world of hurt |
| 10:54 |
pinesol_green |
Launchpad bug 1339190 in SIPServer "SIPServer is heavy, not my brother" (affected: 3, heat: 14) [Undecided,Fix committed] https://launchpad.net/bugs/1339190 |
| 10:54 |
csharp |
oh, and we're using a SIPServer of an early 2013 vintage |
| 11:00 |
jeff |
do you have time/resources to run a new SIPServer on an alternate host or alternate port, and test with a small group of SIP clients, adding or removing from the test if/as you run into trouble? |
| 11:00 |
jeff |
i know you'd hate to be too much of a test bed... |
| 11:00 |
csharp |
hmm - that's a thought |
| 11:01 |
csharp |
our testing process is actually asking libraries to connect their devices/third-party services to whichever testing cluster we've set up for the purpose |
| 11:01 |
jeff |
but there are certainly benefits for you (and all) in having the gains of things like the work in that bug, so identifying any new issues would clear the path... |
| 11:02 |
Dyrcona |
Looks like we're not running that fix, yet. |
| 11:02 |
csharp |
but it would answer most of our questions to throw in an upgraded sip server for a day and record what happens |
| 11:36 |
goood |
thanks |
| 11:37 |
goood |
kmlussier: you're using the admin account? |
| 11:38 |
kmlussier |
goood: Yes |
| 11:38 |
goood |
I'm not having that issue. just tested with admin |
| 11:38 |
jboyer-isl |
csharp, There's no news like old news, but I thought I'd pass along that we've been running SIPServer master as of roughly christmas time with Multiplex and it's been good. (I did have to bring back the nightly service restarts, but that's not that big a deal.) |
| 11:39 |
jeff |
jboyer-isl: what made you bring back the nightly service restarts? |
| 11:40 |
jeff |
jboyer-isl: and do you mean just SIPServer, or restarting OpenSRF services on the SIP host also? |
| 11:55 |
|
vlewis joined #evergreen |
| 11:57 |
kmlussier |
Never mind. It seems to be working correctly now. The autocompleting URL probably steered me wrong. |
| 11:58 |
jeff |
9118 Pure Significance Inlet |
| 12:00 |
kmlussier |
OK, one webby mystery solved then. :) |
| 12:00 |
* kmlussier |
resumes testing bug fixes |
| 12:01 |
|
bmills1 joined #evergreen |
| 12:14 |
csharp |
jboyer-isl: thanks for sharing that |
| 12:14 |
csharp |
I'll definitely consider upgrading, at least in a rollback-able way ;-) |
| 12:42 |
bshum |
dbwells: Reading the Launchpad entry, I said I did backport it. So if it's not there, then I guess I screwed something up? |
| 12:43 |
* bshum |
can look more closely when he finishes eating lunch. |
| 12:46 |
kmlussier |
mmorgan: Hooray! :) |
| 12:47 |
dbwells |
bshum: Yes, it was probably just an oversight, but the fact that that piece relied on the other bug gave me pause. I just tested on our live 2.7 install, and am now sure it is needed. I'll push it in when I get back from lunch unless you beat me to it. (same for rel_2_6) |
| 12:48 |
mmorgan |
Forcing https would be good practice, though. |
| 12:57 |
bshum |
dbwells: Well darn, that's an annoying screwup. I'll add that missing commit and then adjust the launchpad ticket to signify that it wasn't actually backported right till now... :( |
| 12:58 |
bshum |
dbwells: Related, I think we've got enough stuff for a good maintenance release soon. |
| 13:13 |
|
mnsri_away joined #evergreen |
| 13:13 |
|
book` joined #evergreen |
| 13:16 |
goood |
kmlussier: I'm going to go ahead and hide it |
| 13:18 |
kmlussier |
goood: OK. I'm about to post to the LP bug the results of our first round of testing on the fixes. |
| 13:35 |
|
kbutler joined #evergreen |
| 13:56 |
|
graced joined #evergreen |
| 13:57 |
|
graced joined #evergreen |
| 16:01 |
collum |
Nope. |
| 16:01 |
collum |
gmcharlt just tweeted. |
| 16:02 |
collum |
I can only go to one conference a year, and this year it's going to be Computers in Libraries. |
| 16:26 |
Dyrcona |
Rollback is great for testing. |
| 17:02 |
|
Kshitij joined #evergreen |
| 17:06 |
|
mrpeters left #evergreen |
| 17:07 |
|
kshitij_2015 joined #evergreen |
| 17:08 |
|
nhilton joined #evergreen |
| 17:08 |
|
mmorgan left #evergreen |
| 17:11 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:16 |
|
julialima_ left #evergreen |
| 19:32 |
|
remingtron joined #evergreen |
| 19:38 |
|
bmills joined #evergreen |
| 02:42 |
|
Callender joined #evergreen |
| 02:59 |
|
Callender_ joined #evergreen |
| 03:00 |
|
BigRig joined #evergreen |
| 05:14 |
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 |
|
jboyer-isl joined #evergreen |
| 07:42 |
|
dbwells_ joined #evergreen |
| 07:54 |
|
rjackson-isl joined #evergreen |
| 11:58 |
|
jwoodard joined #evergreen |
| 11:59 |
|
bmills joined #evergreen |
| 12:00 |
|
jihpringle joined #evergreen |
| 12:00 |
jeff |
mmorgan: does the template file work in the previous version of the client? i don't remember offhand how tricky that might be in your environment to test. |
| 12:01 |
jeff |
(i'm wondering if there was a change that broke import of previous-version receipt templates, either in some or all circumstances) |
| 12:02 |
|
bmills joined #evergreen |
| 12:04 |
mmorgan |
jeff: Hmm. That's a thought. I'll see if I can find an older client to test it on. |
| 12:05 |
kmlussier |
mmorgan: I could try it in a 2.5 client |
| 12:05 |
jeff |
could also explain why the new client failed to load the stored templates from disk. |
| 12:06 |
jeff |
if you find signs that seem to confirm that theory, the template file that broke could be useful -- especially if it's "only under certain circumstances" kind of thing. |
| 16:17 |
|
bmills joined #evergreen |
| 16:24 |
|
bmills joined #evergreen |
| 16:24 |
RoganH_ |
Quick question - does anyone know off the top of their head if last activity includes SIP activity? |
| 16:24 |
RoganH_ |
(I can go test it of course but feeling lazy.) |
| 16:31 |
kmlussier |
I should know the answer to that question. |
| 16:32 |
mmorgan |
There are sip2 activity types. One for login and one for verify |
| 16:36 |
jeff |
and I think only "verify" is used by current code. |
| 16:52 |
gmcharlt |
@later tell foo you have been eaten by a grue |
| 16:52 |
pinesol_green |
gmcharlt: The operation succeeded. |
| 16:52 |
eeevil |
dbwells++ |
| 16:56 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:03 |
csharp |
@quote random |
| 17:03 |
pinesol_green |
csharp: Quote #21: "< Dyrcona> Writing software is more fun than working." (added by csharp at 09:29 AM, November 29, 2011) |
| 17:04 |
Dyrcona |
And with that, I'm outta here. |
| 04:59 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:11 |
|
BigRig_ joined #evergreen |
| 07:46 |
|
rjackson-isl joined #evergreen |
| 07:55 |
|
jboyer-isl joined #evergreen |
| 09:49 |
dbwells |
So, on Google's guide page linked above, looking at the Do/Don't "Travel stream" example, does anyone agree with Google that the raised buttons here are more "heavy" than necessary? |
| 09:50 |
dbwells |
It's about a third of the way down the page. |
| 09:50 |
|
pmurray_away joined #evergreen |
| 09:52 |
phasefx |
dbwells: I don't have a strong opinion there, but I think I'm used to what Google is doing, and I'm very adaptable. Presumably they've done actual user testing (I'd pretty much bet on it) |
| 09:52 |
dbwells |
I'm presuming that as well. |
| 09:53 |
phasefx |
I think the words being verbs and all caps invite them to be interpreted as actions |
| 09:53 |
dbwells |
But even with zillions of dollars, there is always going to be a certain subjectivity to really subtle design choices which is hard to measure, so I'm not going to go all in on Google, either :) |
| 09:55 |
phasefx |
dbwells: and also potential bureaucratic craziness/bias |
| 09:55 |
|
Shae joined #evergreen |
| 09:55 |
phasefx |
I doubt any company is purely rational and numbers driven |
| 09:55 |
jboyer-isl |
My issue with that example (took me a while to find it) is they are comparing completely flat with raised. There’s a level in between, which is just the color border, no shadow. That’s the one I’d prefer in that situation. |
| 09:56 |
jboyer-isl |
phasefx: Google may be as close as can be on that front. (Que stories about the 47 shades of blue A/B testing, etc.) |
| 09:56 |
phasefx |
mmm |
| 09:57 |
gmcharlt |
I also think we can't dismiss that firms like Google, while I do believe that they can and do more actual UX testing... are also under a marketing impetus to refresh their look periodically |
| 09:57 |
phasefx |
as opposed to Yahoo with the CEO changing colors at the last minute :) |
| 10:00 |
dbwells |
jboyer-isl: So do you think you would generally support the idea of a "lighter" button style for cases where button-ness is easily identifiable from context, but a "heavier" style when you need a button to stand out due to placement or generally screen busy-ness? |
| 10:01 |
dbwells |
That question is for everyone else too, of course. |
| 11:56 |
csharp |
hopefully we'll be closer to a browser based client by the time Windows 10 is in common usage, though |
| 11:56 |
mrpeters |
it was working fine |
| 11:56 |
bshum |
mrpeters++ |
| 11:56 |
mrpeters |
i used it for a day to test our standalone debs for Evergreen |
| 11:56 |
bshum |
Testing the future. |
| 11:56 |
mrpeters |
win 10 is going to be pretty solid i think |
| 11:56 |
mrpeters |
may get me to upgrade from win 7 |
| 11:57 |
Jake___ |
Thats great to hear |
| 12:38 |
gmcharlt |
just need somebody to contact me or bshum when they're ready to say go |
| 12:38 |
mrpeters |
i'd probably need someone to tell me when one is needed, and then i'd upload the file and let someone update the downloads page when they update the rest of the clients |
| 12:38 |
gmcharlt |
and for that matter... I'm happen to simply be sent the clients, and I can put them in place |
| 12:59 |
csharp |
gmcharlt: testing your fix now |
| 12:59 |
gmcharlt |
csharp: did you all run into the issue? |
| 12:59 |
* csharp |
recalls running into NOHEADING several months ago |
| 12:59 |
gmcharlt |
snap |
| 13:05 |
kmlussier |
#info kmlussier is Kathy Lussier, MassLNC |
| 13:05 |
gmcharlt |
:) |
| 13:06 |
kmlussier |
Small meeting? :) |
| 13:06 |
gmcharlt |
appears so... |
| 13:06 |
gmcharlt |
#topic Updates |
| 13:06 |
gmcharlt |
#action gmcharlt will install (or verify that it was installed) the libc6 fixes for the "GHOST" vulnerability today on the evergreen-ils.org boxes |
| 13:08 |
gmcharlt |
#action after ALA Midwinter, gmcharlt will get the documentation test VM provisioned |
| 13:08 |
gmcharlt |
kmlussier: any quick updates from you? |
| 13:08 |
kmlussier |
gmcharlt: No, I haven't done anything for the web site this month. |
| 13:08 |
gmcharlt |
I saw that ericar has sent out a query about updated the roster |
| 13:09 |
gmcharlt |
I believe she's on the road today, though |
| 13:28 |
kmlussier |
I would argue that since there wasn't a quorum, the meeting didn't actually take place. ;) |
| 13:28 |
csharp |
one_screenful_meetings++ |
| 13:29 |
tsbere |
kmlussier: Ah, but to discuss things we didn't need a quorum. Just to actually vote on stuff. Our decision was more along the lines of "why discuss things if we can't vote on them anyway?" :P |
| 13:29 |
csharp |
#vote ulitmate power to the web team: Yes |
| 13:30 |
csharp |
er.. ultimate power, even |
| 13:30 |
csharp |
gmcharlt: I tested your branch - signoff branch on the way |
| 13:31 |
bshum |
For fun, http://evergreen-ils.org/irc_logs/evergreen/2011-07/%23evergreen.08-Fri-2011.log was when I thought I had the shortest meeting ever for the community meetings (back when we were doing those). The timestamps put it at14 minutes. So yes, that meeting I missed was shorter :) |
| 13:31 |
bshum |
gmcharlt: Apologies for missing things, I was stuck talking while retrieving my lunch :( |
| 13:32 |
|
vlewis joined #evergreen |
| 12:06 |
pinesol_green |
[evergreen|Dan Wells] Remove unwanted index recreation - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c3c8b74> |
| 12:07 |
goood |
make that 4ffa62207 |
| 12:07 |
pinesol_green |
[evergreen|Ben Shum] LP#1253163: stamping upgrade for authority.in-line-headings - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4ffa622> |
| 12:09 |
bshum |
Honestly, I don't remember what I was testing that day when I merged that. Wasn't that related to the PG 9.3 weirdness and function breakage? |
| 12:11 |
|
jihpringle joined #evergreen |
| 12:11 |
bshum |
Wait, I'm confused by those two commits you linked now. |
| 12:11 |
bshum |
Are you saying the index should be there or shouldn't be there? |
| 12:11 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "MVLC WWW diff with master" (40 lines) at http://paste.evergreen-ils.org/27 |
| 12:12 |
bshum |
Dyrcona: That doesn't look too unusual to me. |
| 12:18 |
bshum |
Or to put it another way, what did I break now? 10+ months later :( |
| 12:41 |
goood |
berick: thanks. are there any instructions for installing on windows or mac? |
| 12:45 |
berick |
goood: no instructions. same concepts for both, though, just different commands |
| 13:03 |
|
bmills joined #evergreen |
| 13:05 |
csharp |
goood: I'm attempting to apply the fix for bug 1414112 on a test server and getting this error: http://pastie.org/9865951 ... it looks like it should work, though :-/ |
| 13:05 |
pinesol_green |
Launchpad bug 1414112 in Evergreen 2.7 "Audience filter no longer searching blank spaces" (affected: 2, heat: 12) [Medium,Confirmed] https://launchpad.net/bugs/1414112 |
| 13:09 |
Dyrcona |
berick: After comparing notes wth bshum, I really think it is something under EGCatloader, probably doing xact_begin followed by xact_commit or xact_rollback, but no disconnect. |
| 13:09 |
Dyrcona |
He sees the messages in his logs, also, just not as many. |
| 13:19 |
csharp |
Dyrcona++ |
| 13:23 |
dbwells |
Hey all. Just a quick double-check: is PG 9.1 still the minimum version for EG 2.7? |
| 13:23 |
csharp |
dbwells: from my understanding, 9.1 has not been deprecated yet for any EG version |
| 13:24 |
bshum |
dbwells: PG 9.1 is the minimum version, but personally I only tested with PG 9.3 and recommend that to everyone who goes up to EG 2.7 :) |
| 13:24 |
dbwells |
csharp++ Thanks. I thought that to be true, but didn't want to find out mid-upgrade that I was wrong :) |
| 13:25 |
csharp |
dbwells: I'll mention that we're on 9.3, so I can speak from experience upgrading to 2.7 on 9.1 ;-) |
| 13:25 |
dbwells |
bshum: That's probably good advice, but my upgrade window is a little tight this time around. We'll get there eventually. |
| 15:12 |
Stompro |
Wireshark says it is trying to use tls1.0, which is enabled, so maybe the problem is with the ciphers enabled. Apache logs show nothing so it is't getting past the ssl negotiation phase. |
| 15:12 |
dbs |
Stompro: umm. works pretty great for me |
| 15:12 |
dbs |
https://www.ssllabs.com/ssltest/analyze.html?d=laurentian.concat.ca&latest anyways |
| 15:13 |
Stompro |
dbs: would you mind sharing your SSLCipherSuite line? I also just loaded a non self signed cert.. I should probably not change too many things at once before testing :) |
| 15:13 |
* dbs |
using https://wiki.mozilla.org/Security/Server_Side_TLS (intermediate support) |
| 15:14 |
|
Shae joined #evergreen |
| 15:14 |
dbs |
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-R |
| 15:14 |
jeff |
Stompro: i'd be interested in your config and in your failure mode / errors, but purely for selfish reasons -- i'd like to know how it can break. doesn't help you fix it right now. |
| 15:14 |
Stompro |
Firefox can connect just fine to the catalog... just not the staff client. |
| 15:14 |
* dbs |
also redirecting everything from HTTP to HTTPS |
| 15:19 |
Stompro |
jeff: The error mode is that the server status check fails with a red "There was an error testing this hostname". The other issue that could be related is that the cert is so new that the OCSP info hasn't been updated, so maybe the staff client is trying to validate the cert against the OCSP list and failing because of that? |
| 15:19 |
Stompro |
And it has nothing to do with the cipher suites. |
| 15:19 |
jeff |
What OCSP issue do you think you're running into? |
| 15:22 |
Stompro |
I think I was supposed to wait an hour or two before using the new cert for the OCSP info to get added. I think a negative reply is cached now on the OCSP server so I have to wait for 24 hours for it to time out. ssllabs does give me an "OCSP ERROR" so they are seeing it also. |
| 16:40 |
Dyrcona |
We got two feet plus, all right. |
| 16:52 |
Dyrcona |
Well, I'm signing off. |
| 16:53 |
Dyrcona |
TTYL, #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> |
| 17:21 |
gmcharlt |
goood: bug 1415234 |
| 17:21 |
pinesol_green |
Launchpad bug 1415234 in Evergreen "uncontrolled attribute values that consistent only of spaces are normalized away" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1415234 |
| 21:26 |
|
csharp joined #evergreen |
| 10:39 |
Dyrcona |
berick: I could possibly share them. |
| 10:39 |
berick |
so they are just hanging out waitin to time out |
| 10:39 |
Dyrcona |
Well, I don't think CStoreEditor is the problem, though we should still probably clean up the code. |
| 10:40 |
Dyrcona |
I mentioned last week that I added a warn to the destructor and did some tests on my dev machine and every other line (not quite) in the logs was the destructor being called. |
| 10:41 |
berick |
that's great, but doesn't help when the destructor isn't called, like when refs are still in scope |
| 10:42 |
Dyrcona |
And now, we're down to 41 cstore drones. |
| 10:42 |
Dyrcona |
Thing is, I haven't found anywhere the refs look like they would still be in scope. |
| 15:17 |
tsbere |
Bmagic_: You need to fix that. ;) autogen.sh -u may work? |
| 15:18 |
Bmagic_ |
tsbere: ok, that did fix that |
| 15:19 |
tsbere |
Bmagic_: In that case your "4 times" issue is likely fixed |
| 15:20 |
Bmagic_ |
tsbere: testing |
| 15:25 |
Bmagic_ |
tsbere: yep, solved |
| 15:25 |
Bmagic_ |
tsbere++ |
| 15:26 |
Bmagic_ |
tsbere: can you help me understand why the DB returned those rows in that function? |
| 16:12 |
dbs |
guess not! |
| 16:34 |
|
eby joined #evergreen |
| 16:45 |
|
mdriscoll1 left #evergreen |
| 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 |
|
mmorgan left #evergreen |
| 18:16 |
|
mrpeters left #evergreen |
| 20:09 |
|
maryj joined #evergreen |
| 09:00 |
pinesol_green |
Launchpad bug 1386347 in Evergreen 2.6 "Speed up hold copy map deletion for clear shelf process, etc." (affected: 1, heat: 6) [Undecided,New] |
| 09:05 |
csharp |
dbs: or eeevil: for bug 1206936, does the suggested change in comment #7 supercede my "use window functions" branch and solve the original problem? |
| 09:05 |
pinesol_green |
Launchpad bug 1206936 in Evergreen "money.transaction_billing_summary view displays incorrect billing_type and billing_note for the actual last transaction" (affected: 1, heat: 6) [High,Triaged] https://launchpad.net/bugs/1206936 |
| 09:05 |
* csharp |
hasn't tested, jsyk |
| 09:07 |
tsbere |
jeff: Regarding differences in default notification formats: TPac (pipe, prefers email, then phone, then sms) vs old JSPac entries (dunno) vs Patron Editor (colon, prefers phone, then email, then sms) |
| 09:10 |
jeff |
tsbere: thanks. i had suspected as such, and started to compare new/old patron editors vs tpac -- thought i saw in tpac that it was colon-delimited, just with a different order. guess i'll have to re-look. |
| 09:14 |
bshum |
csharp: On bug 1386347, I was leaning towards removing the milestone from that, since nobody seems to be championing it for backport presently. |
| 14:00 |
pinesol_green |
[sipserver|Thomas Berezansky] LP#1227273: Clear account info at start and end of connection - <http://git.evergreen-ils.org/?p=SIPServer.git;a=commit;h=cd45513> |
| 14:01 |
bshum |
That's the last commit our SIPServer is up to running apparently. |
| 14:01 |
bshum |
It was before the timeout stuff and the multiplex stuff |
| 14:25 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 14:46 |
Stompro |
Is creating read only postgres access really as difficult as it seems to be? Needing to run a command for every schema individually? |
| 14:50 |
bshum |
Stompro: I believe that's how we had to do it in the past. |
| 14:50 |
bshum |
And actually I think we even went further and specified it table by table in some cases. |
| 15:28 |
kmlussier |
bshum: It shouldn't take me long to look at it again. The problem is all of the other stuff I have on my plate today. |
| 15:30 |
kmlussier |
But if you wait until tomorrow, I can also look at that Lost and Paid bug too. |
| 15:31 |
Dyrcona |
kmlussier: I've loaded the branch on my dev system already, so feel free to toggle settings on there if you want. |
| 15:31 |
dbwells |
kmlussier: rats, sorry. Probably a merge error I made of some kind when getting it into the branch. I loaded the branch earlier on my test box, but haven't gotten back to it yet. I'll get it fixed. |
| 15:31 |
Dyrcona |
The lost and paid fix branch, that is. |
| 15:31 |
kmlussier |
dbwells++ Great, thanks! |
| 15:32 |
bshum |
kmlussier: That's fine, I can wait to cut tomorrow. |
| 15:41 |
bshum |
Damn, missed the # in the previous commits |
| 15:41 |
jeff |
but not as many wasted characters as LP#number - Commit description here |
| 15:41 |
bshum |
I need to finish poking at the ilbot config |
| 15:43 |
Dyrcona |
I need to test phasefx_'s marc_export changes. Probably won't get to it today. |
| 15:44 |
Dyrcona |
They won't go into 2.7 anyway. |
| 15:48 |
pinesol_green |
[evergreen|Bill Erickson] LP#1407171 Avoid DEFLATEing fm_IDL.xml - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=112b270> |
| 15:50 |
pinesol_green |
[evergreen|Ben Shum] LP#1373594: Also ignore subfield 7 in get_graphics_880s - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=67999a6> |
| 15:57 |
bshum |
It's cause that's already the default, but should we keep that in the help info for people who might have it live elsewhere for some reason? |
| 16:12 |
|
mrpeters left #evergreen |
| 16:12 |
|
mrpeters joined #evergreen |
| 16:14 |
dbwells |
kmlussier: Dyrcona: I missed one added and two deleted lines in my merging (or unmerging, as the case may be). It seems happier now at my end, so I force pushed over the same branch (collab/dbwells/1198465_cstore_fines_gen). Thanks for the early testing! |
| 16:14 |
kmlussier |
dbwells++ |
| 16:18 |
Dyrcona |
kmlussier: I can load the revised branch if you want to look at it tomorrow. |
| 16:18 |
remingtron |
bshum: I think the help info should be enough as is, since the config setting is the first option listed. But I don't have strong feelings either way. |
| 16:30 |
bshum |
Dyrcona: Most of the things I end up pushing to 2.7 tend to be either tiny or broken things. I usually save dbwells the trouble of pushing it to rel_2_6 on his behalf, but I could change that if he'd prefer to push it himself :) |
| 16:31 |
kmlussier |
Dyrcona++ Thank you! |
| 16:31 |
jeff |
bshum: so trying to install debian-wheezy-packager target after installing debian-wheezy-developer results in an error because it tries to clone the node git repo a second time. |
| 16:31 |
bshum |
If it was me, I wouldn't hold off on backporting if it's indeed a bug fix. |
| 16:32 |
bshum |
jeff: Ahh..... I primarily tested the Ubuntu side of things, and those are all packages. |
| 16:32 |
bshum |
So it doesn't usually clobber itself, it'll just add whatever packages it's still missing. |
| 16:32 |
* jeff |
nods |
| 16:32 |
bshum |
jeff++ # may want to file that a new bug then for 2.8 series. |
| 16:33 |
bshum |
Darn Wheezy |
| 16:44 |
bshum |
Hmm |
| 16:45 |
bshum |
Maybe like the install_libdbi thing before install_nodejs_from_source |
| 16:45 |
bshum |
Where we look for the folder, if not present, get it, etc. |
| 16:45 |
dbwells |
I think whoever does the testing should go ahead and push to all applicable branches. The fact that bshum is an RM and also tests a bunch of things just confuses the situation ;) |
| 16:46 |
* bshum |
either has lots of hats or lots of heads. |
| 16:46 |
bshum |
Possibly both. |
| 16:47 |
bshum |
jeff: That's of course all from Makefile.common I'm curiously looking at. |
| 16:55 |
Dyrcona |
I'll just build a new vm on Saturday or Monday. |
| 16:55 |
kmlussier |
Dyrcona: Thanks for trying! |
| 16:55 |
* kmlussier |
calls it a day |
| 16:56 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:01 |
berick |
tsbere: re: bug 1413624, if you hope to get it merged into 2.8, go ahead and target 2.8-beta |
| 17:01 |
pinesol_green |
Launchpad bug 1413624 in Evergreen "New AccessHandler Module" (affected: 1, heat: 8) [Undecided,New] https://launchpad.net/bugs/1413624 |
| 17:02 |
eeevil |
dbwells: I've been terribly remiss in not looking at your cstore-fine-gen code ... I'm wondering what the reason for that is? (the use of cstore instead of dbi in the storage app, in particular) ... but, I think I've found a problem in any case. it looks like penalty calculation is being called before the cstore->commit is called |
| 14:12 |
|
nhilton joined #evergreen |
| 14:15 |
Dyrcona |
Ah.. here's a question. |
| 14:15 |
Dyrcona |
What happens to results from a substream search if the transaction is rolled back and the editor disconnected? |
| 14:16 |
Dyrcona |
S'pose I can write a test program to find out. |
| 14:18 |
berick |
cseditor does everything synchronously, so you couldn't disconnect/rollback until all results had been retrieved. |
| 14:19 |
berick |
in which case they're no different than non-substream data |
| 14:19 |
Dyrcona |
OK/ |
| 15:34 |
kmlussier |
I knew the answer to that question a few months ago. |
| 15:34 |
tsbere |
I believe marking as claims returned will overwrite the lost stop fines reason as well. |
| 15:34 |
tsbere |
Just as an extra data point |
| 15:35 |
bshum |
Then I feel better about looking at the stop_fine reason to decide whether to set the lost&paid status |
| 15:35 |
bshum |
mmorgan++ # testing |
| 15:42 |
* dbs |
moves onto trying to find out why "Add to list" is failing silently (at least client side), wonders whether our HTTPS-everything config may be a factor. |
| 15:44 |
dbs |
"GET /eg/opac/mylist/add?locg=105;record=830689 HTTP/1.0" 302 4896 "http://laurentian.concat.ca/eg/opac/mylist/add?locg=105;record=830689" says yes. |
| 15:44 |
dbs |
302 = "go to HTTPS dummy!" |
| 15:45 |
kmlussier |
For those who missed the email, the scheduling poll for our next Bug Squashing Day is at http://doodle.com/umc27afh7akqczft |
| 15:46 |
* dbs |
squints at ctx.opac_root |
| 15:47 |
* Dyrcona |
pushed a commit to fix a/ts to the collab branch. |
| 15:47 |
Dyrcona |
Tested it on dev with a hold notification and it still works. |
| 15:48 |
Dyrcona |
We're going to load it into production next time we have to restart services. |
| 15:49 |
dbs |
$ctx->{base_path} = $r->dir_config('OILSWebBasePath'); # getting there |
| 15:51 |
|
vlewis joined #evergreen |
| 16:37 |
* dbs |
determines that the http 302 redirects for lists are from yandex web crawler. *sigh* |
| 16:38 |
bshum |
mmorgan: I added a new comment with a potential working branch for https://bugs.launchpad.net/evergreen/+bug/1412893/comments/2 |
| 16:38 |
pinesol_green |
Launchpad bug 1412893 in Evergreen "Applying lost and paid status at the wrong time" (affected: 2, heat: 10) [Undecided,Confirmed] |
| 16:39 |
bshum |
mmorgan: If you get time later to try tossing that in some test environment and seeing if it handles the lost&paid situation better, let me know what you can find out. |
| 16:39 |
bshum |
I plan to try it out more when I can get it on a system too. |
| 16:39 |
bshum |
Dyrcona++ # helping me fix my sucky perl |
| 16:42 |
|
mrpeters left #evergreen |
| 16:46 |
mmorgan |
bhum: I will give it a try at some point soon. |
| 16:47 |
mmorgan |
bhsum++ |
| 10:31 |
wsmoak |
this is a fairly fresh Yosemite install, and I haven't customized FF at all |
| 10:33 |
wsmoak |
will be interesting to see what another osx user sees. Norton might be to blame, it sticks its nose where it isn't wanted all the time. |
| 10:34 |
wsmoak |
anyway... the search works fine now that I know what I'm looking at. :) minor issue. |
| 10:48 |
dbs |
http://i.imgur.com/dbmZDa9.png is what mine looks like |
| 10:48 |
dbs |
(highlighting PINES obscures the icon sadly, oh well) |
| 10:53 |
|
julialima_ joined #evergreen |
| 10:54 |
* dbs |
wonders idly why Browse catalog by title works in one library in our instance but not in another |
| 10:54 |
dbs |
(returns a server 500 error, yikes) |
| 10:58 |
* dbs |
peers at egweb: Context Loader error: Can't use an undefined value as a HASH reference at WWW/EGCatLoader/Browse.pm line 271. |
| 11:00 |
dbs |
suggests its a database error, and the there's no $self->editor->event member that was returned I guess. |
| 11:03 |
* dbs |
opts to stop testing defensive code in production after making every page request return 500 :) |
| 11:21 |
|
yboston joined #evergreen |
| 12:00 |
|
Dyrcona joined #evergreen |
| 12:09 |
dbs |
my defensive code is simply offensive |
| 12:12 |
dbs |
even weirder, that browse works on our test instance where we haven't reingested all of the records. hrm. |
| 12:18 |
|
jihpringle joined #evergreen |
| 12:23 |
eeevil |
dbs: any chance the osrf translator memcache instance is misconfigured in the apache configs? I've seen that break browse and just a couple other things in the past. A/T event def editor would also break, for instance |
| 12:24 |
dbs |
eeevil: definitely possible |
| 12:37 |
Dyrcona |
But then, I'm "off" today. |
| 12:38 |
|
sandbergja joined #evergreen |
| 12:47 |
julialima_ |
Hello evergreeners!!! The web client is not working, at least for me. In the patron search I can´t perform any search, I have no feedback so I don´t know what is going on. Anyone know if there is a problem? |
| 12:47 |
bshum |
Dyrcona: I've seen that too actually. |
| 12:47 |
bshum |
Also "off" :) |
| 12:51 |
bshum |
julialima_: I'm probably not the best person to answer you (I'm not sure how many folks have off today in the US). Anywho, which server are you using to test with? |
| 12:52 |
dbwells |
julialima_: Some folks might be at lunch, which is where I am headed. Also, just to clarify, are you talking about webby.evergreencatalog.com, or some other test site? |
| 12:52 |
bshum |
Maybe there might be a hint in the browser console |
| 12:53 |
gmcharlt |
julialima_: try webby now; I've restarted services there and it's now working for me |
| 12:54 |
julialima_ |
gmcharlt: It is working now, thank you very much! :) |
| 07:34 |
|
sarabee joined #evergreen |
| 07:53 |
|
ericar joined #evergreen |
| 08:06 |
|
_bott_ joined #evergreen |
| 08:15 |
kmlussier |
eeevil: I'll see if I can get some end user testing here on webby for those web client fixes. |
| 08:26 |
|
rjackson-isl joined #evergreen |
| 08:31 |
|
Shae joined #evergreen |
| 08:34 |
|
abowling joined #evergreen |
| 10:20 |
* csharp |
laughs evilly |
| 10:20 |
jboyer-isl |
It's particularly fun to use cores-1, provided it has the RAM to pull it off. |
| 10:20 |
csharp |
jboyer-isl: daredevil! |
| 10:21 |
jboyer-isl |
I like to test ACID compliance, keep postmaster on it's toes, etc. :D |
| 10:21 |
* berick |
waits for a 'top' screenshot |
| 10:22 |
csharp |
ERROR: not enough room on screen |
| 10:22 |
berick |
says it all |
| 12:09 |
dbs |
We are still using scripts though! Which is always fun. |
| 12:09 |
|
julialima_ joined #evergreen |
| 12:16 |
|
mtcarlson joined #evergreen |
| 12:39 |
kmlussier |
berick/eeevil: For commit b577d39, is there a specific bug with dates being fixed that we should be testing for? |
| 12:39 |
kmlussier |
Hmm...I thought that would bring up the commit if I typed it that way. |
| 12:39 |
|
buzzy joined #evergreen |
| 12:39 |
berick |
kmlussier: it's not a bug |
| 12:39 |
berick |
it's part of the noncat circ display |
| 13:41 |
mrpeters |
what is current reccomended xulrunner for 2.72? (building a mac client) |
| 13:45 |
berick |
mrpeters: 14.0.1 |
| 13:45 |
mrpeters |
thanks berick! |
| 13:45 |
eeevil |
kmlussier++ # testing! :) |
| 13:57 |
|
nhilton_ joined #evergreen |
| 13:59 |
|
Sally joined #evergreen |
| 14:21 |
dbs |
julialima++ # great stuff |
| 14:45 |
Dyrcona |
kmlussier: OK. I likely haven't read that one yet. |
| 14:47 |
jeff |
kmlussier: thanks for calling that out. i've been reading that thread but apparently am not current. |
| 14:49 |
|
nhilton joined #evergreen |
| 14:52 |
kmlussier |
eeevil / berick: If you're still around, there were 4 bug fixes mentioned in Mike's most recent bug repairs comment that I was unsure on what to test for. http://pastebin.com/r21hv2ke |
| 14:53 |
kmlussier |
Some may be related to other fixes to be tested there, but I just want to make sure I'm not missing anything. |
| 14:53 |
berick |
kmlussier: for "Repair browser client dropdown buttons" -- it's an issue that would only appear on a fairly new server |
| 14:54 |
|
mrpeters left #evergreen |
| 14:54 |
berick |
in the grids, the Actions drop-down buttons don't work w/o the patch |
| 14:54 |
berick |
making sure they still work on older servers would be helpful, thoug |
| 14:54 |
berick |
h |
| 14:54 |
kmlussier |
berick: Ok. So the 1st isn't something I can really test for on webby? |
| 14:55 |
berick |
checking Actions dropdowns in Webby to make sure the change didn't introduce a problem would be good |
| 14:55 |
kmlussier |
berick: Sure, that we can do. :) |
| 14:55 |
berick |
kmlussier: for "Avoid org tree retrieval race condition on patron app" -- without this patch, pages would sometimes fail to load with a JS error. if you never saw the problem before, it's not really testable, apart from "hey, pages load!" |
| 11:45 |
bshum |
patron? |
| 11:45 |
bshum |
Hmm |
| 11:45 |
bshum |
Oh right |
| 11:45 |
abowling |
bshum: just for testing, i've commented out this line just for a simple test: |
| 11:45 |
abowling |
//$('hold_usr_textbox').value = au_obj.card().barcode(); |
| 11:45 |
bshum |
My mind's not on XUL stuff :) |
| 11:46 |
abowling |
understood. i'm pretty good with the perlmods and OPAC, but my XUL history is limited, and that's understating it |
| 11:47 |
abowling |
upon restarting the staff client, $('hold_usr_textbox') is still getting a value set |
| 12:09 |
bshum |
berick: Right, I know |
| 12:09 |
jeff |
abowling: worth noting that your apache log line is NOT requesting the javascript file you stated you were editing. |
| 12:10 |
bshum |
If so, he's probably looking for /openils/var/template/opac/place_hold.tt2 (or ../parts/place_hold.tt2 actually) |
| 12:10 |
abowling |
i'm pulling up test records, clicking "Place Hold", and then selecting "Advanced Options" |
| 12:10 |
jeff |
abowling: i think you want to be looking at /openils/var/web/opac/skin/default/js/holds.js and such. |
| 12:10 |
abowling |
bshum: that now seems likley |
| 12:10 |
bshum |
Ah, yeah, wrong place. |
| 16:03 |
rangi |
they do 2 weeks, first week is learning |
| 16:03 |
rangi |
2nd week is project work |
| 16:04 |
rangi |
its been Koha, Drupal, Mahara, Silverstripe and Piwik |
| 16:09 |
* jeff |
returns from digging |
| 16:10 |
jeff |
vandelay functions were in a bad state on my test instance. |
| 16:10 |
Dyrcona |
rangi: Cool. |
| 16:10 |
jeff |
fixed, all's well. |
| 16:11 |
jeff |
and this is a good reminder that i need to do some more research with regard to better ways to schema-only diff postgres databases :-) |
