| 01:23 |
|
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 |
| 03:50 |
|
abowling joined #evergreen |
| 04:34 |
|
jonadab joined #evergreen |
| 05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:14 |
|
rjackson_isl joined #evergreen |
| 07:16 |
|
agoben joined #evergreen |
| 07:56 |
|
lualaba joined #evergreen |
| 10:09 |
berick |
mmorgan: ohh, right, i was not considering all-day closing |
| 10:14 |
kmlussier |
gmcharlt / miker / dbwells: Are we still planning for a point release today? |
| 10:15 |
miker |
kmlussier: checking, but I think a couple of patches are yet to be merged ... and, I've got a fix for a vandelay-via-acq issue on opensrf master (which I think you said you had problems with) when activating a PO |
| 10:17 |
kmlussier |
miker: Any specific patches you want me to look at? The issue I had was related to the bundling / chunking thing, I think. |
| 10:17 |
* kmlussier |
can look at that one. |
| 10:22 |
|
jvwoolf joined #evergreen |
| 10:23 |
kmlussier |
Has anyone running the web client noticed a lot of log bloat? I've found that the two MassLNC VMs that are running the web client run out of space very quickly. I never have any problem on the VMs that are webby free. |
| 10:26 |
kmlussier |
I reduced the log level to 2 last week, but it's still a problem. I suppose I can reduce the log level even further, but that won't be an option for production servers. |
| 10:31 |
kmlussier |
Ah, I see. The earlier bundling / chunking fix only addressed the pull list issue. miker: are you planning to add the vandelay fix to the same branch as the pull list fix? If so, I'll hold off on testing. |
| 10:31 |
csharp |
hmm - I'm curious about the types of messages that are causing that |
| 10:31 |
JBoyer |
kmlussier, can you post some samples somewhere so we can try to see what kinds of messages you're getting and if they can be fixed/toned down? |
| 10:31 |
miker |
kmlussier: I can, if that's easier for you |
| 10:32 |
kmlussier |
JBoyer: Sure, but I just cleared them out this morning. I'll post something later when they've had some time to grow. |
| 10:33 |
JBoyer |
kmlussier++ |
| 10:33 |
miker |
kmlussier: well, it's less work for me to not create a new bug, so I'll add to the same branch :) |
| 10:34 |
kmlussier |
Works for me |
| 10:39 |
kmlussier |
Is anyone actively testing the latest branch at bug 1657237? |
| 10:39 |
pinesol_green |
Launchpad bug 1657237 in Evergreen "Trigger function maintaining hold-target mapping not well constrained" [Critical,Confirmed] https://launchpad.net/bugs/1657237 |
| 10:41 |
miker |
kmlussier: I know of several sites that are actively using it in production ... so, yes? |
| 10:41 |
kmlussier |
miker: I was thinking of somebody who could add a signoff to it. :) |
| 10:50 |
|
bos20k joined #evergreen |
| 11:02 |
miker |
kmlussier: branch at http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp1657885-alt-pull-list-print updated (this does fix PO activation for some broken cases) |
| 11:02 |
miker |
updating the LP ticket now |
| 11:02 |
kmlussier |
OK, thanks. I'll test it now. |
| 11:03 |
JBoyer |
miker, merge away! It fixed up the migration and dev servers that I had heretofore ignored with no problems. |
| 11:04 |
miker |
JBoyer: thanks! |
| 11:11 |
|
khuckins joined #evergreen |
| 11:33 |
pinesol_green |
[evergreen|Mike Rylander] LP#1657237: Rewrite the hold target cache - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cbe4cae> |
| 11:50 |
|
bmills joined #evergreen |
| 12:13 |
|
sandbergja joined #evergreen |
| 12:22 |
kmlussier |
miker: I noticed when testing Vandelay imports on OpenSRF 2.4, I'm not getting the usual updates on progress. Looking at your comments in the commit, I'm guessing that's expected? |
| 12:22 |
miker |
kmlussier: it is ... does the import succeed? |
| 12:24 |
miker |
kmlussier: I'll see if I can think of a good way to retain the behavior for 2.4 |
| 12:24 |
kmlussier |
miker: Yes, it does. But for a larger one, the progress bar never went away when the import was complete. When importing a smaller set of records, that wasn't a problem. |
| 12:25 |
miker |
kmlussier: gotcha. I'll see what I can do. do updates show up with opensrf master? (or are you not testing that yet?) |
| 12:25 |
kmlussier |
miker: Yes, they do in opensrf master. And they also work in opensrf master, so that's a big improvment. :) |
| 12:26 |
miker |
:) |
| 12:37 |
miker |
kmlussier: the branch is updated ... that should bring back the update stuff for 2.4 |
| 16:56 |
pinesol_green |
Launchpad bug 1392396 in Evergreen "Wishlist: Action Trigger for new user creation" [Wishlist,Fix released] https://launchpad.net/bugs/1392396 |
| 16:59 |
berick |
hah, there is already an 'au.create' even fire in the patron update API |
| 16:59 |
berick |
*event |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:08 |
|
mmorgan left #evergreen |
| 17:23 |
gmcharlt |
I've uploaded 2.10.9 and updated the downloads page |
| 17:23 |
gmcharlt |
I'll check in later this evening for 2.11.2 and to do the release announcement |
| 05:02 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:47 |
|
tspindler joined #evergreen |
| 06:57 |
|
agoben joined #evergreen |
| 07:13 |
|
rjackson_isl joined #evergreen |
| 09:58 |
* JBoyer |
feels for Dyrcona. Many are the LPs in my head, but faster are the workarounds and more work waits. :( |
| 10:22 |
|
Christineb joined #evergreen |
| 10:28 |
Dyrcona |
Great....The two servers where I've tried yaz-client get connection refused, but someone is connecting because the number of simple2zooms > 1. |
| 10:28 |
Dyrcona |
I just wanted to test the configuration, but I don't remember from where I tested it successfully last time. |
| 10:29 |
Dyrcona |
Maybe the training server? |
| 10:52 |
|
jvwoolf joined #evergreen |
| 11:23 |
|
abowling joined #evergreen |
| 14:53 |
jeff |
i see some queries involving auditor.asset_copy_history in your future. |
| 14:56 |
|
collum joined #evergreen |
| 14:59 |
Dyrcona |
Hmm... Can I tell psql to fill a variable from a file, one line at a time? Something tells me, "No." |
| 15:00 |
berick |
recently vacuum-full'ed auditor.asset_copy_history on a test server after removing old entries... table size went from 127G to 11G. woot. |
| 15:00 |
berick |
in less than 20 minutes, no less |
| 15:02 |
|
mmorgan1 joined #evergreen |
| 15:03 |
csharp |
@love vacuum full |
| 15:03 |
pinesol_green |
csharp: The operation succeeded. csharp loves vacuum full. |
| 16:54 |
Dyrcona |
It apparently has no concept of keep alive packets. |
| 16:55 |
phasefx |
Stompro: it's the staff client doing that; the web staff client isn't so zealous. Look at patron/search_form.js, line 372 |
| 16:57 |
phasefx |
Stompro: you could comment that out on the server-side and be okay, I think |
| 17:02 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:08 |
|
mmorgan left #evergreen |
| 17:12 |
Stompro |
Thanks, I'm trying to figure out why this is done. it would be one thing if names starting/ending with numbers couldn't be registered... |
| 17:19 |
Stompro |
Pre commit f7db7f578e6f numbers were allowed, then it was changed to allow unicode characters but to exclude digits. I wonder if that was on purpose or not? |
| 03:41 |
|
serflog joined #evergreen |
| 03:41 |
|
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 |
| 05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:15 |
|
rjackson_isl joined #evergreen |
| 07:29 |
|
agoben joined #evergreen |
| 08:01 |
|
kmlussier joined #evergreen |
| 10:50 |
kmlussier |
rjackson_isl: There are times when account adjustments are used even if those library settings are not enabled, but it's not for lost item returns. |
| 10:53 |
rjackson_isl |
kmlussier++ |
| 10:53 |
kmlussier |
rjackson_isl: More detail here: http://docs.evergreen-ils.org/2.9/_circulation_4.html. But it looks like those adjustments are always applied, regardless of settings, when overdue fines are adjusted after marking an overdue item lost. |
| 10:57 |
al-muradi |
hey thanks for replies. yes the server we are testing on is a bit weak.. just 3GB of RAM |
| 10:59 |
al-muradi |
but it is a fresh debian installation and nothing else is running on it.. |
| 11:03 |
phasefx |
al-muradi: if you're doing a full stack on one server (database, apache, memcached), then you want it to be beefy. But if you're just playing with it, and aren't going to have multiple concurrent users, then it'll probably be okay |
| 11:04 |
* phasefx |
uses 4GB minimum for his virtual machines |
| 11:06 |
al-muradi |
m. i see.. |
| 11:08 |
al-muradi |
so there is no threads or amounts that one can cut on somewhere in the eg.conf or ejabberd confs.. at least for testing |
| 11:09 |
phasefx |
al-muradi: there's all sorts of tuning one can do, but I don't know what would be best for you given your constraints and your intended uses. The number of Apache children to spawn at startup is configurable |
| 11:09 |
berick |
3G ram is plenty for testing |
| 11:09 |
phasefx |
berick++ |
| 11:10 |
phasefx |
al-muradi: I think the real test is to see how it performs while you're using it |
| 11:10 |
berick |
using a default install, i would expect apache to start up in a matter of seconds on a 3G ram server. if it's not, something is probably not right.. |
| 11:10 |
al-muradi |
why does one need so many apache children, actually? |
| 11:11 |
berick |
al-muradi: how many is it starting? |
| 11:13 |
berick |
ps ax | grep apache |
| 11:13 |
al-muradi |
no |
| 11:14 |
al-muradi |
they are all apache2 -k start |
| 11:14 |
berick |
i'm currently working on a 2G ram test server. I have 14 total apache processes. half of them are apache-websockets. |
| 11:14 |
berick |
ok |
| 11:14 |
berick |
well, in any event, 18 is more than I would epxect, but it's not that high |
| 11:15 |
berick |
try changing the apache StartServers config to 5, see if that helps at all |
| 11:16 |
al-muradi |
like in the mpm prefork thing |
| 11:16 |
al-muradi |
? |
| 11:16 |
berick |
in /etc/apache2/mods-enabled/mpm_prefork.conf |
| 11:16 |
berick |
yeah |
| 11:19 |
al-muradi |
mmm seems the same |
| 11:20 |
al-muradi |
also memory is still just using 1500mb.. cpu usage is 100% |
| 11:20 |
berick |
hm, ok |
| 11:21 |
berick |
sounds like something is wrong, then. have you tested in 'srfsh' yet? |
| 11:21 |
al-muradi |
it gets stable more quickly now, tho |
| 11:21 |
berick |
so, like phasefx asked.. does it work after it stabililizes? |
| 11:21 |
al-muradi |
just two minutes.. |
| 11:22 |
berick |
how many cpu cores? |
| 11:22 |
al-muradi |
to see what happens.. |
| 11:22 |
al-muradi |
2 cores |
| 11:23 |
berick |
hm, 2 cores might have something to do with it. |
| 11:24 |
berick |
i generally use 4 cores for my VM's. haven't tested on 2 in some time. |
| 11:24 |
berick |
don't know how it compares |
| 11:25 |
berick |
when apache first starts, there is a lot of CPU churning |
| 11:27 |
al-muradi |
ah allright. so it might just be that. will try and get a better machine to compare.. |
| 11:27 |
berick |
if raising the cpu core count is not an option, i'd lower StartServers to 2 |
| 11:28 |
berick |
but that may just be offsetting the delay, depending on how busy the test server gets |
| 11:29 |
bshum |
"Some thousand records" to be added... might want more memory down the road too. |
| 11:30 |
bshum |
3 GB is what I'd call bare minimum for concerto-sized test systems. With anything more real, I'd want more memory to avoid weirdness. |
| 11:30 |
|
mmorgan1 joined #evergreen |
| 11:43 |
|
al-muradi joined #evergreen |
| 11:51 |
|
bmills joined #evergreen |
| 12:01 |
|
brahmina joined #evergreen |
| 12:01 |
al-muradi |
uhm and anybody has seen this error before, when logging in with a client? Method [open-ils.storage.actor.org_unit.descendants.atomic] not found for OpenILS::Application::Storage |
| 12:16 |
phasefx |
al-muradi: have you tweaked your org hierarchy at all? or are you using stock concerto test data? |
| 12:17 |
al-muradi |
stock data |
| 12:20 |
|
jihpringle joined #evergreen |
| 12:20 |
phasefx |
al-muradi: this is a little out of date, but it's my general strategy for troubleshooting: https://wiki.evergreen-ils.org/doku.php?id=troubleshooting:checking_for_errors The OpenSRF commands need to replaced with their osrf_control equivalents |
| 12:46 |
al-muradi |
happened before during installation, for some reason some cpan modules were not installed |
| 12:47 |
al-muradi |
thanks a lot for the quick answers. |
| 12:47 |
phasefx |
al-muradi: you're welcome |
| 12:48 |
kmlussier |
al-muradi: I hope your Evergreen testing goes well! |
| 12:48 |
phasefx |
I sometimes think we need to set up mirrors for every dependency, and rig the build process to fallback on those if needed |
| 12:49 |
al-muradi |
I didnt have this problem with the 64 bit version, though |
| 13:04 |
csharp |
al-muradi: 32-bit OSes aren't well-tested nowadays - I think 64-bit is pretty much assumed |
| 13:06 |
al-muradi |
abandonware-ils |
| 13:17 |
bshum |
csharp: "aren't well tested" meaning perhaps, "not tested at all" |
| 13:17 |
bshum |
:) |
| 13:21 |
rhamby |
I think it means "wait, we still release that?" |
| 13:26 |
bshum |
I guess it doesn't explicitly say to use 64-bit editions in the README |
| 13:26 |
bshum |
On the downloads page, it does say that for Ubuntu |
| 14:36 |
* kmlussier |
agrees with berick that it was funny. |
| 14:45 |
|
dteston joined #evergreen |
| 16:40 |
|
gmcharlt joined #evergreen |
| 17:02 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 17:03 |
phasefx |
speaking of dependencies... |
| 17:04 |
phasefx |
npm ERR! cb() never called! |
| 17:06 |
|
mmorgan left #evergreen |
| 00:50 |
|
Mark__T joined #evergreen |
| 05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:12 |
|
agoben joined #evergreen |
| 07:54 |
|
collum joined #evergreen |
| 08:11 |
|
kmlussier joined #evergreen |
| 08:40 |
|
mmorgan joined #evergreen |
| 08:51 |
|
yboston joined #evergreen |
| 08:52 |
|
rhamby joined #evergreen |
| 09:09 |
pinesol_green |
[evergreen|Jeanette Lundgren] LP#1494362 Docs: oversized screenshot - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cb07714> |
| 09:28 |
jeff |
like like actor_usr_family_name_unaccent_idx may have an unqualified function call that presents a pg_restore challenge. |
| 09:29 |
* jeff |
looks |
| 09:29 |
* Bmagic_ |
wakes |
| 09:50 |
JBoyer |
csharp++ |
| 09:50 |
JBoyer |
I suppose I can start that process too, need to update our mig server anyway. |
| 09:51 |
jeff |
in my case, this was a fresh db on pg 9.4 created with evergreen 2.11.1 tarball eg_db_config |
| 09:51 |
* csharp |
uses -Fd to take advantage of multiple cores on test DB server |
| 09:53 |
* jeff |
nods |
| 09:54 |
jeff |
doing a pg_dump with -Fd and -j32 is always fun to see run. |
| 09:54 |
csharp |
-j48 here |
| 09:54 |
csharp |
(64 cores) |
| 09:54 |
jeff |
also fun last night was turning a test aws instance into a BIG test aws instance just to run pingest. |
| 09:54 |
csharp |
:-) |
| 09:57 |
jeff |
(and then remembering to turn it off again when i was done) |
| 10:00 |
csharp |
heh |
| 13:35 |
|
afterl joined #evergreen |
| 13:41 |
csharp |
berick++ - thanks |
| 13:42 |
|
tspindler joined #evergreen |
| 13:44 |
berick |
csharp++ terran++ # testing |
| 13:44 |
berick |
well, using |
| 13:44 |
* berick |
is planning to roll out the new targeter after our 2.9 upgrade |
| 13:46 |
|
rgagnon joined #evergreen |
| 13:46 |
terran |
berick++ for such a quick fix! |
| 13:50 |
|
ohiojoe joined #evergreen |
| 16:02 |
remingtron |
kmlussier: thanks! |
| 16:18 |
kmlussier |
Bah! I need to re-read the grammar in my LP comments before I hit submit. |
| 16:31 |
miker |
kmlussier: :) ... responded. it's the full fix |
| 16:32 |
kmlussier |
miker: Ok, thanks! |
| 16:32 |
* kmlussier |
will try to look at it today if nobody beats her to it because it's been causing her headaches on her test VMs. |
| 16:42 |
miker |
kmlussier: thanks! |
| 16:42 |
miker |
kmlussier: have you been using opensrf master on your VMs? |
| 16:42 |
miker |
because I don't think it should be causing problems on opensrf 2.4 or before |
| 16:44 |
|
mmorgan joined #evergreen |
| 16:44 |
kmlussier |
And then I try to upload a bunch of records and the upload hangs. |
| 17:00 |
|
afterl left #evergreen |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:00 |
|
jlundgren left #evergreen |
| 17:01 |
|
khuckins__ joined #evergreen |
| 17:04 |
csharp |
JBoyer: jeff: I can confirm that the same thing happens on our production data: http://pastebin.com/YR7EfSGb |
| 05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 05:55 |
|
Mark__T joined #evergreen |
| 06:16 |
csharp |
berick: for when you're back around, in the new hold targeter, there needs to be a space added in one of the log messages (HoldTargeter.pm, lines 696/697): |
| 06:16 |
csharp |
$self->log_hold("skipping copy ". |
| 15:39 |
Dyrcona |
I intended to submit one last Thursday/Friday.... |
| 15:40 |
bshum |
Well I think I remember reading about how popular git talks can be. :) |
| 15:40 |
Dyrcona |
heh |
| 15:40 |
kmlussier |
bshum / Dyrcona: Will I really get my money back if I don't get a test system up and running? |
| 15:41 |
kmlussier |
And why did my /me not working earlier? |
| 15:41 |
Dyrcona |
Maybe you had a space in front of it. |
| 15:42 |
Dyrcona |
/me |
| 15:42 |
Dyrcona |
Like that. |
| 16:30 |
|
akilsdonk joined #evergreen |
| 16:59 |
jeff |
hrm. |
| 17:00 |
jeff |
dear pingest: why do you appear to be stuck on your final batch of 100 records on this system? |
| 17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:05 |
jeff |
hrm. seems to be spinning on metabib.browse_entry_def_map |
| 17:07 |
csharp |
jeff: the inline comments mention that |
| 17:08 |
csharp |
took about 20 hours for it to process on our server |
| 17:08 |
csharp |
in one test run it took 36 hours |
| 17:09 |
jeff |
ah: |
| 17:09 |
jeff |
# This subroutine forks a process to do the browse-only ingest on the |
| 17:09 |
jeff |
# @blist above. It cannot be parallelized, but can run in parrallel |
| 00:43 |
|
bmills joined #evergreen |
| 05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 05:21 |
|
gmcharlt joined #evergreen |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:14 |
|
rjackson_isl joined #evergreen |
| 10:06 |
berick |
csharp: iirc, it's pulling data from aged_circulation now |
| 10:07 |
csharp |
right - and action.circulation and action.aged_circulations are huge and are getting seq scans |
| 10:10 |
berick |
got the original query and/or analyze? |
| 10:10 |
csharp |
I'm running an explain analyze now on our test server - coming soon (or not) |
| 10:10 |
csharp |
argh - it's not giving me any useful data |
| 10:11 |
csharp |
http://pastebin.com/SHumZdwj |
| 10:11 |
JBoyer |
You'll likely have to run some of the queries inside it by hand to see what's really happening. postgres really doesn't explain functions. :/ |
| 10:12 |
berick |
yeah... |
| 10:14 |
csharp |
it's action.all_circ_chain, and it contains 2 loops |
| 10:39 |
berick |
caching should not be any different w/ the new auth code. (it all uses the same C cache client) |
| 10:39 |
JBoyer |
Shoot. Well, you said you wanted to get through circ anyway, I'll stop grasping at straws. |
| 10:40 |
berick |
running out of children is, of course, a problem |
| 10:41 |
bshum |
krvmga: If there's an email text gateway for the SMS config, i don't see why not. |
| 10:42 |
bshum |
But I haven't tested it personally in any way. |
| 10:42 |
bshum |
And who knows with google voice, vs. I assume you mean something like Project Fi users |
| 10:42 |
berick |
csharp: were you also seeing no-children for both open-ils.auth and auth_internal? it may just be that the login process takes longer now, just enough to throw off the delicate balance of max_children |
| 10:42 |
csharp |
berick: just auth, not auth_internal |
| 10:42 |
berick |
ok |
| 10:46 |
bshum |
krvmga: yeah I just read over this article about Project Fi integration for SMS/email - https://support.google.com/fi/answer/6356597?hl=en |
| 10:47 |
bshum |
But I kind of hate it, given the precarious nature of hangouts vs. sms vs. google voice vs. whatever else google is doing under the hood with all that. |
| 10:47 |
krvmga |
yes, thanks. i was looking at the same. |
| 10:47 |
bshum |
They keep changing their minds over there. |
| 10:47 |
|
Christineb joined #evergreen |
| 10:48 |
bshum |
Live testing, whee |
| 10:54 |
csharp |
berick++ # adding the parent_circ index to aged_circulation works - now waiting for index creation to finish on our overloaded live DB :-) |
| 10:54 |
berick |
awesome! |
| 10:54 |
berick |
csharp: if you open a bug (when you have time) i'll pitch in |
| 16:23 |
david___ |
Thanks for the input... |
| 16:24 |
|
david___ left #evergreen |
| 16:50 |
|
tsadok joined #evergreen |
| 17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:04 |
|
mmorgan left #evergreen |
| 18:08 |
|
rlefaive joined #evergreen |
| 19:25 |
|
_adb joined #evergreen |
| 00:22 |
|
phasefx_ joined #evergreen |
| 02:36 |
|
wsmoak joined #evergreen |
| 05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:12 |
|
rjackson_isl joined #evergreen |
| 07:51 |
rhamby |
morning |
| 08:06 |
jeff |
good morning! |
| 15:43 |
jeff |
i thought that pymarc was silently dropping subfields when there was a problematic character in the data, but that turns out to be yaz-marcdump. |
| 15:44 |
jeff |
checking more recent versions of yaz-marcdump and changelog to see if that's a known/fixed issue, expected behavior, etc. |
| 15:44 |
Dyrcona |
COPY is too slow. You need to use JDBC, run about 12 threads, and do batch updates of 10,000 rows a piece. :P |
| 15:44 |
* phasefx |
uses yaz-marcdump to convert to UTF-8 and marc_cleanup from migration-tools; some records do get thrown out in that process. Not sure about the 0107 Foo example |
| 15:45 |
phasefx |
we should collect some problem records like that and build tests |
| 15:45 |
jeff |
but in the case of an 020 tag with one subfield that yaz-marcdump doesn't like, you end up with an empty 020 with zero subfields, which throws a fatal error in MARCC::File::XML when it comes time to maintain_901 :-) |
| 15:46 |
phasefx |
yeah, marc_cleanup throws out empty tags |
| 15:46 |
phasefx |
brb |
| 16:23 |
|
mllewellyn joined #evergreen |
| 16:26 |
|
mllewellyn left #evergreen |
| 16:26 |
|
mllewellyn joined #evergreen |
| 17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:02 |
|
jvwoolf left #evergreen |
| 17:03 |
|
mmorgan left #evergreen |
| 17:22 |
|
dbwells joined #evergreen |
| 02:49 |
|
miker joined #evergreen |
| 02:49 |
|
abneiman joined #evergreen |
| 02:49 |
|
Shae joined #evergreen |
| 05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:13 |
|
rjackson_isl joined #evergreen |
| 07:58 |
|
jvwoolf joined #evergreen |
| 14:16 |
Dyrcona |
Thanks! I'll probably drop the extra GIST indexes soonish. |
| 14:17 |
JBoyer |
csharp, Am I remembering correctly that GIN is (roughly) 3x faster and 3x bigger? |
| 14:18 |
JBoyer |
(Than GiST, that is.) |
| 14:21 |
bshum |
Bigger, at least till you get the new stuff in PG 9.4+ (we hope) |
| 14:21 |
bshum |
I didn't get to test it, but PG 9.4 boasted reduced GIN size in the release notes |
| 14:21 |
bshum |
Well, test it with live data |
| 14:24 |
csharp |
JBoyer: yep and yep |
| 14:24 |
csharp |
I rebuilt the GIN indexes in 9.4, but didn't measure the size difference |
| 14:24 |
csharp |
we did notice a performance improvement though |
| 16:36 |
jeff |
is it a matter of searching for a name fragment + dob off of ID and then seeing high-probability duplicate / variant accounts? |
| 16:37 |
jeff |
now having asked, i have a stong feeling of deja vu, but the bug is new, so... |
| 16:47 |
|
rlefaive left #evergreen |
| 17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:08 |
|
jvwoolf left #evergreen |
| 17:11 |
|
mmorgan left #evergreen |
| 17:25 |
terran |
jeff: yes, that's it - in our case, we just have so many patrons that duplicate names is a huge problem, especially if we're searching by "j smith" to catch variations of john / jon / jonathon etc |
| 04:40 |
|
serflog joined #evergreen |
| 04:40 |
|
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 |
| 04:40 |
|
abneiman joined #evergreen |
| 05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 05:37 |
|
StomproJ joined #evergreen |
| 07:19 |
|
rjackson_isl joined #evergreen |
| 08:11 |
pinesol_green |
[evergreen|Mike Rylander] LP#1655149: Badges need CDBI support for location groups - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8958094> |
| 08:14 |
|
Stompro joined #evergreen |
| 08:16 |
|
collum joined #evergreen |
| 08:28 |
|
collum joined #evergreen |
| 08:38 |
|
rlefaive joined #evergreen |
| 08:40 |
|
mmorgan1 joined #evergreen |
| 08:46 |
|
StomproJ joined #evergreen |
| 08:55 |
miker |
_bott_: aye. thanks for testing it |
| 09:08 |
|
jvwoolf joined #evergreen |
| 09:09 |
|
yboston joined #evergreen |
| 09:15 |
|
maryj joined #evergreen |
| 13:12 |
dbwells |
kmlussier: anything to note on the feedback soliciting? |
| 13:12 |
kmlussier |
I didn't get to that action item. I'll have to defer it for next month's meeting. |
| 13:12 |
kmlussier |
I'll send something out this week. |
| 13:12 |
dbwells |
okay, thank you |
| 13:13 |
dbwells |
#info kmlussier will post to open-ils-dev soliciting feedback on the release process documentation (carry over) |
| 13:14 |
dbwells |
sorry, let me action that |
| 13:14 |
dbwells |
#action kmlussier will post to open-ils-dev soliciting feedback on the release process documentation |
| 13:14 |
dbwells |
#topic OpenSRF release info |
| 13:15 |
dbwells |
#info OpenSRF 2.5-alpha was release on 7 December 2016 |
| 13:15 |
dbwells |
Does anyone else have comment on that? |
| 13:15 |
dbwells |
as a reminder, gmcharlt is hoping for testing of three aspects: |
| 13:15 |
dbwells |
1. the proxy configurations |
| 13:16 |
dbwells |
2. bundling and chunking |
| 13:16 |
dbwells |
3. TZ changes |
| 13:16 |
dbwells |
#topic Evergreen release info |
| 13:17 |
dbwells |
#topic state of Arabic translation |
| 13:17 |
dbwells |
phasefx: Might you be available for a quick update? Not seeing the others in channel. |
| 13:18 |
kmlussier |
I know there has been a lot of discussion on this over the past week. I think Nawjo may have found a solution that works for him locally. |
| 13:20 |
dbwells |
#info some progress has been made on Arabic support with some localized changes |
| 13:20 |
kmlussier |
There has been talk of including support in 2.12, but I don't know if anyone is actively working on it. |
| 13:27 |
berick |
kmlussier: yes |
| 13:27 |
dbwells |
sorry, didn't even realize the bug already had two branches on it. |
| 13:27 |
kmlussier |
berick: I didn't address it in my web client e-mail from last week, but that was mostly an oversight. Do you consider this as a must-have branch for production use of the web client? |
| 13:27 |
berick |
kmlussier: if we want anyone to test Hatch in production, yes |
| 13:28 |
berick |
otherwise, not a showstopper, I don't think, but a nice to have |
| 13:28 |
berick |
so we can start smoothing over any bugs introduced i this code |
| 13:28 |
berick |
and fix a few along the way |
| 13:28 |
kmlussier |
OK, I think I'm going to stop short of calling it a showstopper, but I agree that it would be better to have it in there. |
| 13:30 |
kmlussier |
And we had people (including me) who volunteered to test it during the last meeting. I don't know if jeff or gmcharlt had a chance to look at it, but I know I didn't. |
| 13:30 |
gmcharlt |
#info gmcharlt = Galen Charlton, back from a competing meeting |
| 13:31 |
csharp |
kmlussier: not a showstopper for 2.12, but I would consider it one for 3.0 (first web client GA release) |
| 13:31 |
kmlussier |
@blame competing meetings. |
| 13:51 |
kmlussier |
jeffdavis: Are there specific pieces of it we can help out with? |
| 13:51 |
Dyrcona |
Yeah, time is my shortest commodity at the moment. "So much to do....So much to do..." |
| 13:51 |
dbwells |
jeffdavis: I probably wouldn't be able to merge your branch, since we don't subscribe to the services. Is any part testable without subscription? |
| 13:51 |
jeffdavis |
My current plan is to get the key UI bits working over the next couple of weeks, then share that with some basic documentation. |
| 13:52 |
jeffdavis |
There is a test module which will be usable for seeing how it works without having subscribed to OverDrive or OneClickdigital's APIs. |
| 13:52 |
jeffdavis |
although of course testing against live external systems would be important for including it in a release :) |
| 13:53 |
jeffdavis |
kmlussier: not so much specific pieces until the above is done. Hoping that devs can weigh in if there are issues with the approach outlined in the LP bug, otherwise just wanted to raise awareness of this work. |
| 13:53 |
kmlussier |
If I wanted to test it against our Overdrive, would I need to sign up for an API key ahead of time? |
| 13:54 |
jeffdavis |
Yes. My attempts to arrange shareable vendor API access for testing have not panned out so far. |
| 13:54 |
kmlussier |
OK, I'll try to go about doing that in preparation for testing. There's a lot of interest here too. :) |
| 13:55 |
dbwells |
Well, I'd say awareness has been raised. Thanks for bringing it up. Anything else before I end the meeting? |
| 13:55 |
kmlussier |
Yes |
| 13:56 |
kmlussier |
I just wanted to remind everyone that I would like to schedule a web client hacking day to get more work done on the web client before the beta release. |
| 14:02 |
JBoyer |
csharp, do you know if there are still many reports in PINES that use the dewey_block_* fields in reporter.classic_current_circ? If we try to filter on say, dewey_block_hunreds = '900' the query blows up with ERROR: invalid input syntax for type double precision: "." |
| 14:02 |
JBoyer |
Drop that out altogether and it's fine. |
| 14:05 |
|
maryj_ joined #evergreen |
| 14:05 |
csharp |
JBoyer: ewww |
| 14:06 |
csharp |
JBoyer: I know libraries *do* use it, but I'm pretty sure we haven't tested it |
| 14:06 |
|
krvmga joined #evergreen |
| 14:06 |
JBoyer |
"Eww" is what I thought too. :) |
| 14:07 |
JBoyer |
I've been toying with a simple test query that I had clark log from a template that was built today. That error makes no sense given what it does. :/ |
| 14:08 |
jeff |
JBoyer: are you running into a situation where unexpected input data is being transformed into something which postgres then fails to cast? |
| 14:09 |
jeff |
JBoyer: depending on how things are being transformed beforehand, you might not actually have input data of '.', but might be an empty string, or something like 'foo.bar' or ' .', etc. |
| 14:14 |
csharp |
I've moved away from recommending the classic_current_circ source generally, though because the join to metabib.rec_descriptor creates seq scans o'plenty |
| 16:08 |
|
egbuilder joined #evergreen |
| 16:19 |
|
NawJo joined #evergreen |
| 16:30 |
|
jvwoolf joined #evergreen |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 19:12 |
|
book` joined #evergreen |
| 19:13 |
|
sard joined #evergreen |
| 20:53 |
|
dcook joined #evergreen |
| 03:51 |
|
wsmoak joined #evergreen |
| 04:11 |
|
StomproJ joined #evergreen |
| 04:59 |
|
Stompro joined #evergreen |
| 05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 05:07 |
|
StomproJ joined #evergreen |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:16 |
|
rjackson_isl joined #evergreen |
| 09:47 |
agoben |
well and all the other things tied to the item ID :) |
| 09:48 |
|
_adb joined #evergreen |
| 09:51 |
JBoyer |
I can't decide if it's a good thing or a bad one that it isn't reproducible. :/ |
| 09:51 |
csharp |
works on our 2.11.1 test server as far as I can tell |
| 09:51 |
csharp |
usually feels worse when it's not reproducible in other places :-/ |
| 09:51 |
* JBoyer |
is leaning that way |
| 09:52 |
* mmorgan |
just checked the asset.copy table and confirmed that it's not happening on our 2.11.1 system. |
| 09:52 |
JBoyer |
I suppose that means I should stop looking at git.evergreen-ils.org and start looking more closely at our local branch. |
| 10:47 |
miker |
Dyrcona: strictly speaking, should not be necessary, and we don't. autogen de-populates memcache of objects it creates, IIRC |
| 10:48 |
Dyrcona |
miker: Thanks. I recall tsbere telling me something like that a year or two ago, and I don't always restart apache after running autogen, but often do on my dev vms at least. |
| 10:48 |
Dyrcona |
Sometimes, that's because I just restarted services before doing the autogen, maybe. ;) |
| 10:48 |
_bott_ |
tsbere: You may find this useful, re Net::HTTP http://pastebin.com/raw/HpMzeRK1 |
| 10:50 |
_bott_ |
That's the result of a few lines of Perl, testing read_response_headers() |
| 10:52 |
* csharp |
doesn't usually restart apache after autogen runs |
| 10:54 |
Dyrcona |
cssh++ |
| 10:55 |
Dyrcona |
bshum++ # For recommending cssh |
| 14:14 |
jeff |
i see some shady characters in your future... wait, no. malformed characters -- not shady. |
| 14:15 |
* jeff |
makes a weak rdacarrier / medium joke |
| 14:16 |
berick |
the spirits all recoil in horror at MARC |
| 14:40 |
kmlussier |
Looks like it will be 1 p.m. Eastern on Tuesday the 10th. I'll add it to the calendar and send out an e-mail. |
| 14:57 |
|
bos20k joined #evergreen |
| 15:26 |
kmlussier |
gmcharlt / miker: If you're around, I was thinking of testing/merging the recent web client code in the collab branch either today or first thing Monday. Is there current activity happening there that would make it a bad idea for me to do so? |
| 15:27 |
gmcharlt |
kmlussier: no, the branch should be in a stable enough state |
| 15:27 |
kmlussier |
gmcharlt: Great, thanks! |
| 15:28 |
* kmlussier |
also noticed that we're just a month away from feature slush. Yikes! |
| 15:49 |
|
brahmina joined #evergreen |
| 16:33 |
|
jvwoolf left #evergreen |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:04 |
|
mmorgan left #evergreen |
| 18:27 |
|
bmills joined #evergreen |
| 19:13 |
|
Stompro joined #evergreen |
| 02:43 |
|
abowling joined #evergreen |
| 05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:15 |
|
agoben joined #evergreen |
| 07:23 |
|
rjackson_isl joined #evergreen |
| 10:51 |
Dyrcona |
Bmagic: Have you had problems with added content? |
| 10:51 |
_bott_ |
fwiw, NoveList had no issues |
| 10:51 |
|
Dawn joined #evergreen |
| 10:51 |
Dyrcona |
_bott_: Thanks! I haven't tested added content on Ubuntu 16. |
| 10:52 |
_bott_ |
Nor had I. That's what production is for! |
| 10:52 |
Dyrcona |
Come to think of it.... Let me check something. I might have inadvertently tested Content Cafe. ;) |
| 10:53 |
Dyrcona |
Nope. False alarm. |
| 10:53 |
Guest82566 |
Hi, does anyone use the Evergreen integrated credit card payment at the front desk? We use the online integrated payments and would like to look into using the front line payments as well. |
| 10:54 |
Dyrcona |
Oh, wait. Wrong server. Yes, I have run 16.04 on a test vm where I believe Content Cafe was configured and don't recall seeing any issues. |
| 10:54 |
Dyrcona |
Guest82566: Don't do that, unless you like paying lots of money in PCI insurance premiums. |
| 11:03 |
|
Christineb joined #evergreen |
| 11:03 |
Guest82566 |
Thanks, Dyrcona. |
| 11:35 |
Guest82566 |
Thank you, Jeff. |
| 11:37 |
berick |
"2.75% per swipe, dip, or tap" -- spending piles of money was never so adorable |
| 11:40 |
|
brahmina joined #evergreen |
| 11:41 |
Dyrcona |
berick: They all hit you with fees, but I can say from experience if you're processing the CC transactions through Evergreen, you will also pay for the insurance, because you will not pass the tests. |
| 11:43 |
Dyrcona |
_bott_ Do yo have customizations to the Syndetics code? |
| 11:43 |
_bott_ |
Dyrcona: Nope, nothing for them. |
| 11:43 |
Dyrcona |
OK. Just aking, 'cause I know you have some customizations. |
| 11:44 |
bshum |
Bmagic: Did you test the added content in the record details, like _bott_ noted issue for? I'm not sure if it was just that or if it affected covers, _bott_ ? |
| 11:44 |
bshum |
I think he said reviews, etc. right? |
| 11:44 |
bshum |
reviews, summary, etc. |
| 11:44 |
_bott_ |
bshum: correct. |
| 11:45 |
_bott_ |
Tabs display for each of the noted, but no content |
| 11:46 |
_bott_ |
All seems happy until my ($code) = $req->read_response_headers; in Record.pm. $code ends up empty |
| 11:52 |
Dyrcona |
_bott_: So, I'm looking at content cafe via the opac on my old, MVLC development vm. (It's still running after over 6 months of not being touched!) |
| 11:52 |
Dyrcona |
Novelist is working fine, but the content cafe stuff is acting bizarre. |
| 11:53 |
Dyrcona |
So, it looks like you're on to something. |
| 11:55 |
csharp |
We'll be testing on 16.04 soon (post upgrade to 2.11 next weekend) and we use Syndetics - if it's not solved by then, I'm willing to help |
| 11:56 |
Bmagic |
bshum Dyrcona: sorry, I was away, I am catching up here |
| 11:57 |
|
jihpringle joined #evergreen |
| 11:57 |
JBoyer |
csharp, what kind of use are you seeing on your 2.11 testing server? I'm seeing a lot of seemingly random waiting on locks here. (Slony might be contributing to that though, but it has increased dramatically since the upgrade.) |
| 11:59 |
|
bmills joined #evergreen |
| 12:02 |
Bmagic |
bshum: no I didn't check that. Just the book jackets (most obvious) - I will have to take a closer look at that added content stuff |
| 12:03 |
NawJO |
Hello everyone, I was thinking lately on solving RTL-LTR switching in TPAC, I created a custom RTL template and added it to eg.conf. I thought to add a conditional sentence on applying RTL template, but I have no clue, can you help me? |
| 12:07 |
bshum |
So that does seem to point at a 16.04 problem with added content handling :\ |
| 12:09 |
|
mrpeters1 joined #evergreen |
| 12:09 |
Bmagic |
sounds plausable |
| 12:10 |
* bshum |
doesn't have any added content codes to test with, so will leave it in more experienced hands now :) |
| 12:10 |
bshum |
NawJO: What I was thinking was to change something in ../opac/parts/base.tt2 |
| 12:11 |
bshum |
In there, we define the stylesheets |
| 12:12 |
bshum |
So I was thinking to put an [% IF something.locale.something = "ar-AR" check there to see if we were using a particular locale, and then add a link to the stylesheet we add in |
| 12:12 |
miker |
NawJO: looks like you could add something like the following to templates/opac/css/style.css.tt2 ... |
| 12:12 |
bshum |
Otherwise, it'll skip it |
| 12:12 |
bshum |
but sounds like miker has ideas too :) |
| 12:14 |
NawJO |
everything set to right must be set to left and vice versa |
| 12:15 |
NawJO |
it's not too different, but every right is changed to left, and every left is changed to right |
| 12:15 |
NawJO |
like margin-left to margin-right, float:left to float: right |
| 12:15 |
miker |
ah! I see. just went to the test site. |
| 12:15 |
NawJO |
http://104.251.212.186/eg/opac/home |
| 12:16 |
miker |
very cool |
| 12:16 |
Bmagic |
bshum: I think this proves it |
| 14:29 |
NawJO |
it's time for me to go offline. Have a good time :) |
| 14:53 |
|
brahmina joined #evergreen |
| 15:03 |
berick |
@tea my-belly |
| 15:03 |
* pinesol_green |
brews and pours a pot of Wild Snow Sprout Tea, and sends it sliding down the bar to my-belly (http://ratetea.com/tea/wild-tea-qi/wild-snow-sprout-tea/6447/) |
| 15:08 |
|
mmorgan joined #evergreen |
| 15:16 |
|
mmorgan joined #evergreen |
| 15:59 |
|
brahmina joined #evergreen |
| 16:38 |
|
kmlussier joined #evergreen |
| 16:51 |
|
bmills joined #evergreen |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:05 |
|
mmorgan left #evergreen |
| 17:15 |
|
jvwoolf left #evergreen |
| 17:18 |
|
khuckins joined #evergreen |
| 15:02 |
bshum |
I've been thinking about the RTL vs. LTR issues lately |
| 15:02 |
bshum |
I'd love to see the stylesheet this was created with |
| 15:02 |
kmlussier |
That's interesting. So the RTL stylesheet isn't dependent on the locale that's selected? I see everything goes RTL when French is selected. |
| 15:02 |
Nawjo |
actually, I'm not familiar with EG yet. I'm trying to apply Arabic translation, then I'll add some testing data . |
| 15:02 |
bshum |
It's probably forced |
| 15:03 |
Nawjo |
yes exactly ! Stylesheets must change according to locale , but I couldnt achieve that |
| 15:03 |
bshum |
I've been thinking about how to design some variable that would detect which direction based on the chosen language and apply appropriately |
| 16:08 |
Nawjo |
I'm not that one :D haha |
| 16:09 |
Dyrcona |
:) |
| 16:51 |
Nawjo |
bshum I've just sent the styles to your mail :) |
| 16:51 |
bshum |
Nawjo: Cool, look forward to playing with that more in the coming days |
| 16:52 |
bshum |
I'll send you what I can put together to try new RTL variable detecting when I get a test server put together to try things out |
| 16:53 |
Nawjo |
that's good :) |
| 16:54 |
|
vlewis joined #evergreen |
| 16:57 |
bshum |
Nawjo++ # welcome and thanks for sharing, look forward to working with you more on this |
| 16:58 |
Nawjo |
thank you bshum :) |
| 16:59 |
kmlussier |
Nawjo++ # thanks for starting the conversation on this! |
| 16:59 |
kmlussier |
bshum++ # For diving in further. |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:02 |
Nawjo |
I can't wait till I see our libraries using Arabic Evergreen ILS:) Thank you for your help and support. Your team is friendly and nice, nice to talk to you all :) |
| 17:02 |
vlewis |
kmlussier # I'm working on https://bugs.launchpad.net/evergreen/+bug/1522644 webclient: Transfer title holds issues So you think I should move or remove the button? |
| 17:02 |
pinesol_green |
Launchpad bug 1522644 in Evergreen "webclient: Transfer title holds issues" [Medium,New] - Assigned to Victoria Lewis (sykeslewis) |
| 17:04 |
kmlussier |
vlewis: Personally, I think we should remove it. Or maybe comment it out? |
| 17:04 |
kmlussier |
That way, if somebody really wants to use it, they could easily reinstate it. |
| 17:05 |
mmorgan |
That sounds like a good solution to me. |
| 17:07 |
kmlussier |
vlewis: There were concerns when I tried to remove it from the xul client a while back, but now it's really easy to select all the holds and select the "transfer selected" option. |
| 17:07 |
* kmlussier |
had hoped to test some of the new web client fixes today, but got caught up in a more tedious task. Sigh... |
| 17:09 |
|
mmorgan left #evergreen |
| 17:09 |
vlewis |
I can comment it out. |
| 17:11 |
kmlussier |
Better than my alert suggestion from last month - http://irc.evergreen-ils.org/evergreen/2016-11-29#i_277681 |
