| 02:21 |
|
dbwells joined #evergreen |
| 02:58 |
|
dreuther joined #evergreen |
| 02:58 |
|
chatley joined #evergreen |
| 05:08 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:43 |
|
phasefx joined #evergreen |
| 07:19 |
csharp |
@later tell Bmagic yeah, I've consistently seen that problem with the permissions group UI. The problem with "just use the database" is that it puts a burden on system staff with server-level access to do things that should be available to non-technical users. |
| 07:19 |
pinesol_green |
csharp: The operation succeeded. |
| 09:16 |
bshum |
Before I cut 2.7.1 today, hoping finish looking over https://bugs.launchpad.net/evergreen/+bug/1366964 |
| 09:16 |
pinesol_green |
Launchpad bug 1366964 in Evergreen "Transaction Issues with libdbi 0.9.0" (affected: 1, heat: 6) [Undecided,Confirmed] |
| 09:17 |
bshum |
And also, have to finish setting up my build environment to get the web client stuff properly into the tarball |
| 09:18 |
csharp |
bshum: what would be the most effective way to test the fix to the libdbi bug? |
| 09:19 |
csharp |
Dyrcona: weren't you only experiencing the issue under conditions of higher load? |
| 09:19 |
* csharp |
re-reads |
| 09:19 |
bshum |
csharp: I was going to try following what happened in the bug report as far as copy creation goes. And also figure out the perl test that was included. |
| 09:20 |
csharp |
ah - there's a test |
| 09:20 |
Dyrcona |
csharp: No, it had nothing to do with load. pcrud transactions simply failed. |
| 09:20 |
bshum |
berick++ |
| 09:20 |
csharp |
Dyrcona: okay - my quick read several months ago clearly led to inaccurate impressions of the issue :-) |
| 09:20 |
bshum |
csharp: If you have time to spare a look, extra eyes never hurt. |
| 09:20 |
Dyrcona |
The fix is very simple and seems to work, but a mass delete script I tested on precise after applying the change gave me several "unknown errors." |
| 09:21 |
csharp |
well, since we're an ubuntu shop, and this is a obvious impediment, I only think it fair that we participate ;-) |
| 09:36 |
|
RoganH joined #evergreen |
| 09:41 |
|
kmlussier joined #evergreen |
| 09:54 |
|
sarabee joined #evergreen |
| 09:58 |
* csharp |
tests the fix for bug 1366964 without issues |
| 09:58 |
pinesol_green |
Launchpad bug 1366964 in Evergreen "Transaction Issues with libdbi 0.9.0" (affected: 1, heat: 6) [Undecided,Confirmed] https://launchpad.net/bugs/1366964 |
| 09:58 |
berick |
to be clear, the fix to 1366964 doesn't prevent "unknown errors" (from the DB), it just allows cstore to recognize them as transient instead of "OMG DB IS DOWN" |
| 09:58 |
csharp |
live test works fine |
| 10:01 |
Dyrcona |
berick: I suspected as much. I'll sign off on it. |
| 10:02 |
berick |
Dyrcona++ |
| 10:02 |
berick |
csharp++ # testing |
| 10:02 |
Dyrcona |
If csharp wants to sign off, too, that's cool. I can wait and sign his branch then push that. |
| 10:03 |
Dyrcona |
It's today we want to release the dot releases for 2.5, 2.6, and 2.7, right? |
| 10:05 |
bshum |
Dyrcona: That's certainly my goal for 2.7. |
| 10:06 |
bshum |
Dyrcona: Sounds right to me. |
| 10:07 |
Dyrcona |
Will do. |
| 10:07 |
|
RoganH joined #evergreen |
| 10:11 |
pinesol_green |
[evergreen|Bill Erickson] LP#1366964 Update libdbi connection test error parsing - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ca4e28a> |
| 10:12 |
Dyrcona |
Done and done. |
| 10:12 |
berick |
woot |
| 10:13 |
Bmagic |
csharp: thanks for the feedback. Glad it's not just my system |
| 11:16 |
|
kmlussier joined #evergreen |
| 11:23 |
kmlussier |
jboyer-isl: Is bug 1210541 ready for a pullrequest tag? |
| 11:23 |
pinesol_green |
Launchpad bug 1210541 in Evergreen "Copy locations table should have a 'deleted' flag" (affected: 9, heat: 52) [Wishlist,Confirmed] https://launchpad.net/bugs/1210541 - Assigned to Jason Boyer (jboyer) |
| 11:24 |
jboyer-isl |
I think so. I've tested it a bit but I haven't heard of anyone else trying it out. |
| 11:26 |
jboyer-isl |
kmlussier, It worked well enough for me the day of the hackaway, for what that's worth. |
| 11:26 |
kmlussier |
jboyer-isl: OK, I'll add one then. I think we have somebody here is interested in trying it out. |
| 11:27 |
jboyer-isl |
Good to hear. Hopefully there's nothing to find. :) |
| 11:36 |
|
dreuther joined #evergreen |
| 15:57 |
bshum |
Maybe it'll be helpful in my future |
| 15:58 |
berick |
yeah, the git stuff was necessary on wheezy |
| 15:58 |
bshum |
I'm still deciding if I want to upgrade my laptop to utopic unicorn... |
| 15:59 |
berick |
well, hmm, trusty install 0.10.25. earliest i tested was 0.10.28 -- |
| 16:00 |
berick |
not entirely sure what I just said is true, but likely true |
| 16:00 |
bshum |
Heh |
| 16:00 |
berick |
i'll give it a shot |
| 16:01 |
bshum |
I didn't get to finish up the written instructions for the README in Evergreen for webclient building. |
| 16:34 |
gmcharlt |
eeevil++ |
| 16:38 |
|
nhilton_ joined #evergreen |
| 16:42 |
|
nhilton joined #evergreen |
| 16:51 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 16:51 |
|
mrpeters left #evergreen |
| 16:52 |
|
kmlussier left #evergreen |
| 16:54 |
phasefx |
that last failure includes one not related to DST: open-ils.cstore 2014-11-05 16:27:37 [ERR :21897:oils_sql.c:2483:] open-ils.cstore ERROR inserting config::copy_status object using query [INSERT INTO config.copy_status (holdable,id,name,opac_visible,copy_active,restrict_copy_delete) VALUES (DEFAULT,1,DEFAULT,DEFAULT,DEFAULT,DEFAULT);]: 0 ERROR: null value in column "name" violates not-null constraint |
| 16:55 |
bshum |
Hmm |
| 16:56 |
bshum |
That's the new test |
| 16:56 |
bshum |
For the libdbi thing? |
| 16:56 |
|
dMiller_ joined #evergreen |
| 16:57 |
bshum |
Yep |
| 16:57 |
phasefx |
the test itself didn't throw an error |
| 16:58 |
bshum |
Hmm |
| 16:58 |
phasefx |
live_t/08-lp1366964-libdbi-error.t ..... ok |
| 16:59 |
berick |
that's supposed to happen |
| 16:59 |
berick |
the point of the test is to see how it recovers from a DB error |
| 16:59 |
dbwells |
That's great :) |
| 17:00 |
phasefx |
k, then when we can tell the webifier thing to expect an error |
| 17:00 |
* phasefx |
will poke |
| 17:01 |
berick |
phasefx++ |
| 17:01 |
berick |
didn't realize it would bark at that |
| 17:03 |
berick |
bshum: btw, initial test of nodejs package on trust looks good. will document when i get some time |
| 17:03 |
bshum |
berick++ # cool! |
| 17:08 |
|
mmorgan left #evergreen |
| 17:08 |
phasefx |
for reference, http://git.evergreen-ils.org/?p=working/random.git;a=commitdiff;h=2983559ea27c6506f750a757e64d9bb4d5b43548 Haven't tested it yet |
| 17:09 |
phasefx |
so that makes two exeptions that are DBI related :) |
| 17:09 |
phasefx |
exceptions, even |
| 17:10 |
bshum |
phasefx++ # nifty |
| 17:39 |
|
nhilton joined #evergreen |
| 17:54 |
|
nhilton_ joined #evergreen |
| 08:49 |
|
tsbere joined #evergreen |
| 08:50 |
kmlussier |
mrpeters: DIG will take submissions in any format. We prefer AsciiDoc, but we have people who can convert content into AsciiDoc if it's submitted in another format. |
| 08:52 |
mrpeters |
i can whip something up much quicker today without learning the formatting, though i probably should just do that |
| 09:07 |
bshum |
eeevil: Hmm, should we push these changes to master/rel_2_7 as bug fixes? http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/miker/web-client-sprint1-bug-fixing |
| 09:08 |
bshum |
They're not attached to any particular LP, but I assume they should be tested and included. |
| 09:12 |
|
tspindler joined #evergreen |
| 09:25 |
|
Dyrcona joined #evergreen |
| 09:33 |
|
StomproJ joined #evergreen |
| 11:02 |
kmlussier |
rfrasur++ |
| 11:02 |
rfrasur |
Oy, we'll see. Y'all know my lack of technical know how. But...something is better than nothing, right? |
| 11:04 |
yboston |
dwells: got a second? |
| 11:05 |
kmlussier |
rfrasur: Our new Get Involved page may help - http://evergreen-ils.org/involvement/ |
| 11:06 |
kmlussier |
I'm going to update that page soonish to include testing too. |
| 11:06 |
|
sandbergja joined #evergreen |
| 11:06 |
rfrasur |
Perfect. |
| 11:20 |
|
mrpeters joined #evergreen |
| 13:21 |
berick |
bshum: I'll trade you bug #1366964 for bug #1369169 |
| 13:21 |
pinesol_green |
Launchpad bug 1366964 in Evergreen "Transaction Issues with libdbi 0.9.0" (affected: 1, heat: 6) [Undecided,Confirmed] https://launchpad.net/bugs/1366964 |
| 13:21 |
pinesol_green |
Launchpad bug 1369169 in OpenSRF "Add install instructions for websockets to README (and other cleanup)" (affected: 1, heat: 6) [Medium,Triaged] https://launchpad.net/bugs/1369169 |
| 13:24 |
Dyrcona |
berick: I can test 1366964. I was waiting until some other testing was done on a vm running precise, but the person I was working with is on vacation this week, I think. |
| 13:25 |
berick |
Dyrcona: sweet.. well, except the part where you were trying to do something else and can't ;) |
| 13:25 |
Dyrcona |
:) |
| 13:26 |
|
dkyle joined #evergreen |
| 15:27 |
hbrennan |
csharp: Are those dates pretty well locked in? It's a graduation weekend, so I need all the time I can get to make it work |
| 15:30 |
csharp |
hbrennan: I don't have enough information to answer that, but from Buzzy's report to the EOB, it sounds firm |
| 15:31 |
hbrennan |
csharp: Thanks |
| 16:10 |
jeff |
perl packages that include Simple in the name yet depend on: |
| 16:10 |
jeff |
==> Found dependencies: Capture::Tiny, Sub::Exporter, MooX::Types::MooseLike::Base, Email::Abstract, Email::Simple, List::MoreUtils, Try::Tiny, Test::More, MooX::Types::MooseLike, Moo::Role, Throwable::Error, Module::Runtime, Moo, Sub::Exporter::Util, Email::Address |
| 16:12 |
|
wsmoak joined #evergreen |
| 16:12 |
|
wsmoak joined #evergreen |
| 16:15 |
jeff |
> 34 distributions installed |
| 16:21 |
wsmoak |
well csharp this is no fun at all. I talked to my local librarians and they say that all their issues with PINES are fixed promptly and they don’t really need anything. :) |
| 16:21 |
kmlussier |
:D |
| 16:22 |
kmlussier |
@praise PINES |
| 16:42 |
frank__ |
yes, the problem is that we planned to upgrade to 2.6.3 until december, Is there something I could do to solve this problem without upgrade? |
| 16:43 |
Dyrcona |
frank__: Upgrading is the best bet, but you could apply the code from the above bug. |
| 16:48 |
frank__ |
ok Dyrcona, thanks |
| 17:00 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:11 |
|
mmorgan left #evergreen |
| 18:19 |
|
kmlussier joined #evergreen |
| 18:25 |
|
nhilton joined #evergreen |
| 09:10 |
* pinesol_green |
grabs some Apple Crisp for csharp |
| 09:12 |
wsmoak |
good morning |
| 09:12 |
wsmoak |
remind me… what version is Pines on? (Is there a way I can tell?) https://gapines.org/eg/opac/home |
| 09:12 |
csharp |
wsmoak: we're on 2.5.1 |
| 09:12 |
csharp |
well, with backports, so 2.5.1+ |
| 09:13 |
csharp |
wsmoak: we have a test server running 2.7.0 at http://next.gapines.org if you're interested in that too |
| 09:13 |
wsmoak |
well, I guess that will shortcut me going to talk to the librarian to figure out where the IT folks are :) |
| 09:14 |
bshum |
csharp++ |
| 09:14 |
csharp |
wsmoak: are you at a PINES library? |
| 10:49 |
jboyer-isl |
jeff, Thanks, I must not have been searching for the right thing because I didn't find either of those. |
| 10:54 |
|
kmlussier joined #evergreen |
| 11:12 |
|
dcook__ joined #evergreen |
| 11:15 |
yboston |
Hello everyone, I could use some advice about upgrading Postgres 9.1 to 9.2 on a test server. |
| 11:15 |
yboston |
I want to set up this test server with production data, but my hosted productions server is running PG 9.2 |
| 11:15 |
yboston |
I have used apt-get to install postgres-9.2 on a EG 2.6.2 server, and I just ran pg_upgradecluster and got the following errors that makes me think I might have missed some steps |
| 11:15 |
pastebot |
"yboston" at 64.57.241.14 pasted "errors running pg_upgrade_cluster" (465 lines) at http://paste.evergreen-ils.org/10 |
| 11:16 |
yboston |
I ran: pg_dropcluster --stop 9.2 main then pg_upgradecluster 9.1 main |
| 11:16 |
yboston |
^^ here are the errors |
| 11:21 |
yboston |
Dyrcona: thanks again |
| 11:24 |
yboston |
I wonder if it would be easier in the future to tweak the EG intall makefiles so that when I install EG I end up with PG 9.2 instead of 9.1? |
| 11:25 |
|
sandbergja joined #evergreen |
| 11:25 |
bshum |
yboston: I've done that before for some of my test servers where the default was 9.1 but I wanted 9.3. |
| 11:25 |
bshum |
Lots of paths to completion :) |
| 11:26 |
dbwells |
jboyer-isl: We had a computer science project team work on building a mapping system prototype for us last Dec. It never made it to production in any form. Still, I think I am going to try to find that code, and will post it if it is available somewhere. |
| 11:26 |
Dyrcona |
yboston: If I've wanted something other than the default Pg version for my distro, I've usually installed the appropriate PG packages first, and then I install Evergreen. |
| 11:27 |
jboyer-isl |
dbwells: thanks, that would be cool. |
| 12:33 |
* phasefx |
deletes his unfillable hold now |
| 12:33 |
bshum |
kmlussier: I wonder if that's a matter of adding ffilter="true" to the parts field in hold_pull_list.tt2 |
| 12:34 |
bshum |
If so, then fwiw, Copy Status is also not a field you can filter on? |
| 12:34 |
kmlussier |
Really? I didn't notice that one. |
| 12:34 |
kmlussier |
I was thinking it was probably a simple thing to fix, but I hadn't gotten around to looking at it. |
| 12:36 |
kmlussier |
bshum: copy status gives the appearance of being sortable. But the system I'm on shows all available items, so I can't test it out to make sure it works. |
| 12:36 |
bshum |
kmlussier: Hmm, fsort=false |
| 12:36 |
bshum |
Is next to the parts one |
| 12:37 |
* bshum |
sighs |
| 12:49 |
bshum |
Yep, changing that to fsort="true" adds a selector for parts sorting |
| 12:49 |
bshum |
Since that's always been false, since the initial add of the simplified pull list, I'd be curious if there was a design reason for that, but I doubt it. |
| 12:50 |
bshum |
Open-ILS/src/templates/circ/hold_pull_list.tt2 |
| 12:51 |
kmlussier |
IIRC, parts weren't displaying at all during my early tests of the simplified pull lists. I'm guessing it the sorting was overlooked when it was added to the display. |
| 12:52 |
kmlussier |
And then it was overlooked when I tested it. :( |
| 13:44 |
|
_bott_ joined #evergreen |
| 13:57 |
csharp |
@karma vandelay |
| 13:57 |
pinesol_green |
csharp: Karma for "vandelay" has been increased 1 time and decreased 0 times for a total karma of 1. |
| 14:31 |
|
vlewis_ joined #evergreen |
| 14:32 |
|
chatley joined #evergreen |
| 14:32 |
mmorgan |
hbrennan: As long as no one runs the "Clear holdshelf" process, the item will stay on the holdshelf. |
| 14:33 |
hbrennan |
mmorgan: That process isn't just pulling up the list from Circ> Clear Hold Shelf, right? It's the actual check in of the item to either clear it back to Available or jump to the next person in line? |
| 14:34 |
hbrennan |
It's times like this that I really need a time machine so I can fast forward and test things like this |
| 14:34 |
|
buzzy joined #evergreen |
| 14:35 |
csharp |
hbrennan: correct, as far as I remember |
| 14:36 |
berick |
hbrennan: just to clarify, clear shelf cancels the hold then generates a report of likely next actions for the item (hold, transit, back to shelf). it doesn't actualy perform the checkin. |
| 14:36 |
hbrennan |
csharp: I'm glad I'm not the only one with a fuzzy recollection on how this works |
| 14:36 |
csharp |
check in of the item will change its status |
| 14:37 |
csharp |
hbrennan: oh, and we don't have a time machine, but our test server is the best we can get: http://next.gapines.org |
| 14:37 |
csharp |
;-) |
| 14:37 |
hbrennan |
Excellent. The reason I ask is that our hold notices for email and text clogged up, and haven't gone out since Monday. Everyone received their notice this morning, but the time has been ticking since Monday. |
| 14:38 |
hbrennan |
I'm glad we have a little control over the process. :) |
| 14:39 |
hbrennan |
berick: So if we don't pull items from the clear list, those items are essentially in limbo... neither still officially on hold for the original person, but not starting the clock for the next in line either? |
| 16:31 |
mmorgan |
berick: hbrennan: not to labor the point about clearing the holdshelf (ok, I will :)) after the hold is cancelled, the item does indeed show in browse holds shelf, but you can't tell where it is just by looking at the *item* |
| 16:37 |
berick |
mmorgan: well, dang. i guess you can't |
| 16:42 |
mmorgan |
Yeah :-(, lp 1271182 |
| 16:42 |
pinesol_green |
Launchpad bug 1271182 in Evergreen "Item status set as "incorrectly set to on holds shelf"" (affected: 2, heat: 10) [Undecided,Confirmed] https://launchpad.net/bugs/1271182 |
| 16:58 |
|
mdriscoll left #evergreen |
| 17:03 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:10 |
|
mmorgan left #evergreen |
| 17:12 |
|
buzzy joined #evergreen |
| 18:06 |
|
buzzy joined #evergreen |
| 02:42 |
|
StomproJ joined #evergreen |
| 04:51 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:42 |
|
mceraso joined #evergreen |
| 06:47 |
|
bshum joined #evergreen |
| 07:08 |
|
phasefx joined #evergreen |
| 14:46 |
berick |
related, I just got around to porting the wheezy installer to trusty at random/collab/berick/trusty-auto-installer |
| 14:46 |
berick |
bonus points for being called "trusty auto installer" ;) |
| 14:47 |
bshum |
berick++ # that's awesome sounding :D |
| 14:50 |
phasefx |
berick++ Do we want to separate out the qa stuff from the wheezy installer, or bundle all installers + qa together? It looks like the trusty one would still work with the qa tests with the way it's producing output |
| 14:51 |
* berick |
wonders if anyone has had a chance to look at bug #1366964 |
| 14:51 |
pinesol_green |
Launchpad bug 1366964 in Evergreen "Transaction Issues with libdbi 0.9.0" (affected: 1, heat: 6) [Undecided,Confirmed] https://launchpad.net/bugs/1366964 |
| 14:51 |
berick |
phasefx: i like having the QA stuff in there |
| 14:51 |
berick |
though, admittedly, I don't often use it all. |
| 14:52 |
bshum |
berick: I was just looking at the code, but I'm not in a position to test till next week sometime. |
| 14:53 |
* berick |
nods |
| 14:53 |
|
dcook__ joined #evergreen |
| 14:54 |
bshum |
Eager to try it out though, of course :) |
| 14:54 |
phasefx |
berick: I think we should option out the timezone stuff.. it's important for the qa tests, maybe, but not for someone in some arbitrary timezone |
| 14:55 |
phasefx |
s/arbitrary/different/ |
| 14:55 |
berick |
phasefx: ah, hadn't thought about that |
| 14:55 |
* berick |
forgets what all is in the tests |
| 14:55 |
phasefx |
something prompted us to set the timezone for the qa vm, I think |
| 14:56 |
bshum |
Ugh, speaking of timezones.... good night folks. See you all again in a week. |
| 14:57 |
berick |
sleep well, bshum |
| 15:36 |
hbrennan |
Thanks, gmcharlt |
| 15:36 |
* csharp |
saw a huge crowd of people at the Apple Store at Lenox Mall standing around for hours *just in case* a shipment of new iPhones arrived |
| 15:37 |
hbrennan |
I'm glad that's not even a choice for me |
| 15:37 |
csharp |
hbrennan: fwiw, we're running our test 2.7.0 cluster on OpenSRF 2.4 alpha, and we haven't seen problems |
| 15:38 |
* csharp |
pets his trusty Galaxy Note 2 |
| 15:38 |
bshum |
hbrennan: fwiw, we run 2.7.0ish in production with OpenSRF 2.4 alpha and haven't seen any explosions either. |
| 15:38 |
hbrennan |
That's good to know, thanks csharp |
| 15:38 |
* bshum |
tries to sleep again |
| 20:43 |
|
kmlussier joined #evergreen |
| 20:45 |
kmlussier |
@later tell csharp I think we may be having trouble with the oversight board list. There are recent 3 messages in the archive that don't appear to have been sent out. |
| 20:45 |
pinesol_green |
kmlussier: The operation succeeded. |
| 22:13 |
* jeff |
shakes his fist a marc_stream_importer.pl |
| 22:13 |
jeff |
quote the script, "Failed to import 1 records" |
| 22:19 |
jeff |
quoth, even. |
| 22:20 |
jeff |
(not to be confused with Kvothe) |
| 22:29 |
jeff |
ah. |
| 22:29 |
jeff |
1) marc_stream_importer.pl requires a full path for the spool file if running in --no-daemon mode |
| 22:30 |
jeff |
2) marc_stream_importer.pl deleted the spool file |
| 22:30 |
jeff |
3) the permissions in this particular test database are... in an interesting state. |
| 22:42 |
* jeff |
runs smack dab into bug 1170514 |
| 22:42 |
pinesol_green |
Launchpad bug 1170514 in Evergreen "vandelay.auto_overlay_bib_record discrepancy" (affected: 1, heat: 8) [Undecided,Confirmed] https://launchpad.net/bugs/1170514 |
| 23:14 |
|
dcook joined #evergreen |
| 15:55 |
pinesol_green |
Dyrcona: What are you asking me for? |
| 15:56 |
kmlussier |
eightball appears to be a little snippy today. |
| 15:56 |
kmlussier |
eightball appears to be a little snippy today. |
| 15:59 |
rangi |
Dyrcona: my plan is to get all the unit tests up to scratch, then merge your stuff and fix until the tests pass again, moving my branch to old_stuff and the new merged branch becoming master |
| 15:59 |
rangi |
Dyrcona: my plan is to get all the unit tests up to scratch, then merge your stuff and fix until the tests pass again, moving my branch to old_stuff and the new merged branch becoming master |
| 15:59 |
Dyrcona |
rangi: Cool, bro. ;) |
| 15:59 |
Dyrcona |
rangi: Cool, bro. ;) |
| 16:00 |
Dyrcona |
I'm still working with Auto-graphics. Found some template issues last night. I botched the messages a bit. |
| 16:00 |
Dyrcona |
I'm still working with Auto-graphics. Found some template issues last night. I botched the messages a bit. |
| 16:00 |
Dyrcona |
Also, it seems that when validating with the schema, the order of some of the elements matters. |
| 16:00 |
Dyrcona |
Also, it seems that when validating with the schema, the order of some of the elements matters. |
| 16:03 |
rangi |
yeah i had to work with auto graphics too .. you'd think they would know their product better, but no ... werent able to get sample messages, couldnt set up a test instance etc ... everything just takes a zillion times longer, didnt help that they first were sending ncip 1.0 messages then changed to 2.0 mid dev stream |
| 16:03 |
rangi |
yeah i had to work with auto graphics too .. you'd think they would know their product better, but no ... werent able to get sample messages, couldnt set up a test instance etc ... everything just takes a zillion times longer, didnt help that they first were sending ncip 1.0 messages then changed to 2.0 mid dev stream |
| 16:17 |
Dyrcona |
Oh, I was going to do this earlier, but got distracted by work: xmllint++ xmlstarlet++ |
| 16:17 |
Dyrcona |
Oh, I was going to do this earlier, but got distracted by work: xmllint++ xmlstarlet++ |
| 16:32 |
kmlussier |
I've always wondered - is there a reason the bib record in the catalog shows both a "Next 10" link and a "show more copies" link? Shouldn't it be one or the other? |
| 17:10 |
pinesol_green |
Hmm... kmlussier... Let me see now... RAVENCLAW! |
| 17:11 |
kmlussier |
Heh...my daughter is amused by that. |
| 17:11 |
kmlussier |
Heh...my daughter is amused by that. |
| 17:17 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:17 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:20 |
|
mmorgan left #evergreen |
| 17:20 |
|
mmorgan left #evergreen |
| 17:24 |
pinesol_green |
[evergreen|Galen Charlton] LP#1384868: limit fund drop-downs on the invoice page to only active funds - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4e29499> |
| 17:24 |
pinesol_green |
[evergreen|Galen Charlton] LP#1384868: limit fund drop-downs on the invoice page to only active funds - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4e29499> |
| 17:44 |
|
mrpeters left #evergreen |
| 17:44 |
|
mrpeters left #evergreen |
| 18:44 |
|
dbwells joined #evergreen |
| 00:58 |
|
akilsdonk joined #evergreen |
| 01:35 |
|
aliceR joined #evergreen |
| 05:05 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:42 |
|
eeevil joined #evergreen |
| 06:42 |
|
mtate joined #evergreen |
| 06:43 |
|
phasefx joined #evergreen |
| 15:11 |
kmlussier |
csharp++ |
| 15:13 |
csharp |
cool |
| 15:14 |
tsbere |
kmlussier: Actually, if you are on any aliases, you are probably benefitting from me fixing the access list. Given that you are on the same server as me and the messages are coming from the same place ;) |
| 15:15 |
kmlussier |
tsbere: No, I also tested with my gmail address just to rule out MVLC being the issue. :) |
| 15:30 |
|
buzzy joined #evergreen |
| 15:37 |
|
jwoodard joined #evergreen |
| 15:41 |
|
nhilton joined #evergreen |
| 17:50 |
|
whargrove joined #evergreen |
| 17:51 |
whargrove |
Hi all, is it possible to configure evergreen to require a terminal password for SIP commands? |
| 18:01 |
jeffdavis |
whargrove: What do you mean by a terminal password? Our SIP clients (self-check machines etc) do need to submit a username and password for authorization before they can do anything... |
| 18:05 |
whargrove |
jeffdavis: Right, I understand that and we have verified our SIP client works with evergreen |
| 18:05 |
whargrove |
jeffdavis: we are using Evergreen as a dev sandbox |
| 18:06 |
whargrove |
and another vendor wants us to send terminal password and we want to test it with evergreen |
| 18:06 |
whargrove |
not a requirement for SIP to work with evergreen, but I want to see if I can test the changes with our evergreen server |
| 18:12 |
|
rjackson-isl joined #evergreen |
| 18:13 |
|
sandbergja joined #evergreen |
| 18:30 |
|
whargrove joined #evergreen |
| 02:22 |
|
dbwells joined #evergreen |
| 03:27 |
|
StomproJ joined #evergreen |
| 05:05 |
|
Stompro joined #evergreen |
| 05:41 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:46 |
|
mtate joined #evergreen |
| 06:46 |
|
eeevil joined #evergreen |
| 06:47 |
|
Callender joined #evergreen |
| 12:29 |
|
nhilton joined #evergreen |
| 12:31 |
|
sandbergja joined #evergreen |
| 12:33 |
|
sandbergja joined #evergreen |
| 12:34 |
mmorgan |
jboyer-isl: we're on 2.6.2, in a highly unscientific test, I just edited barcodes on 20 patrons on our training system and didn't freeze up. Are you able to reproduce?mmmpooj |
| 12:34 |
mmorgan |
oops, sorry about that last... |
| 12:35 |
jboyer-isl |
mmorgan: I’ve started poking around at our migration server but I’m also on a Mac here, so there are multiple variables now. |
| 12:36 |
mmorgan |
never a shortage of variables :) |
| 12:38 |
mmorgan |
freeze ups have been an ongoing elusive problem, we've never looked at patron edit, but we'll keep it in mind to look at now. |
| 12:44 |
jboyer-isl |
Well, It may not be ram related. I edited maybe 7-8 accounts and the client is completely locked up, only 390MB in use on a 16GB machine. :-/ |
| 12:49 |
mmorgan |
Wow! Are you just editing barcodes? |
| 12:50 |
Dyrcona |
jboyer-isl: Did you say you were doing this on a Mac Book? |
| 12:51 |
jboyer-isl |
I did my personal test on an iMac, the actual issue is on Windows PCs at our new member. |
| 12:51 |
jboyer-isl |
mmorgan: I edited barcodes and added 1 day to their birthdays as if there were other edits to make. |
| 12:52 |
Dyrcona |
Well, I would not be surprised if XulRunner has more problems on a Mac than on other platforms. |
| 12:52 |
Dyrcona |
In my sporadic, and unscientific testing, it certainly appears to. |
| 12:53 |
jboyer-isl |
Dyrcona: I wouldn’t be surprised either, though I am surprised I got it to break. I can’t seem to ever run into problems when I’m trying to. |
| 12:54 |
Dyrcona |
Well, that often happens when you want something to go wrong it doesn't. That usually means your initial impression of the problem is wrong. |
| 12:55 |
Dyrcona |
But, for anyone following the bug email, I solved my Z39.50 problem. I made a typo in the config. |
| 00:44 |
|
nhilton joined #evergreen |
| 00:51 |
|
nhilton_ joined #evergreen |
| 02:47 |
|
terence joined #evergreen |
| 05:27 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:12 |
|
kmlussier joined #evergreen |
| 06:30 |
* bshum |
wishes everyone a happy Monday. |
| 06:35 |
bshum |
@later tell gmcharlt Guess we'll need a plan to upgrade Piwik someday for the webstats.http://piwik.org/blog/2014/10/announcing-piwik-will-end-php-5-3-support-six-months-may-2015/ |
| 09:10 |
bshum |
csharp: I didn't get to finish 2.7.1 before I left for my travels |
| 09:27 |
tsbere |
csharp: Sometimes git cherry-pick is better, wrapped in a "give me all the commit hashes from <base branch> to HEAD on the customized branch, then cherry-pick them into the new customization branch in order" - Lets you skip some of the "prep version and upgrade script" commits from release branches. |
| 09:27 |
tsbere |
(without having to find them in the interactive list) |
| 09:32 |
phasefx |
jeff: roger roger, thanks man re: dns and test |
| 09:47 |
csharp |
bshum: no prob ;-) |
| 09:47 |
csharp |
tsbere: thanks for the tip - I was able to quickly identify and comment out the undesired commits |
| 09:48 |
|
sarabee joined #evergreen |
| 14:05 |
jeff |
whargrove: that said, yes Evergreen + SIPServer support it. There have been... inconsistencies identified in the standard, and I cheered when I saw that SIP3 removes checksums. :-) |
| 14:06 |
|
StephenGWills joined #evergreen |
| 14:08 |
Dyrcona |
+1 what jeff says. Some 3M products don't do checksums correctly, and it is their protocol. |
| 14:09 |
whargrove |
Got it, thanks for the responses |
| 14:10 |
whargrove |
One ILS vendor we are integrating with requires checksumming ... but we wanted to test it with our evergreen sandbox first |
| 14:10 |
jeff |
Can you name the vendor so that I can personally mock them? :-) |
| 14:11 |
Dyrcona |
whargrove: You should ask them where the serial cables are, 'cause TCP has checksumming built in, so checksumming on top of that is redundant. |
| 14:13 |
whargrove |
jeff: Carl.X |
| 15:52 |
pinesol_green |
Dyrcona: The operation succeeded. |
| 15:53 |
Dyrcona |
Too many distractions. |
| 16:09 |
|
ldwhalen joined #evergreen |
| 16:41 |
phasefx |
qa tests passed this time, yay :) |
| 16:43 |
jeff |
phasefx: yay. did resolv.conf have one or both of those nameservers, or was it a different issue? |
| 16:44 |
phasefx |
jeff: right issue, different DNS servers |
| 16:45 |
jeff |
heh |
| 16:46 |
jeff |
did QTS recently notify customers with open resolvers or something? :-) |
| 16:46 |
phasefx |
no, it was all our fault; change internally and qa01 is a second class citizen :) |
| 16:47 |
jeff |
heh |
| 16:49 |
jeff |
shows how often I use non-lowercase identifiers in postgres... couldn't figure out why certain things weren't being found. |
| 16:50 |
jeff |
twas because the relation was named temp_Foo and unless I quoted it, it was being folded to temp_foo and not being found. |
| 16:50 |
jeff |
of course, the error doesn't fold the case, so: |
| 16:50 |
jeff |
jeff=> \d temp_Foo |
| 16:50 |
jeff |
Did not find any relation named "temp_Foo". |
| 16:51 |
jeff |
hrm. maybe part of this specific quirk is limited to temporary tables. |
| 16:52 |
jeff |
ah, nope. did it to myself again by not quoting when I created my test. |
| 16:52 |
jeff |
anyway. |
| 16:53 |
jeff |
> Quoting an identifier also makes it case-sensitive, whereas unquoted names are always folded to lower case. For example, the identifiers FOO, foo, and "foo" are considered the same by PostgreSQL, but "Foo" and "FOO" are different from these three and each other. |
| 16:57 |
|
tspindler left #evergreen |
| 17:00 |
|
dreuther_ joined #evergreen |
| 17:07 |
|
dreuther joined #evergreen |
| 17:09 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:25 |
|
nhilton_ joined #evergreen |
| 18:19 |
|
StephenGWills_ joined #evergreen |
| 18:47 |
|
StephenGWills left #evergreen |
| 00:50 |
|
atlas___ joined #evergreen |
| 00:53 |
|
AliceR joined #evergreen |
| 00:55 |
|
atlas__ joined #evergreen |
| 05:33 |
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 |
|
b_bonner joined #evergreen |
| 07:23 |
|
mnsri_ joined #evergreen |
| 07:24 |
|
mtcarlson_away joined #evergreen |
| 11:25 |
kmlussier |
eeevil: Thanks for the background on the setting. It's helpful. |
| 11:25 |
eeevil |
good! :) (and I agree on the description change) |
| 11:26 |
|
vlewis joined #evergreen |
| 11:28 |
tsbere |
Looking at the reshelving complete code, I think the "fix" for allowing it to run mid-day and not screw things up may actually be a single line of code. <_< Not sure how to *test* it though. |
| 11:29 |
hopkinsju |
tsbere: Can you put your idea into a paste? We may be able to help test it. |
| 11:31 |
tsbere |
hopkinsju: I was thinking just drop it into a working branch you could cherry-pick from. |
| 11:31 |
tsbere |
(and attaching said branch to the launchpad bug) |
| 11:32 |
Bmagic |
tsbere: sounds good to me |
| 11:48 |
eeevil |
Able. Autocorrect... |
| 11:50 |
* tsbere |
watched locks with and without the status = 7 checks and didn't see any noticable difference in them, but didn't exactly do an overly complete job of watching either and wasn't on a production-level system data-wise |
| 11:51 |
dbwells |
bshum: I would typically branch rel_2_x_x from rel_2_x, do the release stuff, then forward-port the upgrade file back to rel_2_x and master (eventually). Then all the scripts are already in rel_2_x for the next point release. Does that answer your question? |
| 11:53 |
eeevil |
My bigger point is that the current reshelver has an intended purpose, and IMO we should consider that when looking for a solution that is outside that original intent. I'm 100% for code reuse, but I think this might be stretching it, in this specific case... But, testing will tell |
| 11:55 |
tsbere |
eeevil: I am all for "new code for the new intent" or even "more efficient/targeted code for this intent" (only doing short-term reshelving when open, for example) - I am also all for calling it a bug that the reshelving complete code can, regardless of when or how often it is run, change the status of something *not* in reshelving at update time. |
| 12:04 |
|
sal_ joined #evergreen |
| 12:05 |
eeevil |
fair enough. in practice, of course, it /only/ happens during open hours, but yes, it's a fair point |
| 13:07 |
gmcharlt |
RoganH: I recalled that we discussed this the other day... do you want to put it through its paces a bit before we make an announcement? |
| 13:08 |
RoganH |
Yeah, let me play with it for a couple of days. |
| 13:08 |
gmcharlt |
kmlussier: very creatively... http://evergreen-ils.org/jobs/ |
| 13:08 |
RoganH |
I'll do some test posts, deletions, etc... |
| 13:08 |
gmcharlt |
RoganH: it also exposes a jobs dashboard |
| 13:08 |
gmcharlt |
http://evergreen-ils.org/job-dashboard/ |
| 13:08 |
kmlussier |
When you've run it through its paces, I would like to share the link with OPW. As OPW sponsors, I think we get a benefit of having our jobs page listed on their site. |
| 13:11 |
RoganH |
shiny ball received |
| 13:11 |
gmcharlt |
RoganH++ |
| 13:12 |
kmlussier |
RoganH++ |
| 13:12 |
gmcharlt |
so, noting a couple action items for myself |
| 13:12 |
gmcharlt |
#action (carry-over) gmcharlt will coordinate/assist with dbs to move the planet |
| 13:12 |
gmcharlt |
#action gmcharlt with work with DIG to get a test VM for doc-building set up |
| 13:13 |
kmlussier |
gmcharlt++ |
| 13:13 |
RoganH |
gmcharlt++ |
| 13:13 |
gmcharlt |
next up, the FAQs... |
| 16:47 |
* berick |
recalls a recent conversation about that |
| 16:47 |
kmlussier |
Yup. http://markmail.org/message/jsrbhxlwr2dshglv |
| 16:49 |
|
nhilton_ joined #evergreen |
| 16:57 |
pinesol_green |
[evergreen|Bill Erickson] LP#1261486 Action/trigger aggregator script repairs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a7c3267> |
| 17:03 |
|
kmlussier left #evergreen |
| 17:04 |
|
kmlussier joined #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:45 |
gmcharlt |
dokuwiki updated to current stable version |
| 19:10 |
|
maggieWCL joined #evergreen |
| 19:13 |
|
kmlussier joined #evergreen |
| 01:46 |
|
jcamins joined #evergreen |
| 03:29 |
|
AliceR joined #evergreen |
| 03:49 |
|
AliceR joined #evergreen |
| 05:19 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:40 |
|
mtate joined #evergreen |
| 06:40 |
|
eeevil joined #evergreen |
| 07:10 |
|
Callender joined #evergreen |
| 09:05 |
aashita |
Hi Berick! |
| 09:05 |
aashita |
i Just want to know only Julia Lima has done editing of UI style guide |
| 09:24 |
|
RoganH joined #evergreen |
| 09:36 |
mrpeters |
trying to load the concerto, etc. data in 2.7 -- error that "env_create.sql" is missing. Is this a part of the test dataset that maybe got left out, or a missing dependency |
| 09:39 |
tsbere |
mrpeters: I see env_create.sql in what I believe to be the correct location |
| 09:40 |
mrpeters |
is that not /home/opensrf/Evergreen-ILS-2.7.0/Open-ILS/tests/datasets/sql ? |
| 09:40 |
* tsbere |
is also looking at master |
| 09:41 |
Dyrcona |
mrpeters: Is this from git or a tarball? |
| 09:41 |
mrpeters |
tarball |
| 09:43 |
Dyrcona |
"Someone" being bshum. ;) |
| 09:44 |
Dyrcona |
I checked rel_2_7 and tags/rel_2_7_0, and the file is in both branches where it should be. |
| 09:44 |
Dyrcona |
Just for the record. |
| 09:45 |
mrpeters |
/home/opensrf/Evergreen-ILS-2.7.0/Open-ILS/tests/datasets/sql is correct location, no? |
| 09:45 |
Dyrcona |
Yes, it is. |
| 09:45 |
Dyrcona |
jason jason:~/Src/Evergreen$ find ./ -name env_create.sql |
| 09:45 |
Dyrcona |
./Open-ILS/tests/datasets/sql/env_create.sql |
| 10:16 |
|
yboston joined #evergreen |
| 10:24 |
kmlussier |
dbs: I must have missed your comment in IRC regarding adding berick's script-based install to the README, but if you point me in the right direction, I can, at a minimum, add it to the OPW wiki page. |
| 10:25 |
kmlussier |
I'll even try to add it to the README if I get a minute to breathe. :) |
| 10:29 |
|
buzzy joined #evergreen |
| 10:31 |
mrpeters |
hmm, so the env_create is in the tarball, it's just looking for it in the cd, so you have to be in the tests/datasets/sql/ directory |
| 10:31 |
mrpeters |
my fault for the false alarm |
| 10:33 |
tsbere |
mrpeters: Are you loading the files manually, instead of with eg_db_config? |
| 10:33 |
mrpeters |
the test data? i just do psql evergreen < load_all.sql |
| 10:33 |
tsbere |
mrpeters: If you use the flags for eg_db_config it does the cd and such for you. |
| 10:33 |
mrpeters |
i just was supplying the full path to load_all.sql, not realizing i had to be in that directory |
| 10:34 |
mrpeters |
ah, interesting. didn't know you could use eg_db_config to load all of that test data |
| 10:36 |
tsbere |
mrpeters: --load-all-sample or --load-concerto-sample, I think. |
| 10:36 |
mrpeters |
awesome, good to know |
| 10:52 |
|
krvmga joined #evergreen |
| 11:18 |
mrpeters |
ok, carry on |
| 11:18 |
mrpeters |
just wanted to dispell your incorrect impression |
| 11:18 |
tsbere |
besides, if you screw up the install steps you may not realize you did so if the package has things in the right place and your install has them in the wrong one, then bash your head as to why your changes aren't working. |
| 11:18 |
mrpeters |
the packaged evergreen is a VERY good way for someone to quickly get a test system up and running as long as they understand basic IP addressing and know how to install linux packages |
| 11:20 |
mrpeters |
thats fine, if you dont see it fit for a developer don't use it, no big deal, just sharing the information that this is available to anyone, and the myth that it is "just for PINES" is completely false |
| 11:20 |
tsbere |
mrpeters: My assumption was "PINES has public non-customized and private customized package sets" - I never assumed the ones I could get at were customized for PINES. |
| 11:21 |
gmcharlt |
well, rather depends on what the ultimate purpose is - if you want a running EG instance to test or document, sure, try the packages |
| 11:21 |
gmcharlt |
if you are aiming to do *coding* ... at the moment, I don't see any responsible way around installing from a git clone if the end result is meant to be useful to a *coder* |
| 11:24 |
mrpeters |
that is fair |
| 11:25 |
Dyrcona |
And, what about production? Do you think that would work from a packaged version?\ |
| 11:25 |
Dyrcona |
Right now, Evergreen is very "old school" in how you install it. Not saying I have a problem with that, but that is not noob friendly. |
| 11:46 |
csharp |
there are some hard-coded assumptions/choices that we have to make for packaging, but we think they're sane and easily changed |
| 11:47 |
Dyrcona |
For us, we build directly from git, and make an integration branch. |
| 11:47 |
mrpeters |
built right from the same code we use to build up PINES |
| 11:47 |
Dyrcona |
We also have two developers with development and test servers, so we're doing integration on a fairly frequent basis. |
| 11:47 |
csharp |
however, (sorry mrpeters :-) ), I have to agree with others that building from source (either by hand or by script) is the best way to participate in community development |
| 11:47 |
Dyrcona |
Conflicts occur, but are often noticed and resolved quickly, and well before we go into production. |
| 11:48 |
mrpeters |
i agree for CODE development |
| 11:48 |
Dyrcona |
We also load onto the test server several weeks before we go live in production so members can have a go at finding things that might not be quite right. |
| 11:48 |
mrpeters |
but if you just want to quickly test out evergreen, man, its a fast way to do it |
| 11:49 |
csharp |
I completely agree that using our deb repo is the easiest way to get up and running on Ubuntu on the most current stable release |
| 11:50 |
mrpeters |
i just remember the days when we supplied virtual box images for people who just wanted to "test out" evergreen |
| 11:50 |
csharp |
but... it obviously comes with the same limitations as all the other methods people have discussed (preferences, best practices, etc. can vary widely) |
| 11:50 |
mrpeters |
and it was a nightmare, they were always outdated, nobody wanted to manage them, etc. |
| 11:50 |
mrpeters |
had i known about this repo back then, man the pain we could have avoided! |
| 17:49 |
berick |
Bmagic: that's probably it |
| 17:50 |
Bmagic |
You think it's possible that the update query from the reshelver could hit on rows that have their status=1 even though the query clearly is looking for 7? |
| 17:51 |
berick |
grr, i opened a LP ticket about this a really long time ago, now i can't find it |
| 17:51 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:51 |
berick |
https://bugs.launchpad.net/evergreen/+bug/1018011 |
| 17:51 |
pinesol_green |
Launchpad bug 1018011 in Evergreen 2.4 "Incorrect copy status caused by reshelving process colliding with item checkout" (affected: 4, heat: 20) [Medium,Confirmed] |
| 17:52 |
berick |
wow, for the first time ever, LP search worked better than google |
