| Time |
Nick |
Message |
| 00:59 |
|
dbwells_ joined #evergreen |
| 00:59 |
|
remingtron_ joined #evergreen |
| 01:06 |
|
StomproJosh joined #evergreen |
| 05:15 |
|
gsams joined #evergreen |
| 07:15 |
|
rjackson_isl joined #evergreen |
| 07:16 |
|
agoben joined #evergreen |
| 07:26 |
|
JBoyer joined #evergreen |
| 07:35 |
csharp |
25cd82ae |
| 07:35 |
pinesol_green |
csharp: [evergreen|dbs] Add org unit settings for default status of newly added copies - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=25cd82a> |
| 08:14 |
|
ericar joined #evergreen |
| 08:21 |
|
rlefaive joined #evergreen |
| 08:26 |
|
mrpeters joined #evergreen |
| 08:32 |
|
Dyrcona joined #evergreen |
| 08:39 |
|
kmlussier joined #evergreen |
| 08:40 |
kmlussier |
Good morning #evergreen! |
| 08:43 |
Dyrcona |
Good morning! |
| 08:43 |
|
mmorgan joined #evergreen |
| 08:46 |
Stompro |
Hello, I would like to talk to Evergreen... Baker & Taylor says that I need to talk to Evergreen so they can implement an EDI enhancement, so could someone give me Evergreen's phone number please. Sigh. |
| 08:49 |
mmorgan |
@coffee Stompro |
| 08:49 |
* pinesol_green |
brews and pours a cup of Ethiopia Yirga Cheffe Koke Espresso, and sends it sliding down the bar to Stompro |
| 08:50 |
Dyrcona |
Stompro: B&T didn't get the memo. When the area codes changed, you have to start dialing 1 before every non-local number. |
| 08:52 |
Dyrcona |
Actually, we have to dial the area code here even for local calls. |
| 08:53 |
Dyrcona |
The irony is, they added all of these area codes back in the late '90s because every had a fax machine, an Internet dialup line, and a cell phone. |
| 08:53 |
Dyrcona |
Then, about 5 years later, everyone got broadband and ditched the landlines. |
| 08:53 |
Dyrcona |
:) |
| 08:54 |
Stompro |
In our rural areas the telco's just charge more for a DSL line without local phone service than with to get around people not wanting/needing local phone service. |
| 08:57 |
Dyrcona |
Stompro: If you're having trouble with EDI and B&T and it involves numbers, it's B&T's fault. :) |
| 08:57 |
Dyrcona |
You need to tell them to set you up with their EDI implementation that actually works. |
| 08:59 |
|
jwoodard joined #evergreen |
| 08:59 |
|
dteston joined #evergreen |
| 08:59 |
|
rlefaive joined #evergreen |
| 09:01 |
Stompro |
Dyrcona, we are not having trouble, we were just trying to get them to send the tracking number with the invoices if possible so it is easier to pull out boxes with material paid for by donations for faster/special processing. They say they have something called ASN (Automatic Shipping Notification) but so far won't share any details about how such a feature works, just saying that "Evergreen" needs to work with them to implement that. I'm like, "Hel |
| 09:01 |
Stompro |
lo, I'm Evergreen, please tell me details", but that hasn't gotten a reponse yet. |
| 09:02 |
Dyrcona |
:) |
| 09:03 |
Dyrcona |
Yeah, I love that line.... ;) |
| 09:04 |
|
bos20k joined #evergreen |
| 09:08 |
JBoyer |
Some vendors really don't get it, others think you're their unpaid intern implementing features. Interesting that various arms of B&T do both. |
| 09:10 |
JBoyer |
Give them a number for Canonical. "I found this on a popular Evergreen development site, try that." |
| 09:11 |
csharp |
JBoyer: re: vendors treating you as unpaid labor - I have SO been there |
| 09:12 |
Dyrcona |
Give them my number. I'll send them a bill. |
| 09:23 |
|
jvwoolf joined #evergreen |
| 09:25 |
|
maryj joined #evergreen |
| 09:30 |
* kmlussier |
looks at her list of assigned bugs and wonders why she assigned herself to half of them. |
| 09:32 |
Dyrcona |
:) |
| 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 |
| 10:59 |
mmorgan |
csharp: I see you added another commit to your branch for lp 1613374. Do you see a need for any other changes? |
| 10:59 |
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) |
| 11:16 |
Bmagic |
Has anyone upgraded their database to 9.5? I did a pg_dump then pg_restore on 9.5, and I am getting errors related to return types in functions inside of the permission schema |
| 11:22 |
jeff |
Bmagic: sounds like bug 1568046 |
| 11:22 |
pinesol_green |
Launchpad bug 1568046 in Evergreen "Concerto won't load because of problem with permission.grp_ancestors on PostgreSQL 9.5" [Undecided,Fix committed] https://launchpad.net/bugs/1568046 |
| 11:24 |
kmlussier |
Following up on a question I posted here regarding mapping metarecords when changing config.biblio_fingerprint, I'm still having trouble after following csharp's and berick's suggestion to enable force_on_same_marc. |
| 11:24 |
kmlussier |
I added a comment here https://bugs.launchpad.net/evergreen/+bug/1553287/comments/2 if anyone has further thoughts. |
| 11:24 |
pinesol_green |
Launchpad bug 1553287 in Evergreen "Incorporating part information into biblio fingerprint" [Medium,New] |
| 11:26 |
|
Christineb joined #evergreen |
| 11:28 |
Bmagic |
jef++ |
| 11:28 |
Bmagic |
jeff++ |
| 11:28 |
Bmagic |
hehe! |
| 11:28 |
kmlussier |
Basically, I seem to be running up against bug 1488655. The reingest creates the new maps, but doesn't remove the old ones from the previous master record. |
| 11:28 |
pinesol_green |
Launchpad bug 1488655 in Evergreen "Metarecords are not being maintained properly" [Undecided,New] https://launchpad.net/bugs/1488655 |
| 11:29 |
kmlussier |
But I'm pretty sure there are other sites that have added part information to the fingerprint, so I would be interested to hear if they did anything differently to get their records remapped. |
| 11:32 |
tsbere |
kmlussier: I assume one option might be to truncate metarecord and metarecord_source_map, then run quick_metarecord_map.sql - Not positive that would do what you want, though. |
| 11:32 |
* kmlussier |
looks |
| 11:33 |
berick |
heh, I see tsbere was typing into the same bug I was.. |
| 11:33 |
berick |
again w/ similar results |
| 11:35 |
tsbere |
berick: I guess we have similar views on the subject |
| 11:50 |
kmlussier |
tsbere: That works! Thanks! |
| 11:50 |
kmlussier |
tsbere++ |
| 11:51 |
kmlussier |
It's nice and speedy on a Concerto dataset. |
| 11:51 |
tsbere |
kmlussier: Glad that my "I took ten seconds to look at the issue and made my best guess" worked out for you ;) |
| 11:52 |
remingtron |
gmcharlt: did bug 1511433 get fixed in webstaff sprint 3? |
| 11:52 |
pinesol_green |
Launchpad bug 1511433 in Evergreen "teach webstaff about logical deletion of parts" [Medium,New] https://launchpad.net/bugs/1511433 - Assigned to Galen Charlton (gmc) |
| 11:52 |
|
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:28 |
Dyrcona |
jeff: No. I thought if I placed a hold via the OPAC it would use the client timezone, but the hold has the UTC timezone in the database. |
| 12:28 |
csharp |
awesome |
| 12:28 |
Dyrcona |
I want to make sure that's working before I go back to transits. |
| 12:28 |
jeff |
Dyrcona: and in your setup, the server is running in UTC? |
| 12:29 |
Dyrcona |
I'll never finish looking at either if I keep bouncing and forth. |
| 12:29 |
jeff |
heh |
| 12:29 |
Dyrcona |
jeff: Yeah, 'cause the way I build the vm for xenial, it never sets the timezone correctly. |
| 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 |
| 14:57 |
Dyrcona |
That's good. The message you sent me in email looked like you needed to do the update to get the new servers list. |
| 14:58 |
tspindler |
this http://evergreen-ils.org/documentation/install/OpenSRF/README_2_4_1.html has "make" after runing the config creation, is that a typo? |
| 14:59 |
Dyrcona |
No, you run the make command to build the software and then do make install. |
| 14:59 |
Dyrcona |
The configure step creates the Makefiles. |
| 15:00 |
jeff |
if you don't run "make" before running "make install", you should end up with the same results, but it is useful to use two steps sometimes -- such as when the "make" errors out. |
| 15:00 |
tspindler |
ok, then something is not working |
| 15:01 |
tspindler |
http://paste.evergreen-ils.org/21?tx=on&submit=Format+it%21 |
| 15:01 |
Dyrcona |
You're mising apache-dev. |
| 15:02 |
Dyrcona |
You need to run the prerequisite installer target for your distribution of Linux. |
| 15:03 |
Dyrcona |
The configure failed: configure: error: "could not determine apache version number" |
| 15:03 |
tspindler |
That's step 2 on the instructions apt-get install make make -f src/extras/Makefile.install <osname> |
| 15:03 |
Dyrcona |
You need to do this step as root: http://evergreen-ils.org/documentation/install/OpenSRF/README_2_4_1.html#_installing_prerequisites |
| 15:04 |
|
mmorgan1 joined #evergreen |
| 15:04 |
Dyrcona |
Yes. You need to do it as root or via sudo. |
| 15:04 |
tspindler |
ok, I ran it earlier but must of been an error i missed |
| 15:04 |
Dyrcona |
Could be. It can produce a lot of output. |
| 15:11 |
tspindler |
ca marche |
| 15:15 |
Dyrcona |
C'est super cool! ;) |
| 15:21 |
|
ericar_ joined #evergreen |
| 15:45 |
jeff |
it annoys me more than it should that you can't currently prevent a websocket establishment error from appearing in the browser console. |
| 15:47 |
berick |
it annoys me too |
| 15:47 |
* berick |
is reminded we still need to avoid hatch connect calls when it's not enabled |
| 15:48 |
* jeff |
nods |
| 15:49 |
jeff |
and be louder about non-hatch websocket failures |
| 15:50 |
berick |
indeed |
| 15:52 |
jeff |
in semi-related news, i was able to successfully craft a systemd unit file for opensrf. |
| 15:52 |
jeff |
so i have a vm that runs opensrf at boot using systemd, "after" ejabberd has started. |
| 15:53 |
jeff |
of course, by default apache doesn't wait on ejabberd, so that's unhelpful. |
| 15:55 |
|
tspindler left #evergreen |
| 15:55 |
Dyrcona |
jeff: That's a start. |
| 15:56 |
Dyrcona |
You gonna share it? |
| 16:00 |
Dyrcona |
might be fun to do systemctl start|stop|restart opensrf |
| 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 |
jeff |
normal postgresql behavior. |
| 16:17 |
jeff |
sounds like, at least. |
| 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:19 |
Dyrcona |
I felt rushed on the weekend. :) |
| 16:21 |
Dyrcona |
Hey, nice.... Thank you, Ubuntu... |
| 16:21 |
Dyrcona |
Package libemail-send-perl is not available, but is referred to by another package. |
| 16:21 |
Dyrcona |
Oh, duh. My fault. |
| 16:21 |
* Dyrcona |
starts over... |
| 16:22 |
Dyrcona |
Wrong make target. |
| 16:25 |
jeff |
Dyrcona: this might help demonstrate how psql displays timestamps for different timezone settings: https://gist.github.com/jeff/1a4e32c4a5b58bda28e013346913d3e6 |
| 16:26 |
jeff |
Dyrcona: no matter what the client timezone is, if you're running psql on the server with a UTC TZ, you're going to have timestamps displayed as +00 |
| 16:26 |
Dyrcona |
jeff: All right. Have you looked at this branch? |
| 16:26 |
Dyrcona |
'Cause maybe you should, too. :) |
| 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. |
| 16:35 |
Dyrcona |
There's a word missing there.... |
| 16:44 |
miker |
berick: looking more closely at the end of bug 1464709 |
| 16:44 |
pinesol_green |
Launchpad bug 1464709 in Evergreen "Seamless checkout of non-standard copy status AKA single-use copy statuses" [Wishlist,New] https://launchpad.net/bugs/1464709 |
| 16:45 |
miker |
well, nevermind |
| 16:47 |
kmlussier |
miker: You've left everyone hanging. |
| 16:49 |
miker |
I was going to say "we're back to where we can replace the hard-coded list with is_available" but then we'll just never separate the concepts and instead be left with inferior code ... I'll leave the burr under the saddle so we'll collectively remember to address is_targetable ;) |
| 16:51 |
|
mmorgan joined #evergreen |
| 17:11 |
* Dyrcona |
calls it a day. |
| 17:14 |
|
gsams_ joined #evergreen |
| 17:15 |
|
mmorgan left #evergreen |
| 18:07 |
|
bmills joined #evergreen |
| 18:11 |
|
hbrennan joined #evergreen |
| 18:49 |
jeff |
neat |
| 18:49 |
jeff |
holdable_formats | {"0":[{"_attr":"item_type","_val":"a"},{"_attr":"item_type","_val":"t"}],"1":"","2":[{"_attr":"item_lang","_val":"eng"}]} |
| 20:57 |
|
dcook joined #evergreen |
| 21:00 |
|
_adb left #evergreen |
| 21:57 |
|
artunit joined #evergreen |
