| 10:47 |
jboyer-isl |
Everyone seems to have also taken the day off. |
| 10:48 |
Dyrcona |
Just quiet today. |
| 10:48 |
Dyrcona |
Installed some NCIPServer changes this morning. |
| 10:49 |
jboyer-isl |
Ugh. That reminds me. NCIP is the one thing I haven’t tested on our dev server yet. I need to get back on that. |
| 10:50 |
Dyrcona |
You might be interested in the changes I put in lately, then. |
| 10:50 |
jboyer-isl |
Dyrcona: Almost certainly. Also, is your NCIP testing script somewhere handy? |
| 10:50 |
Dyrcona |
One stops a hold from being placed if all of the eligible copies are checked out or can't fill the hold. |
| 10:51 |
Dyrcona |
The other creates a dummy call number if they don't send one in the AcceptItem message. |
| 10:51 |
Dyrcona |
Not publicly, but I'll throw it in a gist for you. |
| 11:03 |
Dyrcona |
heh |
| 11:03 |
|
Christineb joined #evergreen |
| 11:06 |
Dyrcona |
I added a sample LookupUser request and added a comment on the fields you need to fill in. |
| 11:06 |
Dyrcona |
LookupUser for a known patron is a good smoke test. |
| 11:06 |
jeff |
there are a bunch of sample messages in the iNCIPit repo as well as several in some of the PDFs -- might have been the INN-Reach implementation PDFs from the ncip.info site. |
| 11:06 |
* jeff |
nods |
| 11:06 |
jeff |
few state-related dependencies. |
| 11:35 |
Dyrcona |
After making changes, one of the first things I do, is send a LookupUser request with my barcode. |
| 11:35 |
Dyrcona |
That will tell me if things are basically working, or if I really botched something. |
| 11:35 |
jboyer-isl |
I might even make that a daily (ish) icinga check, even though I don’t plan to modify it much. |
| 11:38 |
Dyrcona |
It's a good test for configuration changes, etc. |
| 11:39 |
jboyer-isl |
Hmm. I need to go over all of the set up again, I’m assuming that a Dancer stack trace isn’t ever the expected output. :-/ |
| 11:40 |
Dyrcona |
No, but if you look closely enough it can point to what is wrong. |
| 11:41 |
Dyrcona |
I've not documented this, but you could run this as a stand-alone dancer app on a vm with OpenSRF and Evergreen backend installed in what I call "client mode." |
| 11:41 |
Dyrcona |
I did my initial development and testing with Dancer listening on its own port on my development vm. |
| 11:42 |
jboyer-isl |
Bah, views is still pointing to the default (/home/chrisc/…) That’s likely related, even though I should have things set correctly. |
| 11:42 |
Dyrcona |
Yeah. that would make it hard to find the templates. |
| 11:43 |
* Dyrcona |
makes a note to autoconfiscate the installation some day or use Makefile.PL. |
| 08:58 |
|
Callender joined #evergreen |
| 09:12 |
|
Callender joined #evergreen |
| 09:26 |
|
maryj joined #evergreen |
| 09:26 |
* csharp |
tests dbs 's approach to bug 1206936 but is still seeing the wrong last_billing_note and last_billing_type for his original example |
| 09:26 |
pinesol_green |
Launchpad bug 1206936 in Evergreen "money.transaction_billing_summary view displays incorrect billing_type and billing_note for the actual last transaction" [High,Triaged] https://launchpad.net/bugs/1206936 |
| 09:26 |
|
drigney joined #evergreen |
| 09:27 |
csharp |
I'm wondering if the problem is that the older data in money.materialized_billable_xact_summary is what's wrong there (which would be a separate bug, probably) |
| 12:48 |
* csharp |
investigates actor.calculate_system_penalties() |
| 12:48 |
tsbere |
csharp: org_depth will only change new entries, assuming it isn't overridden by whatever sets it |
| 12:49 |
csharp |
ah - that helps |
| 12:49 |
tsbere |
csharp: I would start by checking what org unit your test is already set at. Change that to 1 (or the top of your tree if that isn't 1) to force it to show up everywhere. |
| 12:52 |
csharp |
I thought that's what 0 was doing - "all PINES libraries" is "0" for is |
| 12:53 |
csharp |
s/is/us/ |
| 12:53 |
jeff |
you have an actor.org_unit row with id = 0? |
| 12:53 |
jeff |
or do you mean 0 as "depth"? |
| 12:54 |
csharp |
jeff: 0 is depth here, I think |
| 12:54 |
csharp |
if it's consistent with other uses of "depth" in EG |
| 12:56 |
jeff |
i'm fairly certain tsbere was recommending that you set the org_unit value of your test row in actor.usr_standing_penalty to be the id of the org that is top of tree, which in most systems (and i think PINES also) is 1. |
| 12:57 |
tsbere |
csharp: What jeff said. As I pointed out, changing the depth on the penalty type will, at best, only apply to future applications |
| 12:57 |
csharp |
ah - I see |
| 12:57 |
csharp |
okay - lemme try something |
| 17:00 |
|
vlewis_ joined #evergreen |
| 17:08 |
|
mmorgan left #evergreen |
| 17:35 |
|
vlewis joined #evergreen |
| 17:47 |
Bmagic |
Is there a trick to get the web based staff client working on 14.04? Firewall or something. All the node/bower/grunt are installed and working as far as I can tell. Tests pass. Apache2-websockets is running. |
| 17:47 |
Bmagic |
domainname/eg/staff/ opens and shows the login |
| 17:47 |
berick |
https? |
| 17:48 |
Bmagic |
logging in, I see that there is a request for port 7682, which is attempted and timed out |
| 11:19 |
Dyrcona |
s/flow/could/ |
| 11:31 |
* Dyrcona |
should do another angular tutorial or at least more angular exercises. Use it or lose it as they say. |
| 11:34 |
|
vlewis joined #evergreen |
| 11:39 |
* berick |
sees FF finally supports websockets in shared workers |
| 11:39 |
berick |
good time to start testing that again for FF and to see if chrome fixed a bug from way back.. |
| 11:40 |
RoganH |
remingtron: weird, I never did find your's in my email but I found it via MarkMail, it'll be up in a moment |
| 11:44 |
remingtron |
RoganH: strange, glad MarkMail has it |
| 11:46 |
RoganH |
remingtron: published. and if there are email spirits I think they take pleasure in seeing how much they can mess with me sometimes. Or maybe I just have too much email and things go weird. /shrug |
| 15:16 |
jeffdavis |
Has anyone else had trouble with locally hosted cover art (i.e. local images not displaying) in 2.8+? |
| 15:21 |
jeff |
jeffdavis: i don't think i've heard any reports. do you have any more details? |
| 15:23 |
jeff |
Dyrcona: the sudo behavior that you describe is pretty typical of how sudo works. I'm fairly certain that none of our documentation recommends the use of sudo. |
| 15:23 |
mmorgan |
jeffdavis: I'm not aware of problems, but we only have a few. Can you remind me where those are stored on the server so I can find a record number to test? |
| 15:23 |
Dyrcona |
jeff: I didn't think it did, but I know we administrators sometimes take shortcuts. |
| 15:24 |
jboyer-isl |
jeff: That’s true, but this is the only situation I’m aware of that it matters. |
| 15:24 |
jeff |
mmorgan: /openils/var/www/opac/extras/ac/jacket/medium/r/RECORDNUMBER by default |
| 08:53 |
pgardella |
jboyer-isl++ |
| 08:53 |
pgardella |
jeff++ |
| 08:53 |
jboyer-isl |
Definitely. Now the simple fix is "is shared actually set to true" everywhere it needs to be? Hopefully that will be a simple fix. |
| 08:57 |
pgardella |
jboyer-isl: I think the issue is that the report templates are now owned by other users, which are not parent/child of one of the others. Most of the parents are null in template_folder |
| 08:58 |
pgardella |
All the folders except a few testing ones are shared, the templates just aren't where people expect them to be. |
| 08:58 |
jboyer-isl |
That's fine if they're not sub-folders. ("Templates", "Reports", and "Outputs" don't count as parent folders, even though that's how they're displayed.) |
| 09:00 |
* tsbere |
usually avoids sub-folders for a number of reasons |
| 09:21 |
|
jwoodard joined #evergreen |
| 13:43 |
jeff |
you can also \copy temp_staging FROM pstdin WITH CSV HEADER |
| 13:44 |
* csharp |
dives back into his "acq vandelay no longer creates copies" issue :-/ |
| 13:44 |
jeff |
which can be handy for something where you are using a psql variable like :somevar |
| 13:44 |
csharp |
I was hoping that upgrading the acq test server to 2.9.0 would Just Fix™ it |
| 13:45 |
jeff |
then you call psql -v somevar=3 -f script.sql dbname < $CSV_FILE |
| 13:46 |
csharp |
so hmm... what is supposed to happen if subfields are defined for a vendor/provider but not used in the file being uploaded? |
| 13:47 |
csharp |
$u barcode and $j call number are set up but they are not in the file being imported |
| 13:57 |
pinesol_green |
csharp: The operation succeeded. csharp hates acq way more than before. |
| 13:58 |
csharp |
well, they don't match in that barcode and call number are defined as holdings subfields but are not present in the uploaded file |
| 13:58 |
csharp |
but everything else lines up |
| 13:58 |
kmlussier |
csharp: I will confirm that mapping call number and barcode and then not including them in the upload shouldn't be a problem. I do it all the time in testing. |
| 13:58 |
csharp |
okay good |
| 13:59 |
csharp |
I *think* what I'm looking for is in the DB |
| 13:59 |
kmlussier |
csharp: They have values for quantity and owning library? |
| 14:01 |
csharp |
yep - that's where I'm spending a lot of my time lately |
| 14:02 |
csharp |
my coworkers love it! |
| 14:06 |
csharp |
huh acq.extract_provider_holding_data() returns no rows for one of the lineitems I just imported - maybe whatever is causing that not to work is the issue |
| 14:21 |
kmlussier |
csharp: I'm going to take back what I said earlier. I'm just retested, and I'm having trouble with the automatic barcode generation. I don't know if it's related to what's in the provider record or not. |
| 14:21 |
kmlussier |
I'm going to test a little further. |
| 14:21 |
kmlussier |
In my case, the acq.copies were generated, but I was getting a message saying that the barcode already exists. It was generating the same barcode for each lineitem. |
| 14:23 |
Dyrcona |
So, there isn't a good way to reprocess EDI messages, eh? |
| 14:23 |
Dyrcona |
IOW, it looks like it would be more hassle than it is worth. |
| 14:24 |
kmlussier |
@dunno |
| 14:24 |
pinesol_green |
kmlussier: Down time is a fact of business when you're a poor 501c3 corporation. |
| 14:25 |
Dyrcona |
But, to follow up on the conversation from hours ago, it does look like the problem with processing the invoic message was the space in the PO name. |
| 14:30 |
kmlussier |
csharp: After further testing, I can confirm that there is a problem with automatically generating barcodes if the provider record includes a subfield for barcodes but the incoming record doesn't include that subfield. |
| 14:31 |
csharp |
holy shiznit - I recreated the acq.extract_holding_attr_table function that was returning no rows with some RAISE NOTICE statements and after that it works |
| 14:31 |
csharp |
I have no idea why that would have work |
| 14:31 |
csharp |
ed |
| 14:31 |
csharp |
@eightball do we need to start reingesting acq functions now? |
| 14:31 |
pinesol_green |
csharp: Maybe... |
| 14:31 |
kmlussier |
csharp: Call numbers seem to generate fine in the same situation. Apparently, my comment above - "I do it all the time in testing" - was a big lie. |
| 14:31 |
csharp |
heh |
| 14:31 |
miker |
csharp: sounds like maybe you had an old version? |
| 14:32 |
csharp |
no idea |
| 15:29 |
dbwells |
csharp: Just read the backlog including the conclusion to your recent acq saga. Classic. :) Definitely been there once or twice. |
| 15:31 |
* dbwells |
feels better after thinking somehow, someway, he's the one who broke it |
| 15:39 |
csharp |
dbwells: I knew it was either something I did and didn't remember or something an end user did and wasn't saying ;-) |
| 15:41 |
phasefx |
out of sight, out of mind. QA tests have been failing for a while. Suspect it's the environment and not EG code. Need to resubscribe pinesol to the RSS feed |
| 15:43 |
kmlussier |
yikes |
| 16:14 |
berick |
dbwells: i'm done w/ bug 1468422 for now. i left the authproxy for you if you want it. |
| 16:14 |
pinesol_green |
Launchpad bug 1468422 in Evergreen "Improve Password Management and Authentication" [Undecided,New] https://launchpad.net/bugs/1468422 |
| 16:20 |
dbwells |
berick: Thanks. You're right, it should be very simple (and remove some of the ugliness from AuthProxy to boot). I appreciate your efforts to handle the hard bits, and I'll definitely make it a priority. |
| 16:20 |
berick |
dbwells++ |
| 16:38 |
mmorgan |
Lovely moonrise tonight! Though I hate that it happens at 4:30 :-( |
| 17:06 |
phasefx |
a lot better this time: http://testing.evergreen-ils.org/~live/ |
| 17:10 |
|
mmorgan left #evergreen |
| 17:11 |
kmlussier |
phasefx++ |
| 17:42 |
Bmagic |
anyone played with running more than one instance of Evergreen on the same postgres cluster? divided by database and dbuser? |
| 14:14 |
kmlussier |
miker then suggested that we try removing uniqueWords in addition to documentLength. And we did. |
| 14:14 |
kmlussier |
krvmga: That's what you went live with. |
| 14:14 |
* krvmga |
adds opensrf.xml file to watch list |
| 14:15 |
kmlussier |
It didn't work out very well. Coverage density didn't come into play at all. So we restored them. |
| 14:15 |
kmlussier |
krvmga: I think the lesson is, don't touch those settings unless you do a lot of testing ahead of time. I personally have been scared away from touching them ever again. |
| 14:15 |
krvmga |
lol |
| 14:16 |
kmlussier |
krvmga: If you think back to the phrase search bug we discovered this week, search relevance in your early days were very similar to those results. |
| 14:16 |
miker |
kmlussier: removing all is effectively the phrase bug I just fixed, BTW. |
| 14:16 |
krvmga |
heh |
| 14:16 |
kmlussier |
miker: Not sure why removing documentLength on its own didn't do anything for us, because it is a question that has come up time and time again at all of our sites. |
| 14:18 |
miker |
kmlussier: part of it is that "document" really means "each individual field indexed, on its own" in evergreen |
| 14:19 |
kmlussier |
Yeah, but IIRC, we were testing it on keyword searches at the time. And it's back before we had added additional indexes before the blob. |
| 14:20 |
miker |
which, for titles especially, is a pretty narrow range of lengths |
| 14:21 |
miker |
tuits, but it wouldn't hurt to analyze in detail |
| 14:21 |
kmlussier |
We've generally found that the preference for shorter documents also leads to older records coming up high, because apparently we didn't catalog as much detail decades ago. |
| 14:22 |
krvmga |
yes, we have seen that is so. |
| 14:22 |
kmlussier |
Yeah, it might be worth taking another look at again since I don't have the pressure of two upcoming migrations as I did the last time we looked at it. |
| 14:23 |
krvmga |
i'm up for it. what i'm trying to do is document and test and document... |
| 14:23 |
* krvmga |
has to run to another meeting. back in a while. |
| 14:24 |
kmlussier |
Yes. One thing I want to do is put some of the search configuration for C/W MARS and NOBLE on the Evergreen wiki as examples of what they have done for adding indexes and improving relevancy. Maybe putting failed experiments there would be worthwhile too. |
| 14:36 |
gmcharlt |
dbs: looking at bug 1516867, and a quick question: any objection if sortable were moved to under Open-ILS/web/js/ ? |
| 14:36 |
pinesol_green |
Launchpad bug 1516867 in Evergreen "HTML reports should be dynamically sortable" [Wishlist,Confirmed] https://launchpad.net/bugs/1516867 - Assigned to Galen Charlton (gmc) |
| 14:37 |
* berick |
bites the bullet and updates to 15.10 on the laptop |
| 14:39 |
dbs |
gmcharlt: no particular objections; I had avoided it largely because everything under web/js/ appeared to be dojo, but there's always a first :) |
| 14:40 |
dbs |
gmcharlt: would you like me to refactor and push a revised branch? |
| 14:41 |
gmcharlt |
dbs: that would be great; meanwhile I'll finish testing its functionality |
| 15:23 |
* dbs |
suspects a Google Form might help the "CC gmcharlt" barrage (then either working with a google sheet backend to generate the JSON, and/or store the JSON in git for pull request delight) |
| 15:24 |
gmcharlt |
yeah, we'll certainly want something of the sort by the time it goes from beta to production |
| 15:27 |
dbs |
Oh right, it was the disturbing nature of having a CSS file located under a /js/ directory that gave me pause :) |
| 15:29 |
gmcharlt |
but not unprecented; lots of CSS files accompanying the Dojo stuff under /js/ |
| 15:30 |
dbs |
gmcharlt: I've pushed the branch with a second commit; you can squash it if you like |
| 15:31 |
gmcharlt |
thanks |
| 15:31 |
dbs |
thanks for testing! |
| 15:31 |
gmcharlt |
speaking of which, my substantive feedback from said testing |
| 15:31 |
gmcharlt |
1. looks nice and necessary |
| 15:32 |
gmcharlt |
2. the time it takes to render the table and sort it can really bog down after a certain point. with some emperical testing I've done in the XUL client and Chrome, up to 10,000 rows or so is fine |
| 15:33 |
gmcharlt |
but 100,000 can be a browser-killer |
| 15:33 |
dbs |
I think 100,000 rows is a killer without any javascript, isn't it? |
| 15:33 |
gmcharlt |
since the average # of rows in report output I've measured for a large consortium today is 4,300, on average things are fine as is |
| 15:34 |
gmcharlt |
but I'm thinking that perhaps picking a magic row count number, after which the JS isn't loaded, might be good |
| 16:36 |
Dyrcona |
Well, the IDL is valid XML. |
| 16:36 |
Dyrcona |
All the services are running. |
| 16:39 |
Dyrcona |
Lots of warnings about subroutines being redefined, but no syntax errors in AppUtils or CStoreEditor. |
| 16:45 |
Dyrcona |
Hmm... AppUtils.pm has undergone some changes in the past few weeks, including some from a test branch of my own, so guess I did modify AppUtils. :) |
| 16:47 |
Dyrcona |
So, I added a new subroutine that looks good and self-contained. |
| 16:48 |
Dyrcona |
I would almost think if this failed that the staff client would be unusuable. |
| 16:54 |
|
vlewis joined #evergreen |
| 10:29 |
Bmagic |
it could* work |
| 10:30 |
Bmagic |
lol |
| 10:30 |
* bshum |
doesn't think he's ever played Doom. |
| 10:30 |
gmcharlt |
Dyrcona: indeed, better ways for staff to visualize and/or test circ policies would be great |
| 10:30 |
Dyrcona |
The idea behind the solver is to show you how your rules actually work. |
| 10:30 |
phasefx |
Dyrcona: one useful entrypoint might be from the item editor, but you'd need a lot of context options |
| 10:30 |
Dyrcona |
You put in barcodes and locations and it tells you what happens. |
| 10:30 |
Dyrcona |
phasefx: I have been considering something standalone that only talks to the database. |
| 10:31 |
phasefx |
probably the safest option as far as clutter goes |
| 10:31 |
Dyrcona |
Another option is to add an open-ils.circ-solver service and make calls against that. |
| 10:31 |
phasefx |
there is a circ test api call, IIRC |
| 10:32 |
gsams |
Dyrcona: As someone more or less on the outside of things, I think this is a great idea. |
| 10:32 |
miker |
you know, I thought there was a UI in the xul client for supplying a patron and item barcode to "fake" a circ... maybe just a wishlist thing from long ago |
| 10:32 |
Dyrcona |
phasefx: yeah, but it either does too much or doesn't do enough depending on what I want to know. :) |
| 10:33 |
Dyrcona |
Most of the db functions that I use are not exposed directly in the open-ils api. |
| 10:33 |
miker |
ah, well, nevermind me ... phasefx++ |
| 10:34 |
gmcharlt |
it's a start though - and I think it would be good if the code that test circ policies were essentially accessing exactly the same pathways that real loan and hold transactions do... just with additional instrumentation as needed for Dyrcona's purposes |
| 10:34 |
phasefx |
miker: there's a Test Circulation option for some A/T stuff; you may be thinking of that. I never played with it |
| 10:36 |
kmlussier |
gmcharlt: I was just reviewing your RM proposal on supporting the web client for production use. When you mention holds, are you thinking of all holds functions, including pull list and managing the holds shelf, or were you just thinking of things you would most commonly do while working with a patron, (i.e. placing, viewing, updating holds)? |
| 10:36 |
Dyrcona |
Lovely: ERROR: column "ccvm.ctype" must appear in the GROUP BY clause or be used in an aggregate function |
| 10:37 |
Dyrcona |
Guess string_agg( ccvm.ctype || 'something else') doesn't count..... |
| 16:05 |
Dyrcona |
Well, I suspect something is slightly off on the input, but I don't read EDI. |
| 16:06 |
berick |
Dyrcona: not even enough to be fun at parties? |
| 16:06 |
Dyrcona |
What I think should happen is the id: for the line items should come from the RFF+LI after the / or whatever. |
| 16:07 |
berick |
useful tool: cd Open-ILS/src/support-scripts/test-scripts/; perl edi_reader.pl <edi_file> |
| 16:07 |
Dyrcona |
What happens on this one is they all get the same number from somewhere else in the INVOIC. |
| 16:08 |
Dyrcona |
And that seems to be happening with all of the invoices from this vendor for this library, so I'm tempted to say, just stop using that vendor. ;) |
| 16:08 |
csharp |
@quote add < Dyrcona> Acquisitions: It's all EDI to me. |
| 09:10 |
kmlussier |
miker++ #The fix for bug 1516707 is working great! |
| 09:10 |
pinesol_green |
Launchpad bug 1516707 in Evergreen "Relevance ranking deteriorates when phrases are added to search" [Medium,New] https://launchpad.net/bugs/1516707 |
| 09:10 |
kmlussier |
Dyrcona++ #Loading the fix on his VM |
| 09:11 |
Dyrcona |
kmlussier: Should we target that for 2.8 and 2.9? It could make it into today's releases, unless we think it needs more testing. |
| 09:12 |
kmlussier |
Dyrcona: I think it's good to go. I can merge it in a minute. Yes, I think it should be backported. |
| 09:14 |
Dyrcona |
I've targeted it for 2.8.5 and 2.9.1. I think we should let berick decide if it goes into 2.8, though. |
| 09:17 |
kmlussier |
OK, I'll hold off until I get the ok (or not ok) from berick then. |
| 10:29 |
bshum |
:) |
| 10:31 |
jboyer-isl |
Dyrcona: It’s probably not a great plan, but after our upgrades I stop looking at upstream (aside from security) until the next upgrade approaches, when I have to dust off a bunch of knowledge and start over. |
| 10:31 |
jboyer-isl |
Though that makes me wonder, why rebase to 2.9, I thought you stayed on master for the most part? |
| 10:31 |
Dyrcona |
I build new development/test branches almost weekly, sometimes more often, sometimes less. |
| 10:31 |
Dyrcona |
I typically include our customization branches unless I'm build for concerto. |
| 10:32 |
Dyrcona |
So they get rebased with some frequency. |
| 10:32 |
jboyer-isl |
That makes sense. |
| 10:37 |
Dyrcona |
kmlussier++ # for release notes |
| 10:37 |
Dyrcona |
Head's up: I've decided to roll 2.9.1 early in the day. |
| 10:38 |
Dyrcona |
Most of the fixes are in, and we'll have a few left for 2.9.2. |
| 10:38 |
Dyrcona |
Most of the ones that haven't made it are not things that I think I can test easily, i.e. would take me more than one day or we don't normally use that feature. |
| 10:39 |
pinesol_green |
[evergreen|Kathy Lussier] Adding bug fixes and acknowledgements to 2.9.1. Release Notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ada78de> |
| 10:59 |
|
ericar_ joined #evergreen |
| 11:09 |
pinesol_green |
[evergreen|Kathy Lussier] Docs: 2.8.5 point release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f14e164> |
| 11:10 |
berick |
kmlussier++ |
| 11:11 |
|
sarabee joined #evergreen |
| 11:11 |
Dyrcona |
berick: Did you want the QP fix branch in 2.8? kmlussier and I weren't sure if you wanted to test it before or not. |
| 11:11 |
kmlussier |
berick: For reference bug 1516707 |
| 11:11 |
pinesol_green |
Launchpad bug 1516707 in Evergreen 2.8 "Relevance ranking deteriorates when phrases are added to search" [Medium,New] https://launchpad.net/bugs/1516707 |
| 11:12 |
Dyrcona |
heh. I was just looking the bug# up. |
| 11:12 |
kmlussier |
I had it in an open tab |
| 11:12 |
berick |
Dyrcona: yes, i do want it. |
| 11:13 |
berick |
did we ever find a suitable concerto test for that? |
| 11:13 |
berick |
(not that worried about it, really, if it works in 2.9) |
| 11:13 |
Dyrcona |
I don't think so, but kmlussier would know better than i. |
| 11:13 |
kmlussier |
berick: No, I don't think it's something you can test in concerto. I tested it with production data. |
| 11:13 |
Dyrcona |
It works on my production data. |
| 11:14 |
berick |
k |
| 11:14 |
berick |
i'll just make sure it doesn't blow up |
| 11:14 |
kmlussier |
berick: Actually, "violin concerto" might be a good test. |
| 11:15 |
Dyrcona |
:) |
| 11:16 |
berick |
i'll try that |
| 11:16 |
berick |
thanks |
| 12:25 |
|
ericar_ joined #evergreen |
| 12:39 |
|
Christineb joined #evergreen |
| 12:40 |
Dyrcona |
Yay for new server(s)! |
| 12:42 |
csharp |
are there currently test suites for javascript in EG? |
| 12:42 |
csharp |
we're looking at karma/jasmine and it's very simple to use |
| 12:43 |
csharp |
(in the angularjs bootcamp) |
| 12:43 |
csharp |
https://jasmine.github.io/2.3/introduction.html & https://github.com/karma-runner/karma |
| 12:45 |
* csharp |
has a stack of new dells sitting on the cage floor waiting for power which is waiting for contract stuff :-/ |
| 12:47 |
Dyrcona |
kmlussier and anyone else: Head's up that I am shutting down my normal vm to test the 2.9.0 to 2.9.1 upgrade. |
| 12:48 |
Dyrcona |
csharp: I'm not aware of any JS tests, but I've not looked into the Angular staff client code much. |
| 12:48 |
Dyrcona |
I know that Angular is supposed to be easy to write tests for. |
| 12:51 |
|
gsams joined #evergreen |
| 13:01 |
|
gsams joined #evergreen |
| 13:07 |
gmcharlt |
webstaff does have some tests for the Angular code |
| 13:08 |
Dyrcona |
I thought it might, but wasn't sure. |
| 13:10 |
|
jihpringle joined #evergreen |
| 13:10 |
berick |
csharp: we use karma/jasmine now for the angular stuff |
| 14:44 |
pinesol_green |
Launchpad bug 1517596 in Evergreen "webclient: merge patrons missing" [Medium,New] https://launchpad.net/bugs/1517596 |
| 14:44 |
pinesol_green |
Launchpad bug 1517595 in Evergreen "webclient: delete patron action is missing" [Medium,New] https://launchpad.net/bugs/1517595 |
| 14:45 |
csharp |
kmlussier: will do |
| 14:45 |
kmlussier |
I would have added that comment when I submitted them, but I didn't see it until it was too late. |
| 14:46 |
kmlussier |
Despite many, many hours of us of the web staff client, I sometimes feel as if I've only scratched the surface of testing it. There's just so much there. |
| 14:46 |
kmlussier |
s/us/use |
| 14:49 |
Dyrcona |
Oh, speaking of web client testing. My dev vm should be back to "normal." |
| 14:50 |
csharp |
kmlussier: I agree - PINES is about to dive into testing it on 2.9.X, so we'll have more data to work with |
| 14:52 |
|
vlewis__ joined #evergreen |
| 14:52 |
|
vlewis___ joined #evergreen |
| 14:56 |
|
vlewis joined #evergreen |
| 15:17 |
berick |
had to add -lm -lpthread and -lrt |
| 15:17 |
berick |
following along with https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=713616 |
| 15:17 |
pinesol_green |
Debian bug 713616 in src:netcfg "netcfg: FTBFS: ld: /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/libcheck.a(check.o): undefined reference to symbol 'floor@@GLIBC_2.2.5'" [Serious,Fixed] |
| 15:17 |
berick |
yay, tests pass |
| 15:18 |
berick |
that is, add it to Open-ILS/src/c-apps/tests/Makefile LIBS = |
| 15:18 |
pinesol_green |
[evergreen|Ben Shum] Docs: Change references to release 2.9.1 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=26d08db> |
| 15:18 |
* berick |
makes a note to open an LP |
| 15:20 |
berick |
kmlussier: I def. notice a difference in the "violin concerto" query after applying the QP patch |
| 15:26 |
Bmagic |
no problem! |
| 15:27 |
berick |
this is the result of the latest hackaway https://bugs.launchpad.net/evergreen/+bug/1513872 |
| 15:27 |
pinesol_green |
Launchpad bug 1513872 in Evergreen "Move EDI toggles into DB" [Wishlist,New] |
| 15:28 |
kmlussier |
berick: I'm not surprised about the "violin concerto" query. the results were quite remarkable in my testing on Dyrcona's database. I'm surprised I never noticed the problem before. |
| 15:29 |
kmlussier |
Pre-patch we have these results for "the blue": |
| 15:29 |
kmlussier |
http://catalog.mvlc.org/eg/opac/results?query=%22the+blue%22&qtype=keyword&fi%3Asearch_format=&locg=1 |
| 15:30 |
kmlussier |
And post-patch we have: |
| 15:30 |
csharp |
berick: happy to test whatever you need |
| 15:30 |
kmlussier |
https://jasondev.mvlcstaff.org/eg/opac/results?query=%22the+blue%22&qtype=keyword&fi%3Asearch_format=&locg=1 |
| 15:30 |
csharp |
(or otherwise help) ;-) |
| 15:30 |
berick |
kmlussier: makes all the difference |
| 09:19 |
|
mmorgan joined #evergreen |
| 09:36 |
|
yboston joined #evergreen |
| 09:54 |
|
sarabee joined #evergreen |
| 10:07 |
kmlussier |
Dyrcona: For clarification, test writing day is today, not tomorrow. |
| 10:08 |
Dyrcona |
Well, now you tell me. |
| 10:08 |
kmlussier |
ldw sent his email last night. |
| 10:08 |
Dyrcona |
And, goodbye. I have a day of meetings. |
| 10:51 |
* Dyrcona |
is likely to disappear in a minute or so. |
| 10:51 |
gmcharlt |
dbs: wheee! incompatible changes FTW! at least it was documented |
| 10:53 |
berick |
oh right... release cutting. |
| 10:53 |
* dbs |
ponders the work required to set up a suite of tests for the reporter |
| 10:54 |
dbs |
live tests I guess |
| 10:54 |
berick |
kmlussier: are you still our point person for release docs? |
| 10:54 |
kmlussier |
berick: Yup. I haven't done the legwork to find somebody to take my place yet. |
| 10:55 |
|
sandbergja joined #evergreen |
| 11:00 |
Dyrcona |
dbs: Of course it does. |
| 11:00 |
bshum |
"Can open.... worms everywhere...." |
| 11:01 |
Dyrcona |
bshum++ |
| 11:07 |
StomproJ |
Question for the core devs. I was working on combining all the outstanding "Permission missing from system" launchpad tickets into one branch. And I was also planning on merging all of the database upgrade scripts into one file. I was thinking that it would be easier to deal with them all at once, and just have one db update to apply and test. Is this an ok practice? |
| 11:07 |
bshum |
StomproJ++ # yes |
| 11:07 |
bshum |
And in fact I mentioned doing something similar at the Hackaway with mmorgan |
| 11:07 |
|
ericar joined #evergreen |
| 12:19 |
dbs |
yeah, yeah that's the ticket |
| 12:20 |
gmcharlt |
kmlussier: I think it reasonable to treat it as a backportable bugfix |
| 12:23 |
gmcharlt |
dbs: what about CSV and the debug HTML output? |
| 12:23 |
ldw |
Following the emails regarding test writing day and patch release day, I will postpone test writing day until next week. I will send out an email shortly. |
| 12:25 |
dbs |
gmcharlt: CSV seems to be handled by the Text::CSV_XS module, same way Excel module does |
| 12:25 |
gmcharlt |
OK |
| 12:26 |
gmcharlt |
(I'm asking on the basis of having just read the patch, not yet putting it through its paces) |
| 12:27 |
dbs |
I haven't bugged this or submitted it as a formal fix because I'm curious about what happens on a system with DBD::Pg 3.0.0+ |
| 12:28 |
dbs |
tsbere: I can believe that |
| 12:35 |
|
jihpringle joined #evergreen |
| 12:41 |
kmlussier |
ldw: I don't think that's necessary. Dyrcona thought test-writing day was tomorrow, not today. |
| 12:42 |
kmlussier |
ldw: I clarified the date for him in channel, but forgot to send something out to the list. |
| 12:45 |
|
sarabee joined #evergreen |
| 12:45 |
dbs |
fwiw, the debug output seems thoroughly escaped; a report name of 'Test Francais 8é' gets translated in the output as 'name' => "Test francais 8\x{e9}" |
| 12:46 |
dbs |
which seems fine. But then the subject of the email gets corrupted because we're not doing the right SMTP things |
| 12:46 |
dbs |
so... how far down this rathole do we really want to go? Me, I'm happy just seeing the HTML output fixed as a start. |
| 12:47 |
dbs |
Having fixed the email output for action-trigger notifications way back when, the path is reasonably clear, but the cost/benefit ratio is suspect |
| 12:48 |
gmcharlt |
do what you can, LP the rest and move on |
| 12:50 |
kmlussier |
ldw: Another thing to consider, next week could be problematic due to U.S. Thanksgiving. |
| 12:57 |
|
jihpringle_ joined #evergreen |
| 12:57 |
|
Shae_ joined #evergreen |
| 13:11 |
pinesol_green |
[evergreen|blake] LP1402018_Acq_Copy_location_UI_scoped_to_registered_workstation - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4b094b1> |
| 13:20 |
ldw |
kmlussier: ahhh. I think now that I have gone and spammed the list about a date change, I might as well stick with it. Hopefully, we can find one day next week that works for everyone in the US. |
| 13:24 |
ldw |
Unless everyone here wants to write tests today (just reading the emails now). I am fine with doing it today too. |
| 13:34 |
kmlussier |
I'm fine going along with the crowd. Based on the silence, I'm guessing there aren't many people around to do it today. |
| 13:34 |
ldw |
kmlussier: seems to be the case. Do people take extended holidays for Thanksgiving? Should I move it to the next week? |
| 13:38 |
kmlussier |
I think it's common for people to take both Thursday and Friday off - don't want to miss all those Black Friday sales. Monday and Tuesday might be better. |
| 17:28 |
kmlussier |
Excellent! I may load up a VM with it now. |
| 17:28 |
kmlussier |
miker++ |
| 17:28 |
* csharp |
finds http://search.cpan.org/~drolsky/DateTime-1.21/lib/DateTime.pm#0-based_Versus_1-based_Numbers based on miker's last comment |
| 17:28 |
kmlussier |
hmmm...I wonder if I can find a good example in Concerto to test the branch against. |
| 17:29 |
miker |
kmlussier: it's a one-liner ... maybe noble's test system can absorb it? |
| 17:31 |
miker |
csharp: right... my thinking was, "if we use the /explicit/ *_0 method names in the perl, there will never be a question" ... whether that thinking was sound is left as an exercise for the reader to determine ;) |
| 17:31 |
kmlussier |
miker: Maybe. I'll run it by them in the morning since it looks like mmorgan just left. |
| 17:31 |
csharp |
miker: makes sense ;-) |
| 17:32 |
miker |
of course, the module's contention that "There is a year 0." is ... problematic :) |
| 15:17 |
|
dwgreen joined #evergreen |
| 15:26 |
Bmagic_ |
anyone else have issues using the "message center" interface? It endlessly spins (loading) with no results. The server logs do not provide any feedback. |
| 15:26 |
Bmagic_ |
I get an error in the javascript console: Use of getAttributeNode() is deprecated. Use getAttribute() instead. Source File: oils://remote/js/dojo/dojo/dojo.js Line: 16 |
| 15:30 |
bshum |
oils? |
| 15:31 |
bshum |
Is this in the staff client? |
| 15:31 |
bshum |
Bmagic_: staff client vs. browser? |
| 15:31 |
* bshum |
only tested message center in the browser, not the client |
| 15:33 |
Dyrcona |
bshum: That's the oils wrapper that tricks xul into loaded stuff remotely. |
| 15:34 |
Dyrcona |
s/loaded/loading/ |
| 15:34 |
bshum |
Right, so .... staff client. :) |
| 16:43 |
berick |
yeah, makes sense |
| 16:44 |
gmcharlt |
0446.schema.naco-normalize-modifiers.sql is another bad one |
| 16:46 |
miker |
git can't tell us who to blame for that one ... svn didn't track renames |
| 16:47 |
Dyrcona |
Yeah, I found it in 2.8.4 to 2.9.0 because of transaction issues when testing. |
| 16:48 |
* miker |
suspects miker, or dbs, for 0446 |
| 16:48 |
Dyrcona |
I'm not sure we should fix 0446 at this point, that is so old. |
| 16:48 |
* miker |
now runs away |
| 09:26 |
Dyrcona |
NM. I found it. |
| 09:54 |
berick |
Dyrcona: there are a couple branches. collab/berick/hatch2 is the current canonical branch |
| 09:54 |
Dyrcona |
Thanks, berick. That is what I thought after a quick git log on a couple. |
| 09:55 |
gmcharlt |
following up on a question kmlussier asked on Wednesday, I'd like to sound folks out on merging the current sprint2/sprint3 branch (ollab/gmcharlt/webstaff-sprint2-sprint3) into master |
| 09:55 |
gmcharlt |
perhaps around the end of next week, by which point miker and I should be done, or close to done, with sprint2 follow-up work based on testing partner reports |
| 09:56 |
Dyrcona |
gmcharlt: Do you think it is mostly ready for testing? I could load it so kmlussier and I (and possibly others) could see it with production data. |
| 09:56 |
gmcharlt |
the branch also includes some sprint3 stuff that's a bit more WIP-y, but since sprint3 is mostly just administration and config interfaces, that's pretty self-contained |
| 09:56 |
berick |
+1 to merging from me # disclaimer, a few commits are mine. |
| 09:57 |
gmcharlt |
Dyrcona: yeah, the current branch is in a fit state to usefully test with |
| 09:57 |
Dyrcona |
OK. I'll plan to merge it for testing by Monday. |
| 09:57 |
gmcharlt |
thanks |
| 09:57 |
berick |
Dyrcona++ |
| 10:03 |
|
yboston joined #evergreen |
| 12:32 |
dbs |
yeah, parallel seqscan should make a big difference |
| 12:36 |
dbs |
Or maybe not yet :/ |
| 12:37 |
berick |
yeah, early stages |
| 12:39 |
* dbs |
was at the retirement party for the DB2 software engineer who first got parallel query working in DB2 for Linux |
| 12:40 |
dbs |
he started a test query, headed out to his car to go home so he could see the results next day, realized he forgot something in his office and went back and it was already done |
| 12:40 |
Bmagic |
anyone aware of a SIP bug that reports holds to a query like AY4AZF087 and responds with all of the holds prefixed |CD - Then if the query was AY4AZF086 - responds with all of the holds prefixed |AS |
| 12:41 |
Bmagic |
which is conflicting information, essentially it's saying that the holds are both not available and available |
| 12:43 |
jboyer-isl |
Bmagic: could you paste in the rest of the SIP message? (minus any patron information) That's just the error detection stuff. |
| 15:59 |
kmlussier |
I don't think there were any merged but fixes for last month's release. Shouldn't have that problem this month. |
| 15:59 |
Dyrcona |
There was 1 for 2.9 and it was not a big deal. |
| 16:00 |
* kmlussier |
will try to get a jump on point release notes this time. |
| 16:00 |
Dyrcona |
kmlussier: I'm going to push lp1513554 as soon as I test the staff client bits. |
| 16:00 |
Dyrcona |
lp 1513554 |
| 16:00 |
pinesol_green |
Launchpad bug 1513554 in Evergreen "It is possible to delete acq.cancel_reasons that are used by the system" [High,New] https://launchpad.net/bugs/1513554 |
| 16:00 |
Dyrcona |
There we go. Need the space. |
| 16:07 |
Dyrcona |
Grabbing 0949. |
| 16:09 |
dbs |
mmorgan: I turned it off a while ago, because it kept on generating HTTP links in our HTTPS-only environment |
| 16:09 |
dbs |
and thus wouldn't work in any sane browser |
| 16:13 |
mmorgan |
dbs: Ok, thanks, we were testing and noticed the http/https thing. |
| 16:14 |
mmorgan |
Makes it kinda hard to implement. |
| 16:16 |
pinesol_green |
[evergreen|Jason Stephenson] LP#1513554 - Stamping Upgrade Script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0fd044b> |
| 16:16 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1513554 - Doc update for cancel reason selection - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f6d9c1e> |
| 16:16 |
pinesol_green |
[evergreen|Chris Sharp] LP#1513554 - Prevent deletion of reserved rows. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f84c75b> |
| 13:40 |
gmcharlt |
but for lp1502292, writing your patch against that collab/gmcharlt/webstaff-sprint2-sprint3 branch is probably the better bet |
| 13:46 |
|
maryj joined #evergreen |
| 13:52 |
vlewis |
gmcharlt: Thank you. |
| 13:58 |
kmlussier |
I'm not really here today, but since the topic was just raised. |
| 13:58 |
kmlussier |
gmcharlt: Is there a way we could get the web client branches merged into master more frequently? |
| 13:59 |
kmlussier |
I do some of my web client testing on Dyrcona's server, and I sometimes forget what's been put in master and what is only available on webby. |
| 14:00 |
kmlussier |
It might also make it easier for people like vlewis to contribute since we'll all be working from the same place. Not that she couldn't load the collab branch, but not everybody knows where the latest code is. |
| 14:01 |
gmcharlt |
kmlussier: in the short term, we can mention the current review branch here whenever it changes, and we're also (as you know) getting to a milestone with the sprint 2 branch where it could be considered for merging |
| 14:02 |
kmlussier |
Yeah, the thing that makes it difficult is that sprint 2 and sprint 3 code is in the same branch. I feel very confident that the sprint 2 stuff looks pretty good. I haven't even looked at any of the sprint3 features yet. |
| 14:03 |
gmcharlt |
indeed, but won't be too hard to split apart if need be -- although arguably, it won't be in the short term, as the admin interfaces in sprint 3 have the virtue of being relatively self-contained |
| 14:14 |
David___ |
I'll give it a whirl, then. :) |
| 14:17 |
frank__ |
Hi all, I am again, Why Can´t I see the bucket I created in the Marc Batch Edit records? Do I need to reestart something? |
| 14:28 |
|
bmills joined #evergreen |
| 16:06 |
kmlussier |
I love all the new copy locations in the sample data. But, one unexpected problem I've come across is that the limited number of sample Concerto copies that have monographic parts are landing in non-holdable copy locations. |
| 16:07 |
kmlussier |
Not that I can't change those copy locations when testing, but is there a way in the Concerto script that we could force those in holdable copy locations? |
| 16:14 |
|
jonadab joined #evergreen |
| 16:58 |
|
bmills joined #evergreen |
| 18:06 |
|
sarabee joined #evergreen |
| 20:00 |
pinesol_green |
[evergreen|Ben Shum] Update core committer information on the staff client's About Page - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e2f1b53> |
| 20:02 |
|
artunit joined #evergreen |
| 20:44 |
pinesol_green |
[evergreen|Bill Erickson] LP#1483508 PGTAP tests for text_concat / agg_text - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1c3ba71> |
| 20:59 |
kmlussier |
@developer |
| 20:59 |
pinesol_green |
kmlussier: Communication:14, BigPicture:10, DetailOriented:6, KungFu:11, GetsStuffDone:14, FlakeFactor:13, JavaAvoidance:15 |
| 21:00 |
bshum |
@sortinghat |
| 21:07 |
pinesol_green |
Hmm... kmlussier... Let me see now... GRYFFINDOR! |
| 21:07 |
* kmlussier |
yawns |
| 21:08 |
kmlussier |
I was hoping for Slytherin |
| 21:18 |
pinesol_green |
[evergreen|Josh Stompro] LP#1483500 - pgtap Test for evergreen.lowercase - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=52fa86a> |
| 22:05 |
pinesol_green |
[evergreen|Yamil Suarez] LP# 1483506 public.first_agg & public.first pgTAP tests - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=066232c> |
| 01:05 |
|
tsbere_ joined #evergreen |
| 02:48 |
|
phil joined #evergreen |
| 02:49 |
phillipjphry |
Hello! |
| 03:06 |
phillipjphry |
I'm a library worker in BC setting up Evergreen for the heck of it. I'm on the last step in Evergreen/opensrf setup |
| 03:07 |
phillipjphry |
when I run the settings-tester.pl script, it hangs on testing connections to the database, and I think something went funny with my perl database setup script, as it just hangs(and is STILL hanging) |
| 03:21 |
phillipjphry |
Woop. Looks like I was just too hasty. I opened top and saw root had an init script running, and then some stuff popped up, one of them being the message about joining this channel for help. |
| 03:21 |
phillipjphry |
so I guess I'll just let it run. Silly me. |
| 03:33 |
phillipjphry |
Ok, completed, but threw an error, trying the settings tester again, just going to be patient this time |
| 04:39 |
phillipjphry |
Sorry about all the late night spam. |
| 05:05 |
phillipjphry |
AArrrrrggggghhhhh. I ran through everything, including the troubleshooting guide, and well, now apache won't start. I'm going to just wipe it and try again tomorrow night. |
| 05:05 |
phillipjphry |
Thanks for the wall to yell at. I'll try not to step on anyone's toes. |
| 05:12 |
phillipjphry |
fishyjoes.com is where I've posted my problems. If anyone feels like following up. |
| 05:12 |
phillipjphry |
Thank you. |
| 07:38 |
|
ericar joined #evergreen |
| 07:45 |
|
rjackson_isl joined #evergreen |
| 07:56 |
csharp |
phillipjphry: what instructions are you going by? |
| 08:54 |
Dyrcona |
Bib without titles!? Inconceivable! |
| 08:55 |
|
RoganH joined #evergreen |
| 08:56 |
|
Shae joined #evergreen |
| 08:57 |
jeff |
yeah. |
| 08:57 |
jeff |
To be more accurate, it wasn't that I was making that explicit assumption, I was just failing to properly account for the possibility when I added some new code to process titles. |
| 08:58 |
jeff |
I find myself wanting to write search tests. |
| 08:59 |
Dyrcona |
I mean titles are kind of the whole point, no? |
| 08:59 |
jeff |
Not hard pass/fail so much as "run this test suite to get an idea of how these known searches are performing with regard to these expected results" |
| 08:59 |
Dyrcona |
Heh. "Bibs without titles!? Pointless!" |
| 08:59 |
jeff |
"a search for FOO should turn up the following record or records within the first X results", that kind of thing. |
| 09:00 |
jeff |
Dyrcona: "I don't know the title, but it was blue..." |
| 09:02 |
* Dyrcona |
feels like a kid hopped on sugar. |
| 09:03 |
Dyrcona |
When I stayed with a family in France, the daughter arranged the books on the shelf by size. |
| 09:04 |
Dyrcona |
I don't dare touch the books on the shelf over the desk at home. Move one, and the rest come toppling down. |
| 09:05 |
dbwells |
jeff: Having search tests like you are talking about would be a very valuable thing. Maybe even necessary for regression purposes if we want to try to make bigger changes. |
| 09:06 |
dbwells |
It's really easy to improve specific searches, much harder to improve them all together :) |
| 09:08 |
jeff |
yeah. in experimenting with Elasticsearch over the past few weeks, we've been quite aware that pushing something down over here pushes a bunch of things up over here, etc. |
| 09:09 |
jeff |
(a concept not unique to Elasticsearch, and one that I heard at least one other person reference during hack-a-way discussions) |
| 09:09 |
jeff |
I've been trying to think what it reminds me of. |
| 16:30 |
kmlussier |
Yes, concerto and a given branch. I try ask people to submit their requests ahead of time to give us time to get ready. |
| 16:31 |
jeff |
also, how long do the VMs need to be made available? 24 hours? |
| 16:31 |
jeff |
12 hours? 72 hours? :-) |
| 16:31 |
kmlussier |
jeff: We've gotten to the point where we really could use more Sandboxes. I think I used a community demo server last time around. |
| 16:32 |
kmlussier |
jeff: For a little more than 24 hours. You'll want to have it in Sandbox mode before you leave the day beforehand, and then you could repurpose it the day after Bug Squashing Day. |
| 16:32 |
kmlussier |
jeff: Sometimes, people ask to keep theirs a little longer if they didn't get through testing during the official day. However, the MassLNC Sandboxes can be used after Bug Squashing Day. |
| 16:36 |
Bmagic |
kmlussier: sounds good |
| 16:37 |
kmlussier |
Bmagic: In that case, Sandbox requests should be submitted by the end of the day Thursday, December 10? That will give you Friday and Monday to prepare. Or do you need it to be a little earlier? |
| 16:38 |
Bmagic |
kmlussier: that will be great! |
| 09:15 |
csharp |
@quote add <gmcharlt> for a moment I had fears that Google Telepathy had exited alpha |
| 09:15 |
pinesol_green |
csharp: The operation succeeded. Quote #128 added. |
| 09:23 |
|
maryj joined #evergreen |
| 09:54 |
* jeff |
adds some more complicated mappings to elasticsearch and watches indexing speed drop by one record per second (oh noes!) |
| 09:54 |
* jeff |
tests a theory to confirm where the extra time is being spent |
| 09:55 |
jeff |
okay, bulk of the time is still being spent in fetching records and extracting fields data. |
| 09:55 |
jeff |
(as i'd expect) |
| 09:55 |
jeff |
meaning, i probably won't bother with bulk insert API yet. |
| 09:57 |
|
yboston joined #evergreen |
| 10:03 |
berick |
jeff: i played w/ bulk insert and it increased speed dramatically. |
| 10:04 |
* berick |
was doing a bib/copy parent/child experiment |
| 13:24 |
gmcharlt |
https://evergreen-ils.org/welcome-evergreens-newest-core-committer-kathy-lussier/ |
| 13:25 |
* csharp |
notices bug 1470957 when doing an LP search |
| 13:25 |
pinesol_green |
Launchpad bug 1470957 in Evergreen 2.8 "Items are incorrectly sorting when using the Sort By Publication date feature" [Undecided,New] https://launchpad.net/bugs/1470957 |
| 13:25 |
csharp |
kmlussier++ |
| 13:25 |
csharp |
looks like that just needs a test |
| 13:27 |
jboyer-isl |
kmlussier++ |
| 13:28 |
gmcharlt |
kmlussier++ |
| 13:29 |
berick |
kmlussier++ |
| 13:44 |
dbwells |
kmlussier++ |
| 13:44 |
jboyer-isl |
csharp: are you thinking that bug fix will speed up the searches, or are were you pointing out that it needs a sign-off? I couldn't tell from your reply, but I'm not sure it would effect the search/sort speed. |
| 13:45 |
yboston |
kmlussier++ |
| 13:45 |
dbs |
csharp: kmlussier++ needs a test? |
| 13:45 |
dbs |
because I'm happy to test it: kmlussier++ |
| 13:45 |
dbs |
kmlussier++ |
| 13:45 |
gmcharlt |
let's see if that worked... |
| 13:46 |
gmcharlt |
@karma kmlussier |
| 13:46 |
pinesol_green |
gmcharlt: Karma for "kmlussier" has been increased 161 times and decreased 0 times for a total karma of 161. |
| 13:46 |
kmlussier |
Wait, nobody told me there were tests involved! ;) |
| 13:46 |
kmlussier |
Thanks everyone! |
| 13:47 |
krvmga |
Saw the email announcement just now. Congratulations, Kathy! |
| 13:47 |
krvmga |
kmlussier++ |
| 13:48 |
jboyer-isl |
kmlussier: if 2 unladen african swallows leave the station at the same time, one going east, the other going north... |
| 16:05 |
csharp |
miker: I was chatting with others at the Hack-A-Way about page size - I don't recall the full discussion as to why we're using 10K pages, except that irrelevant results were showing up with the 1K number |
| 16:05 |
csharp |
that was several years ago, before QP improvements |
| 16:05 |
miker |
csharp: yeah, there's risk to smaller page sizes, certainly |
| 16:06 |
csharp |
I'll play with that on one of our test machines and try (and possibly try to find a balance with Elaine ;-)) |
| 16:09 |
miker |
csharp: that won't make things "fast", mind. I think a "show me stuff with this attribute" set of API methods could be, though. |
| 16:09 |
jboyer-isl |
I was looking at some of our 60+s searches in pgbadger and they all appear to be blank keywords with formats, or subject searches . (subject: United States seems to be a favorite.) |
| 16:09 |
miker |
the search query structure assumes search terms of some sort |
| 09:48 |
ldw |
bshum: ah, my change is not necessary then. |
| 09:49 |
gmcharlt |
ldw: http://wiki.evergreen-ils.org/doku.php?id=documentation:technical:jsontutorial - grep for aggregate and having |
| 09:50 |
ldw |
gmcharlt: thank you |
| 09:51 |
pinesol_green |
[evergreen|Bill Erickson] LP#1501471: Stamping SQL update - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6c21348> |
| 09:51 |
pinesol_green |
[evergreen|Galen Charlton] LP#1501471: add some unit tests for batch OU retrieval - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d7e5c77> |
| 09:51 |
pinesol_green |
[evergreen|Galen Charlton] LP#1501471: add DB function for batch retrieval of OU settings - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=be1b6aa> |
| 09:51 |
pinesol_green |
[evergreen|Galen Charlton] LP#1501471: check OU setting view_perms only when needed - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=81e674e> |
| 10:00 |
|
kenstir joined #evergreen |
| 10:00 |
kenstir |
my EG android notes are here: https://docs.google.com/document/d/1KHHpPK7jEl3haEVOvHPCDmOvy3nkSjve6ymD0Rav2cY/edit?usp=sharing |
| 10:02 |
jeff |
kenstir++ |
| 11:13 |
jeff |
but not the idea at hand. ;-) |
| 11:13 |
|
collum_ joined #evergreen |
| 11:14 |
jeff |
It might be useful also to have the contents of said webinar used to seed written resources. |
| 11:17 |
* dbs |
is struck by Dyrcona's note from yesterday about wanting an app for staff--has anyone tested webby with common tablets? |
| 11:19 |
Bmagic |
Is the hackaway on a new hangout today? |
| 11:19 |
jeff |
Bmagic: yes (dunno why): https://goo.gl/72GJ4Z |
| 11:20 |
jeff |
https://goo.gl/72GJ4Z or https://hangouts.google.com/call/veduowhkbtuxw3siics5r3pegia |
| 13:47 |
jeff |
I'm going to look for more examples, but I am also wondering if the relevant xpath libs handle "//mods32:mods/mods32:name[@type='personal' and not(mods32:role/mods32:roleTerm[text()='creator'])]" in a way othan than the Python lxml library (which so far, is the only thing I've compared it with) |
| 13:47 |
jeff |
hack-a-way hangout is still muted, fwiw. |
| 13:48 |
miker |
fwiw, the relevant xpath lib is libxml (native pg XPATH() function) |
| 13:48 |
* jeff |
attempts to test that theory before finding any more examples |
| 13:49 |
jeff |
(will he regret that decision, folks?) |
| 13:49 |
miker |
jeff: //mods32:mods/mods32:name[@type='personal' and not(mods32:role)] |
| 13:49 |
jeff |
oh hey. |
| 13:50 |
miker |
so, it is the existance, in tadl's case :) |
| 14:24 |
alynn26 |
remingtron++ |
| 14:24 |
yboston |
I will move on, because of the hack-a-way |
| 14:24 |
krvmga |
remingtron++ |
| 14:24 |
yboston |
#info 11) yboston will test and sign-off on Launchpad bug 1482336 - allowing release notes with “.adoc” suffix |
| 14:24 |
pinesol_green |
Launchpad bug 1482336 in Evergreen "create_release_notes.sh include .adoc files" [Wishlist,Fix committed] https://launchpad.net/bugs/1482336 |
| 14:24 |
yboston |
I beleive this was pushed to master yesterday |
| 14:24 |
remingtron |
yboston++ |
| 16:01 |
* kmlussier |
double checks |
| 16:02 |
miker |
always look on the bright side of life</python> |
| 16:02 |
bshum |
miker: !!! one hopes :) |
| 16:04 |
miker |
and, looks like no. nexus 6 still in testing |
| 16:06 |
jeffdavis |
that spreadsheet comparing search times is quite useful, thank you to whoever put that together! |
| 16:07 |
jeffdavis |
(and fwiw I expect many of Sitka's search times to get drastically better tomorrow, once I've applied a fix for 1438136) |
| 16:07 |
bshum |
jeffdavis++ |
| 14:15 |
bshum |
If there's nothing else, we shall end early. |
| 14:15 |
bshum |
:) |
| 14:15 |
berick |
#info we installed Hatch on the local PC and did some experimenting w/ printing. some good, some needs work. |
| 14:15 |
gmcharlt |
berick++ |
| 14:15 |
gmcharlt |
csharp++ # testing hatch |
| 14:15 |
bshum |
#endmeeting |
| 14:15 |
pinesol_green |
Meeting ended Wed Nov 4 14:15:39 2015 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
| 14:15 |
dbwells |
Any word on the search discussion time? I'd like to listen in, but have a meeting until 3:30 tomorrow. If it's better earlier, that's alright. |
| 15:09 |
Dyrcona |
I just asked, "Can Evergreen send an email before a patron's account expires?" |
| 15:09 |
Dyrcona |
I said, "Yes, when we upgrade to 2.9." |
| 15:09 |
Dyrcona |
Someone just asked me... duh. |
| 15:13 |
pinesol_green |
Showing latest 5 of 7 commits to Evergreen... |
| 15:13 |
pinesol_green |
[evergreen|Bill Erickson] LP#1384740 MARC stream importer auth release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=465b0e2> |
| 15:13 |
pinesol_green |
[evergreen|Bill Erickson] LP#1384740 MARC stream (etc) use auth nonce - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5cb6e6b> |
| 15:13 |
pinesol_green |
[evergreen|Bill Erickson] LP#1384740 marc_stream_importer no-import repairs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=38050c1> |
| 15:13 |
pinesol_green |
[evergreen|Bill Erickson] LP#1384740 marc_stream_importer test script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ad72cfc> |
| 15:13 |
pinesol_green |
[evergreen|Bill Erickson] LP#1384740 marc_stream_importer auth and cleanup - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=17cc186> |
| 15:14 |
|
_bott_1 joined #evergreen |
| 15:18 |
Dyrcona |
tsbere: Real time updates of thing1-access if you select me in the hangout. It's getting close. |
| 15:18 |
berick |
gmcharlt++ |
| 15:21 |
jboyer-laptaupe |
gmcharlt: lp 1371647 |
| 15:21 |
pinesol_green |
Launchpad bug 1371647 in Evergreen "config.marc21_ff_pos_map needs an audit" [Undecided,New] https://launchpad.net/bugs/1371647 |
| 15:23 |
Dyrcona |
tsbere: I'm going to let it run until it gets bad. I've seen it do this and it usually clears up in a few minutes. |
| 15:24 |
gmcharlt |
RoganH: kenstir: https://evergreen-ils.org/testing/libraries.json |
| 15:24 |
RoganH |
gmchart: thanks! |
| 15:24 |
RoganH |
gmcharlt even! |
| 15:24 |
gmcharlt |
RoganH: yeah, gmchart is off making maps |
| 16:01 |
pinesol_green |
Launchpad bug 924952 in Evergreen "Acquisitions: Order record loads fail when there is a null value in a holdings subfield" [High,Confirmed] |
| 16:05 |
kmlussier |
parts++ |
| 16:06 |
jeff |
it got quiet over there. |
| 16:07 |
gmcharlt |
Dyrcona: bug 1501471 now can haz tests |
| 16:07 |
pinesol_green |
Launchpad bug 1501471 in Evergreen "fetching OU settings in batch can be made faster" [Wishlist,New] https://launchpad.net/bugs/1501471 |
| 16:07 |
berick |
gmcharlt++ |
| 16:07 |
Dyrcona |
gmcharlt++ |
| 16:17 |
* berick |
loads the code |
| 16:17 |
tsbere |
Have you taught SIP to call the stored proc yet? |
| 16:18 |
dbwells |
berick: I'm not sure that's really the issue, although maybe you're just a step ahead of me. |
| 16:18 |
gmcharlt |
Dyrcona: heh, I was thinking that I would have to intentionally break a record in my test database to try out your patch for 1502152 |
| 16:18 |
gmcharlt |
as it happens... NOT NECESSARY. :) |
| 16:19 |
Dyrcona |
Yeah, just some weird characters are enough. |
| 16:19 |
ldw |
what is the preferred way to send a message in dojo (ie not alert). |
| 16:19 |
ldw |
? |
| 16:38 |
berick |
ok, i see |
| 16:38 |
dbwells |
The second call is if we authenticated via 3rd party. |
| 16:38 |
dbwells |
okay |
| 16:38 |
berick |
for non-native, it's just testing the password |
| 16:38 |
berick |
well, it's faking an internal login |
| 16:38 |
berick |
by loading the password |
| 16:38 |
berick |
and sending it on to aut |
| 16:39 |
dbwells |
yes |
| 16:40 |
berick |
hmm |
| 16:41 |
dbwells |
It was the simplest way to get all the trappings of a normal login without messing with auth or duplicating the token code, etc. Of course we're messing with auth now, so it makes sense to me to find a more direct path. |
| 16:51 |
berick |
dbwells: that would work |
| 16:52 |
dbwells |
It would limit the duality of the code, I think, but maybe overkill? I'm not sure. |
| 16:52 |
berick |
well, it would be good to have it all going through one entry point, since Perl vs. C memcache clients have been known to push the same key to different servers |
| 17:08 |
pinesol_green |
Showing latest 5 of 6 commits to Evergreen... |
| 17:08 |
pinesol_green |
[evergreen|Galen Charlton] LP#1251415: (follow-up) update release note extension - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fef3298> |
| 17:08 |
pinesol_green |
[evergreen|Bill Erickson] LP#1251415: juv-to-adult release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1b142be> |
| 17:08 |
pinesol_green |
[evergreen|Bill Erickson] LP#1251415: Juv-to-adult live test - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3f46924> |
| 17:08 |
pinesol_green |
[evergreen|Bill Erickson] LP#1251415: Skip deleted users in juvenile update - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3b630bd> |
| 17:08 |
pinesol_green |
[evergreen|Steven Callender] LP#1251415: Use the juvenile setting when removing juvenile flag. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0fd4ecc> |
| 18:12 |
|
bmills joined #evergreen |
| 19:00 |
|
rlefaive joined #evergreen |
| 22:30 |
|
RoganH joined #evergreen |
