| Time |
Nick |
Message |
| 04:30 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:11 |
|
rjackson_isl joined #evergreen |
| 07:22 |
|
JBoyer joined #evergreen |
| 07:29 |
|
agoben joined #evergreen |
| 08:12 |
|
collum joined #evergreen |
| 08:53 |
|
collum_ joined #evergreen |
| 09:38 |
* csharp |
discovers nice tool for initial diagnosis of SPF problems: http://www.openspf.org/Why |
| 09:39 |
bshum |
csharp++ # always handy :) |
| 10:07 |
bshum |
fwiw, I tested my branch changes for newer nodejs for fresh wheezy and it installed with the -developer target there too. |
| 10:38 |
auvajs |
hello.. I succesfully installed Evergreen :)) my first question: how can I change settings so that the stuff browser client is not located at https://localhost/eg/staff/login but on address like https://staff.mydomain.com ? I installed evergreen on a vps so that accessing the site via the vps localhost is kinda uncomfortable.. |
| 10:42 |
bshum |
auvajs: Congrats on the successful install :) |
| 10:44 |
|
auvajs joined #evergreen |
| 10:46 |
bshum |
auvajs: So I think that you might be wanting to check out how the vhost is defined in eg.conf |
| 10:46 |
bshum |
For the apache config |
| 10:46 |
bshum |
The default file content is like "ServerAlias 127.0.0.1:443" |
| 10:47 |
bshum |
And if you know of specific hostnames you'd like to define, that could be something to look at |
| 10:47 |
bshum |
But otherwise, I think you might need to know more about how your VPS sets up remote access, and if you have to define your DNS records for your VPS somewhere |
| 10:47 |
bshum |
To say staff.mydomain.com points at the public IP for the VPS |
| 10:49 |
bshum |
I think you'll always see the rest of the page URL like /eg/staff/login, etc. |
| 10:49 |
bshum |
But the hostname part can be changed, depending on how you've got things setup. |
| 10:53 |
auvajs |
I simply changed ServerName to admin.mydomain.com and restarted apache but it doesn't seem to be working. I also have my own set of certificates so I commented out all ssl-lines and maybe it caused some problems |
| 11:02 |
|
jvwoolf joined #evergreen |
| 11:03 |
bshum |
auvajs: Well, there are many SSL lines in the config, so perhaps... |
| 11:03 |
|
kmlussier joined #evergreen |
| 11:04 |
auvajs |
oh yes I got it back.. hope it's not going to mess up with my letsencrypt :) |
| 11:05 |
bshum |
auvajs: I've used letsencrypt on my Evergreen servers before. Great choice these days. |
| 11:06 |
kmlussier |
bshum++ # Web client install success |
| 11:06 |
bshum |
kmlussier: Yay! |
| 11:06 |
kmlussier |
bshum: Is there a LP bug on that or should I create one? |
| 11:06 |
bshum |
We need to create one I guess. |
| 11:06 |
bshum |
Or alternatively |
| 11:06 |
bshum |
I thought about appending it as a followup patch |
| 11:06 |
bshum |
For dbs' branch to update bower->node |
| 11:06 |
kmlussier |
Oh, to the original bug from dbs. That works too. |
| 11:06 |
bshum |
For package changes |
| 11:07 |
bshum |
Since that's what causes the need for the newer nodejs in the first place |
| 11:07 |
bshum |
bug 1680624 |
| 11:07 |
pinesol_green |
Launchpad bug 1680624 in Evergreen "Consolidate JS dependency install with npm" [Undecided,Fix committed] https://launchpad.net/bugs/1680624 |
| 11:08 |
gmcharlt |
since that original bug is fix-committed, I prefer that a new one be opened |
| 11:08 |
kmlussier |
gmcharlt: OK, I'll file the bug then. Thanks! |
| 11:09 |
auvajs |
anyway, I'm getting Internal Server Error instead of the staff web client.. apache error log: http://termbin.com/4w6o -- any idea how to solve it? :( |
| 11:16 |
bshum |
Hmm, for that kind of internal server error, you might learn more from the osrfsys.log file |
| 11:16 |
gmcharlt |
well, the perl:error log entry in that paste makes me suspect that apache2/envvars needs to be updated to set the run user to opensrf |
| 11:19 |
kmlussier |
bshum: You mentioned Friday that we need to make some tweaks to the README? |
| 11:19 |
kmlussier |
Oh, never mind. You made those changes. |
| 11:20 |
bshum |
kmlussier: I did it quickly, I think they looked right to me. |
| 11:29 |
pinesol_green |
[evergreen|Ben Shum] LP#1683388:Install newer NodeJS binary for Ubuntu Trusty and Debian Wheezy - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=098dc59> |
| 11:29 |
pinesol_green |
[evergreen|Ben Shum] LP#1683388: Docs: README change for nodejs installation - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=495b253> |
| 11:36 |
kmlussier |
bshum: Do you think you'll have a chance to look at bug 1682292 before Wednesday's maintenance release? |
| 11:36 |
pinesol_green |
Launchpad bug 1682292 in Evergreen "advanced search filter block title is not translated" [Medium,Triaged] https://launchpad.net/bugs/1682292 |
| 11:38 |
bshum |
kmlussier: I just saw miker's post on that one. I'll give it a proper whirl tonight. |
| 11:38 |
kmlussier |
Also for the maintenance release, would somebody be willing review my code on bug 1680142 by Wednesday? |
| 11:38 |
pinesol_green |
Launchpad bug 1680142 in Evergreen "Responsiveness of new ebook elements" [Medium,New] https://launchpad.net/bugs/1680142 |
| 11:38 |
kmlussier |
bshum++ # Thank you! |
| 11:38 |
* kmlussier |
is going to disappear for a while, but will try to merge some other fixes before the maintenance release. |
| 11:45 |
auvajs |
bshum: http://termbin.com/6ltp this is the osrfsys.log.. I don't understand it at all :) |
| 11:47 |
bshum |
auvajs: gmcharlt had an idea to check the run user for apache config to make sure that it's opensrf |
| 11:54 |
auvajs |
bshum: that was it.. thanks :)) it's finally running :) |
| 11:56 |
|
khuckins__ joined #evergreen |
| 11:59 |
bshum |
gmcharlt++ |
| 11:59 |
bshum |
auvajs++ # yay, running Evergreen :) |
| 12:02 |
auvajs |
only I can't log in .. lol.. after clicking sign in nothing happens.. :D |
| 12:06 |
bshum |
auvajs: Which version of Evergreen are you installing again? 2.12.0? |
| 12:24 |
auvajs |
yup 2.12.0 |
| 12:25 |
auvajs |
I'm able to log in into "My account" but not to the staff one |
| 12:25 |
auvajs |
via /eg/staff/login |
| 12:33 |
* jeff |
shakes fist at ev_def_owner_hook_val_react_clean_delay_once |
| 12:34 |
berick |
auvajs: what browser? |
| 12:35 |
auvajs |
Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:52.0) Gecko/20100101 Firefox/52.0 |
| 12:40 |
auvajs |
doesn't work on mobile either |
| 12:45 |
jonadab |
Shouldn't you be getting the "must register a workstation" thingydoo? |
| 12:46 |
jonadab |
(Assuming the eg account username and password are correct.) |
| 12:47 |
berick |
auvajs: point your browser at https://HOSTNAME:7682/ and click through the SSL warning |
| 12:47 |
bshum |
Two things I can think of to break that... 1) websockets isn't running, or the ports aren't reachable ; or 2) busted fieldmapper / autogen resulting in failure to retrieve org units for workstation registration |
| 12:47 |
berick |
another advantage to using nginx, btw, FF only requires the one click-thru since all SSL takes place on the same port |
| 12:48 |
bshum |
Could double check by pointing a XUL client at the application and seeing if you can register a workstation that way, just to be sure it isn't number 2. |
| 12:49 |
bshum |
auvajs: That's a good point, maybe you need to change the SSL cert for the websocket config, since you using letsencrypt on the main apache instance. |
| 12:49 |
bshum |
So that they're the same |
| 12:49 |
berick |
ah, in that case yeah, point them at the same circ |
| 12:49 |
auvajs |
berick: I'm getting Unable to connect error |
| 12:49 |
berick |
er, cert |
| 12:49 |
berick |
auvajs: ok, that means websockets is not running |
| 12:50 |
berick |
(or it's blocked by a firewall) |
| 12:52 |
bshum |
They might have missed the step cause it's still listed "optional" in the OpenSRF 2.5.0 readme, But that really should be "required" now for web staff client :) |
| 12:52 |
berick |
true |
| 13:49 |
csharp |
more on the "crazy sh*t going on with Atlanta interstates" front: http://www.ajc.com/news/traffic/breaking-all-lanes-west-closed-after-highway-buckles/hYsmmjeyaXo6qfDIYm94mM/ |
| 14:01 |
jonadab |
I think if a road up here looked like that, we'd close it too. |
| 14:18 |
|
scottpails joined #evergreen |
| 15:04 |
* miker |
merges the remainder of the webstaff branch to master, in order to actually work against master... whee! |
| 15:04 |
miker |
(save one commit that phasefx is looking at) |
| 15:05 |
miker |
commit in question is 3c2b5d6208 ... berick, you might be helpful there. it conflicts with the progress bar change |
| 15:07 |
pinesol_green |
Showing latest 5 of 14 commits to Evergreen... |
| 15:07 |
pinesol_green |
[evergreen|Mike Rylander] webstaff: Reprint Last Receipt functionality - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=74a2c69> |
| 15:08 |
pinesol_green |
[evergreen|Kyle Huckins] LP#1528924 Item Status List Columns - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=39bac20> |
| 15:08 |
pinesol_green |
[evergreen|Mike Rylander] LP#1528924: Use localizable date filter format - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c6ce827> |
| 15:08 |
pinesol_green |
[evergreen|Mike Rylander] webstaff: Allow adding new volumes to libaries that were not selected in the holdings UI (and fix a couple minor bugs) - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b58023a> |
| 15:08 |
pinesol_green |
[evergreen|Mike Rylander] webstaff: install and include Lovefield in prep for offline mode - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=406fe9f> |
| 15:09 |
berick |
miker: ah.. the commit it's probably conflicting with prevents the page-load-time empty searches |
| 15:09 |
berick |
so it may not even be necessary |
| 15:09 |
miker |
well, the goal is to add a sound, IIUC |
| 15:10 |
miker |
anyway, I KNOW NUZZINK! I just couldn't easily resolve that one |
| 15:11 |
berick |
ok, right, so some of the commit may be unnecessary (the first_run part) |
| 15:11 |
berick |
phasefx: ^-- |
| 15:11 |
berick |
since there will be no first_run empty search anymore |
| 15:13 |
phasefx |
berick: my first pass at resolving it just resulted in no sound being attempted, but I haven't given it more scrutiny than that |
| 15:15 |
phasefx |
oh, I see, show_search_progress went away too |
| 15:17 |
berick |
eah |
| 15:17 |
berick |
yeah |
| 15:17 |
phasefx |
miker: berick: I can fix it |
| 15:17 |
berick |
phasefx: playing a sound on successfull search? |
| 15:17 |
phasefx |
berick: on empty search results |
| 15:17 |
berick |
oh, ok |
| 15:18 |
phasefx |
berick: well, there is one for successful search too |
| 15:18 |
berick |
yeah.. |
| 15:18 |
phasefx |
as part of that |
| 15:18 |
berick |
just curious about the desire for that. seems like overkill, but i also don't work at a circ desk |
| 15:19 |
berick |
don't let me distract you, though :) |
| 15:20 |
phasefx |
berick: may have been in response to some pain memory of the call timing out, etc. Though I would have expected a network dialog in that case |
| 15:20 |
phasefx |
progress bar would also tackle that point |
| 15:20 |
berick |
and the (new) zero-hits sound |
| 15:20 |
phasefx |
"is it still searching or no results?" |
| 15:21 |
berick |
yeah, progress dialog covers that i would think |
| 15:22 |
phasefx |
given how much I've been reading up on disabilities, I'm not oppossed to overkill when it engages multiple senses |
| 15:22 |
phasefx |
if we could do egOdor I might would throw that in too :) |
| 15:22 |
* berick |
prefers egHodor |
| 15:22 |
berick |
but point taken :) |
| 15:22 |
phasefx |
egGroot |
| 15:23 |
phasefx |
that'll have to be our mascot down the road |
| 15:23 |
berick |
totally |
| 15:23 |
phasefx |
when copyright expires in infinity+1 |
| 15:25 |
phasefx |
berick: so I should throw the warning sound in that ['finally'] clause |
| 15:25 |
phasefx |
wrap it and egProgressDialog.close into a function |
| 15:26 |
berick |
phasefx: yes, exactly |
| 15:26 |
phasefx |
gracias |
| 15:26 |
|
Jillianne joined #evergreen |
| 15:27 |
berick |
well, the finally catches all cases |
| 15:27 |
berick |
error, success, and zero |
| 15:27 |
berick |
so you might need some additional logic in there to chose the right sound |
| 15:27 |
phasefx |
gotcha |
| 15:27 |
berick |
and probably remove the error sound from the error handler or it will fire 2 times |
| 15:28 |
berick |
patronSvc.patrons.length == 0 for the zero-hits test |
| 15:30 |
berick |
well, no, that's probably over complicating it |
| 15:30 |
berick |
leave error.patron.by_search where it is. put success.patron.by_search and warning.patron.by_search both in the main resolve handler (where warning.patron.by_search is now) |
| 15:31 |
berick |
and just check ofr patronSvc.patrons.length to determine which of those 2 to fire |
| 15:31 |
phasefx |
berick: so I'm assuming putting something in the error handler slot will keep finally from firing.. unless maybe you do a return false; or somesuch from it? |
| 15:32 |
berick |
no, finally always fires |
| 15:32 |
phasefx |
k |
| 15:32 |
berick |
so it makes sense to close the dialog there, because it should always go away, but not so much the sounds, because you don't know how you got there, unless you add other context information |
| 15:34 |
phasefx |
berick: look sane? http://paste.evergreen-ils.org/80 well, need to change close to close() |
| 15:35 |
phasefx |
and get rid of that explicit success earch |
| 15:35 |
phasefx |
sound |
| 15:36 |
phasefx |
http://paste.evergreen-ils.org/81 |
| 15:36 |
phasefx |
well, that could make warning trump the error |
| 15:37 |
phasefx |
so do which_sound <> 'error' && patronSvc.patrons.length == 0 |
| 15:37 |
phasefx |
or == 'success' && etc |
| 15:37 |
* phasefx |
tests all this |
| 15:38 |
berick |
yeah, i think that would do it |
| 15:43 |
phasefx |
berick: found an unrelated bug.. doesn't seem to be a big deal, but if I do a patron search get results, then try to clear out the search form and hit Search again, sometimes I'll get cached results from a previous search |
| 15:44 |
phasefx |
on the bright side, sounds are working :) except for 0 results on a completely empty search, but I'm not inclined to do anything about that |
| 15:45 |
phasefx |
miker: collab/phasefx/webstaff_patron_search_sfx |
| 15:45 |
phasefx |
berick: thanks man |
| 15:52 |
miker |
phasefx / berick: thanks. I'll pick that in |
| 15:56 |
pinesol_green |
[evergreen|Jason Etheridge] webstaff: sound effects for patron search - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6173680> |
| 16:02 |
|
Nina_ joined #evergreen |
| 16:02 |
Nina_ |
join |
| 16:03 |
Nina_ |
Hello! |
| 16:30 |
|
jvwoolf left #evergreen |
| 16:30 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:16 |
bshum |
dbs: The more I work on i18n stuff for db.seed fixing, the more I'm starting to think we're missing a major step between newpot and update_pofiles in https://wiki.evergreen-ils.org/doku.php?id=dev:release_process:evergreen:2.8 |
| 17:17 |
bshum |
dbs: When I run the option for "make update_all_locales" in the directory to sync the PO templates against the existing PO files, I get a ton of changes |
| 17:17 |
bshum |
And in reading through our wiki steps for release making, I don't think that's happened |
| 17:17 |
bshum |
Which is why there's such a massive upheaval when I run it locally. |
| 17:18 |
bshum |
and it generates out a whole slew of fresh PO files (mostly empty of course) for all the various locales and files we now translate for. |
| 17:18 |
bshum |
I'm not 100% sure if we want it to generate all these empty translation files or not yet. My next step in testing is to see what it'll do with PO sync against the bzr branch for exported translations from LP |
| 17:19 |
bshum |
But I think we might need to invoke some extra steps here |
| 20:08 |
|
Guest35655 joined #evergreen |
| 20:25 |
|
kmlussier joined #evergreen |
| 20:27 |
dbs |
bshum: yeah, translations.launchpad.net / pootle etc are effective just abstracted front-ends for editing those PO files |
| 20:28 |
dbs |
Doesn't surprise me that there would be drift, particularly with the db.seed file |
| 21:59 |
|
khuckins__ joined #evergreen |
| 22:20 |
|
genpaku joined #evergreen |
| 23:14 |
kmlussier |
@later tell dbwells Could I take https://bugs.launchpad.net/evergreen/+bug/1670407 off your hands? I'm hoping to get it merged for Wednesday's maintenance release. |
| 23:14 |
pinesol_green |
kmlussier: The operation succeeded. |
| 23:14 |
pinesol_green |
Launchpad bug 1670407 in Evergreen "Return of paid lost items will not reopen a closed transaction" [Medium,Confirmed] - Assigned to Dan Wells (dbw2) |
