| 02:16 |
|
jonadab_znc joined #evergreen |
| 03:22 |
|
gsams joined #evergreen |
| 03:24 |
bshum |
@later tell dbwells Curious to know if you had any time to poke at https://bugs.launchpad.net/evergreen/+bug/1379815. We've been thinking about adding copy stat cats more permanently into some of our workflows, but can't if Vandelay doesn't support something like it. |
| 03:24 |
pinesol_green |
bshum: The operation succeeded. |
| 03:24 |
pinesol_green |
Launchpad bug 1379815 in Evergreen "Assign stat cats during Vandelay import/overlay of items" (affected: 1, heat: 8) [Wishlist,New] - Assigned to Remington Steed (rjs7) |
| 03:24 |
|
jcamins joined #evergreen |
| 03:43 |
|
gsams joined #evergreen |
| 03:43 |
|
Mark__T joined #evergreen |
| 03:47 |
|
dbs joined #evergreen |
| 03:53 |
|
mnsri_away joined #evergreen |
| 04:50 |
|
Mark__T joined #evergreen |
| 05:16 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:14 |
|
rlefaive joined #evergreen |
| 07:15 |
|
artunit_away joined #evergreen |
| 08:02 |
|
gsams joined #evergreen |
| 11:56 |
Bmagic |
once I removed that config and restarted rsyslog on the app servers, the log file stopped adding those error messages |
| 12:00 |
jeff |
logical. your app servers were trying to log to files that they didn't need to log to, and their errors about not being able to do so were being logged on the target/remote log host. :-) |
| 12:01 |
Bmagic |
jeff: I think that was it, time will tell of course |
| 12:02 |
Bmagic |
jeff: We have been having weird issues and these logs might be a clue. Every week for the last 4 weeks, ALL of our app servers get taken out of LVS rotation because apache stops responding to the test from lvs |
| 12:02 |
Bmagic |
Do you think that an rsyslog misconfiguration could possible pile up high enough to bring apache down to a slow enough crawl? |
| 12:03 |
bshum |
mrpeters: What do you mean when you say xpath issues? |
| 12:04 |
mrpeters |
ive done various ways of doing pg dump and it seems like i had some kind of issue with xpath or search path or something like that |
| 13:31 |
Christineb |
I can't stress how happy this made me :D |
| 13:31 |
jihpringle |
it's slated for 2.9 but we've backported to 2.8 and have been using it since July |
| 13:31 |
mcrawley |
don't know what that one is? |
| 13:33 |
lstjohn |
we are also about to sign off on #1402018 workstation scoping - we've tested it on 2.7.2 |
| 13:33 |
jihpringle |
the acquisitions admin menu was moved to be under the Admin menu rather than under Admin -> Server Administration |
| 13:33 |
Christineb |
The Acquisitions Admin menu has been moved directly under Admin instead of having to to into Admin --> Server Admin |
| 13:33 |
Christineb |
lstjohn - that is great news!! |
| 13:40 |
lstjohn |
I have a question. When you delete a line item from a purchase order that has not been activated, it deletes the line item from the selection list but not from the OPAC - is this your experience also? |
| 13:40 |
Christineb |
lstjohn - I have seen this happen |
| 13:41 |
Christineb |
when a MARC order file is loaded in "Load MARC Order Records" and Load Items for Imported Records is selected |
| 13:42 |
Christineb |
Is on my to-do list to do some more testing to figure out if this is a bug or desired behaviou |
| 13:42 |
Christineb |
does this scenario match what you are seeing? |
| 13:44 |
lstjohn |
Yes, order records loaded, copies created - there seems to be a related bug https://bugs.launchpad.net/evergreen/+bug/1269574 |
| 13:44 |
pinesol_green |
Launchpad bug 1269574 in Evergreen "ACQ lineitems canceled via EDI not deleting linked bibs/items" (affected: 5, heat: 26) [Medium,Confirmed] |
| 15:29 |
Dyrcona |
jeff csharp bshum: lp 1484655 |
| 15:29 |
pinesol_green |
Launchpad bug 1484655 in Evergreen "ftp://ftp.mozilla.org has moved to http://archive.mozilla.org" (affected: 1, heat: 6) [High,New] https://launchpad.net/bugs/1484655 - Assigned to Jason Stephenson (jstephenson) |
| 15:29 |
Dyrcona |
Oops. Should unassign myself. ;) |
| 15:30 |
jeff |
say, why didn't live tests break? because it doesn't build a staff client? |
| 15:31 |
Dyrcona |
I successfully built a client last week, so don't know when this actually changed. |
| 15:31 |
Dyrcona |
Also, maybe it doesn't build a client. |
| 15:32 |
jeff |
timestamp on the README in question is "8/7/15, 10:22:00 PM" |
| 15:33 |
Dyrcona |
Missed it by a couple of days. |
| 16:25 |
|
ericar joined #evergreen |
| 16:35 |
|
jihpringle joined #evergreen |
| 16:59 |
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 |
Dyrcona |
jeff: Looking through the test logs above, it doesn't appear to make a client. It just does the server-side bits. |
| 17:01 |
* Dyrcona |
disappears. |
| 17:08 |
|
mmorgan left #evergreen |
| 17:32 |
|
jlundgren left #evergreen |
| 18:00 |
dbwells |
rfrasur: what's up? |
| 18:02 |
rfrasur |
I think Rogan is taking care of it. Maybe? Thank you :-) |
| 18:02 |
dbwells |
okay :) |
| 18:04 |
berick |
Bmagic: yes, i think requesting a static file from your apache server via http is a common way to confirm it's alive |
| 18:04 |
berick |
Bmagic: many load balancers use that as a way to take server in/out of rotation. request a file (e.g. /openils/var/web/ping.tx) and if it's not there, the server is removed from rotation |
| 18:05 |
berick |
well, ping.txt (but i imagine it can be anything) |
| 18:06 |
berick |
that style of test is great because you can take a server out w/o having to touch the load balancer |
| 18:37 |
rfrasur |
Okay, I'm thinking through some stuff for our library. In a consortium...or library system...can you hide all the collections of a branch from the rest of the library system? |
| 18:38 |
rfrasur |
I mean, using Evergreen...not a book truck and a closet. |
| 18:41 |
|
buzzy joined #evergreen |
| 02:23 |
|
Mark__T joined #evergreen |
| 04:48 |
|
Mark__T joined #evergreen |
| 05:12 |
|
artunit_ joined #evergreen |
| 06:43 |
csharp |
ldw++ # test wrangling |
| 07:37 |
|
Callender joined #evergreen |
| 07:45 |
|
TaraC joined #evergreen |
| 07:46 |
|
mrpeters joined #evergreen |
| 08:50 |
krvmga |
in eg 2.5 it was easy to change the order of search format filters in the opac dropdown list. since 2.6, they have been listed alphabetically. is it possible to change the order of the filters somehow other than by alphabetical manipulation? |
| 08:56 |
|
mmorgan joined #evergreen |
| 09:14 |
|
jwoodard joined #evergreen |
| 09:25 |
Stompro |
mmorgan++ thanks for testing the patron expiration notice.. now to get the release notes done. |
| 09:25 |
|
yboston joined #evergreen |
| 09:27 |
* Dyrcona |
wonders if hopkinsju had any success with backstage yesterday evening. |
| 09:27 |
mmorgan |
Stompro++ Thanks for polishing the code, and (in advance) for the release notes! |
| 09:29 |
|
ericar_ joined #evergreen |
| 09:35 |
|
collum joined #evergreen |
| 10:07 |
|
pmurray_away joined #evergreen |
| 10:10 |
Stompro |
ldw++, thanks for all the test writing bugs, I assigned myself to the simplest one I could find :-) |
| 10:23 |
krvmga |
is there any way to change the order of search format filters in the opac other than by playing with the alphabetical listing? |
| 10:29 |
dbwells |
krvmga: I don't think there is anything built in. We ordered ours as you are thinking by manipulating the strings. In our case, we prepended a certain number of spaces to the "Search Label"s. The spaces do not show up. |
| 10:29 |
krvmga |
dbwells: can i look at your catalog url? |
| 14:30 |
Bmagic |
I was having trouble finding a report about the in-house barcode box not clearing the box after the enter button was pressed (ready to accept the next barcode) |
| 14:39 |
Bmagic |
https://bugs.launchpad.net/evergreen/+bug/1483857 |
| 14:39 |
pinesol_green |
Launchpad bug 1483857 in Evergreen "Web based staff client in house use barcode box clear" (affected: 1, heat: 6) [Undecided,New] |
| 14:59 |
ldw |
Stompro: thank you for taking a bug. Have you worked with the pgTap testing suite before? |
| 15:00 |
Stompro |
ldw, Never, All I know about it is from reading the docs that you linked to previously. |
| 15:00 |
|
rlefaive joined #evergreen |
| 15:03 |
ldw |
Stompro: If you have any questions about it do not hesitate to ask. |
| 15:04 |
|
akilsdonk joined #evergreen |
| 15:17 |
jboyer-isl |
I don't think I've asked this before, but what are the thoughts re: tests and simply adding new seed data? Don't bother, check to see if a few values are present, check every value, etc? |
| 15:18 |
berick |
jboyer-isl: for example? |
| 15:18 |
jboyer-isl |
I'm looking at LP #1371647 and have a large upgrade script ready to go, but I haven't decided what to do about a test case. |
| 15:18 |
pinesol_green |
Launchpad bug 1371647 in Evergreen "config.marc21_ff_pos_map needs an audit" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1371647 |
| 15:20 |
jboyer-isl |
berick: example incoming |
| 15:21 |
jboyer-isl |
Bah, it would have, but I mistyped my nick... |
| 15:22 |
berick |
sorry, i was confuzzled |
| 15:23 |
berick |
i've just been checking a few values, like a basic sanity check. |
| 15:23 |
berick |
don't think we have a policy on that |
| 15:25 |
jboyer-isl |
Excellent. I don't mind spot checking a few things to be sure the patch was applied, but a "full check" would be a huge pain to write for things like that. |
| 15:26 |
jboyer-isl |
I'll try to get something put together and posted for proper discussion/testing asap; this is holding up some format search improvements that we're trying to do and I don't want it to be a local only fix. |
| 15:27 |
Dyrcona |
Well, you could use a macro in your text editor to write the tests for you... I've done that recently from other upgrade scripts. |
| 15:30 |
berick |
you're gonna need a unit test on that macro |
| 15:32 |
Dyrcona |
You're gonna need a unit test on your unit test, too. :) |
| 15:33 |
Dyrcona |
But actually, I didn't use a macro just a regex search and replace. I misspoke. |
| 15:45 |
jboyer-isl |
That's true, but then there's only full coverage for a chunk of data. If there's ever interest in fully verifying seed data, I'd rather see one big test that checks it all (one file per schema/table, not necessarily the entire seed database) |
| 15:52 |
Dyrcona |
jboyer-isl: That sounds reasonable to me. When do you start working on it? :P |
| 15:52 |
Dyrcona |
j/k |
| 15:54 |
jboyer-isl |
Well, I suppose someone could find and replace 950.config.seed-data.sql, heh. |
| 16:12 |
jlitrell |
Living in soup. |
| 16:21 |
Dyrcona |
Hmm. Looking into something from yesterday that I thought would require a staff client change and now it looks like I can handle it all on the back end. |
| 16:22 |
Dyrcona |
berick: Do you remember the LP bug that was created for the branch that allowed pre cat copies to be created for ILL and other purposes? |
| 16:22 |
Dyrcona |
kmlussier and I tested it, but I can't find the bug now, even search fix committed bugs. |
| 16:23 |
|
mmorgan1 joined #evergreen |
| 16:23 |
|
mmorgan1 left #evergreen |
| 16:24 |
|
mmorgan2 joined #evergreen |
| 16:24 |
pinesol_green |
Launchpad bug 1308239 in Evergreen "Support targeting and fulfillment of precat copy holds (for ILL)" (affected: 2, heat: 10) [Wishlist,Fix released] https://launchpad.net/bugs/1308239 |
| 16:24 |
|
mmorgan2 left #evergreen |
| 16:25 |
Dyrcona |
berick++ # that's a handy feature. |
| 16:26 |
Dyrcona |
Looks like bshum tested it, too. |
| 16:27 |
hopkinsju |
Dyrcona: Just made a breakthrough. |
| 16:27 |
Dyrcona |
hopkinsju: What was the problem? |
| 16:28 |
hopkinsju |
Initial issue was the default last_run_date and the fact that we didn't use the script to do the initial export |
| 17:00 |
Dyrcona |
Well, time to go home. |
| 17:12 |
|
mmorgan1 joined #evergreen |
| 17:12 |
|
mmorgan1 left #evergreen |
| 17:18 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 18:20 |
|
rjackson_isl_ joined #evergreen |
| 18:20 |
|
mmorgan joined #evergreen |
| 18:23 |
|
TaraC joined #evergreen |
| 10:07 |
Dyrcona |
csharp: We don't seem to have set one. |
| 10:08 |
Dyrcona |
We often get requests to fix patrons after registration, but it's usually when the staff tries to use a barcode that got assigned as the usrname on a previous user. |
| 10:08 |
|
collum joined #evergreen |
| 10:08 |
csharp |
Dyrcona: we discovered the need for it when testing the built-in selfcheck, which says "check whether the string the patron has entered matches the opac.barcode_regex setting... if not, treat the string like a username" |
| 10:09 |
csharp |
since our setting is null, all entered values are being treated like usernames |
| 10:09 |
Dyrcona |
Well, our opac.barcode_regex setting is a bit strange. It doesn't check length, for one thing. |
| 10:09 |
Dyrcona |
I thought you were asking about a different setting. |
| 10:10 |
Dyrcona |
But, the patron's barcode and usrname not matching, but both being barcodes, seem to happen in registration when the staff start out using 1 barcode and end up issuing a different one. |
| 10:41 |
|
Christineb joined #evergreen |
| 10:56 |
jeff |
interruptions, possibly. |
| 11:11 |
* mmorgan |
reads backscroll |
| 11:12 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 11:12 |
mmorgan |
Our opac.barcode_regex specified the barcode must have at least five digits, that's all. Not sure where it actually comes into play. |
| 11:14 |
Dyrcona |
The test failure looks like one of those things we can't control. |
| 11:14 |
Dyrcona |
Got a 503 while trying to download the phantomjs package. |
| 11:17 |
phasefx |
start local repos for everything? |
| 11:27 |
Dyrcona |
Nope. It'll probably succeed when the issue on the server is discovered and resolved. |
| 15:26 |
|
jlitrell joined #evergreen |
| 15:27 |
jeff |
ah. title hold on a bib whose only volume is deleted. |
| 15:33 |
jeff |
and we have a surprising number of those. |
| 15:35 |
pinesol_green |
[evergreen|Michael Peters] LP#1394989: Make users_of_interest test for defined actor.usr.card values - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=13da6b8> |
| 15:35 |
pinesol_green |
[evergreen|Bill Ott] LP#1394989: Do not include deleted users when retrieving for Collections - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0f8ec14> |
| 15:39 |
|
berowskim joined #evergreen |
| 15:57 |
Bmagic |
I have a bib that is sorted to the bottom of the list search when sorted newest to oldest. Come to find out, there is no entry in metabib.record_sorter for pubdate for this bib. When I reingest the bib, it still doesnt get created. Where is the glue? |
| 16:02 |
Bmagic |
I found it. sorry, that was easy, Date1 in the 008 |
| 16:11 |
Dyrcona |
It handles authority deletes from a file matching DEL |
| 16:12 |
Dyrcona |
Anything else that doesn't begin with R followed by 2 digits is treated as an authorities file. |
| 16:13 |
Dyrcona |
We get zips with bibs, authorities, and reports all in one and it handles them OK. |
| 16:13 |
hopkinsju |
So if I have a zip file with ONLY a file called BIB.MRC in it, shouldn't that get overlayed? |
| 16:14 |
hopkinsju |
I'm trying to do some smaller scale testing before i set it loose. |
| 16:15 |
Dyrcona |
It depends. If you look in Backstage::Import->do_bibs you'll see there are some criteria, but you should get some output to the screen as each record is processed. |
| 16:15 |
Dyrcona |
Sorry, it's doBibs not do_bibs. |
| 16:15 |
hopkinsju |
Ok |
| 17:00 |
Dyrcona |
It's probably because of the full path to BIB.MRC in the zip file. |
| 17:01 |
Dyrcona |
The zip files that I get from Backstage have no directory information in the member file names. |
| 17:02 |
Dyrcona |
Anyway, signing off for now. |
| 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:05 |
|
mmorgan left #evergreen |
| 17:14 |
jeff |
deleted bibs with non-deleted call numbers. deleted call numbers with non-deleted copies. |
| 17:14 |
jeff |
always fun to try to determine which way to "fix" this. |
| 00:58 |
phasefx |
@later tell Dyrcona the live tests happen on a near pristine snapshot of wheezy and runs all the tests |
| 00:58 |
pinesol_green |
phasefx: The operation succeeded. |
| 02:53 |
|
sarabee joined #evergreen |
| 03:27 |
|
gsams joined #evergreen |
| 09:05 |
kmlussier |
And I see rain in the forecast for Tuesday and Wednesday. Figures. |
| 09:13 |
Stompro |
mmorgan, have you started on the release notes for bug 1124498, I also started on that but forgot to assign it. |
| 09:14 |
pinesol_green |
Launchpad bug 1124498 in Evergreen "Wishlist: Patron notification via email when card is about to expire" (affected: 6, heat: 40) [Wishlist,Confirmed] https://launchpad.net/bugs/1124498 - Assigned to Michele Morgan (mmorgan) |
| 09:15 |
mmorgan |
Stompro: I was actually working on final testing to sign off. You are welcome to the release notes :) |
| 09:18 |
Stompro |
mmorgan, Wonderful, I hope your testing goes well. |
| 09:18 |
kmlussier |
mmorgan++ Stompro++ |
| 09:19 |
kmlussier |
Stompro: I think MVLC might do some of the things you described in your email with staff clients for test servers. tsbere might be able to answer your questions. I don't think he's around this week. |
| 09:21 |
* mmorgan |
is also interested in that info. I often find a need to run 2 clients simultaneously on the same workstation. |
| 09:21 |
kmlussier |
I use MVLC's servers quite a bit for testing. Icons for the clients that access the test servers are a different color and they don't share settings with the other clients on my local machine. |
| 09:21 |
* kmlussier |
has many, many clients on her local machine. |
| 09:22 |
Stompro |
kmlussier, great, any guidance would be appreciated. I'll send him an email if I don't hear from him. |
| 09:22 |
kmlussier |
mmorgan: Yes, that's what I like about testing on MVLC's servers. I can have two or more clients at the same time. tsbere also configured the clients for the MassLNC VMs to work the same way. |
| 09:23 |
kmlussier |
tsbere++ #for general wizardry |
| 09:24 |
mmorgan |
Yes, I noticed that. I can run a MassLNC client concurrently with a NOBLE client, but not a NOBLE Production along with a NOBLE training client. |
| 09:25 |
mmorgan |
Stompro: We will just change the hostname when the different servers are running the same version of Evergreen, but often our servers are on different versions. |
| 09:27 |
Stompro |
mmorgan, I think you can run multiple instances at the same time by enabling multi profile mode and multi-instance mode - http://wiki.evergreen-ils.org/doku.php?id=mozilla-devel:building_the_staff_client#multiple_workstations_on_one_install |
| 09:28 |
Stompro |
Add -P and -no-remote to your client shortcut. |
| 09:30 |
mmorgan |
Stompro: we use -profilemanager all the time. I'll have a look at -no-remote, though. |
| 09:34 |
Stompro |
I just wanted to make it super easy for staff to connect to the training/testing server, without needing to change the hostname, to take out a step where mistakes can be made. I'm just worried about staff accidently thinking they are are production when they are on testing and vice versa. Maybe adding a prefix to all usernames on the test system would help. |
| 09:35 |
mmorgan |
Stompro++ You made my day! |
| 09:42 |
Stompro |
Did the -no-remote work? |
| 09:44 |
mmorgan |
Yes! I now have 2 clients open at the same time :) Not sure how I missed that detail, but am happy to know it now! |
| 10:41 |
Bmagic |
Ok, that is whay I thought, just changing the parent OU should do it with autogen. Sounds easy enough |
| 10:42 |
Bmagic |
/whay/what |
| 10:42 |
Dyrcona |
You might have some memcached issues, so I'd wait and do it in the middle of the night when you can restart memcached without wrecking too much. |
| 10:45 |
Dyrcona |
I'd also suggest trying it on a test/training system first, just to make sure. |
| 10:50 |
* kmlussier |
is spending more time re-learning AsciiDoc conversion than writing documentation. |
| 10:50 |
csharp |
Bmagic: yes, we've moved a branch from one parent to another - it's not a big deal - just move it and run autogen (though you might schedule it after business hours) |
| 10:51 |
csharp |
all holdings and patrons, etc. remain intact |
| 11:03 |
Dyrcona |
My guess is that might be a mistake. |
| 11:04 |
kmlussier |
Yes, I don't think that was the intent at all. |
| 11:04 |
Dyrcona |
But, I'd need to play with with some samples and don't have time at the moment. |
| 11:04 |
Bmagic |
kmlussier: yep! That's what it looks like. I created a new 700 field on a test record and only created a subfield "a" and violla it was indexted |
| 11:05 |
Bmagic |
I am assuming that the contents of config.xml_transform are lifted from some global standard? |
| 11:11 |
Dyrcona |
Bmagic: http://www.loc.gov/standards/mods/ |
| 11:11 |
Bmagic |
Dyrcona: right, and the xsl structure was downloaded somewhere or did the EG community create it from their guideline? |
| 13:21 |
kmlussier |
Dyrcona: No. |
| 13:22 |
kmlussier |
Bmagic: I added a comment to https://bugs.launchpad.net/evergreen/+bug/1331174/comments/15 |
| 13:22 |
pinesol_green |
Launchpad bug 1331174 in Evergreen "Long Overdue processing needs org unit settings separate from Lost Processing" (affected: 4, heat: 18) [Wishlist,Confirmed] |
| 13:23 |
kmlussier |
Bmagic: I don't know what kind of time you have today, but if you were able to get that branch ready today, I could load it on a test server before I leave for vacation. |
| 13:23 |
kmlussier |
mmorgan is interested in testing it. |
| 13:25 |
* kmlussier |
is trying to get various billing bits in before she tackles billing documentation for 2.9. |
| 13:25 |
kmlussier |
Which brings me to bug 1436797. Maybe that's one I can handle. |
| 13:25 |
pinesol_green |
Launchpad bug 1436797 in Evergreen ""grocery" term confuses frontline staff and patrons" (affected: 11, heat: 48) [Undecided,New] https://launchpad.net/bugs/1436797 |
| 13:41 |
Stompro |
dyrcona++ Thanks for enlightening me about the STAFF_CLIENT_NAME variable, that is just what I needed. I'll add that to the buidling the staff client wiki page. |
| 13:42 |
Stompro |
Dyrcona++ (getting the caps right) |
| 14:12 |
pinesol_green |
csharp: It is possible. |
| 14:12 |
Dyrcona |
Stompro: I think it might use the stamp id as the product tag in windowssetup.nsi, but I never actually install the Windows staff client, so I don't know for sure. |
| 14:14 |
Stompro |
I don't thinks so, my STAMP_ID is set to rel_2_8_2 and the PRODUCT_TAG is set to '2.8' which gets combined with "Evergreen Staff Client" to set the default install. |
| 14:17 |
Stompro |
Dyrcona, I just tested it out, and setting a custom PRODUCT_TAG in windowssetup.nsi does set the default install directory. So I think I've got all the pieces figured out. Thanks for your help. |
| 14:18 |
Stompro |
I love having all the various options on how this stuff can work. |
| 14:18 |
Stompro |
iii-- |
| 14:21 |
Dyrcona |
Stompro: Cool! Glad you find my ramblings useful. |
| 16:47 |
kmlussier |
Heading out for the week. Have a nice week everyone! |
| 16:48 |
mmorgan |
Have a great vacation! |
| 16:49 |
|
kmlussier left #evergreen |
| 17:07 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:08 |
|
mmorgan left #evergreen |
| 17:17 |
|
mrpeters left #evergreen |
| 18:09 |
|
rlefaive joined #evergreen |
| 02:12 |
|
jonadab_znc joined #evergreen |
| 05:09 |
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 |
|
rlefaive joined #evergreen |
| 07:03 |
|
rlefaive joined #evergreen |
| 07:25 |
|
rlefaive joined #evergreen |
| 09:41 |
Dyrcona |
Dunno, bshum. You tell me. :) |
| 09:42 |
bshum |
Dyrcona: Oh I was just musing on dbs' musings |
| 09:42 |
Dyrcona |
Yep. |
| 09:43 |
* Dyrcona |
goes back to writing a pgtap test for jeffdavis_afk |
| 09:43 |
Dyrcona |
Well, one of his branches, anyway. |
| 09:43 |
bshum |
:P |
| 09:44 |
Dyrcona |
But, bshum's latest comment on the bug he mentioned might prove helpful to dbs if that is the problem. |
| 10:10 |
bshum |
But not to master |
| 10:10 |
bshum |
And since translations in LP track against master |
| 10:10 |
bshum |
Those strings never showed up for needing translation in LP. |
| 10:10 |
Dyrcona |
miker: If you want sprint2 in master before the alpha/beta release, then you'll need to clean up the upgrade scripts and provide pgtap tests. |
| 10:11 |
Dyrcona |
miker: I'm also concerned about the FIXME comment in XXXX.schema.marc-tag-tables.sql |
| 10:11 |
Dyrcona |
I get errors on line 9 and will try reordering the drop statements, but also wonder if I should even be running those drops given the comment. |
| 10:12 |
phasefx |
bshum: fun |
| 10:13 |
bshum |
phasefx: I would imagine we could still cherry-pick berick's changeset from 2.8 to master now. And then when Dyrcona does i18n dances for 2.9, we just make sure to bring in all the translations |
| 10:13 |
bshum |
But I'm not sure how we can fix 2.8. Yet. |
| 10:13 |
bshum |
Still rethinking it over. |
| 10:13 |
Dyrcona |
I should do a test release build whether there is an alpha or not. |
| 10:14 |
bshum |
Dyrcona: It's always good practice. |
| 10:15 |
Dyrcona |
Yep. Trouble is: not much time for practice. |
| 10:16 |
phasefx |
bshum++ I'm glad you're thinking about it; it's over my head at the moment. So we do something to extract strings from source files into language files, commit those somewhere, and Launchpad can then change them or let us export a new updated set of files based on its global translation effort? |
| 10:27 |
bshum |
That should go on a t-shirt |
| 10:28 |
* csharp |
copyrights it before bshum gets a chance |
| 10:30 |
Dyrcona |
Hmm... Wonder if IRC chat is copyrightable.... That would be an interesting case. |
| 10:31 |
Dyrcona |
And, I still haven't written the pgtap test, yet. |
| 10:32 |
dbs |
Your chat in IRC is an expression of an idea, thus very likely copyrightable. |
| 10:32 |
* dbs |
was just answering a question around copyright and fair dealing for our online learning folks |
| 10:32 |
RoganH |
Yep. If you create the speech you can copyright it. You're just exercising your own right to perform it in public. |
| 10:38 |
Dyrcona |
(C) is not valid, so in Brazil, what you just said is in the public domain, csharp. :) |
| 10:39 |
bshum |
I'm comparing our outputs now, for giggles |
| 10:39 |
Dyrcona |
In Brazil it must have the c in the circle symbol, the word copyright is not good enough by itself. (That I remember from research from a number of years ago.) |
| 10:40 |
Dyrcona |
But, anyway.... that pgtap test... |
| 10:40 |
* bshum |
makes an adjustment to the query |
| 10:40 |
bshum |
Since he realizes current_shelf_lib = 22 doesn't mean the same thing in his system |
| 10:41 |
Dyrcona |
bshum: Try my database and use current_shelf_lib = 17, pretty much guaranteed to blow up at our busiest library. :) |
| 10:42 |
bshum |
I still got a return about 2533 ms |
| 10:42 |
bshum |
So 10 times faster |
| 10:42 |
bshum |
Chose our largest library |
| 10:42 |
csharp |
bshum: my current experiment is deleting (aka, "aging") most of the hold_request table on a test server - gonna see if that helps. |
| 10:43 |
bshum |
One of our busiest ILL libs, got 2977 ms |
| 10:43 |
bshum |
So yeah |
| 10:43 |
bshum |
The shape of the query is different |
| 10:44 |
Dyrcona |
Speaking of slow queries.... |
| 10:45 |
Dyrcona |
bshum and berick do you think that lp 1479953 should be backported to 2.8 and 2.7 as a bug fix? |
| 10:45 |
pinesol_green |
Launchpad bug 1479953 in Evergreen "Deleting queues containing many records is slow, can time out" (affected: 2, heat: 10) [Undecided,New] https://launchpad.net/bugs/1479953 |
| 10:46 |
Dyrcona |
That's what I'm trying to write the pgtap test for. |
| 10:46 |
bshum |
Dyrcona: Remind me what happens if you try to create an index where one already exists? |
| 10:46 |
Dyrcona |
The create index statement dies. |
| 10:47 |
Dyrcona |
But it might succeed if the names are different. |
| 11:09 |
berick |
bshum: arg, feel bad I caused a problem I still don't understand |
| 11:15 |
bshum |
berick: It's okay, I'm not sure I will ever fully understand it. |
| 11:21 |
bshum |
berick: When I can think through everything a bit more, I'll try making some changes to that release_process wiki page on how the i18n bits happen |
| 11:22 |
Dyrcona |
Hmm. Should a commit adding a pgtap test and simply renaming indexes from the previous commit get another sign off? |
| 11:22 |
|
kbutler joined #evergreen |
| 11:22 |
berick |
bshum: k. let me know if I can help |
| 11:24 |
bshum |
berick: Looking back in the git history, I can see that changes for "po files" and "newpot" occurred as separate commits. |
| 11:39 |
bshum |
So yeah, every time we update the pot's in master, it'll setup new strings needing translation in LP |
| 11:40 |
bshum |
And then as people translate them in LP, it gets pushed to dbs' branch |
| 11:40 |
bshum |
Which we then pull back in when we run the updates_pofiles script |
| 11:46 |
pinesol_green |
[evergreen|Jeff Davis] LP#1479953: Add indexes to vqbr foreign key references - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=679578d> |
| 11:46 |
pinesol_green |
[evergreen|Jason Stephenson] LP#1479953: Rename indexes to *_idx and add pgTAP test. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=57d756f> |
| 11:46 |
pinesol_green |
[evergreen|Jason Stephenson] LP#1479953: Stamping Upgrade Script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=768680b> |
| 11:47 |
bshum |
jeffdavis++ Dyrcona++ |
| 11:47 |
Dyrcona |
kmlussier++ # she tested it, too. |
| 11:48 |
bshum |
berick: I'm going to forward port your 2.8 translation changes to master so that the Czechs have something to start working with. |
| 11:48 |
berick |
bshum++ |
| 11:51 |
|
bmills joined #evergreen |
| 14:24 |
yboston |
OK |
| 14:25 |
yboston |
#action kmlussier will complete the marc stream importer work and check on the status of the RDA docs |
| 14:25 |
yboston |
#info 3) remingtron will send out an email to the Dig list anouncing that a new file extension will be used for AsciiDoc files |
| 14:25 |
remingtron |
I was made aware of a possible problem with the way git tracks history when a file name changes. So I want to test that before any more public announcements. |
| 14:25 |
yboston |
interesting |
| 14:26 |
yboston |
I understood that it usually catches name changes |
| 14:26 |
remingtron |
don't want to mess up git history too much, especially for a non-essential change |
| 14:30 |
Stompro |
I'll do it in a few minutes, no need for an action item... |
| 14:30 |
yboston |
anything else on this issue/topic before me move on? |
| 14:31 |
remingtron |
Stompro: you're that much more ahead on next meeting :) |
| 14:31 |
yboston |
moving on |
| 14:31 |
yboston |
#info 4) remingtron will begin testing use of and conversion to the .adoc extension |
| 14:32 |
yboston |
is there more to say about this? |
| 14:32 |
remingtron |
not yet, I'll keep working on it |
| 14:32 |
yboston |
no problem at all |
| 14:32 |
yboston |
remingtron++ |
| 15:28 |
csharp |
kmlussier: yboston learned that at Berklee College of Music :-) |
| 15:28 |
yboston |
1.25 |
| 15:28 |
kmlussier |
csharp++ |
| 15:29 |
csharp |
okay, so for the logs, I did a giant purge of old hold requests and that seems to have fixed the Clear Holds Shelf checkin modifier on our test server |
| 15:30 |
csharp |
now to figure out how to do the same on production without scheduling a several-hours-long downtime |
| 15:33 |
Dyrcona |
csharp: What did you do to purge the old holds? |
| 15:33 |
dbs |
yboston++ |
| 15:35 |
|
rlefaive joined #evergreen |
| 16:10 |
|
Dyrcona joined #evergreen |
| 16:34 |
berick |
haha, george_duimovich++ |
| 16:42 |
|
bmills joined #evergreen |
| 16:52 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 16:57 |
Dyrcona |
Does the live test do a fresh install and run tests? |
| 16:58 |
Dyrcona |
Does it run pgtap as well as perl tests? |
| 17:06 |
|
mmorgan left #evergreen |
| 18:07 |
|
bmills joined #evergreen |
| 18:10 |
|
jonadab_znc joined #evergreen |
| 00:07 |
|
bshum joined #evergreen |
| 00:07 |
pinesol_green |
All hail the supreme potentate, bshum has arrived! |
| 00:09 |
|
kmlussier joined #evergreen |
| 00:11 |
|
mceraso joined #evergreen |
| 01:58 |
|
jonadab_znc joined #evergreen |
| 02:12 |
|
gsams joined #evergreen |
| 04:54 |
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 |
|
rlefaive joined #evergreen |
| 07:43 |
|
mrpeters joined #evergreen |
| 07:46 |
|
rlefaive joined #evergreen |
| 11:44 |
Dyrcona |
mrpeters: I have many custom git branches. |
| 11:44 |
mrpeters |
i meant for websockets |
| 11:44 |
Dyrcona |
websockets doesn't take that long on the OpenSRF side. |
| 11:44 |
mrpeters |
from my testing so far, i can do a hand install of opensrf/evergreen |
| 11:45 |
mrpeters |
and then run the debs to install websockets, bower, and grunt |
| 11:47 |
Dyrcona |
I haven't gotten to the Evergreen bit, yet. I think I might just adjust my build and setup scripts to do those steps for me. |
| 11:47 |
Dyrcona |
Think I'll get something to eat. |
| 11:53 |
terran |
Does anyone have a moment to help me with a fieldmapper question? I'm trying to figure out how to get to acq lineitem_detail info and I can't get the syntax right... |
| 13:19 |
Dyrcona |
mmorgan++ jboyer-isl++ |
| 13:19 |
Dyrcona |
Anyway, think I'll try the master branch of node.js. |
| 13:19 |
* Dyrcona |
is crazy like that. |
| 13:20 |
bshum |
Dyrcona: I think I've only tested with the version specified. But berick experimented with older versions of nodejs too |
| 13:20 |
bshum |
http://irc.evergreen-ils.org/evergreen/2014-11-05#i_135615 |
| 13:20 |
bshum |
The one that comes packaged with trusty was 0.10.25 |
| 13:21 |
Dyrcona |
OK. |
| 13:22 |
Dyrcona |
So, I could just install the package, then.... |
| 13:22 |
bshum |
In theory, yes. |
| 13:22 |
bshum |
Not sure where berick left that one. |
| 13:22 |
Dyrcona |
I know I've checked out tag 0.10.34 and used it. |
| 13:22 |
Dyrcona |
I'm lazy and thought I'd just give the master branch a whirl. :) |
| 13:23 |
* Dyrcona |
has spent more time talking/thinking about it than it would actually take to test...so much for lazy. :) |
| 13:23 |
berick |
Makefile.ubuntu-trusty installs the nodejs package |
| 13:23 |
berick |
it should do everything you need |
| 13:24 |
Dyrcona |
berick: It doesn't appear to do that. |
| 13:27 |
terran |
berick: mmorgan: I'm still getting no results - I also tried connecting to distribution_formulas in case I was trying to pull from the wrong source |
| 13:27 |
Dyrcona |
ok, I'll just run makefile.install again. |
| 13:29 |
Dyrcona |
I suppose the node stuff will move when the web staff client is mainstream, he said rhetorically. |
| 13:29 |
berick |
oh, and to clarify, the installer handles node and npm. installing the node packages and bower deps is still done by hand. |
| 13:30 |
berick |
starting with "== Building, Testing, Minification ==" from /Open-ILS/web/js/ui/default/staff/README.install |
| 13:30 |
|
rlefaive joined #evergreen |
| 13:31 |
Dyrcona |
Right. It looks like node, npm, and bower get installed. |
| 13:31 |
Dyrcona |
And, yeah, was gonna say looks like that is where to start. |
| 14:38 |
terran |
mmorgan: thanks for the moral support! |
| 14:39 |
Dyrcona |
kmlussier: Evergreen should be running on my dev vm with the web staff client and the latest branches you requested. |
| 14:39 |
kmlussier |
Dyrcona++ Thank you! |
| 14:39 |
Dyrcona |
I haven't had a chance to test it, yet, myself. |
| 14:42 |
bshum |
Well the upgrade worked. But non of the network adapters are functioning. Still it didn't completely blow up at least. |
| 14:43 |
* bshum |
continues his adventures |
| 14:56 |
|
jwoodard joined #evergreen |
| 15:14 |
gmcharlt |
yes |
| 15:14 |
ldw |
#action gmcharlt to organize webstaff client hacking day in September |
| 15:14 |
yboston |
ldw++ |
| 15:14 |
ldw |
#info jeff will look into removing old self check interface. |
| 15:15 |
|
rlefaive joined #evergreen |
| 15:16 |
ldw |
#action ldw will follow up with jeff about removing old self check interface status |
| 15:16 |
ldw |
#info jeff will look at removing old JSPAC code. |
| 15:17 |
ldw |
#action ldw will follow up with jeff about removing old JSPAC code status |
| 15:17 |
ldw |
#info dbwells will hopefully write more neg balances tests and push whatever he has ready on July 10 |
| 15:18 |
dbwells |
they done got wrote, mostly by remingtron |
| 15:18 |
Dyrcona |
That one is done. |
| 15:18 |
ldw |
#info dbwells done got wrote'em |
| 15:19 |
Dyrcona |
#info remingtron, too. |
| 15:19 |
berick |
heh |
| 15:19 |
dbwells |
though, apparently nobody actually tried to /run/ them, since the tests immediately failed after getting pushed in (due to a missing setup file) |
| 15:19 |
gmcharlt |
dbwells: something that had existed in your setup but missed being committed? |
| 15:19 |
dbwells |
gmcharlt: yes |
| 15:20 |
gmcharlt |
thought so |
| 15:20 |
Dyrcona |
Well, that's partly 'cause I didn't get to my part. |
| 15:20 |
ldw |
Is there anything else that needs doing on this item? |
| 15:21 |
kmlussier |
I don't think so |
| 15:21 |
ldw |
#info kmlussier to complete her testing on the negative balance branch by July 8 |
| 15:21 |
kmlussier |
#info kmlussier's negative balance testing is complete. Remaining issues have been reported in bug 1479107 and bug 1479110 |
| 15:21 |
pinesol_green |
Launchpad bug 1479107 in Evergreen "Replace manual void option with an "adjust to zero" option" (affected: 1, heat: 6) [Medium,New] https://launchpad.net/bugs/1479107 |
| 15:21 |
pinesol_green |
Launchpad bug 1479110 in Evergreen "Negative balance settings used in combination with one another should interact differently" (affected: 1, heat: 6) [Medium,New] https://launchpad.net/bugs/1479110 |
| 15:22 |
ldw |
#info Dyrcona will follow up with negative balance branch after July 10. |
| 15:23 |
ldw |
did this discussion start? |
| 15:23 |
Dyrcona |
No, it hasn't. |
| 15:24 |
ldw |
#action ldw will follow up with jeff on merge vs cherry-pick discussion |
| 15:24 |
dbwells |
Perhaps on test writing day we can get some more eyeballs on the neg. balance tests. They do the job, but some parts are a little funky, and may need some more thoughts about best practices. |
| 15:24 |
ldw |
#action ldw will looking into integrating neg. balance tests on test writing day |
| 15:24 |
ldw |
#info : |
| 15:25 |
ldw |
#info : |
| 15:25 |
ldw |
#info yboston to followup with ldw about a testing day. |
| 15:25 |
ldw |
done |
| 15:25 |
ldw |
#info bshum to work with berick and others on crafting more information about release maintaining and schedules |
| 15:26 |
berick |
no such crafting has occurred that I know of |
| 15:26 |
ldw |
berick: are you still able to work on this with bshum? |
| 15:26 |
berick |
ldw: yes |
| 15:42 |
kmlussier |
They both have different objectives. One clears the negative balance off the record. The other adjusts a bill so that the balance is zero. |
| 15:42 |
berick |
ah, ok |
| 15:42 |
berick |
nevermind, then |
| 15:43 |
dbwells |
I would prefer to see the alpha released as-is, rather than rush/delay things. Unless we feel like there is nothing else worth testing in the alpha. |
| 15:43 |
berick |
raise your hand if you will install the alpha |
| 15:43 |
kmlussier |
Well, I install master on a regular basis, but I don't need an alpha release to do so. :) |
| 15:43 |
Dyrcona |
I already have, basically. :) |
| 15:46 |
* berick |
chuckles |
| 15:46 |
ldw |
#info Dyrcona protests an alpha action item ;P |
| 15:46 |
miker |
Dyrcona: thougths on pulling in the sprint2 branch at or around alpha time? |
| 15:47 |
Dyrcona |
miker: Well is sprint2 ready for testing or still work in progress? |
| 15:47 |
miker |
today, WIP, but we're closing it on it |
| 15:47 |
|
jwoodard joined #evergreen |
| 15:47 |
miker |
and, tbh, I think any working code should go in regardless of sprint boundary ... but, that's just my opinion |
| 15:51 |
* berick |
would like to see it merged in a lot more frequently |
| 15:51 |
ldw |
#action Dyrcona to investigate sprint2's integration with an alpha release |
| 15:52 |
* dbwells |
seconds more frequent merges |
| 15:52 |
bshum |
I've been testing sprint2 merges during my last two system builds with recent master. |
| 15:52 |
bshum |
It's not too crazy looking to me anyways. |
| 15:52 |
* bshum |
would say more but typing on a phone isn't so easy. |
| 15:53 |
* bshum |
will chat further with Dyrcona on that lookover. |
| 15:53 |
|
ericar_ joined #evergreen |
| 15:55 |
ldw |
Dyrcona: will you set a date for a release/skip an alpha release once you have examined the possibility of a sprint2 merge? |
| 15:55 |
Dyrcona |
Yes. |
| 15:57 |
Bmagic |
#info Bmagic = Blake GH, MOBIUS |
| 15:57 |
kmlussier |
I added that topic to the agenda because the status of the QA proposal seems to still be in limbo. |
| 15:58 |
kmlussier |
I added the proposed guidelines to the contributing page after gmcharlt gave it the okay in that thread, but there were concerns raised shortly thereafter. |
| 15:58 |
ldw |
My concerns are not necessary. Your comment about a developer being able to state why a test is infeasible invalidates my concerns. |
| 15:59 |
dbwells |
I only have a couple minutes before I need to run, but would like more feedback on my proposal for multiple sign-offs in lieu of the "it's too hard to write tests" clause. |
| 15:59 |
ldw |
dbwells: I like that idea. |
| 15:59 |
dbwells |
I think it might keep things a little more objective and self-correcting. |
| 16:00 |
gmcharlt |
well, I think I would like to push back a bit on the notion of sign-offs as being "objective", per se |
| 16:00 |
ldw |
Would it be necessary for us to add a negative sign-off? Incase a committer feels strongly about a test being needed? |
| 16:01 |
gmcharlt |
which is not to dismiss the proposal of trading additional review in place of a statement that automated tests can't be written for a given patch |
| 16:01 |
Dyrcona |
ldw: That's typically done in a comment on the LP bug. |
| 16:02 |
dbwells |
Certainly not all signoffs are created equal, but more-is-better should generally hold true across the aggregate. |
| 16:02 |
gmcharlt |
also, in my view a statement to the effect that a test is not infeasiable is not meant to be a flat assertion |
| 16:02 |
gmcharlt |
rather, a reasoned argument |
| 16:03 |
gmcharlt |
that said, I'm not wedded that wording |
| 16:04 |
gmcharlt |
but I am in disfavor of frequent use of infeasibility statements OR multiple signoffs purely as a mechanism for folks to avoid writing unit tests |
| 16:04 |
gmcharlt |
or to put it another way |
| 16:04 |
gmcharlt |
- more tests: generally good |
| 16:04 |
gmcharlt |
- seeking out additional reviewers: almost always good |
| 16:04 |
gmcharlt |
- not writing tests for new code or significant bugfixes - AVOID! AVOID! |
| 16:05 |
* kmlussier |
is in agreement with gmcharlt |
| 16:06 |
ldw |
do we need to have a +1 type vote on this issue? |
| 16:07 |
gmcharlt |
ldw: dbwells: give me one moment to propose a wording change |
| 16:17 |
pinesol_green |
Yes (10): kmlussier, jlitrell, phasefx, berick, dbwells, Dyrcona, ldw, terran, gmcharlt, dbs |
| 16:17 |
ldw |
#topic Code sanity check appreciated for https://bugs.launchpad.net/evergreen/+bug/1468422 |
| 16:17 |
pinesol_green |
Launchpad bug 1468422 in Evergreen "Improve Password Management and Authentication" (affected: 1, heat: 258) [Undecided,New] |
| 16:18 |
berick |
oh, that's me |
| 16:19 |
berick |
so, want to keep some momentum, but also want to avoid doing more work until i get some nod that it's heading in the right direction |
| 16:19 |
berick |
so if anyone can eye/test/etc. i'd appreciate it |
| 16:19 |
berick |
that is all |
| 16:19 |
dbwells |
berick++ # glad to see this moving forward |
| 16:20 |
kmlussier |
berick++ |
| 16:21 |
dbwells |
berick: my C chops are basically non-existant, so my eyeballs won't help, but I'll plan to do some basic explosion testing. |
| 16:21 |
berick |
dbwells: well, the DB changes are my main concern |
| 16:21 |
dbwells |
ldw: action me up, good sir! |
| 16:22 |
dbwells |
berick: ah, ok |
| 00:26 |
|
_robbat2|irssi joined #evergreen |
| 04:28 |
|
sarabee joined #evergreen |
| 05:15 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:48 |
csharp |
@praise sys admins |
| 07:48 |
* pinesol_green |
sys admins is kind and patient to newbies |
| 08:05 |
|
maryj joined #evergreen |
| 12:30 |
jboyer-isl |
Oops. I was wrong; no regex, but a substr($msg,-9,2), so basically the same thing. I'm not familiar enough with SIPServer to know where to start looking to fix that |
| 12:30 |
jboyer-isl |
jeff: count the number of digits after the AY. |
| 12:31 |
jboyer-isl |
Time to lunch and visit some GenCon'ers. |
| 12:39 |
jeff |
still not sure why on a test instance i get a 96 (retransmit) and on prod i get dead air. might be a secondary bug in multiplex. uncertain yet. |
| 13:45 |
jeff |
but yes, any SIP message that is at least 11 characters and whose last 9 characters start with AY will be passed through verify_checksum |
| 14:27 |
|
akilsdonk_ joined #evergreen |
| 14:32 |
|
Shae_ joined #evergreen |
| 14:59 |
kmlussier |
I'm just getting a chance now to wish a very Happy SysAdmin Day to all the awesome Evergreen Sys Admins in here! |
| 15:39 |
jeff |
apparently additional extensions / internal documentation adds a few others. |
| 15:40 |
jeff |
the argument for having them backed by config is getting stronger in my head, but i'm not sure where i think that config belongs. |
| 15:40 |
jeff |
the first step will be to treat 01 and 02 the same |
| 16:58 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:04 |
|
mmorgan left #evergreen |
| 17:49 |
|
hopkinsju joined #evergreen |
| 17:51 |
hopkinsju |
Using vandelay to import some record we got back from backstage. They had RDA fields added, cleaned up, etc. Odd thing is that when I import with a 901c match set, I get 2 matches per record. |
| 18:05 |
berick |
using a 901c match set just adds another match on the same field |
| 18:05 |
berick |
if you choose "exact match only" (or whatever it's called) the built-in 901c matching should do what you need, no match set needed |
| 18:05 |
hopkinsju |
Well that's bizarre. This is a *ahem* newly acquired system for us. It came with a 901c matchset. I thought that was standard. |
| 18:06 |
berick |
just checked, there's not one in my test DB |
| 18:06 |
hopkinsju |
Oh yeah, weird. I never noticed that Missouri Evergreen doesn't have a 901c matchset. KSL had one, and I just selected it, because it was there. |
| 18:06 |
berick |
ther are merge profiles using 901c, but no match set |
| 18:06 |
hopkinsju |
Cool, well, that clears things up then. |
| 13:35 |
Dyrcona |
I never put anything on the prepaid bit, so don't use it, but that is a handy tip. |
| 13:35 |
jeff |
if everything else is working correctly, mine fails with SERV NOT ALLOWED |
| 13:35 |
Dyrcona |
And, since Dell.com is flaking out on me, I'll have to find something else to do. |
| 13:36 |
jeff |
which saves me from needing to 1) re-bill my patron / test patron, 2) void the charge before settlement or 3) remove/zero the payment in the ILS if things DO test well. |
| 13:36 |
jeff |
Once that part works, I usually do a $1.23 or similar payment and consider it the cost of knowing things are working. |
| 13:37 |
jeff |
(er, to be clear i'd usually have to do 1, 2, AND 3 above, not OR) |
| 13:39 |
|
collum joined #evergreen |
| 13:40 |
Dyrcona |
And, I don't see how the 408 could be my fault. I'm not on the wireless at the moment. :) |
| 13:48 |
* Dyrcona |
mumbles something about "magic beans." |
| 13:48 |
jboyer-isl |
re: pgTAP, I'm assuming no comment means "sure, do that" and I'll be dropping the noise from my upcoming tests. :) |
| 13:48 |
bshum |
@dessert add Lemon Cupcakes |
| 13:48 |
pinesol_green |
bshum: The operation succeeded. Dessert #38 added. |
| 13:49 |
bshum |
@dessert add Key Lime Cheesecake |
| 13:49 |
phasefx |
jboyer-isl: I think the live tester is using pg_prove, but psql should work just as well I thought |
| 13:50 |
csharp |
@dessert add A Moon Pie and some RC Cola |
| 13:50 |
pinesol_green |
csharp: The operation succeeded. Dessert #40 added. |
| 13:51 |
jboyer-isl |
phasefx: The README in the tests dir also only talks about pg_prove, so I figured that's what would see the most use. |
| 13:52 |
phasefx |
jboyer-isl: cool deal |
| 13:53 |
phasefx |
jboyer-isl: looks like psql can run them, but pg_prove actually parses and summarizes the test results |
| 13:54 |
phasefx |
but does that require the boilerplate you mentioned? |
| 13:55 |
phasefx |
oh I see.. those psets make it look nice if using psql |
| 13:56 |
phasefx |
could put that stuff into a common file and \i it |
| 13:56 |
kmlussier |
@dessert 40 csharp |
| 13:56 |
* pinesol_green |
grabs some A Moon Pie and some RC Cola for csharp |
| 13:59 |
jboyer-isl |
phasefx: yeah, the boilerplate is just for formatting, pg_prove sets all of that ahead of time. I was hoping to just say "we suggest using pg_prove, so do that" and then we can ignore all of that, simple tests could have 4 necessary lines vs a dozen lines of setup + 4 lines of work. (line # are estimates, of course) |
| 13:59 |
phasefx |
sounds good to me |
| 14:01 |
bshum |
@dessert 40 csharp |
| 14:01 |
* pinesol_green |
grabs some Moon Pie and some RC Cola for csharp |
