| 08:08 |
|
rlefaive joined #evergreen |
| 08:13 |
JBoyer |
The rest were lost in the great desktop reimage of '16. Now they're mostly bugs I have a branch for myself. |
| 08:15 |
JBoyer |
bug 1593834 is fairly low impact and will end the scourge of Android email clients assuming our mail is sent from the beginning of unix time. |
| 08:15 |
pinesol_green |
Launchpad bug 1593834 in Evergreen "Date header not set in default A/T email templates" [Low,New] https://launchpad.net/bugs/1593834 |
| 08:15 |
pinesol_green |
[evergreen|Jason Stephenson] LP 1306666: Abort Transit Only Change Copy Status if In Transit - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cfe5110> |
| 08:15 |
pinesol_green |
[evergreen|Jason Stephenson] LP 1306666: Add Perl tests for new behavior. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5f1362f> |
| 08:15 |
pinesol_green |
[evergreen|Mike Rylander] LP#1306666: Rename test file - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d3e3f3b> |
| 08:15 |
JBoyer |
(I was hesitant to set the milestone to anything but 2.next because I thought the RMs were doing that.) |
| 08:16 |
|
rlefaive joined #evergreen |
| 08:24 |
|
kmlussier joined #evergreen |
| 08:27 |
miker |
JBoyer: I'd call that a bug fix, fwiw, but, I'm 'bout to merge it to master and 2.10 |
| 08:27 |
kmlussier |
I would like to advocate for bug 1612274 if somebody wants to look at it. |
| 08:27 |
pinesol_green |
Launchpad bug 1612274 in Evergreen "Improvements to My Account Holds Screens" [Wishlist,Confirmed] https://launchpad.net/bugs/1612274 |
| 08:31 |
kmlussier |
I also wondered what the likelihood is of bug 1596595 getting in. I'm not in a position to test it myself since I would want to use a test system with production data, but we have a lot of interest in seeing faster holds targeting. |
| 08:31 |
pinesol_green |
Launchpad bug 1596595 in Evergreen "Hold targeter features and refactoring" [Wishlist,New] https://launchpad.net/bugs/1596595 |
| 08:31 |
pinesol_green |
[evergreen|Jason Boyer] LP1593834: Add Date Header to A/T Email Examples - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=780f40a> |
| 08:33 |
JBoyer |
miker, I suppose it's a seed data bug fix, the real benefit for existing installations is the brief documentation (if they don't follow LP). |
| 09:19 |
Dyrcona |
I didn't look to see if we explicitly enable it, or the package is doing it, now. |
| 09:19 |
kmlussier |
miker: Yes, I have time now. |
| 09:19 |
miker |
kmlussier: cool. I'll push those bug fixes, then. thanks! |
| 09:21 |
* Dyrcona |
will do his best to test the tz branch today, but time is not on his side. |
| 09:21 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1614807: Fix Circ History table header display on small screens - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4c16071> |
| 09:21 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1614807: Holds history should look like other My Account screens - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4e1ab37> |
| 09:21 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1614807: Fix spacing issues in responsive design for My Account screens - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f414ddd> |
| 10:28 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1612274: Release notes for improved holds interfaces - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=36f3313> |
| 10:29 |
miker |
dbwells: re bug 1315552, is http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbwells/lp1315552_fix_duplicates_in_ranked_volumes the correct branch still? |
| 10:29 |
pinesol_green |
Launchpad bug 1315552 in Evergreen "Duplicate initial search results where copy circ lib/call number owning lib are different" [Medium,Confirmed] https://launchpad.net/bugs/1315552 |
| 10:34 |
berick |
just updated to master.., upgrade/0990.data.copy-count-badge.sql not happy. could be my janky test db.. |
| 10:34 |
berick |
ERROR: null value in column "id" violates not-null constraint |
| 10:34 |
berick |
DETAIL: Failing row contains (null, Copy Count, null, rating.copy_count, f, f, t). |
| 10:39 |
berick |
maybe id should be a SERIAL? |
| 10:39 |
berick |
in rating.popularity_parameter |
| 10:40 |
* berick |
has not been following that branch closely |
| 10:49 |
kmlussier |
Oof. I guess I didn't test the upgrade script on that one. |
| 10:49 |
miker |
berick: I'll fix it. it needs to be a pinned ID |
| 10:50 |
* berick |
nods |
| 10:51 |
miker |
pushed |
| 10:51 |
miker |
berick: thanks for testing! |
| 10:54 |
pinesol_green |
[evergreen|Mike Rylander] Correct upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=58fc8f0> |
| 11:06 |
|
akilsdonk joined #evergreen |
| 11:07 |
Stompro |
Does anyone know off the top of their heads if meta holds not showing up in catalog hold counts is expected behavior? I tried to find a bug report on that, to see if anyone had suggested changes in that area, but didn't find anything. Is that configurable? |
| 12:02 |
pinesol_green |
[evergreen|Mike Rylander] Stamping upgrade script for ranked-volumes update - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=51759b2> |
| 12:04 |
|
rlefaive joined #evergreen |
| 12:10 |
miker |
berick: I've signed off your commits to the is_available branch ... want to look at the branch one last time, or are you happy with it? |
| 12:10 |
berick |
miker: i'm happy with it. did a few more tests this a.m. |
| 12:11 |
berick |
gracias |
| 12:12 |
miker |
kk |
| 12:12 |
berick |
miker: did you see the comment on bug #1588948 I added just before you posted your code? |
| 12:12 |
miker |
grabbing 0992 |
| 12:12 |
pinesol_green |
Launchpad bug 1588948 in Evergreen "Authority update propagation should update bib record editor and edit_date" [Undecided,New] https://launchpad.net/bugs/1588948 |
| 12:14 |
miker |
berick: update_headings_tgr is a BEFORE trigger, and aaa_auth_ingest_or_delete is an AFTER, so they run in the right order already |
| 12:14 |
berick |
miker: oh! nevermind then |
| 12:14 |
berick |
thanks |
| 12:15 |
berick |
i'll test that branch |
| 12:15 |
miker |
(I had the same thought, so doublechecked when looking for the best place to insert the check) |
| 12:15 |
|
jihpringle joined #evergreen |
| 12:22 |
pinesol_green |
Showing latest 5 of 7 commits to Evergreen... |
| 12:36 |
miker |
ok, thanks. I'm calling it a feature for backporting purposes, then :) |
| 12:38 |
miker |
grabbing 0993 |
| 12:42 |
csharp |
miker: if my branch for bug 1612752 gets accepted, it would theoretically be possible to "unwrap" the status on canceled transit checkin too, right? |
| 12:42 |
pinesol_green |
Launchpad bug 1612752 in Evergreen "Feature Request: Cancel Transits, Don't Delete Them" [Wishlist,Confirmed] https://launchpad.net/bugs/1612752 - Assigned to Chris Sharp (chrissharp123) |
| 12:42 |
pinesol_green |
[evergreen|Bill Erickson] LP#1570909 User activity transient default - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b1f4d59> |
| 12:42 |
pinesol_green |
[evergreen|Bill Erickson] LP#1570909 User activity purge function - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ea8b2ae> |
| 12:42 |
pinesol_green |
[evergreen|Bill Erickson] LP#1570909 User activity purge pgtap test - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fc5b3ec> |
| 12:42 |
pinesol_green |
[evergreen|Bill Erickson] LP#1570909 User activity purge release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cfad22b> |
| 12:42 |
pinesol_green |
[evergreen|Mike Rylander] Stamping upgrade script for transient usr_activity - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=95ea3d5> |
| 12:43 |
miker |
csharp: not sure I follow. If an item got into Canceled Transit, and then transited (was scanned somewhere) the transit home would carry the Canceled Transit status and the copy would end up with that until a user did something about that ... is that what you mean? |
| 12:44 |
miker |
(that's the case regardless of whether we restrict the situations we make use of Canceled Transit, though) |
| 12:45 |
miker |
ah, you mean "the data still exists because it's on a closed transit" |
| 12:59 |
csharp |
I was trying to keep the features separate in case one didn't get accepted, the other still had a chance |
| 12:59 |
|
bmills joined #evergreen |
| 13:00 |
miker |
I'm concerned that we'd be trading confusion for (effectively, to the user) lost data, unless we have something that pulls the old status from the canceled transit and uses that for any /new/ transit. which, I think, would fix the issue for remote aborts that re-transit. |
| 13:00 |
pinesol_green |
Showing latest 5 of 6 commits to Evergreen... |
| 13:00 |
pinesol_green |
[evergreen|Bill Erickson] LP#1588948 Authority propagation PGTAP test - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7605ed8> |
| 13:00 |
pinesol_green |
[evergreen|Bill Erickson] LP#1588948 Release notes (auth prop. bib edit[or|_date]) - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8e95974> |
| 13:00 |
pinesol_green |
[evergreen|Bill Erickson] LP#1588948 Auth propagate bib meta on change only - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d61a652> |
| 13:00 |
pinesol_green |
[evergreen|Mike Rylander] LP#1588948: Only attempt a bib update if the heading changes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=84bed71> |
| 13:00 |
pinesol_green |
[evergreen|Mike Rylander] Stamping upgrade script for authority edit changes and propagation improvement - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1215938> |
| 13:07 |
|
serflog joined #evergreen |
| 13:07 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged: http://irc.evergreen-ils.org/evergreen | Large pastes at http://paste.evergreen-ils.org |
| 13:08 |
|
jyorio joined #evergreen |
| 13:09 |
|
tarac_ joined #evergreen |
| 13:34 |
berick |
kmlussier: thanks for testing bug #1497335. investingating now... |
| 13:34 |
pinesol_green |
Launchpad bug 1497335 in Evergreen "Display aged circulations for copies (was: "virtually aged circulations")" [Wishlist,New] https://launchpad.net/bugs/1497335 |
| 13:35 |
* berick |
will also rebase |
| 13:36 |
kmlussier |
berick: Thanks! |
| 13:36 |
kmlussier |
Unfortunately, I can't test it in the web client at the moment. |
| 13:37 |
csharp |
miker: I'm looking to change my canceled transit status branch (bug 1613374) so that it checks the stored copy status... how much time do I have before you call the beta done? :-) |
| 13:37 |
pinesol_green |
Launchpad bug 1613374 in Evergreen "Feature Request: "Canceled Transit" Item Status" [Wishlist,Confirmed] https://launchpad.net/bugs/1613374 - Assigned to Chris Sharp (chrissharp123) |
| 13:39 |
miker |
csharp: commit by EOB today, or whenever level3 decides to stop having problems, whichever comes later ;) |
| 09:47 |
csharp |
heh |
| 09:55 |
berick |
kmlussier: no backsies |
| 09:55 |
kmlussier |
berick: Ha ha. I guess I should get working then! |
| 10:39 |
* mmorgan |
always seems to find more bugs when testing bugs. |
| 10:39 |
bshum |
Testing bugs or testing bug fixes? :P |
| 10:40 |
Dyrcona |
Both! :) |
| 10:40 |
mmorgan |
:) |
| 10:43 |
|
maryj joined #evergreen |
| 12:03 |
|
mrpeters joined #evergreen |
| 12:05 |
|
rlefaive joined #evergreen |
| 12:06 |
|
jihpringle joined #evergreen |
| 12:17 |
csharp |
mmorgan: I think it's good for now - I was just about to look into creating a perl test for the branch - I'll prolly need help :-) |
| 12:23 |
csharp |
Dyrcona: I think I remember you mentioning that you might genericize your live_t for bug 1306666 for general transit testing - looking at it now, I tend to agree |
| 12:23 |
pinesol_green |
Launchpad bug 1306666 in Evergreen 2.9 "When Aborting a Transit, items should not automatically get a status change." [Low,Confirmed] https://launchpad.net/bugs/1306666 |
| 12:23 |
Dyrcona |
csharp: Part of the reason it is so long is that this feature had no tests. |
| 12:24 |
csharp |
right, I can see that |
| 12:24 |
Dyrcona |
It needs to be in live_t because it requires concerto for copies, patrons, etc. |
| 12:24 |
bshum |
100.00% spanish translation; 0 strings remaining. Sweet! (at least till we do the next POT sync up from all the stuff that went into master) |
| 12:24 |
Dyrcona |
I got hung up getting the copy to transit again after the hold transit was aborted by the receiving library. |
| 12:25 |
csharp |
anahi++ |
| 12:26 |
Dyrcona |
I think my vm is presently rigged for the timezone branches, so I'll need to reinstall the code for that branch to continue working on it. |
| 12:26 |
Dyrcona |
Anyway, csharp, if you want help with Perl tests, let me know. |
| 12:27 |
jeff |
Dyrcona: did you determine what your TZ issues were the other day? |
| 12:27 |
csharp |
Dyrcona++ # thanks |
| 12:28 |
mmorgan |
csharp: Thanks. It's looking good to me so far. |
| 12:30 |
Dyrcona |
I think I'll build a fresh vm and install everything again. |
| 12:30 |
Dyrcona |
But that's for later. I have to go, now. |
| 12:46 |
|
bmills joined #evergreen |
| 12:59 |
jeff |
Dyrcona: when you get back... in your testing were you seeing holds being created hours in the past / future, or were you just seeing action.hold_request.request_time displayed with the server TZ of +00? |
| 12:59 |
jeff |
Dyrcona: because the latter should be fine... |
| 13:07 |
jeff |
Dyrcona: holds might not be the best thing to test with. |
| 13:07 |
jeff |
but that does open the question of "how should this be tested". :-) |
| 13:08 |
jeff |
I don't think that anything in 1485374 adds support to xul or web staff clients to pass timezone to the server. |
| 13:12 |
jeff |
oh, actually... webstaff is probably covered by the changes in 1485371, the opensrf companion to that bug. |
| 13:12 |
csharp |
oooh - perl tests go deep |
| 13:13 |
* csharp |
stares in awe at https://metacpan.org/pod/Test::More |
| 13:15 |
csharp |
Dyrcona: since your test is almost exactly what I need, any objections about me using it outright and modifying where necessary? |
| 13:15 |
csharp |
seems like we would benefit from having some solid boilerplate files for this kind of thing |
| 13:16 |
csharp |
or a set of custom functions (e.g., create a workstation at a branch/some branches) |
| 13:18 |
csharp |
ah - OpenILS/Utils/TestUtils.pm has that stated purpose at the top of the file :-) |
| 14:31 |
|
ericar_ joined #evergreen |
| 14:54 |
|
tspindler joined #evergreen |
| 14:56 |
tspindler |
Dyrcona: running apt-install and apt-update worked and ./configure --prefix=/openils --sysconfdir=/openils/conf executed |
| 16:00 |
Dyrcona |
:) |
| 16:02 |
Dyrcona |
One draw back of the way that I build vms for Xenial is that I have to login with virt-viewer or the other console to reconfigure the network interface. |
| 16:03 |
Dyrcona |
All right, I'll start over on the timezone branch with everything clean. |
| 16:14 |
jeff |
Dyrcona: did you see my earlier comments about that, and asking what exactly was looking incorrect in your test? |
| 16:15 |
Dyrcona |
Yes, did you see my answers? |
| 16:15 |
Dyrcona |
The server on a vm is UTC. The client, my laptop, is EDT. |
| 16:15 |
* jeff |
scrolls up for answers |
| 16:16 |
Dyrcona |
I thought when I placed a hold from the OPAC, it would get the EDT timezone, but the database shows UTC. |
| 16:16 |
Dyrcona |
So, maybe I misunderstand the intent, or I had something wrong. |
| 16:16 |
Dyrcona |
That's why I'm going with a clean install on a clean VM, to make sure there's no crud interfering. |
| 16:16 |
jeff |
09:59:09 < jeff> Dyrcona: when you get back... in your testing were you seeing holds being created hours in the past / future, or were you just seeing action.hold_request.request_time displayed with the server TZ of +00? |
| 16:17 |
Dyrcona |
I missed that one. :) |
| 16:17 |
jeff |
heh. |
| 16:17 |
Dyrcona |
The timestamp on the hold was good, just UTC, not EDT. |
| 16:17 |
Dyrcona |
Meaning, it was four hours in the future. |
| 16:17 |
Dyrcona |
Right. |
| 16:18 |
Dyrcona |
I'll reread the bug more carefully and check the code. |
| 16:18 |
jeff |
10:07:07 < jeff> Dyrcona: holds might not be the best thing to test with. |
| 16:18 |
jeff |
10:07:27 < jeff> but that does open the question of "how should this be tested". :-) |
| 16:18 |
Dyrcona |
I'm going to install opensrf master and collab/miker/lp1485374-always-use-client-tz-rebase |
| 16:18 |
Dyrcona |
Yep. |
| 16:19 |
Dyrcona |
I'll take a deeper look this time. |
| 16:26 |
jeff |
Dyrcona: the important part is that they be the correct value... which i'm pretty sure will be the case for a hold request with and without the timestamp support. |
| 16:26 |
jeff |
i've been looking at it, but don't want to be the only one looking at it. :-) |
| 16:27 |
Dyrcona |
So, I should try something like changing a due date where there are reports of times being wrong? |
| 16:27 |
jeff |
so, my comment about holds might not be the best thing to test with. |
| 16:27 |
* jeff |
nods |
| 16:27 |
Dyrcona |
Right. |
| 16:27 |
jeff |
pretty sure that will be a better before/after test. |
| 16:27 |
Dyrcona |
Thanks. I'll do that, also. |
| 16:28 |
jeff |
there are other things that will be interesting (nothing new), like dob. |
| 16:28 |
Dyrcona |
Guess I'll build a xul client and the browser staff client. |
| 16:28 |
jeff |
i don't know if the xul client will get benefit of timezones. |
| 16:28 |
Dyrcona |
Well then, I'll skip it. |
| 16:28 |
Dyrcona |
I haven't been building xul clients for the vms on my laptop. |
| 16:29 |
jeff |
web staff client gets it by nature of opensrf.js having support added in the OpenSRF bug (code in master), but I don't think (haven't looked/tested) that benefits the XUL client. |
| 16:29 |
jeff |
some embedded interfaces might get it. |
| 16:29 |
Dyrcona |
It probably doesn't. |
| 16:29 |
Dyrcona |
Maybe a dojo interface or two, yeah. |
| 16:34 |
Dyrcona |
Hmm. It might be interesting to get opensrf.js working with node... Then you could write command code for Evergreen in JavaScript. |
| 12:51 |
|
gsams joined #evergreen |
| 12:51 |
Dyrcona |
Not until after I changed the capture time on the hold, which puzzles me. |
| 12:54 |
Dyrcona |
I'll do some more experimentation later. I'd like to see the real differences in what's going on for myself. |
| 12:54 |
miker |
the change that let it work was the hold getting retargeted |
| 12:55 |
miker |
after the copy became available or equivalent |
| 12:59 |
miker |
if the problem to solve is "don't break circs" then the first "if" test in my branch is enough. if the problem is "staff are confused" the the status dance is needed. but the status dance kills immediate recapture via op-capture because the hold gets retargeted after the copy becomes untargetable |
| 13:01 |
miker |
if we add the canceled-transit status, per csharp, and allow it to be holdable, op-capture will work as before |
| 13:01 |
miker |
on top of my branch, I mean |
| 13:03 |
miker |
I think we'll really want berick's is_available branch, too, and make the new status true for that flag |
| 13:03 |
miker |
otherwise we'll get warnings at the eventual hold dest |
| 13:03 |
Dyrcona |
Hmm. What you're saying makes sense, but I'm not sure that it completely supports what I think I saw. :) |
| 13:04 |
Dyrcona |
I'll do some looking later. |
| 13:04 |
miker |
k |
| 13:45 |
Dyrcona |
Missing comma on line 667 of oils_auth.c. |
| 13:46 |
miker |
huh. must have missed that in a conflict on rebase. soory :) |
| 13:47 |
Dyrcona |
NP. |
| 14:28 |
Dyrcona |
Hmm. I'm not really certain how to test that branch. I tried placing holds from the OPAC, but the times are in UTC. |
| 14:29 |
Dyrcona |
I tried a SetENV TZ America/New_York in the Apache config for the /opac location and restarted, but that didn't seem to do anything either. |
| 14:48 |
|
bmills joined #evergreen |
| 15:10 |
csharp_ |
I was just going to finally comment out the PINES reporting views by default in fm_IDL.xml, but I can see that other non-PINES tables have been added to the PINES section |
| 09:31 |
* csharp |
is looking now |
| 09:32 |
csharp |
I would bet the dependencies go deep if we look hard enough - an isolated bug report might be the tip of an iceberg |
| 09:32 |
Dyrcona |
Yeah, they sometimes are. |
| 09:35 |
Dyrcona |
I'll load 130666 on a personal vm and see if the perl tests I wrote still work. They may need to be changed or we may want to add one or two given miker's changes to the code. |
| 09:36 |
Dyrcona |
If I'm not satisfied with that, then I might check if it's OK to use my old vm at MVLC with real life data. |
| 09:42 |
Dyrcona |
csharp++ # It's fun trying to hit a moving target. |
| 09:42 |
csharp |
heh |
| 10:07 |
jeff |
i believe you can safely ignore that. |
| 10:07 |
Dyrcona |
OK. |
| 10:07 |
jeff |
something in the dependency chain is listing it as a nice-to-have. |
| 10:08 |
Dyrcona |
miker: Looks like my xenial vm would be perferct for testing timezone stuff. It insists on being set to UTC and my laptop is presently EDT. :) |
| 10:12 |
csharp |
@quote add < jeff> when i see "this branch needs a rebase" i hear it in a jack nicholson voice, every time. |
| 10:12 |
pinesol_green |
csharp: The operation succeeded. Quote #157 added. |
| 10:19 |
berick |
well now we all do |
| 10:21 |
csharp |
Dyrcona++ |
| 10:21 |
* Dyrcona |
has a hard time hearing it in a Homer Simpson voice, but Sean Connery.... |
| 10:22 |
Dyrcona |
And, eg_db_config --load-all-sample is done. |
| 10:26 |
Dyrcona |
Well, the tests did fail, but not exactly how I expected them to fail. |
| 10:27 |
Dyrcona |
Failed test ''Got hold transit copy' isa 'Fieldmapper::action::hold_transit_copy'' |
| 10:27 |
Dyrcona |
Oh, wait. Failures started before that test. ;) |
| 10:29 |
Dyrcona |
OK. Failures start at subtests of test 13, which is more or less where I might expect it. |
| 10:29 |
* Dyrcona |
makes a collab branch based on miker's changes. |
| 10:30 |
Dyrcona |
Test 14, rather. |
| 10:30 |
* Dyrcona |
can't read today, apparently. |
| 10:47 |
|
Christineb joined #evergreen |
| 10:52 |
* miker |
tests new tz branch... |
| 10:59 |
* Dyrcona |
"numbers" the tests in the test script. |
| 11:05 |
|
rlefaive_ joined #evergreen |
| 11:06 |
Dyrcona |
I think I'm going to remove the lp number from the test file, because csharp will need to alter the tests for the new copy status branch. |
| 11:07 |
Dyrcona |
Eh, maybe I'll leave it for now and we can sort it out later. |
| 11:07 |
JBoyer |
"rm it all and let the fs sort it out." |
| 11:10 |
miker |
Dyrcona: updated TZ branch for evergreen located at http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/miker/lp1485374-always-use-client-tz-rebase |
| 11:10 |
Dyrcona |
miker++ # I'll take a look after working on these tests. |
| 11:25 |
csharp |
@quote add < JBoyer> "rm it all and let the fs sort it out." |
| 11:25 |
pinesol_green |
csharp: The operation succeeded. Quote #158 added. |
| 11:35 |
|
bmills joined #evergreen |
| 11:58 |
Dyrcona |
It has been checked in twice at the home library and doesn't fill the hold again after either one. |
| 11:59 |
berick |
should name the canceled transit copy status "stranded" or "stuck at O'Hare" |
| 11:59 |
mmorgan |
Even after you changed it to available? |
| 11:59 |
Dyrcona |
I haven't tried that yet. I have to reload concerto after each failed test run. |
| 12:00 |
Dyrcona |
I'm first going to verify the copy status in the tests after each step. |
| 12:03 |
|
kmlussier joined #evergreen |
| 12:04 |
|
brahmina joined #evergreen |
| 12:12 |
|
bmills joined #evergreen |
| 12:17 |
miker |
in case anyone was talking in my direction |
| 12:18 |
miker |
yeah, quassel core is acting up a lot recently... |
| 12:23 |
bshum |
Poor quasselcore :( |
| 12:23 |
Dyrcona |
I was just speaking in general how holds appear to be trapping differently for me in concerto today and it's more or less the same branch when the tests all passed before. |
| 12:23 |
Dyrcona |
I'm trying tricks to see what I need to do. |
| 12:24 |
Dyrcona |
A script to stop services, reload concerto into the db, and start services again has come in real handy. |
| 12:25 |
tsbere |
Dyrcona: Heh, I have a bash alias to do that for me on my dev machine. :D |
| 12:26 |
* dbs |
wonders if Dyrcona is finding out why our holds aren't getting trapped at checkin -- this is the TZ testing? |
| 12:28 |
Dyrcona |
dbs: It could be, but I'm doing it all on the server where everything is UTC. |
| 12:29 |
Dyrcona |
Maybe it was EDT last time.... I believe I did make a new VM since then. |
| 12:29 |
Dyrcona |
It traps the first time, but after aborting the transit and checking the copy in again, it's not trapping. |
| 09:54 |
|
ericar_ joined #evergreen |
| 10:10 |
|
jwoodard joined #evergreen |
| 10:11 |
* mmorgan |
has always been curious about this: What is the purpose of the script_test field in config.circ_matrix_matchpoint? |
| 10:12 |
berick |
mmorgan: it does nothing today. the hope was to support optional/additional script-based tests, to cover logic that's not supported directly in the circ matrix. |
| 10:13 |
berick |
similar to the old-school circ rules, which were script based and quite powerful IF you knew what you were doing |
| 10:13 |
tsbere |
I was once going to code that in when I re-wrote things (probably as a "call this DB function" instead though) but I am not likely to re-write circ stuff anytime soon. If ever. |
| 10:14 |
mmorgan |
Ah. I was wondering if it was a vestige of the past, or a placeholder for the future. A little bit of both, I guess! |
| 10:20 |
jeff |
plv8! |
| 10:30 |
bshum |
https://bugs.launchpad.net/evergreen/+bug/1545115 |
| 10:31 |
pinesol_green |
Launchpad bug 1545115 in Evergreen "config.circ_matrix_matchpoint and config.hold_matrix_matchpoint need a description field" [Wishlist,New] |
| 10:31 |
bshum |
Still wip by rhamby, but if we're all thinking about touching the matrix tables |
| 10:32 |
rhamby |
That was a bit while bach bshum but at that time it tested fine in master for me but I don't think anyone else test drove it. |
| 10:32 |
rhamby |
back even. Though some bach would make good listening right now. |
| 10:34 |
rhamby |
jeff: I thought about making a patch to change all circ matrix rules match strange unicode and require people to use a 1956 new york phone book as a key to decrypt it but never got around to it |
| 10:36 |
jeff |
JBoyer: joking aside, what did you have in mind for applying the new feature? |
| 10:38 |
tsbere |
JBoyer: I personally think you are going to have issues there, but I have ideas for how to implement. But I suspect other things already there would be better choices. <_< |
| 10:38 |
JBoyer |
jeff, Currently we have multiple circ mods like so: dvd, dvd new, dvd r-rated, dvd r-rated new, and so on. I want to remove the new-ness and r-rated-ness and make them stat cats that can just be applied to a 'dvd' circ mod'd item. |
| 17:05 |
kmlussier |
miker: The webclient code you've been merging - does that make it on to webby? |
| 17:05 |
miker |
kmlussier: it can, but it's not there yet |
| 17:06 |
miker |
kmlussier: I'll push it out now |
| 17:06 |
kmlussier |
miker: Thanks! |
| 17:07 |
|
mmorgan left #evergreen |
| 17:07 |
kmlussier |
Actually, I guess I wasn't so much asking about the merged code as the code that's being added to the sprint 3 branch. Because the merge code doesn't need testing, does it? |
| 17:07 |
* miker |
tells bower to do its thing |
| 17:08 |
miker |
kmlussier: it doesn't hurt for more eyes to be on it |
| 17:08 |
kmlussier |
true enough |
| 17:25 |
jeff |
yeah. |
| 17:25 |
jeff |
got it. :-) |
| 17:27 |
hbrennan |
Sad that I'm debating whether to save $6/year per OPAC (we only have four total, too) |
| 17:27 |
Stompro |
Has anyone had any issues with the circ history sorting? I cannot get it to work on our test system. I have 226 items in my history, and that seems to be too much for it to handle. |
| 17:28 |
hbrennan |
jeff++ I'll check out Web Converger after lunch |
| 17:40 |
jeffdavis |
Stompro: that rings a bell, but I can't recall any details or find a record of the problem in our ticketing system |
| 17:40 |
jeffdavis |
</unhelpful> |
| 11:03 |
Dyrcona |
Bmagic: That should be fine. |
| 11:03 |
|
mmorgan joined #evergreen |
| 11:04 |
|
Christineb joined #evergreen |
| 11:04 |
Bmagic |
on my test machine, that line is present and I could launch the sip server and login to it, but I didnt test anything else |
| 11:24 |
jeff |
Bmagic: can you sum up what you're trying to do/fix? |
| 11:24 |
Bmagic |
it started with me installing SIPServer on xenial |
| 11:24 |
Bmagic |
turns out UNIVERSAL module is depricated in perl 5.22 and beyond |
| 14:55 |
Dyrcona |
I think I would trust the copy status over the existence of a transit. |
| 14:55 |
Dyrcona |
Which is where I was coming from, only change the copy status if the copy status is in transit. |
| 14:56 |
Dyrcona |
A new status for canceled transit is fine with me. |
| 14:59 |
* csharp |
runs off to test his branch before referring to it in the original bug thread |
| 15:00 |
* mmorgan |
saw bug 1612754 and overlooked the one about the status |
| 15:00 |
pinesol_green |
Launchpad bug 1612754 in dpkg (Ubuntu) "package openssh-client 1:7.2p2-4ubuntu1 failed to install/upgrade: package openssh-client is already installed and configured" [Undecided,New] https://launchpad.net/bugs/1612754 |
| 15:00 |
csharp |
jeff: OPERATION KRYPTONITE? |
| 15:07 |
mmorgan |
I'm warming up to the idea of a new status for cancelled transits |
| 15:09 |
Dyrcona |
It complicates things a bit. It will need to be added to relevant lists of what different statuses to look for in certain situations and so on. |
| 15:10 |
Dyrcona |
Some parts of the code only look for copies with certain statuses, and those places will need to be examined to determine if they should look at this new status as well. |
| 15:10 |
csharp |
Dyrcona: right - I was wondering about that |
| 15:10 |
csharp |
so my branch is not complete since I haven't considered that yet |
| 15:12 |
csharp |
also, I will definitely need guidance on writing perl tests for my changes, but not today |
| 15:13 |
mmorgan |
I would think it could avoid a lot of confusion for the end user, though. |
| 15:13 |
csharp |
well, the reason I went that direction (completely unaware of the discussion on the older bug) was that it's a clear signal to staff what happened to their item |
| 15:14 |
csharp |
it feels kind of unsubtle, but it may be a good solution |
| 11:25 |
krvmga |
:) |
| 11:26 |
JBoyer |
dbs, Ah, I see. I wasn't sure if you had a file full of records that needed changed or if they were indb, etc. |
| 11:28 |
|
bmills joined #evergreen |
| 11:40 |
* tsbere |
hates being asked to log dive with no indication as to how far back he may need to look |
| 11:56 |
tsbere |
gmcharlt: Any chance you can take a quick look at my marc-perl pullrequest changes and let me know if you think they may cause significant issues? I want a second opinion at least before I throw it in our production system for a real world test. |
| 11:58 |
|
brahmina joined #evergreen |
| 12:01 |
gmcharlt |
tsbere: gut reaction - they're unlikely to cause significant issues, and I'll likely merge it soon after writing some test cases |
| 12:02 |
gmcharlt |
my only quibble at the moment is whether to add a flag to specify a strict input mode that squawks if \035 is found inside a record, as there's no (known-to-me) character encoding for MARC records where that would be permissible |
| 12:04 |
Dyrcona |
gmcharlt: I've seen a number of MARC records in the wild that do not use valid character encodings for MARC, and sometimes different fields in the same record have different encodings. |
| 12:04 |
Dyrcona |
But, I'm going to lunch, so.... ;) |
| 12:04 |
gmcharlt |
Dyrcona: well yes :) |
| 17:03 |
kmlussier |
This would be another good thing to document someday. |
| 17:03 |
Bmagic |
perl 5.22 is default. SIPServer uses UNIVERSAL which complains upon install in cpan |
| 17:04 |
hbrennan |
kmlussier++ |
| 17:05 |
kmlussier |
hbrennan: OK, so what you are using is a library setting to prevent renewals for copies when there are holds on its record. Rather than using the library setting, you can configure your policies to prevent the renewals in a more sophisticated way. |
| 17:05 |
kmlussier |
hbrennan: The mailing list link is here http://georgialibraries.markmail.org/thread/njevrzhizdugshwd |
| 17:05 |
kmlussier |
hbrennan: I mention a bug in that thread, but that bug has since been fixed. I don't know if any of our sites are using it, but, in my testing, the ratios work fairly well now. |
| 17:06 |
Dyrcona |
Bmagic: The require UNIVERSAL::require or the UNIVERSAL::can line? |
| 17:06 |
Bmagic |
use UNIVERSAL qw(can); |
| 17:07 |
Bmagic |
package Sip::MsgType; |
| 17:37 |
kmlussier |
Anyway, time to take my daughter out for dinner. That is, if I want to brave the thunderstorm. |
| 17:37 |
kmlussier |
Have a nice weekend to everyone who's still here! |
| 18:02 |
|
_adb left #evergreen |
| 18:42 |
bshum |
gmcharlt: FYI, I started testing your branch for moving mod_perl over from OpenSRF to Evergreen, but still encounter a few issues |
| 18:42 |
bshum |
Specifically, I think https://bugs.launchpad.net/opensrf/+bug/1585041 is still needed for Jessie |
| 18:42 |
pinesol_green |
Launchpad bug 1585041 in OpenSRF "Fix OpenSRF debian_sys_config order for Debian" [Medium,New] - Assigned to Galen Charlton (gmc) |
| 18:44 |
bshum |
Or hmm |
| 18:46 |
bshum |
Nope, yep, we still need to rearrange things for Jessie to install pre-reqs right |
| 15:27 |
kmlussier |
For the alpha release, should a message go out on the list so that people know about it? |
| 15:27 |
miker |
kmlussier: it should have, and that's on me |
| 15:28 |
miker |
I can send one out |
| 15:28 |
kmlussier |
miker: OK, I'll add that as an action item. |
| 15:28 |
kmlussier |
miker: Also, we'll be looking at the sprint 3 branch here, but I don't know how much testing we can do before Wednesday. I've already used some of the admin interfaces. |
| 15:29 |
kmlussier |
#action miker to send message to e-mail list announcing alpha release. |
| 15:30 |
miker |
re merging webclient, I'm happy with waiting a bit ... but, as always, it's preproduction. we will be backporting significant bug fixes, though, as agreed to before |
| 15:30 |
miker |
opinions on timing? |
| 15:30 |
dbs |
#info dbs is Dan Scott, Laurentian University |
| 15:31 |
miker |
I don't believe there are many. maybe 1 or 2? none that I'm positive do use it |
| 15:31 |
kmlussier |
I think it affects the decision on whether we merge post-beta. If people are using it in production, there may be a higher chance of breakage happening for them at .0 release time. |
| 15:31 |
Dyrcona |
I'd prefer sprint3 going in at/before the beta rather than after. |
| 15:31 |
JBoyer |
I'd think the sooner the better provided all of the existing interfaces are still in the XUL client. If someone is using a pre-pro client in production, they should be paying enough attention to hit the testing rather hard on this update. |
| 15:32 |
miker |
JBoyer: they do exist |
| 15:32 |
gmcharlt |
we could send an olly-olly-oxen-free to open-ils-general |
| 15:33 |
kmlussier |
Looks like we just lost most of the ESI crew |
| 15:34 |
miker |
gmcharlt: we can, though I'm inclined to vote with Dyrcona and JBoyer ... and dbwells :) |
| 15:34 |
JBoyer |
Plus there's the fact that alphas are generally unstable, now's the best time to find where the problems lie. |
| 15:34 |
miker |
dbwells: it's exceedingly low (though not non-zero) |
| 15:34 |
gmcharlt |
miker: yeah, I was thinking more in terms of identifying the folks who then get asked to TEST, TEST, and MOAR TEST :) |
| 15:34 |
kmlussier |
I'm inclined to agree that we should merge before beta. I can commit to putting some testing in by next week. |
| 15:35 |
miker |
gmcharlt: +1 |
| 15:35 |
|
jyorio joined #evergreen |
| 15:35 |
gmcharlt |
but yeah, I'm also in favor in merging before beta |
| 15:35 |
|
akilsdonk joined #evergreen |
| 15:35 |
kmlussier |
Who would like to volunteer to send a message out to the list to get testers? |
| 15:36 |
miker |
I'll do it while I announce alpha |
| 15:37 |
kmlussier |
#action miker to send message to list seeking help to test web client sprint 3 |
| 15:37 |
kmlussier |
Any other updates for 2.11? Other areas where help is needed? |
| 15:37 |
miker |
second question: we have 5 weeks between beta and GA ... would anyone like to steal a week from RC and make it 4, giving us 2 more weeks until beta? |
| 15:38 |
JBoyer |
+1 |
| 15:38 |
miker |
reason being: folks (including me) have been focusing on bug fix branches recently |
| 10:29 |
|
maryj joined #evergreen |
| 10:37 |
|
jvwoolf left #evergreen |
| 10:53 |
dbs |
Does the new password security approach take the password passed in for auth_proxy (e.g. LDAP) and store the salted hashed version of that in the actor.passwd table? |
| 10:59 |
* tsbere |
has found 3 different ways to *not* modify USMARC.pm, all of which he figured out before he finished making the changes |
| 11:00 |
|
Christineb joined #evergreen |
| 11:14 |
|
sandbergja joined #evergreen |
| 11:42 |
* tsbere |
hopes he isn't missing something in his testing now that he has code he thinks may work |
| 11:58 |
tsbere |
gmcharlt: I have barely tested it, and it is lunchtime so I am off to get lunch. But if you want to see my fix attempt: https://github.com/tsbere/marc-perl/commit/1b46cde3c76cd1dc6943010de98ac6d172d97b1c |
| 12:03 |
miker |
grabbing 0985 |
| 12:04 |
|
brahmina joined #evergreen |
| 12:07 |
pinesol_green |
[evergreen|Dan Wells] LP#1588543: Speed up record attribute ingest - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cf3bd14> |
| 12:07 |
pinesol_green |
[evergreen|Galen Charlton] LP#1588543: further speed up record attribute ingest - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6cc1d1e> |
| 12:07 |
pinesol_green |
[evergreen|Galen Charlton] LP#1588543: tests for verifying correct generated of record attributes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f668201> |
| 12:07 |
pinesol_green |
[evergreen|Galen Charlton] LP#1588543: schema update script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=982472f> |
| 12:07 |
pinesol_green |
[evergreen|Mike Rylander] Stamping upgrade for reingest speedup - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4b5b791> |
| 12:15 |
pinesol_green |
[evergreen|Jason Boyer] LP 1481441: Improve Hold Failure Messages - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=54e21a0> |
| 12:15 |
|
jvwoolf joined #evergreen |
| 12:24 |
* tsbere |
wonders if he should be adding his name and adjusting years in the MARC::Record README file while he is making code changes, or if gmcharlt would take care of that later. |
| 12:24 |
bshum |
miker: It occurs to me that the stuff we're pushing right now probably should get a milestone target of 2.11-beta (which has yet to be created). |
| 15:33 |
remingtron |
Christineb: any idea if your docs video links have been clicked? |
| 15:33 |
Christineb |
I will get click stats for next meeting |
| 15:34 |
Christineb |
we only added the specific video links during our last upgrade (May) |
| 15:35 |
yboston |
did we want to pick a particualr section to test out addign the links? |
| 15:37 |
yboston |
we can decide later too |
| 15:38 |
remingtron |
I guess I'd rather focus on making sure features from 2.10 and 2.11 are covered, and maybe try to add a video link while we're in there. |
| 15:38 |
Christineb |
maybe the patron related videos? |
| 15:38 |
Christineb |
remingtron++ |
| 15:55 |
sandbergja |
(and a few bits that would need to be written) |
| 15:56 |
yboston |
one thign that is not a concer is that it looks liek the web client will not be “ready” in a couple of weeks, because it if was that would have an impact on the re-org |
| 15:56 |
sandbergja |
and some functional requirements and some survey feedback |
| 15:56 |
yboston |
we also have a test server that could be used for dispalying re-org experiments |
| 15:59 |
yboston |
I would suggest that we again try another re-org specific meeting and/or a new email list thread |
| 15:59 |
yboston |
thoguh of course that is soemthign you have done before |
| 15:59 |
remingtron |
sandbergja: it wouldn't take much work to create a new root.txt just for that new book, generate the html, and go from there |
| 15:59 |
remingtron |
yboston: does anyone else have access to the new DIG test server? |
| 15:59 |
yboston |
Right now I think only Galen adn I have access. |
| 16:00 |
yboston |
try reaching out to him for access, and of course tell him I can verify that we want to give you access |
| 16:00 |
sandbergja |
Well, why don't we get a new root.txt file onto that server somehow, generate a sysadmin-from-the-staff-client manual using our ToC, and use that to generate some excitement |
| 16:02 |
sandbergja |
:-P |
| 16:02 |
|
mmorgan joined #evergreen |
| 16:03 |
remingtron |
yboston: right, a working repo branch could work |
| 16:03 |
yboston |
not sure how the DIG test serve is set up. I know it is pulling from our main Git repo a cuple of times a day |
| 16:03 |
yboston |
I can email Galen |
| 16:03 |
sandbergja |
Thanks, yboston! |
| 16:03 |
yboston |
#action yboston will email Galen to give remingtron and sandbergja access to DIG test server |
| 16:04 |
remingtron |
yboston: thanks! |
| 16:04 |
yboston |
#link docs-testing.evergreen-ils.rog |
| 16:05 |
remingtron |
yboston: typo, should be ".org" |
| 16:05 |
yboston |
oops, copied it from an email, tis time not my fault :) |
| 16:05 |
remingtron |
:) |
| 16:05 |
yboston |
#link http://docs-testing.evergreen-ils.org |
| 16:06 |
yboston |
anything else before we wrap up? |
| 16:06 |
remingtron |
just a plea |
| 16:06 |
yboston |
go ahead |
| 16:07 |
remingtron |
if anyone has time, take a look at the 2.10 needs and let's try to document more things! thanks all! |
| 16:25 |
kmlussier |
Justin__: Yes, that's one way to do it. In Evergreen, a volume is the call number record and then you add a copy. Sitka has some documentation for adding holdings - http://docs.sitka.bclibraries.ca/Sitka/current/html/add-holdings-title-records.html |
| 16:25 |
kmlussier |
Justin__: If you have the holdings info in your MARC records, you can also import the copies along with the records. |
| 16:27 |
kmlussier |
Justin__: http://docs.evergreen-ils.org/2.10/_importing_materials_in_the_staff_client.html#_staff_client_batch_record_imports has docs on how you would use holdings profiles to do so. |
| 16:28 |
Justin__ |
I'll give that documentation a read. I know I added a volume on one book to test. It shows there's a volume, but copies is 0. I assume I did something incorrectly. |
| 16:28 |
Justin__ |
Unfortunately, our MARC records didn't have our holdings info. |
| 16:29 |
Justin__ |
In most cases, we only have one of each book added to the catalog. Is there a way to automate adding one copy for each item in the catalog? |
| 16:29 |
kmlussier |
Justin__: It sounds like you added the volume without going to the next step to add a copy. There's a library setting that allows you to add both from the same screen, which our libraries find useful. |
| 08:46 |
pinesol_green |
[evergreen|Dan Scott] LP#1608711: Update schema.org property name from "seller" to "offeredBy" - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b55b3ca> |
| 08:47 |
JBoyer |
dbs, indeed, it's great. |
| 08:47 |
JBoyer |
Dyrcona++ |
| 08:52 |
bshum |
dbwells: I vaguely remember seeing something in IRC last week or earlier about 2.11 alpha cutting from you. Curious if you guys noticed a lot of string change that would necessitate a POT sync for translations. I saw some churn for the webstaff, but I don't get to peruse the files as often as I'd like anymore. |
| 08:52 |
|
mmorgan joined #evergreen |
| 08:53 |
bshum |
Either way, I'd recommend we do an i18n sync at some point. |
| 08:54 |
bshum |
I'll put together a local test later to see how much stuff actually changed myself. |
| 08:54 |
* bshum |
wanders off |
| 09:01 |
|
bos20k joined #evergreen |
| 09:02 |
|
Dyrcona joined #evergreen |
| 09:20 |
|
mrpeters joined #evergreen |
| 15:47 |
|
bos20k_ joined #evergreen |
| 15:58 |
JBoyer |
That figures. Thanks. |
| 15:59 |
JBoyer |
At least there's (probably) nothing setup wrong in my NCIPServer config. |
| 15:59 |
jeff |
that was fun when trying to debug incipit. |
| 15:59 |
jeff |
"wait, the state server is sending you WHAT in that field?" |
| 16:00 |
jeff |
"that's completely different from the value that they were sending us, which is completely different from the value that they were sending the original developers while testing, which is different from what's in the standard..." |
| 16:02 |
JBoyer |
And I'm using mod_dumpio to be able to see them at all, which is really great for log size. |
| 16:09 |
JBoyer |
and readability. |
| 16:09 |
jeff |
do you have a dedicated endpoint so that you can at least be selective about that, or are you dumping all traffic on a live system? |
| 16:10 |
JBoyer |
well, "live," it's a testing server but technically open to the world to see. Dumpio appears to be all or nothing though, I'd have preferred to only dump the NCIP traffic. |
| 16:11 |
* jeff |
nods |
| 17:11 |
|
mmorgan left #evergreen |
| 18:19 |
|
gsams joined #evergreen |
| 14:13 |
bshum |
Or bad reasons |
| 14:13 |
phasefx |
I was thinking maybe keeping alive some legacy system's way of having a family or classroom group; but I can't think of a better reason |
| 14:14 |
Bmagic |
I could imagine a scenario where the patron lost their old card, got a new one, then found the old one |
| 14:14 |
tsbere |
phasefx: Off the top of my head I can think of a couple. "School" accounts with multiple teachers carrying cards (so you can turn one off without affecting them all) is the best of them. |
| 14:15 |
tsbere |
phasefx: Worst of them is "I want to access more than one library's subscription for a third party service that uses barcode prefix to authenticate, so I need multiple cards!" - Though a single "test account" with a pile of cards for such a thing is less of a bad thing IMO. |
| 14:16 |
phasefx |
mmm |
| 14:16 |
phasefx |
thanks! |
| 14:17 |
tsbere |
I have also heard of "I want my secretary to have a card on my account so that she can pick my holds up for me" and "parent wants a card for each kid so they can pick the holds up, but we don't have a duplicator so we needed new numbers" |
| 15:31 |
jeff |
but in both of those cases, it was pre-speed-fixes and pre-popularity-metric |
| 15:31 |
jeff |
(though i don't know without looking if the popularity metric bits would affect an attr-only ingest at all) |
| 15:32 |
dbwells |
worth noting that the "speed fixes" only get us back close to where we were circa 2.7 or 2.8, so slow -> slower -> yay, we're slow again |
| 15:32 |
* dbs |
is trying to do the 2.11 thing, both for providing actual testing and because this is probably our last upgrade for quite a while. upgrading from 2.7 |
| 15:32 |
dbs |
dbwells__ |
| 15:32 |
dbs |
dbwells++ # i meant! |
| 15:34 |
jeff |
heh |
| 15:34 |
jeff |
and then there's that moment when i confuse a mozilla bugzilla browser tab for a text editor window... |
| 15:36 |
dbs |
at least we have time-based releases, I'm dealing with another project that's still feature-based and holy hell is it madness. "Yes we've merged part of this feature but there's 10 blockers associated with it needing volunteers before we can cut the next release" |
| 15:37 |
dbs |
heh |
| 15:38 |
gsams |
I'm hoping to make the jump from 2.7 upward by the end of the year, as long as things fall in place properly. |
| 15:57 |
miker |
dbs: popularity metric shouldn't interact with reingest at all |
| 16:01 |
* Dyrcona |
doesn't recall any reingest for testing popularity matrix. |
| 16:02 |
Dyrcona |
berick has suggested making pingest a standard bin. I'm for it, but my version and his have diverged a bit. |
| 16:02 |
Dyrcona |
To the point where a merge is nontrivial. |
| 16:16 |
jeff |
looking at 2.8-2.10 docs, minimum supported postgresql version has been 9.1 for a while, with the readme/install recommending 9.3 (though the 2.10 release notes recommend "9.2 or later" in mild conflict with the readme/install). this does leave us with Evergreen 2.9 and 2.10's required minimum PostgreSQL version (9.1) going EOL before the Evergreen release itself is out of support, but... we're getting better. :-) |
| 16:23 |
bshum |
Right direction. |
| 16:23 |
bshum |
KILL IT WITH FIRE! |
| 16:29 |
* Dyrcona |
recalls needing to look at some branches that remove support for Precise Pangolin. |
| 16:41 |
dbs |
miker: yeah, just noting the currency of our test server's database schema |
| 17:07 |
|
mmorgan left #evergreen |
| 17:10 |
|
jvwoolf left #evergreen |
| 18:21 |
|
gsams_ joined #evergreen |
| 13:27 |
berick |
k |
| 13:28 |
berick |
the browser client is leveraging (regular) apache a whole lot less than the tpac, but still based on the same TT processing code |
| 13:29 |
berick |
i'm a little surprised it would be the cause of apache probs |
| 13:30 |
jeff |
when this happened on another more test-only system, it was something i could usually reproduce. at this very moment i'm having trouble reproducing. |
| 13:31 |
jeff |
nevermind, got it. |
| 13:31 |
jeff |
well, "reproduced" |
| 13:38 |
jeff |
it seemed to be an apache child getting stuck, and just not responding at all to the client. |
| 13:39 |
jeff |
at this point, the server sees no tcp session, and the client (Chrome on OS X) is sitting spinning with a blank page, thinking that it's waiting on the server. |
| 13:39 |
jeff |
at this point i only have one side of the tcp session, i'm gathering more data. |
| 13:40 |
jeff |
one thing i'm trying to keep in mind is that this may not be the same as the previous time i had similar symptoms. trying not to combine observations. :-) |
| 13:41 |
|
terran joined #evergreen |
| 13:42 |
|
tspindler joined #evergreen |
| 13:45 |
berick |
on an unrelated note, anyone doing any audit table maintenance / cleanup? |
| 15:07 |
terran |
And to put something on my dune buggy sunburn |
| 15:07 |
kmlussier |
terran: Enjoy! |
| 15:09 |
jihpringle |
kmlussier: hi |
| 15:09 |
kmlussier |
jihpringle: Hello! :) |
| 15:09 |
kmlussier |
I was just testing jeffdavis 's fix for bug 1589586. |
| 15:09 |
pinesol_green |
Launchpad bug 1589586 in Evergreen master "Acquisitions: Cannot prorate charges on invoice" [Undecided,Confirmed] https://launchpad.net/bugs/1589586 |
| 15:10 |
kmlussier |
It's working well for me, but, while testing, I tried adding direct charges on a PO rather than an invoice. |
| 15:10 |
kmlussier |
I found the same issue occurs there with prorated direct charges. But it seems to also happen on 2.9. I was wondering if you know if that's always been an issue on the PO? |
| 15:11 |
|
tspindler left #evergreen |
| 15:11 |
jihpringle |
we stopped using charges on POs several versions ago because they never seemed to work quite right |
| 15:11 |
kmlussier |
I don't know if our users ever add direct charges from the PO, so maybe it's a non-issue. |
| 15:12 |
kmlussier |
jihpringle: Ah, ok. Thanks. |
| 15:12 |
jihpringle |
I think the only PO charges we've tested recently are for blanket orders and those are working (but aren't prorated |
| 15:13 |
* kmlussier |
nods |
| 15:13 |
kmlussier |
I may dig further, but since it appears to be a preexisting condition, I think the current fix is good to go in. |
| 15:15 |
Christineb |
kmlussier++ |
| 15:15 |
Christineb |
Thank you for testing! |
| 15:16 |
kmlussier |
Christineb++ #Thanks for finding the problem before our libraries upgraded to 2.10! |
| 15:17 |
jihpringle |
kmlussier: I though there was a direct charge/po related bug on launchpad but I couldn't find it |
| 15:17 |
kmlussier |
Oh, you know what? I bet you the problem on the PO occurs for the same reason it was happening on the invoice. Because the charges on the PO are encumbered. |
