| Time |
Nick |
Message |
| 04:12 |
|
remingtron_ joined #evergreen |
| 04:34 |
pinesol_green |
Showing latest 5 of 14 commits to Evergreen... |
| 04:34 |
pinesol_green |
[evergreen|Dan Scott] LP#1410532: TPAC "Show more details" config option - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0a9ae15> |
| 04:34 |
pinesol_green |
[evergreen|Art Rhyno] LP#1410532: TPAC - Make "Show more details" in results optional - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f691386> |
| 04:34 |
pinesol_green |
[evergreen|Ben Shum] LP#1410532: Follow-up to fix config option for "Show more details" - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=628891a> |
| 04:34 |
pinesol_green |
[evergreen|Dan Scott] LP#1411106: Add URIs to the list of bib records for sitemaps - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e3e63c1> |
| 04:34 |
pinesol_green |
[evergreen|Christine Morgan] LP#1413769: Better access to My Lists - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=abfc6b4> |
| 04:47 |
bshum |
@later tell dbs I added a quick release note about the "show more details"; we may want to write up a longer/comprehensive notes entry for all the new changes for linkeddata/schema.org stuff |
| 04:47 |
pinesol_green |
bshum: The operation succeeded. |
| 04:50 |
pinesol_green |
[evergreen|Ben Shum] LP#1413769: Add release note for new link to My Lists - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2ab14a8> |
| 04:50 |
pinesol_green |
[evergreen|Ben Shum] LP#1410532: Add release note for "show more details" option - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d045583> |
| 07:29 |
|
Callender joined #evergreen |
| 07:36 |
|
graced joined #evergreen |
| 07:41 |
|
julialima_ joined #evergreen |
| 07:44 |
|
jboyer-isl joined #evergreen |
| 07:48 |
|
rjackson_isl joined #evergreen |
| 07:57 |
|
ericar joined #evergreen |
| 08:08 |
|
collum joined #evergreen |
| 08:20 |
|
akilsdonk joined #evergreen |
| 08:30 |
|
mrpeters joined #evergreen |
| 08:43 |
pinesol_green |
[evergreen|Mike Rylander] LP#1413592: Don't change lost/long-overdue fines/fees on zero-balance - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e65a760> |
| 08:43 |
pinesol_green |
[evergreen|Mike Rylander] LP#1413592: Avoid generating fines in "consider zero balance closed" mode - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=43c8619> |
| 08:43 |
pinesol_green |
[evergreen|Kathy Lussier] lp1413592: Release notes entry for no changes to fully-paid lost transactions - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=78d7ce8> |
| 09:19 |
mrpeters |
morning all -- im still fighting a mark lost action trigger and the only real error im seeing in the logs is "Use of uninitialized value in string ne at /usr/local/share/perl/5.14.2/OpenILS/Application/Trigger.pm line 421." but I find that current master still has the exact same line 421 -- is this just noise I can ignore and not related to my my mark lost action is erroring or is there more to this? |
| 09:20 |
mrpeters |
next if ($granularity && $def->granularity ne $granularity ); |
| 09:20 |
|
maryj joined #evergreen |
| 09:25 |
|
TaraC_ joined #evergreen |
| 09:35 |
|
sarabee joined #evergreen |
| 09:49 |
mrpeters |
looks like that wasn't the cause of my problems, got them solved! but still curious about the noise in the logs about that uninitialized value |
| 09:55 |
* eeevil |
goes to clean up his db upgrade script numbering bumble... |
| 09:56 |
eeevil |
calling 0907 |
| 09:59 |
pinesol_green |
[evergreen|Mike Rylander] LP#1413592: DB upgrade script numbering - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9238334> |
| 10:03 |
eeevil |
dbwells: I was just peeking at your "last_fine^Wnext_fine" branch, and this line doesn't make sense to me: |
| 10:04 |
eeevil |
+ if ( $next_fine == $due + 1 # we have no fines yet |
| 10:04 |
eeevil |
the "+ 1" part in particular |
| 10:05 |
eeevil |
$next_fine and $due are epochs, IIRC |
| 10:07 |
eeevil |
dbwells: ah, nevermind... I see where you're incrementing the next fine one second into the window |
| 10:14 |
dbwells |
eeevil: funny enough, at one point I had an $is_first_billing bool to make that test more clear, but decided it was simpler to just do the math again. Oh well. |
| 10:15 |
eeevil |
dbwells: well, you have a comment that I should have noticed. all's well, I think |
| 10:49 |
|
wjr joined #evergreen |
| 11:03 |
|
mrpeters joined #evergreen |
| 11:05 |
|
eeevil joined #evergreen |
| 11:05 |
|
sarabee joined #evergreen |
| 11:29 |
|
chatley joined #evergreen |
| 11:56 |
|
chatley left #evergreen |
| 11:57 |
|
dMiller_ joined #evergreen |
| 12:31 |
|
dMiller_ joined #evergreen |
| 12:31 |
|
sarabee joined #evergreen |
| 12:31 |
|
eeevil joined #evergreen |
| 12:31 |
|
wjr joined #evergreen |
| 12:31 |
|
TaraC_ joined #evergreen |
| 12:31 |
|
maryj joined #evergreen |
| 12:31 |
|
akilsdonk joined #evergreen |
| 12:31 |
|
ericar joined #evergreen |
| 12:31 |
|
rjackson_isl joined #evergreen |
| 12:31 |
|
jboyer-isl joined #evergreen |
| 12:31 |
|
graced joined #evergreen |
| 12:31 |
|
Callender joined #evergreen |
| 12:31 |
|
remingtron joined #evergreen |
| 12:31 |
|
pmurray joined #evergreen |
| 12:31 |
|
kmlussier joined #evergreen |
| 12:31 |
|
mceraso joined #evergreen |
| 12:31 |
|
bshum joined #evergreen |
| 12:31 |
|
pastebot joined #evergreen |
| 12:31 |
|
mtate joined #evergreen |
| 12:31 |
|
RBecker_ joined #evergreen |
| 12:31 |
|
dbs_ joined #evergreen |
| 12:31 |
|
rangi joined #evergreen |
| 12:31 |
|
eby joined #evergreen |
| 12:31 |
|
artunit joined #evergreen |
| 12:31 |
|
TaraC joined #evergreen |
| 12:31 |
|
StomproJ joined #evergreen |
| 12:31 |
|
_bott_ joined #evergreen |
| 12:31 |
|
dbwells joined #evergreen |
| 12:31 |
|
jcamins joined #evergreen |
| 12:31 |
|
BigRig joined #evergreen |
| 12:31 |
|
book` joined #evergreen |
| 12:31 |
|
gsams joined #evergreen |
| 12:31 |
|
edoceo joined #evergreen |
| 12:31 |
|
berick joined #evergreen |
| 12:31 |
|
pinesol_green joined #evergreen |
| 12:31 |
|
ningalls joined #evergreen |
| 12:31 |
|
jeff__ joined #evergreen |
| 12:31 |
|
hopkinsju joined #evergreen |
| 12:31 |
|
bradl joined #evergreen |
| 12:31 |
|
jeffdavis joined #evergreen |
| 12:31 |
|
Bmagic joined #evergreen |
| 12:31 |
|
phasefx joined #evergreen |
| 12:31 |
|
egbuilder joined #evergreen |
| 12:31 |
|
mtj_ joined #evergreen |
| 12:31 |
|
csharp joined #evergreen |
| 12:31 |
|
ldw joined #evergreen |
| 12:31 |
|
gmcharlt joined #evergreen |
| 12:31 |
|
jeff joined #evergreen |
| 12:31 |
|
goood joined #evergreen |
| 12:31 |
|
jcamins1 joined #evergreen |
| 12:31 |
|
paxed joined #evergreen |
| 13:23 |
|
akilsdonk joined #evergreen |
| 13:44 |
kmlussier |
@weather 02771 |
| 13:44 |
pinesol_green |
kmlussier: The current temperature in APRSWXNET Rumford RI US, Seekonk, Massachusetts is 16.0°F (1:18 PM EST on February 16, 2015). Conditions: Scattered Clouds. Humidity: 31%. Dew Point: -9.4°F. Windchill: 3.2°F. Pressure: 29.99 in 1016 hPa (Falling). |
| 13:45 |
kmlussier |
Nice! I thought it was colder than that. |
| 13:57 |
|
jonadab joined #evergreen |
| 14:08 |
|
eady joined #evergreen |
| 14:37 |
jeff |
in other words: EW0791>APRS,TCPXX*,qAX,CWOP-2:@161818z4150.90N/07120.92W_280/012g019t016r000p000P000h31b10152L568.DsVP |
| 14:40 |
jeff |
(the APRS data packet behind that weather observation) |
| 14:41 |
jeff |
when $BIGEVENT happens and we must resort to running circulation transactions over packet radio, we will regret having removed checksums from SIP! ;-) |
| 14:42 |
jeff |
( and i am not sure words can express the degree to which i am kidding here -- sip_checksums-- ) |
| 14:45 |
jonadab |
If you have to restort to running circ over packet radio, just use a transport-layer protocol with checksums built in, then the app-layer protocol doesn't need them. |
| 14:45 |
jonadab |
Also works for avian carriers. |
| 14:47 |
jeff |
...and TCP, thankfully. :-) |
| 14:53 |
jeff |
i think that in theory APRS packets sent over AX.25 would have at least error detection. |
| 16:26 |
jonadab |
Hmm... first time building OpenILS code pulled using git, what do I use for the STAFF_CLIENT_STAMP_ID in that case? |
| 16:28 |
jonadab |
STAFF_CLIENT_STAMP_ID=master ? Hmm... probably not that. |
| 16:29 |
phasefx |
jonadab: use rel_2_7_3 and you can use a stock 2.7.3 staff client with it.. though I would just not set it at all, and symlink rel_2_7_3 to whatever directory it creates in /openils/var/web/xul/ |
| 16:29 |
jeff |
i think i've used rel_jeffdev or similar. there may have been at one time a magic value recognized, but that may be no longer a thing. |
| 16:30 |
phasefx |
actually, I'm thinking of STAFF_CLIENT_VERSION.. I've forgotten the nuances with the other options |
| 16:32 |
jonadab |
I see. Thanks. |
| 16:36 |
bshum |
Pretty much, it can be whatever you want it to be as long as you build a matching client though. |
| 16:36 |
jonadab |
Ok, that makes sense. |
| 16:36 |
* bshum |
tends to favor master_yyyymmdd when building his master VMs. |
| 16:36 |
jonadab |
And _for the moment_ I'm just gonna run the thing on Debian, so building the client is easy. |
| 16:37 |
bshum |
You could just do it without a variable too and I think that it will use the git hash |
| 16:37 |
jonadab |
Oh, neat. |
| 16:37 |
jonadab |
That'd be good for dev. |
| 16:38 |
bshum |
Or maybe that's just the VERSION that gets it. |
| 16:38 |
bshum |
Never really tried like that.l |
| 16:38 |
jonadab |
For actual deployment, I'd want a stock version, because I don't fancy trying to build a Windows client. |
| 16:39 |
jonadab |
But actual deployment would be Down The Road, after I figure out how to migrate our data in. |
| 16:39 |
bshum |
jonadab: Building a client is pretty easy actually. |
| 16:39 |
bshum |
And in practice you probably would rather have your own client rather than rely purely on community built ones. |
| 16:40 |
jonadab |
Oh? |
| 16:40 |
bshum |
Or at least that's my preferred approach. |
| 16:40 |
bshum |
We use the automatic updates process to roll out new client versions to our users. |
| 16:40 |
jeff |
bshum: is that preference partially because you guys tend not to run a packaged release, but to incrementally update / track master? |
| 16:41 |
bshum |
Automatic update doesn't work with community clients. |
| 16:41 |
bshum |
Since they're not built in chain and there's no reference server |
| 16:41 |
jonadab |
We'd be a rather small deployment, so setting up an automatic update server is unlikely. |
| 16:41 |
jeff |
part of me is happy to be sidestepping the whole "can we use the mozilla maintenance service to allow non-administrator automatic updates of xulrunner without opening up filesystem permissions" question |
| 16:42 |
jeff |
(by moving away from xulrunner) |
| 16:42 |
bshum |
jonadab: Well it's a built-in option. Not super well documented, but it works. |
| 16:42 |
bshum |
When your time comes, maybe we'll have written that chapter better in the docs. |
| 16:42 |
bshum |
jeff: Indeed. |
| 16:43 |
bshum |
jeff: Being on nontraditional "release" does mean having auto update flexibility with our own stamping ensures matching things in our environment. |
| 16:43 |
jonadab |
Maybe. At the rate we've been moving... (I've been looking at this off and on for several years already.) |
| 16:44 |
jonadab |
Although the director seems somewhat more serious about it now. |
| 16:44 |
bshum |
But I think what you said about non-admin updating is a good thing that I've forgotten after years of smooth auto-updates. |
| 16:44 |
jonadab |
I mean, she now thinks this is primarily her idea, so *that's* good. |
| 16:44 |
bshum |
Ha :) |
| 16:45 |
jonadab |
We also may end up in a consortium, but we still have to be able to migrate our data. |
| 16:46 |
jonadab |
And I may as well run a local training server for the staff to play with in any case. |
| 16:47 |
jonadab |
I am *NOT* going through another migration where we rely totally on the vendor for all staff training. That was horrific. |
| 16:47 |
eeevil |
jonadab: re debian, I personally recommend sticking with that. it tends to be less of a moving target than ubuntu, and redhat is, um, under-supported ... and I tend to agree that going with a release is a GoodThing -- you get one-shot upgrade scripts and staff clients (sans auto-update) for "free" |
| 16:47 |
jonadab |
eeevil: I've been using Debian since 1998, no worries there. |
| 16:47 |
jonadab |
Well, off and on since 1998. More or less exclusively since sarge came out. |
| 16:48 |
bshum |
jeff: Also, we modify our offline mode slightly, and pre-built staff clients from the community aren't easily tweaked for us in that sense. |
| 16:49 |
bshum |
jeff: Like tab limits (because infinity is just insanity) and changing the registration form to use "CT" instead of "GA" as the default state :) |
| 16:49 |
jonadab |
Heh. |
| 16:50 |
jonadab |
I would've imagined things like defaults would be configurable without building, but what do I know? |
| 16:50 |
jonadab |
(Although, _normally_ maybe the config would come from the database, which wouldn't be accessible in offline mode...) |
| 16:51 |
eeevil |
bingo :) |
| 16:51 |
eeevil |
although, that could be made to work. we grab other stuff from the server on each connect to make offline better |
| 16:52 |
eeevil |
blocked patron lists, the server's version of the current time (for offsetting client-side time for global transaction ordering), etc |
| 16:52 |
jeff |
yeah, it took me a moment to realize that bshum was talking about the default state in the offline registration interface -- the online interface it's just a setting from the server. |
| 16:53 |
* bshum |
thought he said offline |
| 16:53 |
bshum |
But anywho :) |
| 16:53 |
jonadab |
Oh, believe it or not, our current ILS considers the server time to be non-authoritative (though it does record it), client time to be authoritative for transaction-ordering purposes. |
| 16:53 |
jeff |
but as eeevil says, as long as your client has connected once, it's quite possible to make use of cached data like that. |
| 16:54 |
* jeff |
mumbles something about SIP clients in the vendor's timezone vs the local timezone |
| 17:00 |
|
yboston joined #evergreen |
| 17:02 |
yboston |
quick question, I have some code that is ready for sign off on w orking branch and I have an LP bug for it. Is the next step to add a “pullrequest” tag to the LP bug? |
| 17:04 |
gmcharlt |
yboston: yes |
| 17:04 |
yboston |
gmcharlt: thanks |
| 17:05 |
bshum |
yboston: Generally speaking, yes. |
| 17:05 |
bshum |
LP bugs with "pullrequest" as a tag usually signify to testers/committers that it's time to look at it and get it signed and pushed. |
| 17:05 |
yboston |
bshum: thanks |
| 17:06 |
yboston |
I just realized that I need to add some line breaks to the commit message; will redo the commit tonight |
| 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:27 |
|
graced joined #evergreen |
| 17:33 |
|
eady joined #evergreen |
| 18:03 |
pinesol_green |
[opensrf|Bill Erickson] LP#1418613 per-tab websocket send() JS thinko repair - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=2cf9344> |
| 19:35 |
|
akilsdonk joined #evergreen |
| 19:36 |
|
graced joined #evergreen |
| 20:31 |
|
wlayton joined #evergreen |
| 21:05 |
|
akilsdonk joined #evergreen |
| 23:00 |
|
akilsdonk joined #evergreen |
