Time |
Nick |
Message |
01:19 |
|
remingtron joined #evergreen |
05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
07:18 |
|
rjackson_isl joined #evergreen |
08:21 |
|
_adb joined #evergreen |
08:35 |
csharp |
working with test_json_query this morning... how to I make it not freak out when there are spaces in a key (ex. "not in")? |
08:36 |
csharp |
https://pastebin.com/hwwjviB9 |
08:39 |
|
Dyrcona joined #evergreen |
08:40 |
|
mmorgan joined #evergreen |
08:41 |
tsbere |
csharp: Not sure, but I didn't think "not in" was in the list of 2+ word operators allowed |
08:49 |
csharp |
tsbere: working from https://wiki.evergreen-ils.org/doku.php?id=documentation:tutorials:json_query - also the query is in active use in 2.12+: http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/Application/Acq/Order.pm;h=3eae8602e31730305f346472d0dbf63e5ebbb456;hb=refs/heads/rel_2_12#l1194 |
08:50 |
|
bos20k joined #evergreen |
08:50 |
csharp |
when I remove the space or replace it with _ just to get it working, the resulting SQL is wrong (not just because "notin/not_in" is invalid SQL) |
08:52 |
csharp |
relevant: bug 1257915 - which I tested and signed off on on a stock master server, but it's not working on our test server |
08:52 |
pinesol_green |
Launchpad bug 1257915 in Evergreen 2.11 "Acq: purchase orders stay "on-order" with some lineitems received and the rest canceled" [Medium,Fix released] https://launchpad.net/bugs/1257915 |
08:53 |
csharp |
test server has real PINES data |
08:53 |
tsbere |
csharp: Huh. Ok, maybe my memory is lacking. Or I missed some other change that went through. |
08:53 |
csharp |
s'ok |
08:54 |
Dyrcona |
csharp: Have you converted it to Perl and tried it that way? |
08:57 |
* tsbere |
ran a quick test on his (not updated recently) dev machine and it worked fine if he single-quoted the entire json query when passing it to test_json_query |
08:58 |
tsbere |
csharp: Is your passing being split into multiple arguments on the space? |
08:59 |
csharp |
Dyrcona: the query is converted from perl - I don't know how one tests it from perl :-/ |
08:59 |
csharp |
tsbere: yeah, it appears to be that |
09:00 |
|
collum joined #evergreen |
09:00 |
Dyrcona |
csharp: CStore has methods to run JSON queries. I suspect what you're using converts the JSON to Perl and passes it to one of those. |
09:00 |
csharp |
tsbere: when I add single quotes around the whole query, I get "Unexpected character" |
09:01 |
tsbere |
csharp: I now wonder what you are doing to call test_json_query |
09:02 |
csharp |
test_json_query -v `cat blah.json | sed ':a;N;$!ba;s/\n/ /g'` |
09:02 |
csharp |
oh actually I did it without the sed |
09:03 |
csharp |
test_json_query -v `cat blah.json` |
09:03 |
Dyrcona |
csharp: here's another tool you can use to test it: https://github.com/Dyrcona/evergreen_utilities/blob/master/perl/json_query.pl |
09:03 |
Dyrcona |
Put your json in a file and run it with that. See what happens. :) |
09:04 |
tsbere |
csharp: This should fix it for you: test_json_query -v "`cat blah.json`" |
09:05 |
csharp |
tsbere: that did it - thanks! |
09:05 |
csharp |
wow - around the block for an easy fix - typical day |
09:06 |
mmorgan |
And it's only 9 o'clock! |
09:06 |
tsbere |
csharp: My original attempt I just did test_json_query '<json>', didn't know you had it in a file. |
09:09 |
Dyrcona |
it just works with my script, but feel free to ignore me. :) |
09:10 |
Dyrcona |
And my script serves a slightly different purpose. |
09:10 |
csharp |
Dyrcona: thanks - nice to know that there are alternatives ;-) |
09:11 |
Dyrcona |
It's not meant to test json queries, but to run them and produce CSV output. |
09:12 |
Dyrcona |
I don't use it much, but there it is. |
09:12 |
csharp |
Dyrcona: I just ran it - as expected in this case, it returned no results |
09:12 |
Dyrcona |
Yeap, and no errors. If there was an error in the json, it would have been reported. |
09:13 |
Dyrcona |
I ran it on a test database. |
09:14 |
Dyrcona |
I think I originally wrote that to debug some json queries that weren't giving the results I expected, but that was 5 years ago, so... |
09:15 |
|
terran joined #evergreen |
09:15 |
Dyrcona |
Or more. I think I put 2012 on there when I put it in a public repo. |
09:21 |
|
yboston joined #evergreen |
09:21 |
Dyrcona |
Hmm... It might be handy to have a tool to convert json queries to the Perl representation so you can paste them into the code. |
09:41 |
|
jvwoolf joined #evergreen |
10:09 |
|
mdriscoll joined #evergreen |
10:27 |
bshum |
I think we're going to need to come up with some better ways of implementing these javascript in tpac and strings for i18n |
10:27 |
bshum |
https://bugs.launchpad.net/evergreen/+bug/1711128 that was just filed shows me another spot in the code we don't seem to be doing i18n for |
10:27 |
pinesol_green |
Launchpad bug 1711128 in Evergreen "OverDrive API display of Always Available Titles" [Undecided,New] |
10:28 |
|
lbarry joined #evergreen |
10:32 |
* bshum |
idly wonders if jeffdavis workaround for l_strings would help us there with all those availability status messages too |
10:45 |
dbs |
bshum: one or more TT2 files that simply include strings of interest for use in JS? It's not a terrible route. Still have to avoid constructing output from fragments but that's always a battle :) |
10:50 |
Dyrcona |
dbs: Will that work for strings whose values change during runtime? By that I mean a string that has a part dependent on the value of a select box? |
10:52 |
dbs |
Dyrcona: oh probably not. but then you're rapidly heading down framework road. |
10:53 |
Dyrcona |
dbs: That was what I thought.... |
10:54 |
Dyrcona |
Looking at some stackoverflow discussion, we may be able to add a format string to javascript that tt2 doesn't know about, but then we have the issue of plurals in a language like Polish..... |
10:54 |
Dyrcona |
Polish has multiple plural forms depending on number.... |
10:55 |
jonadab |
A fair number of languages have separate dual number. |
10:55 |
jonadab |
Hebrew does, for example. |
10:56 |
dbs |
multiple genders too |
10:57 |
Dyrcona |
Yeah. |
10:57 |
dbs |
it's not something we want to roll ourselves |
10:57 |
Dyrcona |
No, it isn't.... |
10:58 |
Dyrcona |
There's this: https://www.i18next.com/ |
11:04 |
Dyrcona |
It looks good from the quick perusal of the docs, but I can't find a license. |
11:06 |
Dyrcona |
MIT license. |
11:11 |
berick |
csharp++ dbs++ |
11:41 |
|
jihpringle joined #evergreen |
12:18 |
|
khuckins_ joined #evergreen |
13:03 |
jeffdavis |
Those ebook availability messages ("1 of 5 available" etc) aren't properly translatable via the l_strings workaround AFAIK, since they contain values that aren't available to TT2. |
13:06 |
jeffdavis |
Rewording to something like "Availability: 1/5" is possible, but perhaps cryptic for end users? |
13:08 |
Dyrcona |
Not only cryptic, but also like not translatable either. |
13:08 |
Dyrcona |
It's recommended to use full sentences for i18n. |
13:08 |
* Dyrcona |
has done some research. ;) |
13:09 |
Dyrcona |
It stinks that JavaScript was not designed with this in mind. |
13:10 |
Dyrcona |
@blame Netscape |
13:10 |
pinesol_green |
Dyrcona: Netscape is why we can never have nice things! |
13:10 |
jeffdavis |
@karma javascript |
13:10 |
pinesol_green |
jeffdavis: javascript has neutral karma. |
13:12 |
Dyrcona |
But, I guess it isn't JavaScript's fault. I haven't seen a language, yet, with built-in support for different languages. |
13:12 |
jeffdavis |
I'm trying to remember if we display raw text from OverDrive responses anywhere, because that would be English-only. |
13:13 |
Dyrcona |
Well, what's the likelihood...Oh, never mind... Canada. :) |
13:17 |
* dbs |
recently created a JS widget that still needs i18n - https://coffeecode.net/enriching-catalogue-pages-in-evergreen-with-wikidata.html - might need to feed the requested locale in via a GET param |
13:17 |
dbs |
it's like recreating JSPAC all over again (augh) |
13:18 |
Dyrcona |
AngularPAC! |
13:20 |
dbs |
Well that would be better than AdHocPAC |
13:35 |
* miker |
will lobby to bring back BibTemplate as an angular directive :) |
13:35 |
csharp |
@band add Angular Directive |
13:35 |
pinesol_green |
csharp: Band 'Angular Directive' added to list |
13:36 |
Dyrcona |
@praise [band] |
13:36 |
* pinesol_green |
You don't want to get mixed up with someone like Ejabberd Confit. Ejabberd Confit is a loner, Dottie. A rebel. |
13:37 |
Bmagic |
Is there a document somewhere that shows how to tell a brick's utilization of each of the OpenSRF applications? Does each process equate to the number if "max_children" ? |
13:37 |
Bmagic |
ps aux|grep Drone|awk '{print $13}' | sort | uniq -c |
13:39 |
Dyrcona |
Bmagic: I don't know of a document, but I had a script that would from cron and update a postgresql table with the timestamp and number of drones running. I can probably share that. |
13:40 |
Bmagic |
oh, that's a good idea |
13:41 |
Bmagic |
so, is it the process count? |
13:41 |
Bmagic |
process count per drone = children? |
13:42 |
berick |
Bmagic: yes one 'OpenSRF Drone' is the same as a child |
13:42 |
berick |
WRT max_children |
13:42 |
Bmagic |
ok, then that ps command looks right to you? |
13:43 |
Dyrcona |
Not sure I'd use awk, but yeah. |
13:44 |
berick |
yeah. and you can see similar stuff using osrf_control -l --diagnostic |
13:44 |
Dyrcona |
yeah, berick beat me to it. |
13:44 |
Dyrcona |
pgrep -c is also handy. |
13:44 |
Bmagic |
I am mildly concerned that our production bricks CPU usage is only .8 out of 4 cpu's. I was thinking maybe the bottleneck is my max_children config |
13:44 |
Dyrcona |
Bmagic: Load or cpu usage? |
13:45 |
Dyrcona |
There's a difference. |
13:45 |
berick |
hm, should teach diagnostic to print max_children too |
13:45 |
Bmagic |
sorry, load |
13:45 |
Dyrcona |
Load is an average of how many processes are waiting to run. Lower numbers better. |
13:46 |
Dyrcona |
You can get cpu usage from top. |
13:46 |
Dyrcona |
And, there's an option to toggle showing all cpus. |
13:46 |
Bmagic |
I am talking about the report I am reading from top |
13:46 |
Bmagic |
first line, the 5,10,15 minute interval "load average" |
13:47 |
Bmagic |
you mean to tell me that I have been misunderstanding this report all these years? |
13:47 |
Dyrcona |
Maybe not. I thought you might have been looking at uptime. |
13:48 |
Dyrcona |
Load average is the load. CPU% is cpu usage, so yeah. |
13:48 |
csharp |
berick: printing max_children would be super helpful - I was planning to add to my osrf_control --diagnostic nagios check to pull in the max_children from opensrf.xml so we can alert at percentage thresholds |
13:48 |
Dyrcona |
Load average is what I said earlier: number of processes waiting to run. |
13:48 |
csharp |
but if --diagnostic does it for me that's even better :-) |
13:49 |
Bmagic |
.8 means .8 of one CPU being used right? Out of a maximum of 4.0 ? |
13:49 |
Dyrcona |
And, I have 2 pidgin zombies.... |
13:49 |
Dyrcona |
Bmagic: On load average, no. |
13:49 |
Dyrcona |
It means over the last five minutes 0.8 processes have been waiting per minute to run. |
13:50 |
jeff |
this is useful current reading for understanding load averages on Linux: http://www.brendangregg.com/blog/2017-08-08/linux-load-averages.html |
13:50 |
* csharp |
would read 0.8 as "this server is happy" |
13:50 |
berick |
csharp: good to know, re max_children |
13:50 |
Bmagic |
jeff++ |
13:51 |
csharp |
jeff++ # haven't seen that one |
13:51 |
Dyrcona |
Bmagic: hit 1 in top. |
13:52 |
Bmagic |
k |
13:52 |
csharp |
you *can* configure *top to factor in the number of CPUs to give you a more realistic reading of load averages too |
13:53 |
Bmagic |
I am trying to utilize my hardware the best I can, and when I see .8 - I fee like that machine could use more work to do. You're saying that's not correct? |
13:53 |
csharp |
so a load average of 5.06 on a DB with 64 CPUs is probably still not anything to worry about |
13:54 |
Dyrcona |
In my experience you don't really notice problems until about 4X the number of cores. |
13:54 |
Dyrcona |
But, YMMV. |
13:54 |
Dyrcona |
But, basically what I said with some modifications. :) |
13:55 |
Dyrcona |
The CPU% area below that shows the % activity on the CPU(s), and if you hit 1, it should expand to show all of the CPUs separately. |
13:55 |
Bmagic |
either our libraries are not hitting our servers hard, or they are having to "wait" for some configuration bottleneck that I could potientially open up and use more of the CPU, at least that is where I am headed |
13:56 |
Dyrcona |
Bmagic: Are people complaining about performance? |
13:56 |
Bmagic |
yeah, me |
13:56 |
Dyrcona |
Why do you want to use more cpu if you don't have to? |
13:57 |
Dyrcona |
Low load averages are good. Low CPU utilization is also good if you don't need it. |
13:57 |
Bmagic |
I would like to see the xul staff client "home" screen instantly after hitting enter on my login box |
13:57 |
Dyrcona |
If you're paying per CPU, then reduce the number of CPUs. |
13:57 |
Dyrcona |
That will never happen because network. |
13:59 |
Bmagic |
network, of course, but shouldn't these bricks be pushing everything they have to offer? I guess the true test would be to remove half of the bricks and see if the CPU load doubles on the other half |
14:00 |
Dyrcona |
The idea isn't to max out the utilization of the hardware. The idea is to offer your customers a reasonable level of performance at a reasonable price. |
14:00 |
Dyrcona |
You may have more bricks than you need. |
14:00 |
Dyrcona |
But honestly, when even one of our bricks is maxed out, we get phone calls, and not pleasant ones, either. |
14:01 |
Bmagic |
that's what I am thinking... but it's hard to believe that 4 bricks with 16GBmemory/4CPU's can handle the number of staff / patrons |
14:01 |
Dyrcona |
Why is that hard to believe? |
14:01 |
Bmagic |
we used to have 8 |
14:01 |
csharp |
Bmagic: how many library systems is it? |
14:01 |
Dyrcona |
I think we're larger than mobius and we've been doing fine with 4 for several months. |
14:02 |
csharp |
We're running 54 systems of varying size on 6 bricks |
14:02 |
Dyrcona |
Well, since May. |
14:02 |
csharp |
about to add our 55th in Feb. |
14:02 |
Dyrcona |
We're handling 130+ on 4 at the moment. We normally have 5. |
14:03 |
Bmagic |
select count(*) from actor.org_unit where opac_visible = 120 |
14:03 |
Bmagic |
the answer to the query on the left of the equals sign is 120 |
14:03 |
csharp |
oh, well we have 338 with that query |
14:04 |
Bmagic |
alrighty then, 4 is too many then |
14:04 |
csharp |
select count(*) from actor.org_unit where opac_visible and parent_ou = 1; |
14:04 |
Dyrcona |
The same query gives me 196. |
14:04 |
Bmagic |
csharp: 32 |
14:04 |
csharp |
if you're heirarchically similar (Consortium/System/Branch) |
14:04 |
Bmagic |
yeah, 32 "systems" |
14:05 |
Bmagic |
I like to keep my systems at a power of 2 |
14:05 |
csharp |
we were posting this sort of thing on a wiki or something similar several years ago |
14:05 |
Dyrcona |
My hierarchy is different, so csharp's query won't work for me. |
14:05 |
csharp |
@quote add < Bmagic> I like to keep my systems at a power of 2 |
14:05 |
pinesol_green |
csharp: The operation succeeded. Quote #172 added. |
14:05 |
Bmagic |
lol |
14:05 |
berick |
Bmagic: funny, i prefer odd numbers |
14:06 |
Dyrcona |
Bmagic: 4 may not be enough. It depends on the hardware and how the vms/docker whatsits are configured, too. |
14:06 |
* csharp |
is probably remembering the RSCEL days |
14:07 |
Dyrcona |
I like even numbers, preferably powers of 2, (comes from working with computers since I was 11) or multiples of 5 if it must be an odd number, but I don't get uptight about it. :) |
14:07 |
bshum |
Just remember the old grid style display in JSPAC |
14:07 |
Bmagic |
Dyrcona: yeah, I am trying to find the answer.... and it's not easy. There are at least 3 configuration points, ejabberd, opensrf, apache - the combination of which should yeild CPU load |
14:07 |
bshum |
That's why we didn't have that many layers of org unit hierarchy |
14:07 |
bshum |
For copy info |
14:08 |
Bmagic |
afk |
14:09 |
csharp |
hmm - had to use the wayback machine to find any trace of rscel: https://web.archive.org/web/20120415202523/http://rscel.org:80/ |
14:10 |
Dyrcona |
rascal... |
14:13 |
* csharp |
considers bringing guitar or uke to hackaway |
14:13 |
csharp |
gotta start putting these awesome @band names to good use |
14:21 |
berick |
csharp: bug 1711194 |
14:21 |
pinesol_green |
Launchpad bug 1711194 in OpenSRF "osrf_control --diagnostic should report max-children values" [Wishlist,New] https://launchpad.net/bugs/1711194 |
14:26 |
csharp |
berick: oh - awesome! will test directly |
14:27 |
berick |
fyi requires a re-configure |
14:27 |
csharp |
berick: will do |
14:30 |
|
lasse_ joined #evergreen |
14:31 |
lasse_ |
Hi - I'm looking for a library system for a private school - We don't have much money and I am considering opensource - is evergreen translated ? |
14:31 |
|
krvmga joined #evergreen |
14:32 |
csharp |
lasse_: we have several languages translated - which locale? |
14:33 |
csharp |
lasse_: https://translations.launchpad.net/evergreen gives you a high-level overview of translation progress |
14:33 |
lasse_ |
Danish - I can't seem to find the languages on the website |
14:33 |
csharp |
lasse_: I don't think we have Danish yet |
14:34 |
* csharp |
nudges bshum so he sees this conversation |
14:35 |
lasse_ |
doesn't look like it. I'd have to check it out before I commit to translating it |
14:35 |
lasse_ |
I'd love to help - just want to make sure its the right program for us |
14:35 |
csharp |
lasse_: if you have facility with Linux (or access to people who do), it might be a good fit |
14:35 |
lasse_ |
so windows eco system is a no go ? |
14:36 |
bshum |
No I don't see Danish among the currently listed translations either. |
14:36 |
csharp |
lasse_: yeah... no windows server at this point |
14:36 |
csharp |
but the client software is multi-platform and we're transitioning to browser based with the next release |
14:37 |
lasse_ |
ah if it's just a matter of running the server on linux it's no problem - I am sys admin and could just set up a linux server |
14:37 |
csharp |
lasse_: yep, most of our clients are running on windows boxes |
14:38 |
csharp |
lasse_: if you decide to install a test box, please ask here for help - we're mostly on the east coast of the USA and available 8 a.m. to mostly 6 or 7 p.m. Eastern Time |
14:38 |
lasse_ |
I'm thinking of using it for check in and out of our library (currently students just go in and pick books of the shelf - no control what soever) - same goes for study books - only the teacher is responsible for knowing who has which book |
14:38 |
csharp |
some of us are night owls and early risers though :-) |
14:39 |
csharp |
lasse_: koha would be another open source option too, in case you're not aware |
14:39 |
csharp |
https://koha-community.org/ |
14:40 |
bshum |
Might be worth looking at Koha too given that they appear to have Danish on their translations page with a pretty high percentage |
14:40 |
lasse_ |
I guess it only matters as to which is more easy on the user and danish locale on the client would be AWESOME |
14:40 |
bshum |
86% sounds pretty good to me. |
14:40 |
lasse_ |
sure does |
14:41 |
lasse_ |
but again - if evergreen is the better match for us I'd gladly translate |
14:42 |
bshum |
I guess some other considerations for international users would be what format their records come in (since Evergreen is MARC centric) |
14:42 |
bshum |
If they have records, I guess, heh |
14:43 |
lasse_ |
not sure I follow - records as in... ? |
14:43 |
bshum |
Just thinking bibliographic records. In most library systems, those records are used to provide data about the items in your collection |
14:44 |
bshum |
There's various sources/formats, etc. that go into defining what those records look like |
14:44 |
lasse_ |
ahh like the barcodes on the books ? |
14:44 |
lasse_ |
not a librarian as you've might have guessed :) |
14:44 |
csharp |
lasse_: mostly metadata |
14:44 |
bshum |
lasse_: It's okay, not all of us are librarians either :) |
14:45 |
* csharp |
is a librarian/techie hybrid - we are very rare in the wild |
14:45 |
lasse_ |
metadata as in a resume, author etc ? |
14:45 |
csharp |
lasse_: title/author/publication info |
14:46 |
lasse_ |
charp - you are a rare breed my friend :) *thumbs up* |
14:46 |
csharp |
heh |
14:46 |
lasse_ |
csharp* |
14:47 |
lasse_ |
you say there are different ways of records - so a danish book might use a different record than an american one ? |
14:48 |
Dyrcona |
lasse_: The general format is the same, but there are different standards per country. |
14:50 |
lasse_ |
where would I look up information about which we use in Denmark and which evergreen supports ? |
14:51 |
csharp |
lasse_: probably one of these: http://www.ala.org/alcts/resources/guides/serstdsbib/cataloging - probably worth contacting a librarian local to you to confirm |
14:52 |
csharp |
finding cataloger/techie hybrids is even more rare |
14:52 |
csharp |
which I find odd since cataloging can get very technical |
14:53 |
lasse_ |
thanks csharp |
14:55 |
Dyrcona |
lasse_: Evergreen uses MARC21 with a heavy emphasis on Library of Congress standards, but it is used successfully in other nations, such Czech Republic. |
14:55 |
csharp |
berick: works great! I'll create a signoff branch so it can get into the 3.0 mix :-) |
14:55 |
berick |
csharp: cool |
14:56 |
Dyrcona |
lasse_: You might want to look at Koha, too. IIRC, they have support for different MARC formats. |
14:56 |
lasse_ |
Dyrcona: thanks - I'm already looking :) |
14:57 |
rhamby |
I once saw a presentation about a map library in Denmark using a MARC variant called danMARK but I don't know how widely it's used there |
14:57 |
lasse_ |
rhamby: that would be a little on the nose methinks :) |
14:57 |
Dyrcona |
danMARC? :) |
14:57 |
rhamby |
lasse_: I didn't name it :) |
14:58 |
lasse_ |
surely that could be one of those lame danish jokes... |
14:58 |
lasse_ |
we are a wierd collection of people |
14:58 |
lasse_ |
weird* |
14:58 |
rhamby |
Dyrcona: they spelled it danMARK on the slides, I recall because I thought it was odd but assume there was a language reason for the variation. |
14:59 |
* csharp |
used to work with a Danish woman who was quite a character :-) |
14:59 |
Dyrcona |
Well, it's how they spell Denmark, isn't it? |
15:00 |
lasse_ |
it's Danmark - yeah |
15:00 |
rhamby |
Nationalistic pride, yeah I thought that was a possibility as well, maybe the most likely. |
15:00 |
Dyrcona |
Oops. Now I have the first lines of Beowulf running through my head. |
15:01 |
lasse_ |
There is something rotten in the state of Denmark |
15:01 |
lasse_ |
oh wait that's not it |
15:01 |
lasse_ |
that's hamlet |
15:02 |
Dyrcona |
Whaet! Wir Gardanne.... |
15:02 |
Dyrcona |
Listen! We Spear-Danes... |
15:03 |
lasse_ |
funny because that's not danish |
15:03 |
Dyrcona |
Old English |
15:04 |
lasse_ |
ah |
15:04 |
lasse_ |
again - weird it's written in old english when it's about danes.. |
15:04 |
Dyrcona |
For anyone who uses it, I just changed my git-quickpick script: https://gist.github.com/Dyrcona/4629200 |
15:05 |
Dyrcona |
I like it with git cherry better than git log blah, blah, blah. |
15:07 |
Dyrcona |
I should change my email address in the comments.... |
15:07 |
Bmagic |
lasse_: which library in Denmark? I have visited Denmark. I have friends living there |
15:08 |
Bmagic |
I've spent a great deal of time in Samsø |
15:09 |
lasse_ |
well it's not a public library - I work on a small private school in Djursland - a bit north of Samsø |
15:09 |
Bmagic |
lasse_: awesome! |
15:10 |
lasse_ |
its on "the nose" |
15:10 |
berick |
csharp: heads up.. force pushing a fix to right-justify the percents |
15:11 |
lasse_ |
Bmagic: what were you doing on Samsø ? I was just there 3 weeks ago on vacation |
15:11 |
Bmagic |
lasse_: I spent time in Aarhus also |
15:11 |
lasse_ |
Aarhus is a lovely city :) |
15:11 |
Bmagic |
My friend Anders's family lives in Samsø |
15:11 |
lasse_ |
personally I like the countryside more thogh |
15:12 |
lasse_ |
Bmagic: I know we are a small country - I don't know every dane though :) |
15:14 |
* dbs |
tries to figure out why z39.50 requests for a specific target are timing out in OpenSRF, but work fine using yaz-client |
15:14 |
dbs |
(other targets work just fine in OpenSRF) |
15:15 |
dbs |
happens in both XUL and web staff client so must be something in the Perl and/or associated definitions |
15:20 |
dbs |
oh and for extra fun, maybe only happens when there are records with unicode? |
15:20 |
|
Jillianne joined #evergreen |
15:21 |
dbs |
oh hey extra fun, found "Text of error message received from Jabber: XML stanza is too big" in our EG 2.12 / OpenSRF 2.5.0 instance |
15:22 |
Dyrcona |
:/ |
15:22 |
bshum |
Well that's good and bad? |
15:22 |
bshum |
Good that you found it, bad that it's happening |
15:22 |
Dyrcona |
dbs: I'd say bug it. That's not supposed to happen. |
15:22 |
dbs |
I can jump on bug 1709710 |
15:22 |
pinesol_green |
Launchpad bug 1709710 in Evergreen "OpenSRF Installation Instructions for ejabberd" [Undecided,Incomplete] https://launchpad.net/bugs/1709710 - Assigned to Adam Bowling (abowling) |
15:22 |
bshum |
Yep, that's the one |
15:22 |
Dyrcona |
yeah. |
15:23 |
Dyrcona |
I haven't seen it, but I've not used 2.5 in production, yet. |
15:23 |
Dyrcona |
Just in testing/training. |
15:23 |
|
remingtron joined #evergreen |
15:23 |
Dyrcona |
You are using it with EG 2.12, right? |
15:24 |
dbs |
yep |
15:29 |
Dyrcona |
OK. |
15:32 |
Bmagic |
lasse_: Specifically Nordby |
15:33 |
dbs |
mmm. I think that Z39.50 error might be specifically when retrieving records with UTF8 chars outside of ASCII. Probably more encode()/decode_utf8() madness. |
15:33 |
dbs |
(one target was for a french library for which most records would contain accents) |
15:33 |
Dyrcona |
oh yeah. Even before 2.12 there have been issues with Z39.50 and UTF-8. |
15:34 |
Dyrcona |
Theoretically, it should work, but.... |
15:34 |
dbs |
but now getting timeouts in LoC and other targets if I search for something that I know will have accented chars |
15:34 |
dbs |
(might happen for MARC8-encoded records that have > ASCII chars too, will try to narrow this down) |
15:34 |
dbs |
*SIGH* |
15:34 |
Dyrcona |
but, the stanza too large is troubling. |
15:35 |
|
jvwoolf joined #evergreen |
15:49 |
Dyrcona |
dbs: that "stanza is too big" appears in OpenSRF/OpenILS logs, right? I'm going to check training and one of my dev vms. |
15:51 |
dbs |
Dyrcona: yeah we have ours going to syslog, so on a systemd system 'journalctl -n 100000 | grep "XML stanza"' works |
15:52 |
dbs |
Doesn't show up often, only once in our last 100000 lines of logs |
15:52 |
Dyrcona |
All right. I'm using /openils/var/log on the training and test vms. |
15:52 |
Dyrcona |
I have several gigs of logs going back a couple of weeks. |
15:52 |
Dyrcona |
I hammered SIP2 recently on the test vm, that might turn something up. |
15:54 |
Dyrcona |
Nope. Not finding anything, but my requests may not be that big. |
15:57 |
dbs |
"Bront©± family." eh? hmm |
15:58 |
* Dyrcona |
guesses double encoding or similar. |
15:58 |
Dyrcona |
Funky stuff goes on with Z39.50... |
15:59 |
Dyrcona |
I wanted to really look at it, but never made the time. |
15:59 |
dbs |
yeah, this was an originally MARC8-encoded record |
15:59 |
dbs |
yaz-client shows it just fine so we're messing something up |
15:59 |
dbs |
back on stanza too big, the one case I have seems to be related to incoming SRU queries |
16:01 |
Dyrcona |
Well, I can try some of those. I'm sure we've not looked at that on training or my test vm. |
16:01 |
Dyrcona |
Maybe tomorrow. |
16:04 |
|
collum_ joined #evergreen |
16:18 |
berick |
@band add CHACHA20 |
16:18 |
pinesol_green |
berick: Band 'CHACHA20' added to list |
16:18 |
berick |
from a list of ssl ciphers |
17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
17:02 |
|
mmorgan left #evergreen |
17:18 |
|
jvwoolf left #evergreen |
18:33 |
csharp |
dbs: we have reports of unicode not working on our z39.50-imported records - 2.12.2-ish/OpenSRF 2.5.0 - haven't dug yet but symptoms sound similar |
18:34 |
csharp |
on Ubuntu 16.04 |
18:38 |
csharp |
also got reports of search/other things not working on our test server a couple of weeks ago - found that OpenSRF was offline - I'll look into the logs to see what was going on - I suspect the same issue as bug 1709710 |
18:38 |
pinesol_green |
Launchpad bug 1709710 in Evergreen "OpenSRF Installation Instructions for ejabberd" [Undecided,Incomplete] https://launchpad.net/bugs/1709710 - Assigned to Adam Bowling (abowling) |
18:40 |
csharp |
lots of "4 In-flight request(s) took longer than 600 seconds to complete. Treating requ |
18:40 |
csharp |
est as dead and moving on." |
19:03 |
|
Christineb joined #evergreen |