Time |
Nick |
Message |
02:47 |
|
Jillianne joined #evergreen |
04:03 |
|
gsams joined #evergreen |
05:02 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
07:11 |
|
rjackson_isl joined #evergreen |
08:40 |
|
mmorgan joined #evergreen |
08:53 |
|
bos20k joined #evergreen |
09:03 |
|
mdriscoll joined #evergreen |
09:05 |
* csharp |
is about to test backporting non-Ruby EDI (bug 1373690) |
09:05 |
pinesol_green |
Launchpad bug 1373690 in Evergreen "Direct EDI generation for ACQ orders -- AKA kill ruby webrick" [Wishlist,Fix released] https://launchpad.net/bugs/1373690 |
09:06 |
csharp |
in part because, for whatever reason, A/T is breaking on creating JEDI |
09:07 |
|
_adb joined #evergreen |
09:09 |
|
krvmga joined #evergreen |
09:15 |
|
yboston joined #evergreen |
09:21 |
|
Dyrcona joined #evergreen |
09:24 |
|
mmorgan1 joined #evergreen |
09:36 |
|
jvwoolf joined #evergreen |
09:43 |
|
jvwoolf joined #evergreen |
09:48 |
|
kmlussier joined #evergreen |
09:55 |
berick |
csharp: i'm all ears! BTW, you probably saw this, but you have to enable direct generation for each edi_account now. |
09:56 |
berick |
so you can test by applying attrs while continuing traditional edi delivery |
09:59 |
csharp |
berick: good to know |
10:15 |
pinesol_green |
[evergreen|Galen Charlton] LP#1713160: fix crash viewing circ history in public catalog - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=461072d> |
10:21 |
|
mmorgan joined #evergreen |
10:30 |
csharp |
TFW bug squashing week turns into deal-with-hurricane-fallout week |
10:31 |
Dyrcona |
Well, dealing with hurricane fallout is more immediately important, IMHO. |
10:32 |
Dyrcona |
Was Irma still a hurricane when it reached you? |
10:34 |
csharp |
Dyrcona: it was a tropical storm |
10:35 |
csharp |
my first storm as a homeowner - I didn't realize how much anxiety that adds to the whole thing :-) |
10:35 |
Dyrcona |
Yes. It does. |
10:36 |
berick |
csharp: we had a tree-meet-house scenario a few years ago. And I used to love thunderstorms... :( |
10:37 |
csharp |
yeesh |
10:37 |
csharp |
lots of my neigbors saw damage - we just have small branches and debris and a bunch of spoiled food |
10:37 |
csharp |
power was out for about 38 hours |
10:38 |
csharp |
sweet sweet, glorious power |
10:45 |
berick |
the title ^-- of csharp's autobiography |
10:47 |
csharp |
author photo: https://i.ytimg.com/vi/Kl0OsHIDepA/maxresdefault.jpg |
10:51 |
berick |
chapter 1: "You can tell by me teeth my moral fiber is squishy" |
10:52 |
berick |
well, that and the torture lightning |
10:56 |
berick |
Dyrcona: remind me where you keep pingest.pl? need to rebase my copy. |
10:57 |
Dyrcona |
berick: https://github.com/Dyrcona/evergreen_utilities |
10:58 |
berick |
on github now.. cool |
10:58 |
berick |
thanks |
10:58 |
csharp |
pingest.pl++ |
10:58 |
csharp |
Dyrcona++ |
11:17 |
|
dwgreen joined #evergreen |
11:33 |
|
Christineb joined #evergreen |
11:45 |
|
rlefaive joined #evergreen |
12:01 |
|
rlefaive_ joined #evergreen |
12:09 |
|
khuckins_ joined #evergreen |
12:16 |
|
jihpringle joined #evergreen |
12:47 |
kmlussier |
Ha ha ha. rhamby_++ for https://bugs.launchpad.net/evergreen/+bug/722861/comments/2 |
12:47 |
pinesol_green |
Launchpad bug 722861 in Evergreen "strange predictions for weekly serial patterns" [Medium,Confirmed] - Assigned to Lebbeous Fogle-Weekley (lebbeous) |
12:47 |
Dyrcona |
rhamby++ senator++ |
12:52 |
Dyrcona |
@quote add <rhamby> In reply to the previous query, I don't think Lebbeous is still working on this. |
12:52 |
pinesol_green |
Dyrcona: The operation succeeded. Quote #174 added. |
12:54 |
Dyrcona |
@quote random |
12:54 |
pinesol_green |
Dyrcona: Quote #35: "<tsbere> We have collective sanity left? We might want to double-check on that. ;)" (added by bshum at 05:00 PM, November 06, 2012) |
13:02 |
csharp |
there's a PINES policy somewhere from probably 15 years ago that specifically says that bradl will delete missing items after 1 year - we're still waiting for Brad to return to GPLS staff and take care of that |
13:03 |
kmlussier |
terran++ #Wrangling Bug Squashing Day on a spotty hotspot connection |
13:03 |
csharp |
terran++ |
13:04 |
* kmlussier |
imagines all of the missing items that are still sitting there undeleted in the PINES database. |
13:04 |
csharp |
heh |
13:07 |
|
rlefaive joined #evergreen |
13:09 |
|
collum joined #evergreen |
13:12 |
roycroft |
hello, folks |
13:13 |
roycroft |
i'm curious - has there been any discussion of creating a virtual machine image of an evergreen platform for folks to use for testing/evaluation? |
13:13 |
roycroft |
i'm not complaining, but i've spent 3 hours doing an install so far, and i'm still working on the opensrf installation |
13:13 |
|
jihpringle_ joined #evergreen |
13:14 |
csharp |
roycroft: we used to have a couple out there, but not in years |
13:14 |
rhamby_ |
roycroft: there are a variety of ways to doing quick and dirty builds that are good for test systems but I wouldn't recommend them for production, I use an ansible script usually |
13:14 |
csharp |
it's a moving target and time-consuming to maintain :-/ |
13:14 |
roycroft |
i know that this is a vertical market app, and perhaps it's not evaluated as commonly as things like a cms |
13:14 |
roycroft |
so a vm image might not be as useful |
13:15 |
csharp |
roycroft: the other approach is to share here what your issues are and someone may be able to help |
13:15 |
roycroft |
i am not really having any issues per se |
13:15 |
roycroft |
other than that i don't use git, and it took me a while to figure out how to get the exact branch i needed |
13:15 |
csharp |
well, questions, then? |
13:15 |
roycroft |
there are just a lot of things to do |
13:16 |
csharp |
roycroft: I would skip git if you're unfamiliar and just start here: http://evergreen-ils.org/egdownloads/ |
13:16 |
csharp |
no need to add a level of (not insignificant) complexity |
13:16 |
roycroft |
well, after some discussion here yesterday, i built a debian stretch vm for the installtion |
13:16 |
roycroft |
so i do need to use git |
13:17 |
roycroft |
but if it's a slam dunk on jessie, perhaps i should go back and start over |
13:17 |
csharp |
oh - well, I would go with jessie or one of the Ubuntu LTS's |
13:17 |
roycroft |
i'm up to installing apache2-websockets |
13:18 |
berick |
roycroft: may be of interest: https://wiki.evergreen-ils.org/doku.php?id=server_installation:semi_automated |
13:18 |
berick |
i use the ansible installer (2nd from bottom) |
13:18 |
berick |
docker container is great for test machines too |
13:18 |
csharp |
roycroft: since it sounds like you're basically installing for evaluations, keep it simple and go with long-supported releases (jessie & Ubuntu 14.04) |
13:18 |
berick |
(when the build you want exists) |
13:23 |
roycroft |
yes, i'm beginning to think that would be a good idea |
13:24 |
roycroft |
i do want to work with 3.0beta, as that's what should be current if/when i'm ready for production |
13:24 |
kmlussier |
Should some of the scripts be removed from that wiki page? For example, I'm guessing the one from edoceo doesn't work anymore. |
13:24 |
roycroft |
but the underlying os is not a big deal right now |
13:24 |
roycroft |
debian is what i use for most of my web-related servers, so i'll stick with that, but jessie vs. stretch for an evaluation is irrelevant |
13:28 |
roycroft |
for those who weren't around yesterday when i was discussing my situation, there is no real timefram for deploying evergreen or some other ils system |
13:28 |
roycroft |
we're working on a relatively small set of collections using readerware books right now, but need something more robust and capable eventually |
13:29 |
roycroft |
and we're focusing on classifying the collections right now, and that work should be able to be migrated to an ils pretty easily |
13:30 |
roycroft |
so i'm going to take my time, and it looks like it's a good time to evaluate evergreen, since stretch support is just now happening, and there's a major release due soon with a new client interface |
13:49 |
bshum |
Hmm, looking at the function key stuff in Open-ILS/src/templates/staff/navbar.tt2 ; I'm concerned that putting all the function keys in as translatable might lead to risky/unexpected remapping of things; is there an expected use case to being able to translate "f5" into something else per locale? |
13:50 |
bshum |
(not just function keys, but a lot of the shortcuts in general) |
13:51 |
bshum |
Seems like that would break unhappily if someone put something nonsensical in the i18n translation PO, like mapping "f5" to some other thing entirely "f-cinco" or whatnot |
13:53 |
csharp |
@seen JBoyer |
13:53 |
pinesol_green |
csharp: JBoyer was last seen in #evergreen 5 days, 4 hours, 26 minutes, and 53 seconds ago: <JBoyer> Nothing like playing with ccmm to get you to start lifting weights. |
13:56 |
bshum |
Think I should file a bug and make a branch to remove the localization for these accesskeys so that they aren't accidentally broken? Or is this a "working as intended" changeable option that we want to preserve? (and document way better for?) |
13:56 |
csharp |
I have a working theory that something about nginx is breaking vandelay imports (and possibly auth sessions) |
13:57 |
csharp |
last Thursday I added some debugging to the cache lookup for acq vandelay uploads and found that it was looking for this value "vandelay_import_spool_* {}a01befa6de1f4029b37559975130d385" |
13:58 |
csharp |
that was in the web client (but I'm not convinced web client is the problem) |
13:58 |
csharp |
in XUL, the same sort of lookup looked for "vandelay_import_spool_a01befa6de1f4029b37559975130d385 |
13:58 |
csharp |
" |
13:59 |
csharp |
we've gotten a few complaints since upgrading to 2.12 about auth sessions dying prematurely too, and while I have not done any debugging yet, I'm theorizing that they are related |
14:02 |
bshum |
csharp: For my own curiousity, for your nginx, are you running separate nginx per app server (or apache head)? |
14:03 |
bshum |
Or using one nginx and redirecting to multiple apache hosts? |
14:03 |
bshum |
And with multiple nginx, still load balancing (ldirector?) in front? |
14:03 |
bshum |
(just getting an idea of the architecture design of it) |
14:03 |
bshum |
(no clue what's broken, if anything) |
14:04 |
csharp |
separate per app server |
14:04 |
csharp |
and ldirector out front, yet |
14:04 |
csharp |
yes, I mean |
14:07 |
csharp |
https://pastebin.com/hMKvWKxu shows the debugging I added to Order.pm |
14:10 |
csharp |
new paste with diff and log output: https://pastebin.com/0QHmzCc5 |
14:11 |
csharp |
so whatever creates $key appears to be broken |
14:22 |
jeffdavis |
seems like the open-ils.acq.process_upload_records method is called by the acqHandlePostUpload() function in acq/picklist/upload.js, and that function gets its key from the acqSendUploadForm() function just above it in that file |
14:22 |
jeffdavis |
I don't understand at a glance what acqSendUploadForm is doing though |
14:31 |
jeffdavis |
csharp: Open-ILS/src/perlmods/lib/OpenILS/WWW/Vandelay.pm line 84? |
14:32 |
csharp |
jeffdavis: cool - thanks! |
14:42 |
csharp |
that seems fine - and there is a hash being created, so something further down must be adding the '* {}' |
14:45 |
berick |
do you see this in the logs? "uploaded MARC batch with key a01befa6de1f4029b37559975130d385" ? |
14:45 |
berick |
well, that's one that succeeded |
14:46 |
berick |
more to the point, what does grepping for "uploaded MARC batch with key" show for the one that failed. |
14:46 |
csharp |
bshum: uploaded MARC batch with key d6571ede7b8018943e8fc217457b5769 |
14:46 |
csharp |
sorry, berick ^^ |
14:46 |
berick |
ok, good |
14:46 |
csharp |
CALL: open-ils.acq open-ils.acq.process_upload_records 991de7c6d886fda56de6aa373b23b722, * {}d6571ede7b8018943e8fc217457b5769, HASH(0x6350f70) |
14:46 |
csharp |
there are the extra characters^^ |
14:47 |
* jeffdavis |
looks suspiciously at that acqSendUploadForm() js function |
14:47 |
csharp |
yeah, looks like it has to be there, right? |
14:48 |
berick |
the md5 key is returned as plain text from the upload, then passed directly to the acq.process_upload_records api. |
14:51 |
csharp |
interestingly other uploads worked before and after the ones that failed |
14:51 |
csharp |
it was last week when I did this, but I walked away convince that it was a web client issue |
14:51 |
pastebot |
"berick" at 64.57.241.14 pasted "diff --git a/Open-ILS/web/js/u" (21 lines) at http://paste.evergreen-ils.org/811 |
14:51 |
csharp |
but I'm not sure I have enough cases to prove that to myself |
14:52 |
berick |
.. would be of interest |
14:54 |
berick |
better yet (or in addition): console.log(data.documentElement) |
14:54 |
berick |
so chrome will log the object instead of the string '[object]' or whatever |
14:55 |
|
collum joined #evergreen |
15:05 |
csharp |
well - that worked, but it didn't reproduce the problem |
15:05 |
csharp |
I'll keep messing with it |
15:06 |
berick |
csharp: that's a reference my logging patch? |
15:06 |
csharp |
berick: sorry, yes |
15:06 |
berick |
did you add the one from my last comment, console.log(data.documentElement) too? |
15:06 |
csharp |
the key looks right the whole time - front and back end |
15:06 |
csharp |
yeah |
15:06 |
berick |
ok, good |
15:07 |
berick |
well, when it fails next time, hopefully there will be something interesting in those logs |
15:07 |
berick |
so now you just have to keep trying over and over all day :) |
15:07 |
csharp |
ha! |
15:07 |
csharp |
yep |
15:23 |
mdriscoll |
I'm upgrading a test system to 3.0-beta1. The database has 2m bibs and 3m copies. The 2.12.5-3.0 upgrade script is taking a really long time (>24 hrs). |
15:23 |
mdriscoll |
The problem is with script 1057.schema.copy_vis_attr_cache.sql. I believe it is causing a reingest of every bib record. I'm wondering if there is a way around this. |
15:25 |
csharp |
d9fa69de |
15:25 |
pinesol_green |
csharp: [evergreen|Mike Rylander] LP#1698206: Eliminate Staged Search - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d9fa69d> |
15:25 |
kmlussier |
mdriscoll: I don't think it's reingesting bib records, but I can confirm it takes a very long time based on an upgrade on a much smaller database that I did yesterday. |
15:26 |
csharp |
yowza - that's going to take PINES a very long time too :-( |
15:28 |
mdriscoll |
kmlussier: The script drops a few triggers but I believe it is doing an update on each bib record. This is the line causing the problem: UPDATE biblio.record_entry SET vis_attr_vector = biblio.calculate_bib_visibility_attribute_set(id). |
15:28 |
csharp |
yeah - that would be the (a?) long one |
15:29 |
csharp |
maybe some DB config tuning will help? |
15:29 |
berick |
that would not do a full re-ingest unless the 'reingest on same marc' setting were applied. |
15:29 |
csharp |
make sure autovac is off/supressed, increasing work mem, etc. |
15:30 |
berick |
could still be hitting lots of other triggers, though |
15:32 |
kmlussier |
Further along, there is also a reingest for the metabib Display fields. Also, there will probably be something for authority records at some point. It's looking like the 3.0 upgrade could be a long one. |
15:32 |
mdriscoll |
csharp: I did increase checkpoint_segments but will look at working mem. I think this system has a default postgres.conf. |
15:32 |
berick |
the metabib display field reingest can be disabled. it's not required. |
15:32 |
berick |
was hoping we were going to remove it, actually |
15:32 |
csharp |
mdriscoll: ah - then, yeah, you'll want to up some of those based on the resources of your system |
15:33 |
kmlussier |
berick: You don't think it should be done at some point? |
15:33 |
berick |
kmlussier: yes! definitely, but we're not using it yet |
15:33 |
berick |
and the seed data is /slim/ |
15:33 |
csharp |
mdriscoll: good reference here: https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server |
15:33 |
berick |
so another reingest will be needed anyway |
15:33 |
kmlussier |
berick: Oh, I see. So maybe wait until 3.1, when we should actually be utilizing it. |
15:34 |
berick |
kmlussier: yeah that's what i'm thinking, after we get a usable set of seed data |
15:34 |
mdriscoll |
csharp: thanks! |
15:37 |
|
mmorgan1 joined #evergreen |
15:49 |
Dyrcona |
I will test that upgrade fairly soon on a relatively well-tuned server. |
15:57 |
csharp |
same here |
15:58 |
csharp |
PINES libs are super excited about the web client and we're starting trainings week after next |
16:00 |
berick |
we've started some high level review sessions here |
16:01 |
Dyrcona |
We'll be going web client only next year. |
16:02 |
Dyrcona |
I'm not going to be able to maintain the XUL client customizations that we have here after 2.12. |
16:04 |
|
khuckins_ joined #evergreen |
16:11 |
|
Jillianne joined #evergreen |
16:12 |
berick |
Dyrcona: exciting. as in, January or some time next year? |
16:12 |
Dyrcona |
Sometime next year, likely in June. |
16:13 |
* berick |
nods |
16:20 |
berick |
we need a "concerto street address of the day" twitter feed. today's entry is "1658 Organisational Bedroom Square" |
16:21 |
Dyrcona |
hah |
16:22 |
Dyrcona |
I should make a big placard of that and put it above my house's unobtrusive "83." |
16:34 |
|
sandbergja joined #evergreen |
16:41 |
|
mmorgan joined #evergreen |
16:44 |
csharp |
berick's onto something - here's another: 9674 Filthy Firm Meadows |
16:45 |
csharp |
1062 Scornful Air Fort |
16:45 |
berick |
haha. it's a gold mine. i mean, you can't beat 2800 Cheerful Animal Valley |
16:45 |
csharp |
:-) |
16:46 |
berick |
4223 Spotty Chemical Stravenue -- I'd live there! |
16:46 |
csharp |
just saw that one |
16:47 |
csharp |
2433 Uncomfortable Nature Greens |
16:47 |
csharp |
ate a lot of those during my recent vegetarian period |
16:47 |
berick |
hah |
16:48 |
berick |
lot of dark adjectives |
17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
17:07 |
|
jvwoolf left #evergreen |
17:11 |
|
mmorgan left #evergreen |
19:53 |
|
khuckins joined #evergreen |
20:04 |
|
bos20k joined #evergreen |