| 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? |
| 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. |
| 02:16 |
|
eady joined #evergreen |
| 05:00 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:03 |
|
gsams joined #evergreen |
| 07:42 |
|
ericar joined #evergreen |
| 07:47 |
|
graced joined #evergreen |
| 07:58 |
|
mrpeters joined #evergreen |
| 08:11 |
|
Dyrcona joined #evergreen |
| 08:21 |
jeff |
hah. thought i was seeing something Really Odd. |
| 08:22 |
jeff |
enabled SIP msg64_hold_datatype = barcode, did some testing with (a possibly hacked up copy of) tsbere's PHP SIP2 client. requested Hold and UnavailableHolds summary types in a patron information message. |
| 08:23 |
jeff |
the only item barcodes i was seeing in the response were not items i had holds on... but they were items that i would not be able to renew because someone ELSE had a hold on them. |
| 08:23 |
jeff |
This seemed like a Really Odd failure method until I realized that something was amiss and that the details I was getting were overdue items (which just so happened to be overdue because they had not been able to be renewed, etc) |
| 08:24 |
jeff |
Anyway, all better. |
| 08:24 |
jeff |
And if I didn't break it in the first place, I'll pass on a patch to tsbere. :-) |
| 08:36 |
|
mmorgan joined #evergreen |
| 08:41 |
|
mrpeters joined #evergreen |
| 08:49 |
|
akilsdonk joined #evergreen |
| 12:37 |
jeff |
Yup. |
| 12:37 |
jeff |
bug 1013263 |
| 12:37 |
pinesol_green |
Launchpad bug 1013263 in Evergreen "Support SIP payment type 02 - "credit card"" (affected: 1, heat: 6) [Wishlist,Fix released] https://launchpad.net/bugs/1013263 |
| 12:39 |
jeff |
i wrote, you tested and signed off, lebbeous committed since neither you nor i could push to master at that point in time. :-) |
| 12:39 |
jeff |
I seem to recall it was only a few lines of code. |
| 12:57 |
Dyrcona |
Oh, three years ago... No wonder I don't remember. :) |
| 13:00 |
kmlussier |
Funny...I tend to recall bugs from 3 years ago better than I remember ones from a month ago. |
| 13:04 |
jboyer-isl |
So, about pgTAP tests; are we assuming the use of pg_prove, or should test scripts include all of the \pset and \set boilerplate? Only pg_prove is referenced in the documentation but most of our tests have all of the boilerplate, so... |
| 13:05 |
jboyer-isl |
I'd like to dump the lines we don't need, unless there was a decision that we do need them. |
| 13:06 |
|
Christineb joined #evergreen |
| 13:10 |
RoganH |
I need to invent a SIP wheel of doom so I can spin it each day and see what I think SIP will do today. |
| 13:15 |
jboyer-isl |
RoganH: My favorite experience was when a PC time management company wrote their own SIP communication library that would recognize field codes ANYWHERE. Made capitalized addresses much more "exciting" because it would also crash when it didn't understand what it was getting. |
| 13:19 |
|
gsams joined #evergreen |
| 13:20 |
tsbere |
They insisted that I couldn't use a repeating field for what I was using it for because the standard didn't *do* that. Then I pointed them at several in the standards doc they were using... |
| 13:23 |
jboyer-isl |
Although, come to think of it my toy code didn't take that into account properly either. At least I wasn't trying to charge anyone to use it. |
| 13:24 |
jeff |
so: tips of the day... a basic AAA membership card behaves enough like a Visa card for smoke testing credit card payments at a self-pay kiosk |
| 13:24 |
miker |
jeff: nice |
| 13:24 |
jeff |
and tip 2: if you have someone remoting into a kiosk to work on it and you want the kiosk obviously out of service with screen obscured, grab your nearest clean library T-shirt |
| 13:25 |
jboyer-isl |
jeff++ # lifehacks |
| 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 |
| 09:17 |
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 |
| 09:19 |
kmlussier |
For bug 1479110, I would be curious to know if others agree with our assessment of how the settings should interact with each other. |
| 09:19 |
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 |
| 09:24 |
dbwells |
kmlussier: If we model it straight after the void interface code, it should be pretty simple. I don't think it is worth delaying the alpha for, though. I think the alpha is a litmus test to see if we're way off track, which means undone stuff is a given. |
| 09:25 |
dbwells |
kmlussier: I could add with a high degree of confidence that it should take less time than the original bug. |
| 09:25 |
* dbwells |
ducks |
| 09:33 |
jeff |
and... now you've jinxed it. |
| 09:35 |
|
yboston joined #evergreen |
| 09:58 |
kmlussier |
I'm inclined to agree with Dyrcona on the alpha delay if it's something that can be done in a reasonable amount of time, just because it would be nice to have it in as good shape as possible for the litmus test. |
| 09:59 |
kmlussier |
But, as bshum said, Dyrcona is our fearless leader. |
| 10:01 |
kmlussier |
Of course, part of me is also thinking of all the documentation I have to write and wanting to get started on it as soon as possible. |
| 10:02 |
Dyrcona |
Well, you could get started on the documentation. |
| 10:03 |
Dyrcona |
I find it is sometimes better to write the documentation first, and then write the code so it works according to the documentation. ;) |
| 10:03 |
kmlussier |
Actually, that was an idea raised at the Google doc sprint. Maybe I should start doing it for all of MassLNC's development projects. :) |
| 10:31 |
jeff |
mrpeters: check the value of ingest.reingest.force_on_same_marc in config.internal_flag? |
| 10:32 |
jeff |
mrpeters: still, 12 hours is a bit much to reingest 6k bres unless you're on really underpowered hardware. |
| 10:32 |
jboyer-isl |
mrpeters: Even if they are reingested that sounds like an enormous amount of time. Are things otherwise ok with this installation? Otherwise, jeff is right, that flag being set should be the only reason for a reingest if you don't touch the marc field. |
| 10:33 |
mrpeters |
yeah, its a test server, but comparable hardware to production |
| 10:33 |
jboyer-isl |
Stock postgresql.conf or edited? |
| 10:33 |
jeff |
mrpeters: did you do the updates in individual transactions? if not, is there any other activity on the system? have you checked for locking issues? |
| 10:33 |
jeff |
mrpeters: what does postgres think is happening with that query, and any other queries? |
| 10:40 |
mrpeters |
i will need to reingest eventually, because i will also be changing the marc with REGEXP_REPLACE but i hadn't even gotten to that point in the process yet, but, now i see a lot of hung up crap in the db that may take care of things |
| 10:41 |
Dyrcona |
mrpeters: I'd suggest possibly doing whatever you're doing via Perl. I find it much easier to manipulate MARC in Perl than directly in the database. |
| 10:41 |
|
jboyer-isl joined #evergreen |
| 10:41 |
phasefx |
didn't see it in channel this morning (net-split?), but there's a new failure at http://testing.evergreen-ils.org/~live/ re: perl live tests for negative balances |
| 10:42 |
mrpeters |
gotta stick with what i know, for now, Dyrcona |
| 10:42 |
Dyrcona |
pfft. I'm always keen to learn new things. :) |
| 10:43 |
Dyrcona |
But, I get it if you don't think you have the time. |
| 10:45 |
mrpeters |
yeah, time is the issue...and it's just adding a 856$9 to existing records, and regex_replace has never failed me in the past |
| 10:45 |
jeff |
Dyrcona: with ingest.reingest.force_on_same_marc set to true, UPDATE biblio.record_entry SET id = id WHERE id = 1; will cause a reingest of bre id 1. |
| 10:45 |
dbwells |
phasefx: thanks. Looks like two problems. One, do_checkin_override didn't make it into TestUtils, so it was probably missing from the branch. Two, we need to decide how to handle the pre-test SQL. I'll push something in for #1, but am not sure about #2. |
| 10:46 |
mrpeters |
turning off that flag will be key, i think -- i can then build a script to reingest just the records that changed |
| 10:46 |
mrpeters |
system isnt in use, so no harm in having that flag off while i update the few bibs |
| 10:47 |
jboyer-isl |
mrpeters: that flag should be set to false already, you really don't want edits that don't touch the marc to cause a full reingest all the time. You don't have to do anything special to cause a reingest of records whose marc you're editing. |
| 10:48 |
mrpeters |
although, i think its better than the old production server |
| 10:49 |
mrpeters |
gonna give it a whirl on the new hardware |
| 10:49 |
Dyrcona |
jeff: I guess I imagined the trigger checked more than it does. :) |
| 10:55 |
pinesol_green |
[evergreen|Dan Wells] LP 1198465: Add missing util function for tests - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=437550e> |
| 11:11 |
|
Dyrcona1 joined #evergreen |
| 11:15 |
Dyrcona |
wifi-- |
| 11:35 |
|
bmills joined #evergreen |
| 11:36 |
kmlussier |
So I don't know if we should wait to merge them. |
| 11:39 |
Dyrcona |
We probably should wait. |
| 11:45 |
|
Christineb joined #evergreen |
| 11:55 |
pinesol_green |
[evergreen|Dan Wells] LP 1198465: Move negative balance test xacts into sample data - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3a6c040> |
| 11:55 |
pinesol_green |
[evergreen|Dan Wells] LP 1198465: Load negative balance test transactions in load_all.sql - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b842239> |
| 11:55 |
|
bmills joined #evergreen |
| 11:56 |
dbwells |
tests should be happier now; we'll see! |
| 11:57 |
jeff |
dbwells++ |
| 11:58 |
kmlussier |
dbwells++ |
| 12:56 |
Dyrcona |
dbwells++ |
| 14:37 |
kmlussier |
:( |
| 14:53 |
|
vlewis_ joined #evergreen |
| 14:56 |
|
vlewis__ joined #evergreen |
| 15:09 |
mrpeters |
follow up from earlier Re: bib source updates -- ran fine once i cleared out some queries that had hung in this particular test server -- ran in a matter of a couple minutes like I would have expected. |
| 15:11 |
Dyrcona |
mrpeters++ |
| 15:15 |
mrpeters |
for the logs, in case anyone ever needs to add 856$9 tags to e-resource bib records, this works nicely |
| 15:15 |
mrpeters |
UPDATE biblio.record_entry SET marc = REGEXP_REPLACE(marc, $$(<datafield tag="856" ind1="." ind2=".">)(.*?)(</datafield>)$$, $$\1<subfield code="9">SHORTNAME</subfield>\2</datafield>$$, 'g') WHERE id=foo; |
| 16:36 |
* jeffdavis |
goes ahead and does both |
| 16:42 |
kmlussier |
Sorry, I was working on something else. The settings go changed sometime around when comment 28 was added to the bug (see 3a). https://bugs.launchpad.net/evergreen/+bug/1198465/comments/28 |
| 16:42 |
pinesol_green |
Launchpad bug 1198465 in Evergreen "Support for Conditional Negative Balances" (affected: 17, heat: 80) [Wishlist,Fix committed] |
| 16:43 |
kmlussier |
But I also recall only setting the interval in my original testing. |
| 16:43 |
kmlussier |
I'm fine with whatever the community decides is more intuitive, but in discussions with the team here, there was general consensus that most people would think that, once people set prohibit to true, they would think it would be prohibited in all cases. |
| 16:45 |
kmlussier |
At the same time, in our environments, there are only a few individuals who would be allowed to touch those settings, so it's not as big of an issue as it would be if it were something most end users would be adjusting on a regular basis. |
| 16:56 |
|
vlewis joined #evergreen |
| 17:13 |
|
mmorgan left #evergreen |
| 17:17 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:18 |
dbwells |
yay |
| 17:20 |
bshum |
dbwells++ |
| 17:21 |
|
vlewis_ joined #evergreen |
| 12:07 |
gsams |
jwoodard: Turns out it was nevery turned on afterall because I was afraid it would get used without everyone knowing about it |
| 12:09 |
gsams |
kmlussier: I read the new features docs everytime a release is done and I still miss/forget features exist |
| 12:12 |
kmlussier |
gsams: One of the reasons I like working on the release notes so much is because it keeps me aware of all the new things we're getting. :) |
| 12:13 |
jwoodard |
gsams I turned it on for our library to test it out upon learning that it existed. It is a neat feature that I plan on implementing. |
| 12:13 |
kmlussier |
phasefx: I have no opinion on bug 1478299. I'm fine with your solution if you want to merge it. |
| 12:13 |
pinesol_green |
Launchpad bug 1478299 in Evergreen "Fix hold permit test" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1478299 |
| 12:14 |
jwoodard |
Our library services a large area so a feature like this is very helpful. |
| 12:14 |
kmlussier |
phasefx: Or do you need a signoff for it? |
| 12:16 |
gsams |
jwoodard: I'm going to flip the switch for the whole group |
| 12:41 |
gsams |
jwoodard: I turned your link on for the registration |
| 12:58 |
jwoodard |
gsams: Thank you! I shot you an email about adding stuff to the page. |
| 12:59 |
bshum |
kmlussier: phasefx: I'm leaning towards his solution being generally more predictable too. I wasn't sure how the copy was chosen, since the IDs are generated somewhat randomly? |
| 13:02 |
kmlussier |
bshum: OK, well, like I said, I'm fine with it if somebody wants to merge it so that our tests can be happy again. |
| 13:14 |
|
akilsdonk_ joined #evergreen |
| 13:30 |
bshum |
~search_path |
| 13:30 |
pinesol_green |
After restoring a database, make sure to reset the search_path accordingly with something like: alter database unpredicable_haxxors_go_away set search_path = evergreen, public, pg_catalog; |
| 14:34 |
bshum |
Where _bott_ solved the null card problem a different way by having that method skip over any deleted users. |
| 14:34 |
bshum |
I think we should incorporate both fixes for a complete solution. |
| 14:34 |
bshum |
I'll try and mix-match everything into one LP with a proper pullrequest branch in a few moments. |
| 14:38 |
pinesol_green |
[evergreen|Jason Etheridge] LP#1478299: fix location for asset used in test - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=001bb57> |
| 14:45 |
bshum |
_bott_++ |
| 15:04 |
|
ericar_ joined #evergreen |
| 15:08 |
|
jlitrell joined #evergreen |
| 16:26 |
jboyer-isl |
:Q |
| 16:27 |
|
mrpeters joined #evergreen |
| 16:27 |
bshum |
Calling 0921 |
| 16:34 |
pinesol_green |
Showing latest 5 of 18 commits to Evergreen... |
| 16:34 |
pinesol_green |
[evergreen|Remington Steed] LP 1198465: Initial tests for conditional negative balances - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=336f8a6> |
| 16:34 |
pinesol_green |
[evergreen|Dan Wells] LP 1198465: Make conditional negative balances test sql re-runnable - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=14836cc> |
| 16:34 |
pinesol_green |
[evergreen|Remington Steed] LP 1198465: More tests for conditional negative balances - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cde1573> |
| 16:35 |
pinesol_green |
[evergreen|Kathy Lussier] LP 1198465: Adapt some language in the negative balance branch - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d5ee86b> |
| 16:35 |
pinesol_green |
[evergreen|Ben Shum] LP#1198465: Stamping upgrade script for conditional negative balance - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ea55537> |
| 16:36 |
kmlussier |
I never thought I would see the day... |
| 16:36 |
mmorgan |
Woo-hoo!!! |
| 16:37 |
* dbwells |
feels a disturbance in the Force |
| 16:38 |
kmlussier |
Dyrcona: Well, I obviously am not going to give karma to myself! :) |
| 16:38 |
mmorgan |
dbwells: ...as if millions of negative balances suddently cried out in terror and were suddenly silenced. ;-) |
| 16:39 |
dbwells |
mmorgan: that's right :) |
| 16:40 |
kmlussier |
Also, mmorgan++ for doing a fair share of the testing. |
| 16:41 |
kmlussier |
Should I file a follow-up LP bug on the manual adjustments we discussed last week? |
| 16:42 |
dbwells |
remingtron++ # he deserves a little extra, those pesky tests ended up being 1700+ lines of code (repetitive, yes, but still!) |
| 16:42 |
kmlussier |
bshum++ for writing my release note entries for me. |
| 16:43 |
kmlussier |
Looks like it's a karma party day. :) |
| 16:43 |
bshum |
remingtron++ dbwells++ Dyrcona++ kmlussier++ |
| 16:53 |
pinesol_green |
[evergreen|Ben Shum] LP#1454879: Release notes for Account Expiration Date in OPAC - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c6a5404> |
| 16:53 |
bshum |
And also, probably backport. |
| 16:53 |
bshum |
Cause it looks ready to go |
| 16:57 |
pinesol_green |
[evergreen|Mike Rylander] LP#1465385: Fix some syntax issues with make_release - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c05aeb2> |
| 17:02 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:02 |
kmlussier |
hmmm |
| 17:04 |
|
edoceo joined #evergreen |
| 17:04 |
kmlussier |
Looks like it's unrelated to new copy locations this time around. |
| 00:36 |
|
eady joined #evergreen |
| 04:38 |
bshum |
kmlussier: Going to test https://bugs.launchpad.net/evergreen/+bug/1198465 later today, got it put together on our test server. |
| 04:38 |
pinesol_green |
Launchpad bug 1198465 in Evergreen "Support for Conditional Negative Balances" (affected: 17, heat: 80) [Wishlist,Confirmed] - Assigned to Dan Wells (dbw2) |
| 04:38 |
bshum |
Just one minor note though, one of the library settings in the upgrade script has a typo in it. "overde" instead of "overdue" |
| 05:04 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:19 |
|
Bmagic_ joined #evergreen |
| 07:47 |
|
ericar joined #evergreen |
| 07:59 |
|
rjackson_isl joined #evergreen |
| 13:40 |
csharp |
hmm - having an acq issue where my "acq admin" user can't see/interact with the list of providers (Admin -> Server Administration -> Acquisitions -> Providers) |
| 13:40 |
csharp |
as admin, I'm able to see them |
| 13:41 |
kmlussier |
csharp: Has your acq admin user been able to see them in the past? |
| 13:41 |
* csharp |
continues to look in the postgres logs for clues |
| 13:41 |
csharp |
kmlussier: I don't think so |
| 13:42 |
csharp |
the user in question has all of the *_PROVIDER perms assigned at the System level, and the providers are owned by the library system in question |
| 13:42 |
csharp |
(system, not branch) |
| 13:44 |
csharp |
I can also see that the SQL queries are being performed for the providers, but they aren't displaying |
| 13:44 |
csharp |
the user passes all the permission tests I can see being performed in the logs |
| 13:44 |
kmlussier |
This reminds me of an old bug that was fixed a long time ago. |
| 13:45 |
kmlussier |
bug 731510 |
| 13:45 |
pinesol_green |
Launchpad bug 731510 in Evergreen master "Acquisitions - Unable to view providers" (affected: 2, heat: 12) [Medium,Fix released] https://launchpad.net/bugs/731510 - Assigned to Mike Rylander (mrylander) |
| 13:45 |
kmlussier |
csharp: I can't imagine it's the same thing, but if you page through the interface, do you see the providers? |
| 13:48 |
csharp |
kmlussier: nope :-( |
| 13:49 |
kmlussier |
csharp: And the library selector on that page is the same as the OU that owns the providers? Sorry to ask obvious questions. |
| 13:50 |
csharp |
yes, that's right |
| 13:51 |
csharp |
one possible clue (that could be a red herring), the JS console shows "TypeError: item is null" |
| 13:52 |
csharp |
when I look at Open-ILS/web/js/ui/default/acq/financial/view_provider.js, I see the term "item" used - I'm assuming that's what's being referred to in the JS error |
| 13:57 |
csharp |
also 'request open-ils.acq open-ils.acq.provider.org.retrieve <authtoken>' shows the expected list via srfsh |
| 13:57 |
csharp |
which is what is called by that JS library |
| 13:58 |
csharp |
again, if I'm admin, I can see everything as expected, so it *seems* like this should be perms, but I'm not seeing any messages in the logs |
| 13:59 |
csharp |
and all the perms I do see checked appear to be assigned at the appropriate levels (or I wouldn't expect the srfsh test to work) |
| 14:03 |
berick |
csharp: the JS error mentions view_provider.js specifially? |
| 14:03 |
berick |
i think that file might actually be deprecated |
| 14:04 |
berick |
Open-ILS/web/js/ui/default/conify/global/acq/provider.js is loaded by |
| 14:40 |
jeffdavis |
Is that expected behavior? If not, how would you normally expect to prevent it in a load-balanced environment? |
| 14:41 |
bshum |
berick: gmcharlt: For https://bugs.launchpad.net/evergreen/+bug/1394989, we're looking to try implementing the solution that you suggested alternative to mrpeters' patch. If it passes, should we rework that to be a proper git branch and get it submitted towards review and inclusion in a future release? |
| 14:41 |
pinesol_green |
Launchpad bug 1394989 in Evergreen "Collections API users_of_interest can crash on users with null card values" (affected: 1, heat: 6) [Low,Confirmed] - Assigned to Michael Peters (mrpeters) |
| 14:41 |
csharp |
ooh - another point of interest - the problem is *not* happening on our production server, just our acq testing server :-/ |
| 14:41 |
bshum |
mceraso's been poking around at this at Unique's behest and we just found the LP |
| 14:42 |
gmcharlt |
bshum: yes please |
| 14:43 |
mrpeters |
sorry guys, i never caught those comments |
| 14:43 |
bshum |
From the comment, I think we can just grab berick's approach and copy it in, but we'll test and see what blows up :P |
| 14:48 |
miker |
jeffdavis: that load balancing is probably expected, and you probably don't want to prevent it. if the translator is what's initiating it, it's almost certainly because of a stateful connection from the client side, which is required for several interfaces to work correctly. they have to be able to send several messages, possibly through different apache servers, to one opensrf backend. the translator knows how to coordinate that via a memcache blob |
| 14:56 |
jeffdavis |
What we are seeing is that the translator on server A sends an XMPP request to opensrf private.localhost/open-ils.pcrud_drone_server_B, and gets a 503 error in response |
| 15:01 |
miker |
ah, yeah... you'll need to set up real (if internal-only) names and addresses and cross-register services, and set up the <trusted_domains> stuff ... I'll see if there are pointer docs |
| 11:08 |
bshum |
kmlussier: Well it could be... I suppose. |
| 11:09 |
bshum |
But it seems more like a "from here forward, this is how it is" kind of new feature to me. |
| 11:09 |
kmlussier |
It feels like new feature to me too. |
| 11:09 |
* bshum |
goes back to merging branches for his test system |
| 11:15 |
|
bmills joined #evergreen |
| 11:17 |
berick |
dbs: FYI it worked w/ 2 changes total: http://pastie.org/10309986 |
| 11:18 |
* berick |
just logged in to his VM catalog w/ a salted/crypted password WOOT |
| 13:05 |
kmlussier |
And working on 2 things at the same time, which is never a good idea |
| 13:05 |
jeff |
I'm still in favor of either "Other" or "General". |
| 13:05 |
mmorgan |
Multitasking is highly overrated ;-) |
| 13:06 |
* gmcharlt |
adds "Multitasking Tax" as a billing type to kmlussier's test database ;) |
| 13:06 |
jeff |
and as a refresher, the last large conversation about this subject that i recall was in January: http://irc.evergreen-ils.org/evergreen/2015-01-08#i_148257 |
| 13:06 |
tsbere |
I don't think we should label it as "Staff" myself as that would imply nothing else ever generating them. Same with "Manual", for that matter. "Other" and "General" would work well for me. |
| 13:06 |
kmlussier |
jeff: Yeah, I revisited that when I came up with the original options. |
| 13:23 |
mrpeters |
few kinks to work out still that jeffdavis has helped me with, but man it has to be nice for the patrons once its running! |
| 13:23 |
jeffdavis |
schan wrote most of the code, I just got it over the finish line - but thanks :) |
| 13:23 |
mrpeters |
schan++++++++++++++++++++++++++ too |
| 13:23 |
* kmlussier |
considers moving overdrive-eg-opac testing up on her priority list |
| 13:24 |
mrpeters |
its pretty awesome, anyone using Overdrive should try it out |
| 13:24 |
mrpeters |
i should make a demo video |
| 13:24 |
kmlussier |
mrpeters: Did it take a lot of work to get it working? |
| 16:49 |
kmlussier |
miker: Enjoy your weekend! |
| 16:51 |
* kmlussier |
disappears in a puff of smoke too. |
| 16:51 |
mmorgan |
Have a good weekend! |
| 16:52 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 16:57 |
phasefx |
good way to end a Friday :) |
| 17:01 |
kmlussier |
phasefx: hmmm...could adding copy locations to the sample data affect the pgtap tests? |
| 17:01 |
* kmlussier |
obviously does not know how to disappear |
| 17:02 |
phasefx |
kmlussier: a lot of those live tests make use of the data, so if the data changes, the tests can break. This particular test expected a hold to be permited, but it was not based on a location.holdable flag |
| 17:07 |
|
mmorgan left #evergreen |
| 17:13 |
phasefx |
kmlussier: so the test makes use of item CONC51000640, and the copy location for that item changed from Stacks to Reserves (holdable = f) |
| 17:14 |
phasefx |
easy fix, at least |
| 17:14 |
* phasefx |
out, have a good weekend |
| 17:14 |
kmlussier |
phasefx: You too! |
| 19:23 |
|
bmills joined #evergreen |
| 19:50 |
|
bmills1 joined #evergreen |
