11:29 |
berick |
that JSON.parse() doesn't like |
11:29 |
berick |
but our old JSON parser was OK with |
11:29 |
berick |
we ended up editing the copy templates by hand to remove any spaces or excess junk |
11:30 |
gsams |
I will check into that and see if anything comes of it, thanks for the info! |
11:36 |
|
mmorgan joined #evergreen |
11:57 |
|
bmills joined #evergreen |
12:11 |
gsams |
Hmmm. It seems that the templates are not necessarily at fault but then I'm not sure what would be. |
12:18 |
gsams |
I am thinking I might just suggest reinstallation for this and hope that clears it up for her. |
12:19 |
gsams |
I had her export her templates and send them to me, testing shows that the templates work just fine elsewhere and do not have any odd characters or issues. |
12:54 |
jboyer-isl |
The state of automated vm building in Ubuntu is dire. |
12:55 |
jboyer-isl |
(unless you use Canonical's OpenStack stuff, I suppose?) |
13:01 |
Dyrcona |
jboyer-isl: I manage with vm-builder. |
09:28 |
|
maryj joined #evergreen |
09:33 |
|
yboston joined #evergreen |
09:35 |
|
bmills joined #evergreen |
09:41 |
Dyrcona |
kmlussier: I'm going to reload my dev database to test some stuff for Comcat. I need fresh data from production. |
09:41 |
Dyrcona |
<zombie>Brains!!!!!</zombie> |
09:41 |
Dyrcona |
This means my dev system will be off line for a couple of hours. |
09:47 |
kmlussier |
Dyrcona: Thanks for the heads up! |
11:09 |
bshum |
gmcharlt++ # website stuff |
11:11 |
JimT_ |
Does anyone have the browse index working for 710 tags which contain a subfield t? I think I have fixed all the author browse indexes that weren't working except for this one. Nothing I do seems to make a difference. |
11:20 |
Dyrcona |
And, aborting transits when holds are canceled is now optional in NCIPServer. |
11:20 |
Dyrcona |
Of course, I haven't tested it, yet. ;) |
11:20 |
* Dyrcona |
waits on the database reload to finish. |
11:21 |
Dyrcona |
jboyer-isl: So, I had a net removal of 156 lines of code the other day, and now a net addition of 121 lines since then. |
11:21 |
Dyrcona |
jboyer-isl: In case you're keeping score. :) |
11:25 |
* bshum |
glances at kmlussier and her probable mountain of knowledge with non-stock indexes. |
11:29 |
JimT_ |
I'm no expert and going with what the cataloger has told me should be there...710 t is a title index but supposedly the a,b,c,t,d,g,n will show in the author index as 'conference' listing. |
11:31 |
JimT_ |
...or maybe corporate?...gets mixed up in my head after a while. |
11:34 |
JimT_ |
as far as indexing...I tweak the stylesheet...and then resave my test record. |
11:35 |
|
dbwells joined #evergreen |
11:38 |
JimT_ |
The 710 t index is part of the stock indexes...it just doesn't seem to work. I'm not trying to do anything fancy...just, mostly, trying to make things work that are already defined but do not. |
11:40 |
JimT_ |
Was hoping to find someone who had this working and who would share what they did to make it work. |
13:39 |
kmlussier |
Bug wrangling question. |
13:40 |
kmlussier |
It appears as if bug 1086934 made it in for 2.9.beta, but we forgot to move it to Fix Committed, so the milestone was updated to 2.next. |
13:40 |
pinesol_green |
Launchpad bug 1086934 in Evergreen "TPAC: Complete column sorting in some screens" [Wishlist,Confirmed] https://launchpad.net/bugs/1086934 |
13:40 |
kmlussier |
I want to update the mileston, but my only option now is to move it to 2.9.1. Is there a way I can set the milestone, at this point, to 2.9.beta? |
13:46 |
* kmlussier |
also throws a link to some signedoff patches in case anyone is interested in merging some. http://bit.ly/1kNdEVP |
13:46 |
kmlussier |
Looks like there are a few tests there from our last testing day. |
14:11 |
Dyrcona |
kmlussier: I just took care of it. I made the 2.9-beta temporarily active to retarget the bug, then set it to fixed released. |
14:43 |
kmlussier |
Dyrcona++ # Thank you! |
14:45 |
ldw |
Has there ever been any work done on creating an OAI-PMH Repository for Evergreen? |
09:22 |
pinesol_green |
Dyrcona: The operation succeeded. |
09:23 |
Dyrcona |
Stompro: I would say, "Welcome to the club," but you're already in the club, so Welcome to the Inner Circle. :) |
09:23 |
csharp |
LET THE HAZING BEGIN! |
09:24 |
Stompro |
hehe, now I can start testing patches in production like all the cool kids. |
09:24 |
|
RoganH joined #evergreen |
09:25 |
kmlussier |
csharp: For bug 924952, I think our libraries have worked around it by having their vendors supply order records that don't include the subfield if there is no data in it. |
09:25 |
pinesol_green |
Launchpad bug 924952 in Evergreen "Acquisitions: Order record loads fail when there is a null value in a holdings subfield" [High,Confirmed] https://launchpad.net/bugs/924952 |
12:51 |
kmlussier |
Bmagic++ |
12:52 |
Bmagic |
mmorgan was still working on 1331174 ? |
12:56 |
kmlussier |
I don't know. I don't have it loaded on a Sandbox at the moment. |
13:03 |
* mmorgan |
has all good intentions on finishing testing and siging off in lp 1331174, but got pulled in other directions and didn't want to monopolize kmlussier's sandbox. |
13:03 |
pinesol_green |
Launchpad bug 1331174 in Evergreen "Long Overdue processing needs org unit settings separate from Lost Processing" [Wishlist,Confirmed] https://launchpad.net/bugs/1331174 |
13:03 |
mmorgan |
I can set sights for this on the next Bug Squashing Day. |
13:04 |
|
rlefaive joined #evergreen |
13:18 |
yboston |
The problem I was havign with the PG 9.2 was fixed by the suggestions in bug 1445182 |
13:18 |
pinesol_green |
Launchpad bug 1445182 in Evergreen 2.7 "Debian Jessie 2.8.0 libdbi-drivers cannot find libpq.so" [Undecided,Fix released] https://launchpad.net/bugs/1445182 |
13:18 |
yboston |
also, Dyrcona++ |
13:25 |
kmlussier |
Oh, darn it! I totally missed the fact that ldw is scheduling a test writing day the same week. :( |
13:26 |
tsbere |
kmlussier: Combine them! Squash the bugs and then write tests for them! ;) |
13:26 |
kmlussier |
No, I don't think combining them is the best way to go. Stretching our community resources too thin in one day. |
13:27 |
|
Dyrcona joined #evergreen |
13:27 |
Dyrcona |
wifi-- |
13:28 |
|
mmorgan joined #evergreen |
13:29 |
|
mmorgan joined #evergreen |
13:35 |
RoganH |
Ever have a day where you're trying to remember something you knew you knew but have now forgotten and it's driving you nuts? |
13:40 |
dbs |
Test squashing day! Squash buggy tests day! |
13:41 |
dbs |
(Do not test buggy squash, though, just throw it out) |
13:45 |
Dyrcona |
Squash testing day! |
13:58 |
|
mmorgan left #evergreen |
14:13 |
|
rlefaive joined #evergreen |
14:31 |
kmlussier |
Bmagic: OK, since it looks like November is out, how does the week of Dec. 14 look for all of you? |
11:43 |
|
mmorgan joined #evergreen |
11:43 |
Dyrcona |
Is there an emoticon for rolling eyes? (Yes. I say emoticon, not emoji.) |
11:44 |
jboyer-isl |
I've suggested @_@ before. I think that eared one. |
11:44 |
Dyrcona |
Actually, I'm not changing code in Evergreen. I'm testing if simplifying holds code in NCIPServer will work. |
11:45 |
Dyrcona |
I think it will, but before I actually write any code there, I like to test the concept with some scripts that make the equivalent calls. |
11:45 |
Dyrcona |
It works so far for ILL holds placed on local things to go elsewhere. |
11:45 |
Dyrcona |
I need to test the other direction, now. |
11:46 |
jboyer-isl |
I've been meaning to ask you about that. Are your local NCIPServer changes available? (I was thinking that there were multiple repos for NCIPServer and didn't know what's where) I find myself in a position to help with that in the next few months. |
11:46 |
kmlussier |
jboyer-isl: That looks like it should be an emoticon for somebody who was just blinded by a camera flash. |
11:46 |
jboyer-isl |
kmlussier: Multi-purpose! |
11:57 |
Dyrcona |
:) |
11:57 |
mmorgan |
Dyrcona++ |
11:58 |
Dyrcona |
jboyer-isl: I'll send you a PDF I created for MassLNC. There are no real instructions in the README to install it. |
11:58 |
jboyer-isl |
Dyrcona: Thanks, I was poking around and wondering where to begin. (Seems a fine thing to test on the new dev server I'm supposed to be building ASAP.) |
12:05 |
yboston |
Dyrcona: thanks for replying twice to my email and my apologies for "crossign the streams" |
12:05 |
Dyrcona |
No big deal. I probably would not have replied on list if you had not asked in here. |
12:07 |
yboston |
I'll buy you a beer when I see you soon. BTW, we have been trying out trivia some Tuesday at the Kendall sq Marriot restaurant (Champions). It start at 6, which might be hard to get to |
15:09 |
* dbs |
looking |
15:11 |
|
ericar_ joined #evergreen |
15:18 |
dbs |
Restarting open-ils.storage causes all hell to break loose IIRC? |
15:18 |
* tsbere |
wonders if the typo in gmcharlt's test file should be fixed |
15:19 |
tsbere |
dbs: Depends on what is happening in your system at the time, I would think. |
15:19 |
gmcharlt |
yeah, on a quiescent system, its fine |
15:19 |
|
jboyer-isl joined #evergreen |
15:19 |
* dbs |
currently only has an up-to-date production server and is hesitant to give it a restart there |
15:21 |
gmcharlt |
yeah, easier to do it in a multi-app-server setup |
15:21 |
* dbs |
will test it outside of core work hours though |
15:21 |
gmcharlt |
tsbere: the phase, it is unclosed? |
15:22 |
tsbere |
gmcharlt: My brain jumped on "phase" instead of "phrase" when looking over the test. The fact it isn't closed is obviously intentional. |
15:22 |
gmcharlt |
right |
15:46 |
gmcharlt |
dbs: tsbere: thanks for the feedback; I've pushed a branch that incorporates it |
15:49 |
tsbere |
gmcharlt: You put in more debug code than I would have, at least. |
12:59 |
|
dMiller_ joined #evergreen |
13:00 |
kmlussier |
Speaking of caffeine, I appear to be in need of some. |
13:04 |
|
bmills joined #evergreen |
13:06 |
csharp |
kmlussier++ # yep ;-) |
13:08 |
|
ericar joined #evergreen |
13:29 |
csharp |
kmlussier: mrpeters: (I just read up) - yes, we're running PG 9.3 in production and testing EG 2.9 on PG 9.4 |
13:30 |
kmlussier |
csharp: And your using GIN indexes? |
13:30 |
kmlussier |
*you're* |
13:36 |
csharp |
kmlussier: yes'm |
15:17 |
kmlussier |
I could be operating on old experience, but I didn't think it complained about barcode conflicts at all until you clicked modify. It didn't matter if the conflict was with a precat or not. |
15:18 |
kmlussier |
yeah, what tsbere said |
15:18 |
Dyrcona |
berick++ |
15:19 |
Bmagic |
kmlussier: I see, I was about to test that. So, it's really a wishlist item, to have the barcode conflict tested before the modify copy window? |
15:19 |
pinesol_green |
[evergreen|Bill Erickson] LP#838525 DoB as date SQL upgrade repairs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=01b0255> |
15:20 |
kmlussier |
Bmagic: I recall there be discussion about an enhancment for that a long time ago, but I can't remember if it was an LP bug or just a comment on the mailing list. |
15:21 |
kmlussier |
hmmm...I wonder if I tested that in webby. I think the same thing happens there too. |
15:21 |
kmlussier |
But I think it's more of an annoyance when you're using the separate copy and volume editors in the xul client. |
15:43 |
jboyer-isl |
Bmagic, kmlussier: to change "when" that error happens would require querying the server each time the barcode changes, similar to the way some online services do new usernames when signing up. (a green check for "this username is available" vs a red x for "someone else is using this name already") |
15:44 |
jboyer-isl |
Is the real issue that the changes made to the item are lost once that message is displayed, or just that it should warn the user sooner? |
15:44 |
|
Christineb joined #evergreen |
11:28 |
krvmga |
it is a puzzlement to me |
11:28 |
miker |
krvmga: which location is 217 |
11:28 |
krvmga |
Holyoke Community College - HCC |
11:28 |
miker |
nm, I'll just change the URL ;) |
11:28 |
miker |
ah, thanks |
11:30 |
|
mt-dev joined #evergreen |
11:45 |
miker |
krvmga: in a naive test that does not even come close to approximating all that evergreen does to generate a rank based on your config, they end up with the same relevance score. I wonder if you need to adjust the class weights. (unfortunately, I'm about to turn into a pumpkin, though ... POOF) |
11:46 |
krvmga |
miker: thanks for looking at this. is there anything you can share about the test you did? (however naive) |
11:49 |
miker |
select ts_rank_cd(index_vector,to_tsquery('cooked')),* from test_table; ... test_ contains the id and output of to_tsvector() for the 245 from each record in a index_vector column. they both have 0.2 |
11:49 |
miker |
so, other factors (up to and including the numerical order of the ids) are deciding the final sort order. but, there are knobs ... :) |
11:50 |
* miker |
runs away |
12:01 |
jboyer-isl |
You can also increase the worker limit, unless you’re running out of RAM/SPU/ETC. |
12:01 |
jboyer-isl |
SPU? CPU. |
12:01 |
Bmagic |
What is up with the fine generator rolling back constantly! |
12:02 |
jboyer-isl |
I think it tests and then discards some things. It’s been an age since I’ve looked at it. |
12:02 |
Bmagic |
we have it set to <max_children>45 <min_spare_children>1 <max_spare_children>5 on 4GB memory and 12 cpu |
12:03 |
Bmagic |
At some point, I remember someone saying that once you get to a certain point, you just need to spin up another app server |
12:06 |
jboyer-isl |
We have a 4 CPU, 16GB VM with most services set to a max of 75 children and it never causes us any trouble. |
13:00 |
pinesol_green |
csharp: Ubuntu 's bugfix broke csharp's feature! |
13:03 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "unmet dependencies" (36 lines) at http://paste.evergreen-ils.org/18 |
13:04 |
Dyrcona |
Looks like apache2 and friends are broken, or my sources.lst is. |
13:05 |
csharp |
Dyrcona: I'm cloning a stock trusty VM - I'll test momentarily |
13:05 |
Dyrcona |
My sources.list looks good, no local mirrors. |
13:06 |
Dyrcona |
If I try and install the missing packages by hand, I get a similar message about uuid-dev. |
13:07 |
Dyrcona |
Maybe apt-get follow options (or whatever) changed recently? |
13:16 |
csharp |
(assuming KVM/qemu as opposed to other virtualization possiblities) |
13:16 |
csharp |
ah |
13:16 |
Dyrcona |
yeah, it's kvm/qemu, also. |
13:17 |
jboyer-isl |
Dyrcona: I’ve looked at vmbuilder recently, but it looks like it’s been set aside for years. Is everything ok with it and Trusty? |
13:17 |
jboyer-isl |
(haven’t had time to test it yet, sadly) |
13:17 |
csharp |
@eightball is it time for the Evergreen project to finally give in to the public pressure to support Linux From Scratch? |
13:17 |
pinesol_green |
csharp: No. |
13:17 |
Dyrcona |
jboyer-isl: I got it working after applying a patch. I believe it may also be used with OpenStack. |
12:10 |
|
ldw joined #evergreen |
12:31 |
|
bmills joined #evergreen |
12:40 |
|
ldw joined #evergreen |
12:45 |
kmlussier |
It's funny seeing the kind of results you get when you type "test search" into a catalog search box. |
13:00 |
bshum |
ericar++ kmlussier++ # seeking workflow feedback to figure out the steps to reach an error |
13:05 |
|
mmorgan2 joined #evergreen |
13:07 |
|
mmorgan joined #evergreen |
15:01 |
tsbere |
Though you have to pull the pieces out yourself to pass in |
15:02 |
tsbere |
Bmagic: Also, I suppose a good question would be "were those holds placed BEFORE or AFTER the transit started?" |
15:02 |
Bmagic |
before |
15:02 |
Bmagic |
im testing the function |
15:06 |
Bmagic |
tsbere: I have a success='t' from that query |
15:06 |
Bmagic |
does that mean it should have filled the hold that I simulated? |
15:06 |
tsbere |
Possibly, if the hold was in a valid state at the time to accept the copy |
16:21 |
Bmagic |
does "hold stalling interval of 2 days" mean it wont try to fill holds that are newer than 2 days? |
16:22 |
tsbere |
within the stalling period means "only pull list or checked in at pickup library" |
16:23 |
Bmagic |
ok, so the issue is that there are more holds than it allows for when checking for fulfillment? |
16:31 |
jboyer-isl |
This reminds me of something we ran into when we tested FIFO holds here a few years ago. The gist is that the opportunistic targeter only looks at X holds, and if none of the first X holds returned are for the current branch it gives up. We had huge blockbuster items with tons of holds going back on the shelf at checkin because of the FIFO setting. It's been years since I looked at it, but I don't know if it's changed that much internally since then. |
16:34 |
|
mmorgan joined #evergreen |
16:40 |
mmorgan |
Bmagic: Did you figure out your hold thing? It looks to me like your item is age protected. |
16:40 |
mmorgan |
age_protect=2 |
16:51 |
mmorgan |
And it wants to go home to 161 rather than filling a hold at 156? |
16:52 |
Bmagic |
but instead it tries to fill all of the unfillable holds first and gives up after like 40 other holds |
16:52 |
Bmagic |
The hold that it should fill is not at 156, it's another branch in the same system |
16:53 |
Bmagic |
mmorgan: one example hold that it could fill has a pickup_lib of 157 (same system). Testing to see if the copy will fill it by calling action.hold_request_permit_test function tells me that it will fill it |
16:55 |
Bmagic |
I am sure it's by design, to keep the staff user waiting less for the checkin to finish |
16:56 |
mmorgan |
Hmm. But what's the point of less waiting if the hold that should get filled doesn't get filled? |
16:56 |
Bmagic |
it does seem like the code could prioritize/sort the resulting hold requests by proximity or something so that it wouldn't waste time attempting to fill unfillable hold requests |
17:27 |
pinesol_green |
Launchpad bug 1508208 in Evergreen "Checkin age based hold protected item may not fill fillable holds" [Undecided,New] |
18:04 |
jeff |
so, now's as good a time to ask again as any other: anyone know offhand why we put ineligible-due-to-age-hold-protection copies in ahcm? |
18:59 |
|
dMiller_ joined #evergreen |
19:28 |
miker |
Jeff: I don't believe we do that test in the targetter. /me imagines the "but the age protection expired this morning at 10 am" tickets |
19:29 |
* miker |
disappears |
20:01 |
jeff |
miker: easy fix there -- only include those copies that will be eligible within the next 24h or so ;-) |
20:01 |
jeff |
(and yes, I realize I'm saying "easy" with something to do with holds...) |
23:58 |
|
bmills joined #evergreen |
10:39 |
Bmagic |
csharp: I will say that printing was totally broken in previous versions. 2.8.2 fixed those issues. |
10:39 |
csharp |
awesome |
10:40 |
csharp |
kmlussier: any chance of bringing a couple of spare receipt printers to the hackaway? :-) |
10:41 |
Bmagic |
I agree, the hatch install should be easier. I was thinking of ways to package up all the pieces for our libraries and deliver at the very least a self extracting zip file with some hard links. It seemed like I could do the install on a test system, and zip the resulting directory |
10:41 |
kmlussier |
csharp: I think they may have a couple there. I'll check. |
10:41 |
csharp |
kmlussier: rock on - thanks |
10:43 |
csharp |
kmlussier: I think the ability to have a receipt printer attached to a laptop (or spare box) and the ability to connect to a networked printer would be a good enough mockup for the majority of our use cases (fwiw) |
11:05 |
Bmagic |
After the initial setup, and the initial bug reports, it has settled down and I can only assume they are enjoying the speed and working with it on a regular basis. But I should probably probe. |
11:17 |
|
maryj joined #evergreen |
11:32 |
csharp |
Bmagic++ |
11:36 |
Stompro |
I know it is possible to disable the "Clear Hold Shelf" option from the Circulation drop down, has anyone also disabled/hidden the "Clear These Holds" button on the Browse Hold Shelf page? I just asked someone to test out some instructions that don't mention that button at all, and they immediately clicked the "Clear these holds" button. |
11:38 |
Dyrcona |
People. Why won't they just do what they're told? :) |
11:38 |
csharp |
in our case, we want the option to clear the holds available, but not to automatically happen by entering the interface - what you're desiring might be better controlled by permissions |
11:38 |
csharp |
Stompro: ^^ |
12:31 |
tsbere |
Bmagic: Hint: helpers.get_user_setting(id, setting) |
12:32 |
Bmagic |
alrighty, I'll work this out and get back to you |
12:36 |
|
jihpringle joined #evergreen |
14:35 |
jonadab |
Hmm. After importing a bunch of bib records, I can find them in the staff client, but not in the OPAC. (This is a test installation.) |
14:35 |
kmlussier |
jonadab: Do they have copies attached? |
14:36 |
jonadab |
Oh, no, they currently don't. |
14:36 |
jonadab |
I hadn't gotten to that stage yet. |
15:59 |
Dyrcona |
pinesol_green: I do. Bring me some. |
15:59 |
pinesol_green |
Dyrcona: Have you tried taking it apart and putting it back together again? |
15:59 |
pinesol_green |
Dyrcona: I am only a bot, please don't think I'm intelligent :) |
16:00 |
kmlussier |
csharp: I've received confirmation that a receipt printer and network printer will be available at the hack-a-way for hatch testing. |
16:03 |
gmcharlt |
yay! |
16:05 |
* tsbere |
has an unused network-enabled receipt printer sitting on a shelf in his office |
16:05 |
kmlussier |
tsbere: Can we use it at the hack-a-way? |
08:58 |
|
ericar_ joined #evergreen |
09:01 |
|
abowling1 joined #evergreen |
09:02 |
|
abowling1 left #evergreen |
09:04 |
csharp |
bshum: not using a/t granularity for that at this point, but this is also on a test server, so no real competition for resources |
09:05 |
csharp |
bshum: I do mean PO HTML (printing the PO) |
09:05 |
csharp |
log is here http://pastebin.com/NzzJfkTF |
09:05 |
csharp |
the error messages indicate that there is no active DB transaction |
09:08 |
* bshum |
contemplates this and why his system doesn't seem to have a PO HTML at all. |
09:08 |
csharp |
hmm - do your acq people print POs? |
09:09 |
bshum |
Oh wait there it is |
14:54 |
bshum |
We should do a new survey of systems to see what distributions folks are using. |
14:54 |
bshum |
For fun reference |
14:54 |
kmlussier |
bshum: +1 |
14:57 |
Dyrcona |
bmills: We use Ubuntu 14.04 for almost everything. I still keep a 12.04 vm handy for testing. |
14:58 |
Dyrcona |
jeff: I usually do that sort of thing in Perl or Python and manage the transactions at that level. |
14:58 |
Dyrcona |
jeff: Mainly because I usually need logic to either update a call number or alter the copy, and it's kind a tricky to do that in one transaction without a function. |
14:59 |
Dyrcona |
Plus, I'm usually doing batches. |
15:08 |
Dyrcona |
The Evergreen side would actually do that, but hey don't send values in the messages that actually work. |
15:09 |
rangi |
the RequestItem message? |
15:09 |
Dyrcona |
yeah. |
15:09 |
rangi |
oh yeah, values that don't work |
15:09 |
rangi |
that was 99% of the time testing was, "yeah, you aren't actually sending the correct data" |
15:10 |
rangi |
it's passing testing now, but I forget what we had to do to get it to work, I think we finally got them sending the correct barcodes |
15:11 |
Dyrcona |
We didn't have trouble with testing until they went to production. |
15:12 |
Dyrcona |
Well, a couple of little things. |
15:12 |
Dyrcona |
I wasn't sure from the code if the Koha side could place a hold for a local patron in the local ILS. |
15:13 |
Dyrcona |
Knowing one way or the other might help me decide if it is worth to figure out their messages to make that work with Evergreen. |
15:13 |
rangi |
yup, it does do that |
15:13 |
Dyrcona |
Thanks, bro'. :) |
15:13 |
rangi |
at least it was in testing, it may be broken in production, but I haven't heard that :) |
15:14 |
Dyrcona |
I'll bug them for some of the messages. |
15:14 |
Dyrcona |
What I've got has busted codes, so I can't rely on it. |
15:20 |
Dyrcona |
rangi++ # 'Cause he should get some karma here. |
16:23 |
Bmagic |
for small, medium, large, all complain about NOT FOUND |
16:23 |
jboyer-isl |
Maybe I was thinking of something else. :-/ Last thought: you're running this directly on your main memcache machine, yes? The same one pointed to by your app servers' apache configs? |
16:23 |
Bmagic |
I assume that means that there isn't anything in the cache. And therefore, when I load the Bib in the OPAC, evergreen should* query our content provider for lc.gif |
16:24 |
Bmagic |
yep, for sure, test machine |
16:24 |
jboyer-isl |
Huh. Well, I suppose to make sure in that case you can just cycle the service. :D |
16:26 |
Bmagic |
i did that too, I'm going to do it again and make sure. I grep the logs for lc.gif on the prod servers, and it's everywhere. Just not when I want it to! |
16:26 |
berick |
Bmagic: if it's hitting the added content provider, you'll see something like this in the logs: |
08:53 |
|
ericar_ joined #evergreen |
08:54 |
csharp |
so, general reports question... would people be interested in a "Classic Item List" and/or "Classic Circulation View" cleansed of PINES-specific fields like "Legacy Stat Cat 1" and such? |
08:54 |
mmorgan |
I don't see it on ours: http://catalog.noblenet.org |
08:54 |
csharp |
if so, I wouldn't mind creating a branch for testing that sort of thing |
08:57 |
csharp |
jeff: our stock 2.9 test server is showing the FOUC too: http://webby.gapines.org/eg/opac/home |
08:57 |
* Dyrcona |
missed something. |
08:57 |
csharp |
well, it did on first load - subsequent loads are fine |
08:57 |
csharp |
Dyrcona: 08:39 < jeff> hrm. haven't seen that before: i get a FOUC on a 2.9 catalog that i recently spun up. i wonder why. |
11:47 |
Dyrcona |
or is it delete()? Whatever it is. |
11:47 |
Dyrcona |
It happens because you have the workstation registered locally, but the registration doesn't exist in the datbase. |
11:54 |
berick |
kmlussier: well, this time last year? it must The Great Pumpkin's fault. |
11:55 |
kmlussier |
berick: You're right! We'll wait until the hack-a-way to resume testing in Firefox. :) |
11:55 |
berick |
wise |
11:55 |
kmlussier |
"This time last year" actually should be interpreted as "when we were testing sprtint 1." |
11:55 |
kmlussier |
I don't really remember when that was. It's all become one big blur to me. |
11:57 |
Dyrcona |
At some undetermined point in the past.... |
12:01 |
jeff |
dbs: regarding earlier: NOBLE's catalog would trigger FOUC only with NoScript in use because it has autofocus, but their WriteLibNameLink script normally "worked around" the autofocus FOUC. |
12:06 |
|
bmills joined #evergreen |
14:24 |
berick |
krvmga: k. can't really answer the question, then. restarting all services and apache is safest. |
14:25 |
krvmga |
berick: thanks. i was starting to think better safe than sorry. :) |
14:25 |
|
dMiller_ joined #evergreen |
14:26 |
dbwells |
berick: It was 3-4 weeks ago that I was testing this, so I'm not 100% sure what I was thinking, but I believe we'll let them happen naturally. Our non-LDAP accounts are almost entirely staff, so if things go terrible, we should at least have enough attention and control to get through it. |
14:27 |
dbwells |
In other words, adapting midstream at least won't have major PR implications. |
14:27 |
berick |
dbwells: that's good. sort of a soft launch. |
14:32 |
Dyrcona |
krvmga: you probably don't need to restart anything, maybe an apache reload. |
14:32 |
Dyrcona |
but better safe than sorry. |
15:10 |
berick |
#info berick = Bill Erickson, King County Lib. System |
15:10 |
kmlussier |
#info kmlussier is Kathy Lussier, MassLNC |
15:10 |
miker |
#info miker = Mike Rylander, Equinox |
15:11 |
dbwells |
#topic Action Items from Last Meeting |
15:11 |
dbwells |
#info Dyrcona to update README/INSTALL for master to include web staff client installation instructions for developers by 2.9.0 release date. |
15:12 |
dbwells |
Dyrcona looks to be away, but pretty sure this got done. Anyone to confirm that? |
15:13 |
dbwells |
#info Status: probably done :) |
15:14 |
dbwells |
#info 2) dbwells will attempt to explode berick's Password Managment and Authentication improvements |
15:15 |
|
jlitrell joined #evergreen |
15:15 |
dbwells |
#info Status: Done. dbwells updated the bug earlier today to note that initial tests went well, and no intends to do some limited production testing. |
15:15 |
berick |
dbwells++ # again for good measure |
15:15 |
dbwells |
#info 3) gmcharlt to release OpenSRF version 2.4.2 on 8 September 2015. |
15:16 |
gmcharlt |
#info gmcharlt = Galen Charlton, ESI |
16:27 |
|
kitteh_ joined #evergreen |
16:30 |
dbs |
éwin 36 |
16:30 |
dbs |
fr_CA for the win |
16:35 |
Dyrcona |
Sorry that I missed the meeting. Had training and then intense NCIP testing that lead to the discovery of a bug in open-ils.circ.copy_transit.receive. |
16:36 |
kmlussier |
ugh |
16:36 |
kmlussier |
In the MARC editor in the current client, there is a keyboard shortuct to add a row and another keyboard shortcut to insert a row. They appear to do the same thing. Is there a difference? |
16:37 |
tsbere |
kmlussier: Do they do said "same thing" in the same place? |
14:20 |
krvmga |
bshum: interesting |
14:21 |
* kmlussier |
looks more closely |
14:22 |
krvmga |
krvmga wants more coffee. Coffee pot is done for the day. :( |
14:23 |
kmlussier |
krvmga: I added one here http://mlnc1.mvlcstaff.org/eg/opac/home but I don't know what might be available in the Concerto set with a uniform title to test it with. |
14:23 |
bshum |
Yeah, so... |
14:24 |
kmlussier |
But the resulting syntax on the search results page looks right. |
14:24 |
bshum |
Basic search is based off parts/searchbar.tt2 which pulls from qtype_selector.tt2 |
14:24 |
bshum |
Which seems to do coded_value stuff |
14:24 |
bshum |
So... different. |
14:24 |
bshum |
Hence, my question stands, which search are you working on? :) |
14:24 |
kmlussier |
OK, and the test I just did was for basic search. I assume the preference is that it show up in advanced. I hope. |
14:25 |
krvmga |
i added it to qtype_selector.tt2 and it shows up in both places |
14:25 |
krvmga |
{value => "uniform", label => l("Uniform Title")}, |
14:26 |
* bshum |
wonders if maybe it's deeper than he thought then |
14:57 |
miker |
krvmga: kmlussier's correct, and you can also use metabib.search_alias to give a specific field a name of its own without the class part. in fact, title|uniform can be spelled bib.titleuniform via alias already http://wiki.evergreen-ils.org/doku.php?id=documentation:technical:search_grammar |
14:58 |
kmlussier |
miker++ |
14:58 |
krvmga |
miker++ |
14:59 |
kmlussier |
miker: Thanks for confirming that. Do you have any thoughts on why it seems to be doing a title search when I tried it on a more recent master release? http://mlnc1.mvlcstaff.org/eg/opac/results?query=violin&qtype=title%7Cuniform&fi%3Asearch_format=&locg=1 |
14:59 |
kmlussier |
I don't know if there's a new bug there or if I did something wrong on the test server. |
15:01 |
miker |
kmlussier: hrm... I suspect that qtype is interpreted in EGCatLoader instead of simply used |
15:03 |
miker |
code suggests I'm wrong |
15:04 |
|
jwoodard joined #evergreen |
15:24 |
krvmga |
their marc:subfield is the same, just the datafield is different |
15:25 |
kmlussier |
krvmga: Yes. |
15:25 |
krvmga |
Yay! |
15:26 |
kmlussier |
To test it, change the xpath and then edit one record with a 264. After you save it, the publisher should show up in your publisher metabib entry for that record. |
15:28 |
jeff |
okay, looks like biblio.extract_metabib_field_entry does the "output a row containing a concatenated version of all the entries" for any field that is a search field. |
15:28 |
jeff |
and now i have deja vu. :P |
15:29 |
kmlussier |
bug 1251394 is what's needed for the titles to appear in proper capitalization in the web client, right? I should try loading that branch on the test server again. |
15:29 |
pinesol_green |
Launchpad bug 1251394 in Evergreen "Metabib Display Fields" [Wishlist,Triaged] https://launchpad.net/bugs/1251394 |
15:30 |
Bmagic |
it's funny we are talking about xpath, because I have a question about it as well. "//mods32:mods/mods32:titleInfo[mods32:title and not (@type)]" is stock in our DB for "Title Proper" - It looks like it would include the 700t but it doesn't |
15:31 |
jeff |
Bmagic: what method are you using to look at the mods32 transform of your example records? |
15:35 |
kmlussier |
I'm feeling a sense of deja vu myself. Have you had this discussion before? |
15:36 |
Bmagic |
ah relateditem |
15:39 |
|
ericar_ joined #evergreen |
15:48 |
Bmagic |
jeff: what method are you using to test your mods32 query? |
15:53 |
Bmagic |
jeff: Your query does match the 700t but it also gets the 490a? |
16:09 |
|
Sessions1024 joined #evergreen |
16:27 |
|
jlitrell joined #evergreen |
16:46 |
|
mceraso joined #evergreen |
16:46 |
|
akilsdonk joined #evergreen |
16:50 |
kmlussier |
bshum: bts? I haven't seen that one in a long, long time. |
16:50 |
bshum |
kmlussier: I was just testing it. |
16:51 |
bshum |
kmlussier: It's still reserved and assigned to my IRC account. |
16:51 |
bshum |
But it seems someone else was trying to use it. |
16:51 |
|
rangi joined #evergreen |
16:51 |
|
rangi joined #evergreen |
16:52 |
kmlussier |
OK, I think I've done as much sprint 2 testing as I can handle in a day. |
16:58 |
Dyrcona |
jonadab: I has something similar with an in-house GUI application at a place where I used to work. |
16:58 |
Dyrcona |
There was no generic search library, so I had to open a window hidden, fill the values in, and then do a search. |
16:58 |
Dyrcona |
Worked fine on my brand-new 233 MHz Pentium II. |
09:37 |
Dyrcona |
pinesol_green went bye bye last night, just before I signed off. |
09:37 |
Dyrcona |
kmlussier: If you read yesterday's logs, you'll see me mentioning something in the afternoon that jeff commented on. |
09:38 |
Dyrcona |
kmlussier: It will explain why circulation is currently busted on my development vm. :) |
09:38 |
Dyrcona |
So, if you're trying to test anything there today, be warned.... |
09:40 |
Dyrcona |
I probably won't get around to fixing it until tomorrow. |
09:51 |
kmlussier |
Dyrcona: If I like at anything today, it will be cataloging in the web client, so I'm good. |
09:51 |
kmlussier |
Thanks! |
11:35 |
|
ericar joined #evergreen |
11:56 |
|
rlefaive joined #evergreen |
12:04 |
|
jihpringle joined #evergreen |
12:07 |
gmcharlt |
berick++ # testing stuff even before a pullrequest tag gets applied! |
12:09 |
berick |
gmcharlt: some code is hard to resist :) |
12:11 |
|
graced joined #evergreen |
12:15 |
|
b_bonner_ joined #evergreen |
16:01 |
Dyrcona |
I also have one remote, where the local is an empty git repo on my laptop, and the push is my development vm. |
16:02 |
Dyrcona |
That way, if dev is shut down and I fetch, I don't have to wait on it to timeout. |
16:02 |
jeff |
having the push and pull url for a given remote not point at "the same place" (i.e., point at two completely different instances of a repo) is cautioned against in the git documentation. :-) |
16:02 |
Dyrcona |
And, I can push to the remote to distribute the changes for testing. |
16:03 |
jeff |
But it's mostly a "you break it, you fix it" kind of thing. |
16:03 |
Dyrcona |
jeff: of course it is, 'cause it can get confusing if you don't pay attention. |
16:03 |
Dyrcona |
I like the local bare repo trick for pull and something on a vm for push to distribute changes, though. Very handy. |
13:14 |
Dyrcona |
Well, this stinks. |
13:16 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "checkout.permit is failing with concerto data" (15 lines) at http://paste.evergreen-ils.org/16 |
13:21 |
jeff |
interesting. |
13:44 |
Dyrcona |
Even more interesting: it happens whether I put a STAFF_CHR on the patron or not. I am testing code related to penalties. |
13:45 |
Dyrcona |
I tried using patron with id of 16, also. Same result. |
13:46 |
Dyrcona |
I could try an actual circulator account, instead of admin, I guess. |
14:01 |
Dyrcona |
I should try this with real data, too, but I don't want to spend all day on it. |
14:09 |
Dyrcona |
I just had a thought. I'll test it after I finish the dishes. |
14:42 |
Dyrcona |
Yep. I broke action.item_user_circ_test. |
14:44 |
Dyrcona |
Happily, I did not break action.hold_request_permit_test. |
14:45 |
Dyrcona |
tests++ :) |
14:47 |
Dyrcona |
Heh. Stupid thinko... instead of _org, I have _ou... |
14:51 |
Dyrcona |
And, fixed. |
15:03 |
Dyrcona |
Hmm. Wonder if I should add a copy to concerto owned by only one branch in order to do better testing? |
15:28 |
|
neady joined #evergreen |
15:29 |
|
jyorio_ joined #evergreen |
15:30 |
|
mmorgan1 joined #evergreen |
10:50 |
kmlussier |
krvmga: No, I don't think it is. The bug report is unclear. |
10:50 |
Dyrcona |
No, I'm asking krvmga. |
10:50 |
krvmga |
maybe i should add a note to that bug |
10:50 |
kmlussier |
You're seeing the eresource result on the first screen. And that's consistent with what I found when I tested the bug. |
10:50 |
kmlussier |
But then, when you click into the results, that's where the e-resources aren't showing up. |
10:50 |
krvmga |
kmlussier: yes |
10:50 |
Dyrcona |
We find that e-resources on transcendant sources show up where you might not want them. |
10:50 |
kmlussier |
In your case, there is just one other record, so it's immediately jumping to that. So I think it's a spin on that bug. |
16:34 |
miker |
if I'm reading it right, of course |
16:36 |
miker |
if so, a facet_xpath should be able to grab just <title> and not <partNumber> |
16:36 |
miker |
(but, again, docs...) |
16:37 |
* jeff |
nods |
16:38 |
* jeff |
tests |
16:45 |
Stompro |
miker, our series titles are stored with 490[ind1=0], so that shouldn't be an issue. |
16:46 |
berick |
hmm, in all the discussion of negative balances, has there ever been any talk of avoiding a negative balance only when it's negative because of a forgive payment? |
16:46 |
miker |
if I'm, indeed, correct, you could set the facet_xpath to "//*[local-name()='title']" on the series title index definition, then. my tuits are lacking for testing, but give it a try? |
16:47 |
miker |
berick: specifically a money.forgive_payment row? I don't thinks so |
16:47 |
berick |
for example, if a patron returns a lost item they paid for, they get the money back. but, if a patron returns a lost item whose charge was forgiven, they don't |
16:47 |
berick |
miker: right |
16:47 |
kmlussier |
berick: We made a distintion between overdue balances and lost items. No talk of forgive fines in discussions I've been involved in. |
16:57 |
kmlussier |
There's this http://wiki.evergreen-ils.org/doku.php?id=scratchpad:negative_balances . But then I forgot that I wrote that, so I then did this several months later. http://wiki.evergreen-ils.org/doku.php?id=qa:billing_test_cases |
16:57 |
jeff |
kmlussier++ thanks |
16:58 |
jeff |
kmlussier: anything else, before you presumably start your weekend? |
16:58 |
kmlussier |
The latter is what remingtron referred to when adding some of the live tests with the code. |
16:58 |
kmlussier |
Weekend? What's that? |
16:58 |
kmlussier |
Nope. That's all. |
17:03 |
miker |
Stompro: reingest a record (save it in the marc editor) and search again with a cache killer (put "-sdflkklsdaklsdf" without quotes at the end of the search string) |
17:05 |
miker |
berick: entirely unrelated to your topic, we can't cause the webstaff to set is_staff in mod_perl today (and cause staff searches in the embedded opac) because it will force an oils: protocol. correct? |
17:07 |
miker |
well, and because it's currently done via an http header |
17:12 |
miker |
hrm... ok... thanks. seeing bugs where they don't be. pardon the noise |
17:14 |
miker |
and, yep. ye olde "no workstation" prob |
17:28 |
Stompro |
miker, no change after reingesting ~10 records and using the cache killer line. Thanks for the help though, I'll keep trying various things. |
17:29 |
miker |
np, thanks for testing |
17:34 |
|
bmills joined #evergreen |
18:06 |
|
Dyrcona joined #evergreen |
18:07 |
|
Dyrcona left #evergreen |
14:33 |
yboston |
Stompro++ |
14:33 |
yboston |
jihpringle: works for me |
14:34 |
yboston |
#action jihpringle will send out an email to the list to ask DIG memebers to sign up for pending 2.9 new featutres |
14:34 |
* kmlussier |
should start documenting new features while she's testing them. |
14:35 |
yboston |
remingtron: about deciding if a new feature/release not entries needs docs. maybe we can team up to make that assesment together? |
14:35 |
yboston |
remingtron: so we can save volunteer time? |
14:35 |
remingtron |
yboston: yes, I can help with that |
14:36 |
yboston |
cool |
14:36 |
yboston |
#action yboston & remingtron will asses which 2.9 new features do not require new documentation |
14:37 |
yboston |
I'll send you an email |
14:37 |
Stompro |
If anyone wants to test out the adding adoc to the release notes commit, that would be appreciated. LP 1482336 |
14:37 |
pinesol_green |
Launchpad bug 1482336 in Evergreen "create_release_notes.sh include .adoc files" [Undecided,New] https://launchpad.net/bugs/1482336 |
14:38 |
yboston |
#action yboston will test and sign-off on Launchpad bug 1482336 - allowing release notes with ".adoc" suffix |
14:38 |
pinesol_green |
Launchpad bug 1482336 in Evergreen "create_release_notes.sh include .adoc files" [Undecided,New] https://launchpad.net/bugs/1482336 |
14:38 |
yboston |
anything else on 2.9 new features? |
14:39 |
remingtron |
regarding the .adoc conversion testing, I think we found a reason to halt |
14:39 |
yboston |
the git history concern? |
14:40 |
remingtron |
yes, git can track history across file name changes, but only if you use an additional command line parameter |
14:41 |
yboston |
remingtron: darn, I thought it would do it automatically |
14:42 |
yboston |
what is the parameter? |
14:42 |
remingtron |
Stompro: yes, I think we should encourage using .adoc for new files |
14:43 |
remingtron |
yboston: the parameter is --follow, like 'git log --follow' |
14:43 |
yboston |
have we tested that Robert's ascidoc parsing code can handle it? |
14:44 |
yboston |
remingtron: had no idea, but I am no git expert. all tutorial made it sound that renaming would "just work" if I used "git mv" |
14:44 |
remingtron |
yboston: I guess it works from some perspectives, but not the git log view |
14:44 |
Stompro |
yboston, when something gets included from the root.txt I don't think the parser knows what the file extension was, so it shouldn't matter. |
14:45 |
remingtron |
yboston: yes, the official docs already include an .adoc file |
14:52 |
yboston |
the good news/bad news of all the new content that we pushed probably broke something in the PDF build |
14:53 |
yboston |
I will set a generic action item to have folks look into it |
14:53 |
remingtron |
hm, guess we should email Robert to ask what errors he's seeing |
14:53 |
pinesol_green |
[evergreen|Mike Rylander] Stamping upgrade script and test file - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a9298b2> |
14:54 |
pinesol_green |
[evergreen|Bill Erickson] LP#838525 libdbi DATE types translated via gmtime - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2c42d4c> |
14:54 |
pinesol_green |
[evergreen|Bill Erickson] LP#838525 DoB as date PGTAP test - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e174b43> |
14:54 |
pinesol_green |
[evergreen|Bill Erickson] LP#838525 Store date of birth as SQL DATE type - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7159229> |
14:54 |
yboston |
#action need volunteers to see why the 2.9 and the master/dev PDF is not being built |
14:54 |
yboston |
#action yboston will send Robert an email to check on problems with 2.9 and master PDF |
14:56 |
yboston |
I need to attend a meeting at 3 PM EST |
14:56 |
yboston |
final thoughts or questions? |
14:56 |
jihpringle |
is it just the MassLNC demo server running on 2.9? (I want to include a link in the email to where people can test features to document if they don't have their own 2.9 server) |
14:56 |
kmlussier |
Do we know when it stopped building? |
14:56 |
remingtron |
kmlussier: not sure we have that info besides Robert |
14:56 |
kmlussier |
Yes. The MassLNC demo server is running 2.9 and the ESI server is running 2.8. We coordinated this time around so that we would have the two stable releases on demo servers. |
10:28 |
pinesol_green |
RoganH: But RoganH already hates acquisitions! |
10:29 |
RoganH |
@hate acquisitions_with_a_pervasive_enduring_hatred |
10:29 |
pinesol_green |
RoganH: The operation succeeded. RoganH hates acquisitions_with_a_pervasive_enduring_hatred. |
10:44 |
csharp |
is anyone on 2.9-ish able to test if Offline Transaction Management is busted for them as well? |
10:44 |
csharp |
in my case, I enter the interface and get a skull and crossbones error |
10:45 |
csharp |
http://pastebin.com/YUtuEBGj |
10:46 |
phasefx |
csharp: check your offline-config.pl file? |
10:46 |
csharp |
lemme look |
10:47 |
csharp |
phasefx: it looks right to me |
15:42 |
tsbere |
The more broken I expect things to be without it the more likely I am to want it to finish first |
15:42 |
* csharp |
has not investigated why we need a reingest for 2.8 |
15:43 |
jeff |
i believe we've gone 'live' post-upgrade with a partial (just what MUST be reingested) while the full runs in the background. the ability to do this may vary between what you're upgrading from/to, but with the newer support for selective/partial reingest will likely help there. |
15:43 |
csharp |
our test server is currently in an "upgraded from 2.7 to 2.9 but not yet reingested" state and I'm asking our staff to experiment with searching |
15:43 |
csharp |
pretty sure it's just a partial reingest that's required |
15:46 |
csharp |
actually it's 2.7.2-2.7.3 that requires the reingest |
15:48 |
csharp |
apparently 0904.schema.allow_spaces_as_ff_attr_values.sql |
15:49 |
csharp |
bug 1414112 |
15:49 |
pinesol_green |
Launchpad bug 1414112 in Evergreen 2.7 "Audience filter no longer searching blank spaces" [Medium,Fix released] https://launchpad.net/bugs/1414112 |
15:54 |
csharp |
hmm - miker's comments on the bug report make it seem that a reingest is not required... |
15:54 |
csharp |
gmcharlt: any thoughts on this?^^ |
08:08 |
|
ericar joined #evergreen |
08:37 |
|
mmorgan joined #evergreen |
08:39 |
|
Dyrcona joined #evergreen |
08:49 |
jeff |
thought exercise for the day: anonymizing live data for testing purposes. |
08:53 |
|
Shae joined #evergreen |
08:54 |
Dyrcona |
jeff: Fill names and addresses with pseudo-random noise. |
08:54 |
Dyrcona |
Ditto if you have ID fields and phone numbers. |
08:54 |
Dyrcona |
Email addresses, too.... |
08:54 |
Dyrcona |
Hmm.. Sounds like it could be a big project. |
08:58 |
tsbere |
jeff: I had some code for that at one point when I had to do something like that for MassLNC testing |
08:58 |
tsbere |
I can check the masslnc server to see if I left a copy sitting there? |
08:59 |
|
ericar_ joined #evergreen |
09:03 |
jeff |
tsbere: sure, i'd be interested. |
09:04 |
jeff |
i'm also trying to keep in mind some of the issues around such things, especially https://en.wikipedia.org/wiki/AOL_search_data_leak |
10:01 |
Dyrcona |
jeff: It was used to anonymize patron data during the performance evaluation done by OmniTI. |
10:02 |
Dyrcona |
We used actual data from C/W MARS. |
10:03 |
jeff |
Got it. That was one of the possibilities that came to mind, but I figured best to ask. |
10:05 |
kmlussier |
My use case now is similar. There are times I want to use production data for testing, but, since we work with multiple partners, I prefer to do it with anonymized data. |
10:08 |
|
rjackson_isl joined #evergreen |
10:19 |
|
dbwells joined #evergreen |
10:25 |
|
ericar_ joined #evergreen |
11:05 |
remingtron |
both sections have comments about optional steps during an upgrade |
11:07 |
kmlussier |
remingtron: Seems reasonable to me. Thanks! |
11:08 |
remingtron |
kmlussier: thanks for the feedback |
11:42 |
csharp |
jeff: I was just pondering test data anonymization myself - I don't have anything to offer other than "me too", though ;-) |
11:50 |
dbs |
remingtron: "If you were still using the JSPAC... Why? WHY?!?!" |
11:51 |
csharp |
pinesol_green: WHY?? |
11:51 |
pinesol_green |
csharp: have you tried local mean solar time for the named city as the reference point? |
16:06 |
yboston |
Dyrcona: Stompro put in a patch, but I think it needs a signoff |
16:06 |
kmlussier |
Dyrcona: Yeah, in this case I'm not doing a release notes entry |
16:08 |
kmlussier |
28e9f061 |
16:08 |
yboston |
kmlussier: I thought that remingtron might still need to do some testing |
16:08 |
kmlussier |
That never works for me. |
16:08 |
Stompro |
kmlussier, if you are adding something new, I would go with adoc format. We were waiting on figuring out if it is possible to move all the .txt to .adoc without totally screwing up the git history, or making it hard to use. |
16:08 |
kmlussier |
Stompro: OK, will do |
13:19 |
Dyrcona |
It's not just the reingest. To me, it looks like you're adding a new feature. |
13:19 |
bshum |
jboyer-isl: And yes, 2.next generally means the next major series, not maintenance release. |
13:19 |
Dyrcona |
But, yeah, targeting at 2.next now means 2.10 or 3.0 if that is what it becomes. |
13:21 |
jboyer-isl |
bshum: I spent so much time adding the composite attributes and those weirdo tests that the reingest had slipped my mind. |
13:22 |
bshum |
I tend to agree with Dyrcona's read that the bug in question seems more new featurish. |
13:23 |
jboyer-isl |
Dyrcona: I guess it could be considered a feature, I look at it more as completion of an existing feature. A full reingest makes all of that academic though. |
13:23 |
Dyrcona |
jboyer-isl: Thanks for changing the target, and I'm less concerned about the reingest than is bshum. |
09:37 |
bshum |
The new version of RSS that came with that bot worked "better" |
09:38 |
bshum |
Hmm, since it didn't say so, I wonder if there's a scheduler that came with the old RSS that I don't see in the new one :\ |
09:38 |
bshum |
@rss qatests |
09:38 |
pinesol_green |
bshum: 09:38 AM, September 22, 2015: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
09:40 |
* bshum |
will have to test more later. |
09:40 |
Dyrcona |
It's all good. |
09:49 |
jeff |
is there a recommended order for starting apache vs the websockets instance of apache? |
09:51 |
berick |
jeff: i always start WS second out of habit, but it should not matter. |
13:31 |
RoganH |
I'm starting to hate acquisitions. |
13:31 |
Dyrcona |
:) |
13:31 |
csharp |
@hates |
13:31 |
pinesol_green |
csharp hates dojo_hold_policies_interface; SIP; when libraries purchase third party products without testing and blame Evergreen for it not working; reports; the fact that the Base Filters is unnecessarily greyed out when applying an Aggregate Filter and vice versa; evil; reports more; reports even moar; details; reports even more; the fact that the Base Filters is unnecessarily greyed out (1 more message) |
13:32 |
csharp |
@more |
13:32 |
pinesol_green |
csharp: when applying an Aggregate Filter and vice versa even more; having to teach SIP2 client vendors about the SIP2 specification; troubleshooting reports; money reports; marc; reports even more than before; the EDI ruby bits; acquisitions; <quote>fun<unquote>; and edi |
13:32 |
csharp |
yep, I thought it was there |