| 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 |
| 05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:12 |
|
mrpeters left #evergreen |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:16 |
|
rjackson_isl joined #evergreen |
| 10:34 |
sam_l |
Staff client, and thank you! |
| 10:36 |
sam_l |
rhamby++ |
| 10:37 |
sam_l |
One of our branches just got new computers, and we wanted to give correct instructions to IT before they went to set them up. |
| 10:42 |
csharp |
sam_l: from our scant testing, Windows 10 works fine |
| 10:44 |
Dyrcona |
It works fine on our Windows 10 thin clients. |
| 10:45 |
csharp |
I would actually predict better performance based on everything I know about Windows 10 (which isn't a whole lot) |
| 10:49 |
sam_l |
Thanks. I passed the info on. |
| 14:52 |
kmlussier |
phasefx: Was Eva planning to attend too? I see her name is on the agenda. |
| 14:53 |
phasefx |
kmlussier: I hadn't heard from her |
| 14:54 |
Nawjo |
Kmlussier, Great! |
| 14:54 |
bshum |
Like are the records primarily in english, but they have translated arabic strings for things like title, etc. |
| 14:54 |
bshum |
I've seen that before for other language records like chinese, etc. |
| 14:55 |
bshum |
I'd love to get some sample records to append to Concerto for future testing, actually.... hmm.... |
| 14:55 |
Dyrcona |
Georgian records are quite pretty.... |
| 14:55 |
Dyrcona |
I can't read it, but the script is nice. |
| 14:56 |
kmlussier |
OK, poll for scheduling the meeting next week is at http://doodle.com/poll/esxgzfum2cwkbv7v |
| 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 |
| 00:13 |
chatter |
allah is doing |
| 00:13 |
chatter |
sun is not doing allah is doing |
| 00:13 |
chatter |
to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger |
| 05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:08 |
|
NawJo joined #evergreen |
| 07:17 |
|
Callender joined #evergreen |
| 07:19 |
|
agoben joined #evergreen |
| 12:38 |
berick |
JBoyer: upgrade went OK? |
| 12:40 |
JBoyer |
Splendidly. From a 2.9 to 2.11 db in less than 10 minutes. (not counting the pingest, of course) Would have been even better had I not just overlaid 2M+ records and caused so much table bloat that I almost ran the volume out of space last night. :/ |
| 12:41 |
JBoyer |
Still working on mitigating that but things aren't dire anymore. |
| 12:41 |
csharp |
JBoyer++ |
| 12:42 |
csharp |
JBoyer: 10 minutes!? my test runs have taken 2-3 hours |
| 12:42 |
csharp |
2.9.1 - 2.11.1 |
| 12:42 |
JBoyer |
Had we it to do over again, we probably wouldn't have made a lot of noise about the email receipt feature because no one realized it didn't work with the XUL client. Might have to see how hard it is to wedge in there later. :/ |
| 12:43 |
csharp |
(we're upgrading over MLK weekend) |
| 12:44 |
JBoyer |
I had several thousand lines worth already in our db because I wrote them. ;) (Also, the reingest took bloody ages but I don't generally count that since you can spin services back up while that's running.) |
| 12:45 |
csharp |
reingest (pingest.pl with 16 children, batches of 10K) took about 36 hours in my test run |
| 12:47 |
JBoyer |
Oh, yes, and as far as our highly misaligned ccvm and ccaed tables, I cloned them from a fresh stock db and replaced everything with an id < 10000 pre-reingest. Now all of our translations line up and we won't have to special case every single new locale or es-ES update that comes along. |
| 12:49 |
JBoyer |
csharp, if there's enough time before we "open" again I'll let pingest burn through 35 out of 40 cores. It still only hits a load of around 20 but I don't want to risk it getting too much closer to 40 in case things start taking more oomph than expected.. |
| 12:52 |
csharp |
hmm - we have 64 cores, so maybe I should up the child count |
| 14:11 |
jeff |
well, the good news there might be that moving these two affected workstations to a newer client might help. i think they're still running a 2.7 build that works by virtue of a server-side symlink. |
| 14:11 |
jeff |
(or it's not really the OS after all) |
| 14:11 |
berick |
fwiw i'm not using a community build, i'm using a custom script that does pretty much the same thing |
| 14:11 |
JBoyer |
I didn't see that either with my (admittedly limited) testing on my mac over the weekend. I also may not be packaging the latest "supported" version of XULRunner in my package, which one was included in the client that had the disappearing menubar? |
| 14:14 |
jeff |
according to Contents/Frameworks/XUL.framework/Versions in each app bundle, the 2.7 and 2.10 apps i have handy are both 14.0.1 |
| 14:18 |
JBoyer |
I can't really check until almost 5 or 6, but I'm curious if a different version would have an effect on the transparent background problem even if it turns out this issue is something local. |
| 14:35 |
|
phasefx_ joined #evergreen |
| 16:51 |
Dyrcona |
You're probably correct. |
| 16:51 |
Dyrcona |
I'll have to look at it some more tomorrow. |
| 16:51 |
Dyrcona |
I'm not having any issues, just comparing configurations across twenty some odd servers. :) |
| 17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:07 |
|
mmorgan2 left #evergreen |
| 17:15 |
|
brahmina joined #evergreen |
| 17:29 |
|
rlefaive joined #evergreen |
| 00:08 |
|
Christineb joined #evergreen |
| 05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:20 |
|
agoben joined #evergreen |
| 08:48 |
|
mmorgan joined #evergreen |
| 08:54 |
|
Dyrcona joined #evergreen |
| 09:12 |
|
Bmagic joined #evergreen |
| 09:29 |
|
jvwoolf joined #evergreen |
| 09:38 |
jvwoolf |
Hi everybody! I'm trying to add a new page to our OPAC. It's working in test, but I have to sign in to view it. I've scoured the docs, but I can't figure out how to make it public. Any tips? |
| 09:40 |
|
collum joined #evergreen |
| 09:46 |
Dyrcona |
jvwoolf: I think that's largely a function of where you put the file. |
| 09:46 |
tsbere |
jvwoolf: You will need to edit the TPAC perl code to add your page before the auth check |
| 10:57 |
jvwoolf |
OK, that's where I edited it. |
| 10:58 |
Dyrcona |
And, that's what I thought....You'll want to make a copy of that file and make a diff of the changes or you'll lose them at the next upgrade. |
| 10:58 |
Dyrcona |
If you run bricks, you'll need to update it on every brick, too. |
| 10:59 |
jvwoolf |
Ahh. Gotcha. |
| 10:59 |
jvwoolf |
I'm only doing this in test at the moment. |
| 10:59 |
Dyrcona |
OK, but for production, I'd recommend doing as tsbere suggests and making the change in the source and then copying the final version into place. |
| 11:00 |
Dyrcona |
Git really helps with managing little changes like this, too. |
| 11:02 |
jvwoolf |
I've got it now. Thank you. |
| 14:35 |
miker |
I'll see if I can find a minute to look a that later today |
| 14:48 |
miker |
_bott_: I think http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/aclg-cdbi-for-badges will help you... |
| 14:52 |
_bott_ |
ah, makes sense. I'll give it a whirl. |
| 16:00 |
mmorgan |
I'm looking at the 2.11 SIP feature that treats location as workstation. I'm not getting it to work on our test system. |
| 16:01 |
mmorgan |
I can make connections and perform transactions, but the location isn't being recognized as the workstation. |
| 16:01 |
mmorgan |
Any ideas? |
| 16:03 |
mmorgan |
Also tried adding the location_code to the config file for the staff user and that's not working either. |
| 16:05 |
tsbere |
mmorgan: Just to be sure, did you make sure that both Evergreen and SIPServer are up to date? |
| 16:09 |
mmorgan |
Yes, I checked Sip.pm and SIPServer.pm, both are up to date. |
| 16:11 |
tsbere |
and you either defined client_location_code as "true" for the institution block (passing in a valid workstation name in the login step) or location_code to a valid workstation name? |
| 16:40 |
mmorgan |
Hmm. Still no luck. Will need to revisit this tomorrow |
| 16:41 |
mmorgan |
tsbere++ |
| 16:41 |
mmorgan |
Thanks for the suggestions. |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:02 |
|
mmorgan left #evergreen |
| 17:16 |
|
jvwoolf left #evergreen |
| 17:33 |
|
bmills joined #evergreen |
| 05:02 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:41 |
|
rlefaive joined #evergreen |
| 06:45 |
|
agoben joined #evergreen |
| 07:15 |
|
rjackson_isl joined #evergreen |
| 14:03 |
* tsbere |
goes and looks, finding Dyrcona's description to be good enough |
| 14:04 |
tsbere |
I considered responding with something like "Well, that depends. I can describe how to make it work in any of the ways described". <_< |
| 14:05 |
Dyrcona |
Yes....I deleted a paragraph or two about seeing me at the conference for the gory details, and about waking up in the middle of the night screaming, "Cthulh Ftaghn!" if you try to get fancy. :) |
| 14:06 |
* tsbere |
came up with a few very convoluted setups for testing purposes at one point |
| 14:07 |
tsbere |
Including one "apply this rule to this user group, but not to the child group" that depended on circ fallthrough, the limits sets *not* having fallthrough, and a couple other things |
| 14:08 |
Dyrcona |
Yeah, I didn't want to go there, though I didn't think about the possibility of different limits for different user groups when writing the email. |
| 14:09 |
tsbere |
Basically I went for "what is the most convoluted thing I think this can do based on the documentation I just made for it?" and then tried to make it work. And did. ;) |
| 14:10 |
Dyrcona |
I mean, you could add a matchpoint so that one library's checkout limit applies while the other's circ rules apply, but why would you do that? |
| 14:10 |
Dyrcona |
Heh. |
| 14:10 |
Dyrcona |
Sometimes, it is good to test the limits. |
| 14:13 |
JBoyer |
tsbere, Dyrcona, Am I remembering correctly that one of you had a query that would look at config.circ_matrix_matchpoint and somehow display the weights that each row would result in? I'm - considering - something for the conference and that would be a big help. |
| 14:14 |
tsbere |
I think we have a couple of things that could do that |
| 14:14 |
Dyrcona |
JBoyer: It even produces an XLSX workbook! |
| 15:09 |
|
maryj joined #evergreen |
| 15:11 |
|
jihpringle joined #evergreen |
| 15:58 |
|
jvwoolf left #evergreen |
| 17:02 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:24 |
|
bmills joined #evergreen |
| 17:49 |
|
sarabee joined #evergreen |
| 18:54 |
|
dbwells joined #evergreen |
