10:11 |
csharp |
Fedora's great if you can just stick to the official repos for everything |
10:11 |
dbs |
Bmagic: okay, i'm sure you're following some of the bugs that I've run into because Fedora tends to be ahead of most distros. Encode.pm comes to mind |
10:11 |
csharp |
3rd-party repos tend to lag a bit in my experience |
10:11 |
Bmagic |
csharp: We are running it on debain now, and would like to test the waters more seriously on Fedora due to the Hyper-V issue I mentioned |
10:11 |
dbs |
Bmagic: https://bugs.launchpad.net/evergreen/+bug/1242999 for example |
10:12 |
pinesol_green |
Launchpad bug 1242999 in Evergreen "Encode.pm 2.54 breaks database functions (naco_normalize, maintain_control_numbers, others)" (affected: 1, heat: 10) [High,Confirmed] |
10:12 |
Dyrcona |
csharp: While official Debian and Ubuntu repos tend to lag a lot, and often have bugs that go unfixed. |
10:12 |
Bmagic |
dbs: Thanks for the heads up. I've installed this a few times on Fedora and I seem to remember hitting the Encode issue once before |
10:12 |
csharp |
Bmagic: have you benchmarked KVM in your testing? that might be a better supported alternative |
10:12 |
dbs |
Bmagic: that also motivates me to update the MARC::Record + friend packages that I maintain to be the most current versions :) |
10:12 |
* Dyrcona |
uses Ubuntu for those who don't know. |
10:13 |
csharp |
Dyrcona: yeah - I'd rather have lingering bugs than zero-day(-ish) bugs if I'm running something in production |
10:18 |
dbs |
The good thing about Fedora in production is that its support cycle almost syncs up with Evergreen's |
10:18 |
dbs |
So you could just deploy fresh every 12 months :) |
10:19 |
Dyrcona |
Ooh, now you're talking about being a couple of releases behind. :) |
10:19 |
csharp |
Bmagic: I got OpenSRF master installed on CentOS 6 recently |
10:19 |
csharp |
(in a bare-bones test instance, I should add) |
10:19 |
Bmagic |
csharp: OpenSRF and Evergreen? |
10:19 |
* Dyrcona |
is seriously considering do Linux from Scratch on a laptop if he can find the time. |
10:20 |
Bmagic |
Gentoo? |
10:27 |
csharp |
s/Debian/packaging for Debian/ |
10:28 |
* csharp |
has hopes of cleaning up our deb-builder utility for more general use |
10:28 |
csharp |
but that will be after our MLK weekend upgrade |
10:28 |
dbs |
Bmagic: well, there's a fix for that in the bug I posted |
10:29 |
dbs |
But because nobody else is hitting it yet, nobody else is motivated to really work on testing the final results (understandably) |
10:30 |
csharp |
fedora++ |
10:30 |
Bmagic |
We really would like this to work on fedora and it seem so close fedora++ |
10:32 |
csharp |
Bmagic++ #trailblazing |
14:35 |
|
dMiller___ joined #evergreen |
14:35 |
bshum |
Dyrcona: So I applied the other commit from bug 1243280 and so far no pointless warning errors anymore. |
14:35 |
pinesol_green |
Launchpad bug 1243280 in Evergreen 2.5 "'TypeError: obj.active_services is undefined' error when entering z39.50 MARC import UI" (affected: 2, heat: 10) [Medium,Confirmed] https://launchpad.net/bugs/1243280 |
14:35 |
bshum |
I'm testing the different parts of the client and so far, so good. |
14:35 |
bshum |
Might apply both commits |
14:36 |
Dyrcona |
OK. The other one just makes a useless console warning disappears. |
14:36 |
Dyrcona |
It checks if some field exists before using it. |
14:36 |
bshum |
Yeah, that's what I thought |
15:56 |
mrpeters |
ah, i remember this old friend |
15:56 |
mrpeters |
ERROR: cannot drop view metabib.full_rec because other objects depend on it |
15:56 |
mrpeters |
needs to be a drop cascade |
15:58 |
bshum |
mrpeters: What are the other dependent objects? MIght be non-stock stuff at play that wasn't shown during testing. |
15:58 |
bshum |
(there was lots of that and we noted a few with the reporter views) |
15:58 |
mrpeters |
hmm whats the easiest way to tell? |
15:59 |
mrpeters |
DETAIL: view reporter.steve_old_super_simple_record depends on view metabib.full_rec |
15:59 |
mrpeters |
heh, yeah thats probably not stock :P |
17:01 |
|
mmorgan left #evergreen |
17:03 |
|
pmurray_away joined #evergreen |
17:05 |
|
pmurray_away joined #evergreen |
17:09 |
dbs |
berick++ # thanks for giving the library sample data branch a test run |
17:10 |
|
pmurray left #evergreen |
17:10 |
* dbs |
scoots |
17:16 |
|
netadres joined #evergreen |
17:22 |
|
mceraso joined #evergreen |
17:22 |
|
bshum joined #evergreen |
11:21 |
|
paxed joined #evergreen |
11:21 |
|
tsbere joined #evergreen |
11:23 |
|
akilsdonk joined #evergreen |
11:24 |
pinesol_green |
[opensrf|Galen Charlton] LP#1180849: test case - ignoring subrequest responses after respond_complete() - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=59b4dd7> |
11:24 |
pinesol_green |
[opensrf|Mike Rylander] Protect subrequests from post-complete messages - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=a0d5b05> |
11:26 |
|
jboyer-isl joined #evergreen |
11:26 |
|
jeffdavis joined #evergreen |
11:30 |
pinesol_green |
[opensrf|Bill Erickson] OpenSRF client disconnect robustification (Perl) - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=b0a41d3> |
11:30 |
bshum |
I hate netsplits. |
11:30 |
rfrasur |
I hate socks that slide off when you're wearing snow boots. |
11:36 |
|
b_bonner_ joined #evergreen |
11:52 |
csharp |
dbwells: re: bug 1261355, my next step in troubleshooting was to begin commenting out each numbered script subsection in turn until I find the cause on our DB |
11:53 |
pinesol_green |
Launchpad bug 1261355 in Evergreen "2.4.3-2.5.0-upgrade-db.sql causing "could not find trigger" PostgreSQL error" (affected: 2, heat: 10) [Undecided,Confirmed] https://launchpad.net/bugs/1261355 |
11:55 |
dbwells |
csharp: sounds like a good approach. I was assuming the 'SET CONSTRAINTS' was part of the issue, but Robert's comment makes it sound like the same error can happen when skipping straight to 'COMMIT' |
11:55 |
bshum |
dbwells: fwiw, I also tried using a 2.4.3 DB with concerto yesterday when csharp first mentioned it in IRC and couldn't replicate the problems either. |
11:56 |
bshum |
I don't have a younger DB (not master) to test further with. |
12:02 |
csharp |
it's possible that it's something about older installs that have been upgraded through each release? |
12:02 |
* csharp |
shrugs |
12:03 |
bshum |
Or it's just a table that has stuff in it that concerto doesn't normally. |
12:20 |
bshum |
Fwiw, it's not unprecedented to split apart pieces of the major version upgrade scripts into separate BEGIN; COMMIT; blocks. It's just not good for safe rollbacks :( |
12:20 |
tsbere |
The big monolithic upgrade scripts should probably be rigged in "schema changes first, then data changes" order or something. But I don't use them so I dunno. |
12:20 |
bshum |
Yeah, there's alot of hand editing that goes into them. |
12:21 |
csharp |
well, there has been less hand editing this go-round for me, but yeah |
12:22 |
|
enrichtomsk joined #evergreen |
12:23 |
csharp |
for our 2.5.1 test server, running the numbered upgrade scripts to go from 2.4.3 to 2.5.1 was fine, so I may do 'for i in `cat list-of-numbered-scripts`; do PGUSER=evergreen psql -f $i evergreen; done' |
12:26 |
csharp |
the only issue with that is the partial reingests that get kicked off sometimes, but Ctrl-C is easy enough |
12:27 |
bshum |
See, csharp, you're only inches from just running master :) |
12:27 |
csharp |
well, on the DB, maybe ;-) |
12:27 |
* csharp |
resists the pull of the dark side |
10:05 |
* csharp |
decides to run VACUUM ANALYZE before running the script again |
11:07 |
|
RBecker joined #evergreen |
11:20 |
csharp |
nope - vacuum didn't help :-/ |
13:42 |
bshum |
Hmm, unrelated but the original 0827 doesn't have that in it. It's only in the upgrade script itself. So we probably never stumbled over that particular issue. |
13:43 |
bshum |
csharp: My vague googling is coming up with slony threads that include references to that error you mention about "could not find trigger" |
13:43 |
bshum |
Since we don't use slony, but you do, maybe that is related. |
13:43 |
|
stevenyvr2 joined #evergreen |
13:44 |
|
stevenyvr2 left #evergreen |
13:45 |
bshum |
Either way, I haven't run a version upgrade script in so long that I probably should stop now and let other folks think through it. |
13:45 |
bshum |
Good luck csharp, sorry I can't be more helpful right now. |
14:01 |
bshum |
Unrelated, it may be that we need both the --create-database and --create-schema flags for eg_db_config to create a remote database. The README only notes --create-database |
14:04 |
bshum |
And fwiw csharp, a clean 2.4.3 database with concerto running the 2.4.3-2.5.0 script went through just fine. Not that it's a good test, cause real production data is always better. But it doesn't seem to be an immediately broken script :( |
14:16 |
csharp |
bshum: thanks - I have another test db and I'm going to run the same script on it to see if it's a data corruption issue or something |
14:22 |
bshum |
@later tell dbs Curious if you think this article I was just reading about dojo.require and Firefox rendering makes sense. Maybe it could help with our autosuggest brokenness with Firefox lately? http://stackoverflow.com/questions/1943082/dojo-require-prevents-firefox-from-rendering-the-page |
14:22 |
pinesol_green |
bshum: The operation succeeded. |
14:24 |
bshum |
csharp: Cool deal, curious to see what happens :) |
14:27 |
bshum |
Eh, probably not it dbs, maybe nevermind |
14:36 |
bshum |
Hmm, so I turned on autosuggest on our test database. And then if I search in Chrome for something, it'll suggest it to me. |
14:36 |
bshum |
Interestingly, if I then search for the same term in Firefox, it suggests it to me. |
14:37 |
bshum |
It's probably cache or something |
14:45 |
bshum |
Oh well, off to shovel some snow and then get ready for the first Christmas party of this week. |
16:11 |
ldwhalen |
is anyone around who understands how pgTap tests are supposed to be used? |
16:14 |
jeff |
have you looked at the existing docs and the notes that dbs put in the Encode.pm bug? |
16:15 |
ldwhalen |
no, I looked at 1194246 |
16:17 |
jeff |
bug 1242999 |
16:17 |
ldwhalen |
thanks! |
16:17 |
jeff |
beyond that i don't have direct experience yet, but ask away! |
16:18 |
jeff |
(and soneone else with more direct experience may answer) |
16:19 |
ldwhalen |
I am modifying query_parser_fts, and I am not sure what type of tests I might run. I will look into this bug. |
16:28 |
ldwhalen |
From what I can see the pgTAP tests are testing the effects of data within the database. This modification is |
16:29 |
ldwhalen |
to a function. There are tests that could be run against it. But, I am not sure what the scope should be. |
16:29 |
ldwhalen |
It has 12 input parameters, so a complete test would be massive. |
16:30 |
ldwhalen |
I am going to add it to a workingg branch and put a pull request on the lp bug because that has been requested |
16:30 |
ldwhalen |
and these changes have been running live on Sitka for months. If a test is needed, I will write one. |
17:01 |
csharp |
interesting... if I 'grep block_check 2.4.3-2.5.0-upgrade-db.sql | cut -d"'" -f2' and apply those updates one at a time, I get no errors |
17:02 |
csharp |
so it must be something about the script + my data |
17:02 |
csharp |
or the script itself |
10:45 |
bshum |
I personally don't feel comfortable suggesting changing the name of the penalty without knowing whether anything depends on that vs. the IDs. |
10:46 |
Dyrcona |
"has reached" is probably better than "exceeds" |
10:46 |
Dyrcona |
Make a game of it: Achievement Unlocked: Checkout Limit! |
10:47 |
* bshum |
suggests roses tests and submit a patch to change the language if it does end up making the world a better place :) |
10:48 |
* Dyrcona |
better not let the reference crew see these logs. He'll be asked to add patron achievements as an enhancement. |
10:49 |
|
ericar joined #evergreen |
10:49 |
jeff |
called up our primary isp... "hi. just sitting here reading the article in the newspaper about the outage we're still experiencing, and wondered if you had any more information for us." |
11:54 |
RoganH |
hmmm... I just did a trivial skim, so it's not restricted to URI's but any bibs without copies? |
11:56 |
bshum |
RoganH: Yeah, that's how it works. We used to call that the "gray bibs problem" back in JSPAC, when empty bibs were styled with gray background. |
11:56 |
bshum |
*we being Bibliomation |
11:56 |
kmlussier |
It looks like ldwhalen has a branch that's ready to be tested. But it doesn't have a pullrequest tag. |
11:57 |
RoganH |
bshum: yeah, I know the gray bib problem, it just didn't occur to me that this was the same thing |
11:57 |
bshum |
They're white now :) |
11:57 |
csharp |
heh |
17:20 |
jeff |
(42 hours later) |
17:23 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "Bmagic: an example might be helpful" (81 lines) at http://paste.evergreen-ils.org/43 |
17:24 |
Bmagic |
Dyrcona: that helps a lot!!! |
17:26 |
Dyrcona |
IIRC: It retrieves and pays all outstanding bills. I wrote it when we were getting complaints about payments via SIP to help test if the problem was the backend or what. |
17:27 |
Bmagic |
Dyrcona: that is the example that I needed. Thanks so much. I hope that forgive is similar |
17:27 |
Dyrcona |
Yeah, just set the payment_type to forgive. |
17:28 |
Dyrcona |
forgive_payment, actually. |
09:25 |
Dyrcona |
Looks like bug 1243280 slipped through the cracks because it was not targeted at 2.5. |
09:25 |
pinesol_green |
Launchpad bug 1243280 in Evergreen 2.5 "'TypeError: obj.active_services is undefined' error when entering z39.50 MARC import UI" (affected: 2, heat: 10) [Medium,Confirmed] https://launchpad.net/bugs/1243280 |
09:26 |
bshum |
Oops. |
09:32 |
Dyrcona |
kmlussier: If you find my development server to be slow, that is because I am running the inter authority link script on it, in parallel. I wanted to test if it could be run in parallel. |
09:33 |
kmlussier |
Dyrcona: Ok, thanks! Do you have the two depesz branches on there now? |
09:33 |
Dyrcona |
kmlussier: And, it may have other issues at the moment. I'm not sure if it is because of load or for some other reason, but I get a 500 error when testing the hostname. |
09:33 |
eeevil |
Dyrcona: it can be. there's no particular interlocking danger |
09:34 |
Dyrcona |
kmlussier: I have loaded both of them, yes. |
09:34 |
kmlussier |
Dyrcona: Thanks again. |
09:42 |
Dyrcona |
Or the disk. |
09:42 |
* Dyrcona |
waits. |
09:47 |
Dyrcona |
And autogen.sh fails with a similar message on a different line in a different file. |
09:47 |
* Dyrcona |
suspects what he is trying to test. |
09:52 |
Dyrcona |
And, bingo! Delete the database entry I added and everything works again. |
09:52 |
* Dyrcona |
does more research. |
09:55 |
|
yboston joined #evergreen |
14:55 |
pinesol_green |
[evergreen|Angela Kilsdonk] Documentation for Sorting Billing Columns - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=46768f1> |
15:03 |
|
kbeswick joined #evergreen |
15:05 |
|
mllewellyn joined #evergreen |
15:17 |
csharp |
okay here's something to test... do a catalog search for something in the staff client and click "Place Hold". The Submit button is greyed out (since it now cares whether a barcode is entered). Click Place this hold for me and the button remains greyed out, but if you switch the radio button back to Place hold for patron by barcode, then back to Place this hold for me, the Submit button is activated |
15:17 |
csharp |
this is on 2.5-rc1 actually (need to upgrade to 2.5.1 when we get a chance) |
15:17 |
bshum |
csharp: Yeah that bug is fixed in 2.5.1 |
15:17 |
csharp |
oh? |
15:18 |
bshum |
Or at least I think it is |
12:00 |
pinesol_green |
2.0.x: You are nothing but a gleeking tongueful of tottering urine. |
12:00 |
jcamins |
^^ 2.0.x has been deprecated |
12:01 |
Dyrcona |
2.0.x needs to be buried, not insulted. ;) |
12:02 |
jeff |
@decide real data or made up test cases |
12:02 |
pinesol_green |
jeff: Beyond here be dragons. |
12:03 |
jeff |
bah. |
12:05 |
Dyrcona |
@eightball real data or made up test cases? |
12:05 |
pinesol_green |
Dyrcona: _I_ don't know. |
12:06 |
berick |
@eightball does @eightball ever give an answer? |
12:06 |
pinesol_green |
berick: The outlook is good. |
12:51 |
bshum |
jeff: Could always submit a proposal for the next site selection committee :) |
13:14 |
bshum |
Dyrcona++ # for Marque.pm |
13:14 |
Dyrcona |
Shh! It isn't ready for prime time, yet. |
13:14 |
* csharp |
was about to ask |
13:15 |
csharp |
Dyrcona: I may have said before, but I'll be happy to test that when you're ready |
13:40 |
|
kmlussier joined #evergreen |
13:48 |
|
akilsdonk joined #evergreen |
13:53 |
kmlussier |
I briefly looked at bug 1234845 on Dyrcona's server a while back, but now I'm giving it closer scrutiny on another server. Could somebody give me some information on where the ranked_volumes function comes into play? Is it related to the way copies are retrieved on the search results page? |
14:15 |
pinesol_green |
Launchpad bug 1236979 in Evergreen "Speed up bibs-by-item-age" (affected: 1, heat: 10) [Medium,Confirmed] https://launchpad.net/bugs/1236979 |
14:15 |
Dyrcona |
jeff: *Which* pickaxe? |
14:16 |
jeff |
Dyrcona: -S |
14:16 |
* kmlussier |
assumes so since the difference in performance between the production and test server is very noticeable indeed. |
14:16 |
Dyrcona |
The BitCoin miner, the MMORPG.... |
14:17 |
eeevil |
kmlussier: yes (that's the item-age freshmeat feed). the ranked_volumes change is only part of the fix, of course, the other is an entirely new stored proc that replaces a big query |
14:17 |
jeff |
this pickaxe: git log -SCHECKIN_BYPASS_HOLD_FULFILL --pretty=oneline --abbrev-commit |
15:09 |
pinesol_green |
Launchpad bug 1207903 in Evergreen "Lost billing amounts should be more configurable" (affected: 1, heat: 6) [Wishlist,Triaged] https://launchpad.net/bugs/1207903 |
15:14 |
mmorgan |
dbwells++ |
15:15 |
mmorgan |
Back to the "cost" field for a moment. Is that not visible anywhere in the client? Just for reporting? |
15:19 |
jeff |
it is not visible in the client when viewing a copy. it may be visible somewhere in Acq. it can be reported on. |
15:19 |
jeff |
at our library, we intend to move item cost from a copy note to asset.copy.cost and use it for reporting collection value / depreciation |
15:31 |
jeff |
dbwells++ remingtron++ for bug 1207903. Looks good at a quick glance. Any reason I shouldn't give it a test and commit to master sometime this weekend? |
15:31 |
pinesol_green |
Launchpad bug 1207903 in Evergreen "Lost billing amounts should be more configurable" (affected: 2, heat: 10) [Wishlist,Triaged] https://launchpad.net/bugs/1207903 |
16:18 |
|
dMiller__ joined #evergreen |
16:44 |
smyers_ |
I have a z39.50 problem and was wondering if someone would be willing to help find the issue |
17:00 |
smyers_ |
the odd thing is as soon as I point this at the production environment I get results |
17:00 |
Dyrcona |
Well, something is different. You also get different results from the two environments in the browser. |
17:01 |
smyers_ |
that would be expected to some degree as the databases are different |
17:01 |
Dyrcona |
Is the test environment a copy of production? If not, you should go over what makes it different. |
17:01 |
smyers_ |
the underlying data is older but that should be it |
17:02 |
|
mrpeters left #evergreen |
17:02 |
Dyrcona |
I've had lots of fun migrating Vietnamese records this year and pestered gmcharlt with sample files, that every time I see Vietnamese like that, I tend to blame charset issues. |
07:39 |
|
rjackson-isl joined #evergreen |
08:07 |
|
Dyrcona joined #evergreen |
08:10 |
|
jboyer-isl joined #evergreen |
08:24 |
csharp |
dbwells: I'm interested in 2.5.1... are you awaiting testing feedback that it works? I'm willing to do a test install if that helps |
08:25 |
csharp |
specifically, I'd like to branch off of rel_2_5_1 via git when that gets created |
08:26 |
|
akilsdonk joined #evergreen |
08:27 |
Dyrcona |
csharp: You could just branch off of rel_2_5 now and then change the upstream when 2_5_1 is created. Anything destined for 2_5_1 should go into 2_5. |
08:28 |
Dyrcona |
Which reminds me that we're doing a test upgrade on my development server today before this weekend's update. |
08:29 |
Dyrcona |
As a general recommendation, if you have local changes and you want to track the release branches, I'd suggest basing your local branch off of rel_X_Y and not rel_X_Y_Z anyway. |
08:30 |
csharp |
actually, that's a great idea |
08:30 |
csharp |
it won't matter as much once we lock in on our go-live version, but during this test phase that's better |
08:31 |
Dyrcona |
If you follow rel_X_Y you should pickup anything destined for rel_X_Y_Z, and you'll always be up to date as of your build. |
08:33 |
Dyrcona |
git++ |
08:34 |
* Dyrcona |
checks if yesterday's database reload was successful. |
14:05 |
rsoulliere |
I can go first. |
14:05 |
rsoulliere |
#topic Conversion Coordinator Report |
14:05 |
yboston |
go ahead rsoulliere |
14:06 |
rsoulliere |
#info EG 2.5 documentation is now being processed on the documentation web server. |
14:06 |
rsoulliere |
#info I shared some information and tools with yboston regarding processing documentation from the repositories. Here are some of the tools in a repository I set up a long time ago: |
14:06 |
rsoulliere |
#link https://github.com/rsoulliere/Evergreen_Documentation_Tools |
14:06 |
rsoulliere |
#info If anyone else is interested in setting up their own documentation site for testing or experimenting and needs some technical assistance to get started, let me know. |
14:06 |
rsoulliere |
That is all. |
14:07 |
yboston |
rsoulliere++ |
14:07 |
kmlussier |
I can go next. |
14:07 |
yboston |
rsoulliere: I have a comment for you |
14:09 |
yboston |
I don't want to cause the nightly builds to be broken for several days |
14:10 |
rsoulliere |
Typos etc... shouldn't bring the whole documentation site to a crash. |
14:10 |
yboston |
rsoulliere: I guess we can start with a few as see how it goes. So far I just waited until the next day to see if the one page was built successfully. |
14:11 |
rsoulliere |
I would test locally using the basic ascidoc command and upload if it passes the test. |
14:11 |
rsoulliere |
I probably would load a bit at a time as you suggest. |
14:11 |
yboston |
any particular combination of parameters? |
14:11 |
rsoulliere |
If you notice anything not appearing, let me know via email and I can troubleshoot on the server. |
14:12 |
yboston |
also, I had issues with the bash source highlighting on OS X, was not sure how to fix |
14:13 |
|
dMiller___ joined #evergreen |
14:13 |
rsoulliere |
yboston re: parameters: I think the basic html conversion should be a good test. That should catch most syntax issues. |
14:13 |
yboston |
rsoulliere: OK |
14:13 |
|
jboyer_isl joined #evergreen |
14:13 |
rsoulliere |
re OSX highlighting: do you mean display issues in safari? |
14:26 |
yboston |
Any comments or questions? |
14:27 |
yboston |
My elevator speech about the hack-a-way, it was great for getting new folks trained on DIG workflows and asciidoc. It was hard to find small taks for volunteers to work on |
14:28 |
kbutler |
yboston: Thank you for hosting. I thought it was productive. |
14:28 |
yboston |
we still have files that were worked on that need to be pushed to the repository |
14:28 |
yboston |
kbutler: thanks |
14:29 |
yboston |
I hope by January all of the work that was started (and finished) at the hack-a-way has been integrated to the docs. |
14:30 |
yboston |
I also hope that it iwllbe easier to find tasks to give to newcomers not that we have a video tutorial to get more people u to speed |
14:30 |
yboston |
(now that we have) |
14:32 |
yboston |
Also, at the next conference, we should have a whole day to work on docs. Hope that we can apply other lesson of this hack-a-way to that hackfest |
14:32 |
yboston |
BTW< thanks to ESI, that was the test server we ended up using the most |
14:33 |
yboston |
Any comments or questions? |
14:35 |
kmlussier |
Sounds like you all got a lot accomplished. Nice work! |
14:35 |
kmlussier |
yboston++ for pulling it together. |
14:36 |
yboston |
Next year I plan to again offer to host, but perhaps we can all decide meet somewhere else in Massachusetts |
15:44 |
|
dMiller___ joined #evergreen |
15:53 |
|
stevenyvr2 joined #evergreen |
16:07 |
Dyrcona |
At some point, you just have to stop typing/editing and hit the "Publish" button. :) |
16:13 |
remingtron |
yboston: when publishing docs, we could use the master branch as our test version. If it breaks, it's okay because it's only the dev version! Once it's fixed, pull it into 2.5 and 2.4. |
16:13 |
|
timlaptop joined #evergreen |
16:14 |
remingtron |
yboston: I'll send this idea to the DIG list for discussion |
16:14 |
Dyrcona |
If anyone is interested in what I was doing to use the asciidoc blogpost program to post to blogger: http://blog.sigio.com/2012/05/look-ma-no-hands_15.html |
16:14 |
yboston |
remingtron: that is a great idea |
16:14 |
Dyrcona |
If anyone cares about my other, more personal, blog: http://kissmysock.wordpress.com/ |
17:24 |
Dyrcona |
more like the first one, yes. |
17:25 |
ElliotFriend |
with all that said, what would be the best way to move towards a workflow like that, as opposed to the way I'm doing it? |
17:26 |
ElliotFriend |
Set it up like that on a new set of servers? |
17:26 |
Dyrcona |
Do you have a server that you use for testing or development? |
17:27 |
Dyrcona |
I'd try it out on a test server to start with. |
17:27 |
ElliotFriend |
Both are VMs. I have a test server that is a clone of the production one |
17:27 |
Dyrcona |
I'd set it up on the test vm first. |
17:27 |
ElliotFriend |
I only ever spin up the test one to run through an upgrade, before applying it to production |
17:27 |
ElliotFriend |
sounds good |
17:28 |
Dyrcona |
It is about time for me to head home. I can sign back in when I get there if you want to discuss the work flow some more. |
17:29 |
ElliotFriend |
I think I'm alright. Thanks again! I repeat, Evergreen people sure are swell! |
00:28 |
smyers_ |
boolean returns |
00:29 |
smyers_ |
OpenSRF/Utilies/JSON.pm |
00:31 |
smyers_ |
jeff: I need to go to bed, if you have more questions for me or if I can help anyway let me know |
00:32 |
jeff |
huh. i wonder what "boolean returns" means. guess i'll find out when i upgrade JSON::XS to 3.01 on my second test instance. |
02:01 |
|
senator joined #evergreen |
03:16 |
|
mjingle left #evergreen |
06:38 |
|
b_bonner joined #evergreen |
06:39 |
|
mtcarlson_away joined #evergreen |
06:53 |
jeff |
bug to follow, but user/jeff/fix_json_xs_booleans_option1 and user/jeff/fix_json_xs_booleans_option2 OpenSRF working branches have a fix for latest JSON::XS issues |
07:17 |
jeff |
bug 1257264 |
07:17 |
pinesol_green |
Launchpad bug 1257264 in OpenSRF "JSON::XS 3.0 changes the way booleans are represented" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1257264 |
07:31 |
eeevil |
jeff: I'm going to look at a third option in a bot using opensrf type registration |
07:41 |
|
rjackson-isl joined #evergreen |
09:46 |
dbs |
Projected medium + short running time + audience = preschool + type = motion picture + technique = animation = Cartoon! |
09:46 |
paxed |
isn't there an eg project that's going to do something like this? |
09:47 |
paxed |
add original country = japan => anime :P |
09:47 |
eeevil |
paxed: there's a proposed project, yes |
09:50 |
eeevil |
jeff: so, going back as far as JSON 2.23 (earliest CPAN-able JSON module, Sept 2010) there's a is_bool class function. it's also in both of the available JSON::XS modules. I think we should use that instead of testing the object directly, if it's a scalar ref. should do the right thing in any reasonable version |
09:51 |
dbs |
So right now we have one icon that means exactly what the string says: "Projected medium" - which could be a magic lantern show, a set of slides, a filmstrip, a vhs tape, a dvd, a bluray, a laserdisc... we don't even use the 007 currently in figuring out what icon to display, IIRC |
09:52 |
jeff |
urgh. i know i was up too late when AWS doesn't even want me to re-authenticate in the morning. |
09:52 |
dbs |
I guess if the bulk of your collection is DVD movies, then change the string to "Movies, etc" or something like that? |
09:53 |
bshum |
Our string is currently a generic "Video recording" which is slightly better sounding I guess. |
09:54 |
jeff |
is it unusual to hear this text in the voice of Dr. Strangelove? "Improve your instance's security. Your security group, eg-pub-test, is open to the world." |
09:54 |
dbs |
bshum: yeah, that sounds better to me :) |
09:54 |
jeff |
"Why didn't you tell the WORLD?!" |
09:57 |
dbs |
ah, the proposal eeevil mentions is http://list.georgialibraries.org/pipermail/open-ils-general/2013-September/008961.html - right |
12:46 |
tsbere |
ldwhalen: There is a hard limit of "whatever your network connection and server can handle" - Beyond that, not really. |
12:47 |
ldwhalen |
tsbere: thank you. |
12:50 |
Dyrcona |
ldwhalen: Is there a particular problem that you are trying to solve or are you asking for informational purposes? |
12:55 |
gmcharlt |
jeff: I've cobbled a branch together with eeevil's patch and a test case adjustment for lp1257264 that I think is ready for review, if you care to test |
12:55 |
ldwhalen |
Dyrcona: another programmer asked me, and I did not know the answer. |
12:56 |
Dyrcona |
ldwhalen: There are a lot of configurations for number of drones to run and how many requests a drone can process before it is recycled. While these don't lead to connection limits directly, if you set these too low, it will seem like you have a connection limit. |
13:00 |
eeevil |
gmcharlt++ |
13:07 |
Dyrcona |
tsbere once considered running more than one ejabberd instance here, but ran out of tuits. |
13:08 |
Dyrcona |
I think the last tuit is stuck to my desk via magnet. |
13:08 |
bshum |
We used to run separate ejabberd on the heads of every brick for head/drones. |
13:08 |
tsbere |
I didn't run out of tuits. My plans for test hardware fell through. ;) |
13:09 |
Dyrcona |
heh |
13:23 |
jeff |
gmcharlt: heh. your new branch and mine in-progress look very similar. this is probably good. :-) |
13:24 |
jeff |
who needs test hardware when you have spot instances? ;-) |
13:24 |
gmcharlt |
jeff: yeah, I think main difference is that my branch avoids any direct testing of JSON::{XS,PP}::Boolean |
13:25 |
jeff |
yeah, mine also. i'll append my additional tests and sign off on what's there and if the tests don't seem ridiculous, great! |
13:26 |
jeff |
also, if anyone hadn't seen it yet, google compute engine has gone General Availability, and supports neat things like freebsd: http://googlecloudplatform.blogspot.com/2013/12/google-compute-engine-is-now-generally-available.html |
13:28 |
jeff |
gmcharlt: is it good/bad form to have use strict / use warnings in tests? |
13:28 |
Dyrcona |
use Modern::Perl; |
13:29 |
gmcharlt |
jeff: use strict & use warnings is always good form -- positively elegant, in fact |
13:29 |
* Dyrcona |
should make hacker t-shirts and stickers. |
13:29 |
tsbere |
jeff: I wanted to actually have real networking equipment in the mix >_> |
13:30 |
Dyrcona |
tsbere: All those switches that we gave to the community college? |
13:30 |
tsbere |
Dyrcona: Meh, one cheap-ass netgear switch. Just needed several machines plugged into it. |
13:31 |
tsbere |
The "borrow several nearly identical machines to test with" aspect is what fell through on me |
13:32 |
Dyrcona |
Yeah, not much homogeneity in our closet of broken toys. |
13:57 |
|
kmlussier joined #evergreen |
14:14 |
|
jboyer-isl joined #evergreen |
14:37 |
|
sseng joined #evergreen |
14:41 |
jeff |
gmcharlt++ eeevil++ i think bug 1257264 is almost ready to die. |
14:41 |
pinesol_green |
Launchpad bug 1257264 in OpenSRF "JSON::XS 3.0 changes the way booleans are represented" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1257264 |
14:45 |
jeff |
and if my tests don't make sense, feel free to leave that commit behind. :-) |
14:48 |
|
kmlussier joined #evergreen |
14:51 |
gmcharlt |
jeff: looks fine to me; I will push |
14:51 |
jeff |
gmcharlt++ thanks! |
14:54 |
pinesol_green |
[opensrf|Galen Charlton] LP#1257264: make test cases for JSON::XS Boolean-ness more generic - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=ff472c0> |
14:54 |
pinesol_green |
[opensrf|Mike Rylander] LP#1257264: Use the built-in JSON-y test for bools - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=a5be2f1> |
14:54 |
pinesol_green |
[opensrf|Jeff Godin] Add some additional boolean-related JSON tests - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=b93e0ca> |
14:55 |
|
rfrasur joined #evergreen |
14:57 |
|
gsams joined #evergreen |
14:58 |
rfrasur |
berick: I have a question about a web-based staff client. Does that mean it would open in a browser? in other words, does that mean I could have the staff client in this or that tab and have email or whatever in another tab but only have one browser window open? |
11:49 |
bshum |
Oh, autocomplete... not autosuggest |
11:49 |
bshum |
Or is that what you meant? |
11:50 |
csharp |
ah sorry - I did mean autosuggest |
11:50 |
bshum |
My kneejerk reaction is to blame it on ancient dojo |
11:51 |
bshum |
But there could be more to it |
11:52 |
bshum |
Hmm, clean master tests fine with Firefox 25.0.1 for me. But I can see what you mean about that particular catalog having issues. |
11:52 |
csharp |
https://catalogue.libraries.coop/eg/opac/home?physical_loc=1&locg= too |
11:53 |
csharp |
looks like it's off in Indiana |
11:53 |
bshum |
So it sounds like autosuggest is having some struggles with the latest Firefox |
11:56 |
csharp |
dayum |
11:56 |
csharp |
rfrasur++ |
12:02 |
jeff |
bshum: can you explain what you mean by "wish we could more accurately predict the outcome of reingest work"? |
12:03 |
bshum |
jeff: In our case, I'm thinking I need to apply some more testing methods to look for potential issues. |
12:03 |
bshum |
Or rather, learn how to do better testing |
12:04 |
bshum |
We have the servers presently to test full scale reingests of all our bibs, but this last round we made a huge glaring mistake by not noticing that an entire field was lost in the reingest process. |
12:04 |
bshum |
I'm referring to the alternate titles bug |
12:04 |
bshum |
But it didn't get noticed in our manual testing, and nobody saw it till a few days or weeks post upgrade / reingest |
12:05 |
bshum |
I guess it's hard to predict everything though |
12:05 |
bshum |
Given that we all have little tweaks to our metabib tables |
12:10 |
|
hopkinsju joined #evergreen |
12:15 |
|
kitteh_ joined #evergreen |
12:26 |
eeevil |
bshum: tangentially related: I'd like to see/do more work on ingest logic splitting. made some good progress in 2.5, but there's more to do, like splitting off record attrs as search/facet/browse are now |
14:35 |
bshum |
My head hurts |
14:37 |
bshum |
ldwhalen: If/when you get some free time, I'm curious to know how your changes turned out for https://bugs.launchpad.net/evergreen/+bug/925776 |
14:37 |
pinesol_green |
Launchpad bug 925776 in Evergreen 2.4 "located URIs appear in staff client OPAC searches regardless of $9's" (affected: 4, heat: 22) [Medium,Confirmed] |
14:37 |
bshum |
I'd like to get all of them together into a working branch so that we can test it out as well down the road. |
14:38 |
mmorgan |
bshum: So "people" meaning staff still want to see the Lost items on patron accounts after they're paid? |
14:38 |
bshum |
mmorgan: Right, staff :P |
14:39 |
bshum |
I think that's just so that until the lost item is actually dealt with, they want to know who had it last and quickly see that when they pull up the record. |
15:01 |
dbs |
Or perhaps with default settings |
15:01 |
bshum |
Hmm, perhaps |
15:02 |
dbs |
It doesn't make sense to me that firefox would care about how long it takes for a request to return, vs. chrome |
15:02 |
jeffdavis |
mjingle just tested IE and it works, fwiw |
15:03 |
dbs |
watching the network requests in firefox suggest that it never actually sends a request |
15:09 |
bshum |
Autosuggest doesn't seem very happy with IE11 fwiw |
15:09 |
bshum |
Not sure which IE mjingle was poking with |
15:46 |
pinesol_green |
jboyer-isl: The operation succeeded. |
15:47 |
jeff |
jboyer-isl: thanks for checking. :-) |
15:47 |
jboyer-isl |
No problem. |
15:48 |
jeff |
jboyer-isl: i'm in the process of testing things here. i'm able to let a patron who could not otherwise circ but can perform renewals to get in and do a renewal, and they're still rejected at checkout time, but the message is a tad too generic, so i'm going to improve that. |
15:55 |
|
stevenyvr joined #evergreen |
16:20 |
|
gmcharlt joined #evergreen |
16:31 |
|
mmorgan1 joined #evergreen |
11:11 |
mmorgan |
Does shelf browse search/sort by asset.call_number.label, or asset.call_number.label_sortkey? |
11:12 |
senator |
csharp: to see what bib call number searches exactly on your system, (it's not the 092 by default) see: select format, xpath from config.metabib_field where field_class = 'identifier' and name = 'bibcn'; |
11:12 |
csharp |
aha |
11:12 |
eeevil |
dbwells: thougts on my final comment on our funtime QP bug? (also, did you see Liam's note about sitka testing?) |
11:13 |
dbwells |
krvmga: mmorgan: the shelf browse can be tricky. It uses the non-normalized value to find the "pivot" (that is, the closest match to what the user typed in), then uses the sortkey to sort the surrounding results. |
11:14 |
csharp |
ours is set to 099 - however, we disable bib cn searching because all of our call numbers are free text and locally set, so we could have many variants on a single bib record |
11:14 |
csharp |
and none of those variants gets entered into the 099 |
12:29 |
jeff |
That opac spelling suggestion on search is the only thing I'm aware of. |
12:30 |
* berick |
uploads updated 2.3.12 tarball to previews |
12:30 |
JennB |
ok! thats for reconfirming what I knew/was aware of |
12:30 |
jeff |
Now, there is support for verifying authority controlled fields in the MARC editor -- which isn't strictly "spell check", but can bring to light typos and such. |
12:30 |
jeff |
berick++ |
12:30 |
jeff |
and dbs++ for testing hardcoded paths |
12:31 |
JennB |
OK, thanks! |
12:32 |
dbs |
from what I can see, the install instructions will get simpler if we can avoid the /openils prefix |
12:33 |
jeff |
ouch: SIPServer.pm: OILS: SIP Checkin request took 6.386 seconds |
14:50 |
|
stevenyvr joined #evergreen |
15:21 |
jeff |
interesting. circ block doesn't appear to block on a pre-cat. |
15:28 |
* eeevil |
taps fingers waiting for i18n build to complete for 2.4.4 wrapping |
15:30 |
jeff |
eeevil: in testing, a self checkout terminal from vendor 3 doesn't seem to care about the "renewal privileges denied" flag. if charge privs are denied, the patron can't use the terminal. |
15:32 |
eeevil |
jeff: so even if we did the "right" thing with the renew flag and block check, their thing would not act correctly... :( |
15:32 |
jeff |
eeevil: still worth adjusting our response there to be correct (now that we can), but i suspect i'm also going to add a config option to the sip server to skip over certain standing penalties. |
15:33 |
|
dMiller_ joined #evergreen |
15:35 |
jeff |
eeevil: right. i forced OpenILS::SIP::Patron to always return ok for renewal privs, and the terminal still rejected the patron before giving them a chance to renew things. |
15:36 |
|
janes joined #evergreen |
15:37 |
jeff |
eeevil: i don't think it would be good to "always ignore this circ-blocking penalty" in a hardcoded sense, since i can only test things on certain clients, but i suspect it'll be a "ignore this block for this penalty type" config option with a suggested default. |
15:40 |
jeff |
"ignore these penalties completely" might be simpler, at the expense of some expression/flexibility |
15:41 |
eeevil |
jeff: wonder if it's time to provide a config for each flag allowing "force-Y/force-N/what-ILS-says" |
15:41 |
eeevil |
in the sip config file |
15:41 |
eeevil |
that would allow per-client-device tuning |
15:42 |
jeff |
yes. i'd still like to do per-client config for some things, not all related to this. |
15:43 |
jeff |
though maybe per-sip-user isn't needed if we can do it now with multiple institutions without too much overhead. not sure i'd thought of that yet. |
15:44 |
eeevil |
<sip-flags><circ>auto</circ><renew>Y</renew></sip-flags> ... default for unconfigured flags being "auto" |
15:45 |
jeff |
off to test how well the client reacts to "sure this patron can check stuff out" followed by not allowing anything to be checked out. |
15:45 |
* jeff |
grabs some rfid tags |
15:46 |
sandbergja |
Acquisitions question for everyone: on eg 2.4.0, is there a trick to placing holds via Acquisitions > Patron Requests? I have double checked that "Place Hold" was checked, and I have gone through the whole Add to selection list, Activate PO, Receive PO process. |
16:03 |
|
dMiller joined #evergreen |
16:11 |
|
dMiller_ joined #evergreen |
17:18 |
jeff |
i remember. :-) |
17:18 |
Bmagic|2 |
jeff: so, from your understanding, would an appropriate row in actor.usr_standing_penalty be required to prevent the checkout? |
17:19 |
jeff |
this seems to be a bit of an inelegant workaround, though perhaps useful as a learning experiment. :-) |
17:20 |
Bmagic|2 |
jeff: I only ask, because the (Has overdues) comes up for this test patron even without the row in the table |
17:20 |
jeff |
Bmagic|2: yes, a row in actor.usr_standing_penalty corresponding to the user in question with the standing penalty type in question is what i'd expect to see for a user with that penalty |
17:20 |
jeff |
has overdues is something else. |
17:21 |
Bmagic|2 |
jeff: I think I need (max overdues) |
11:01 |
bshum |
csharp: Yeah it is |
11:01 |
bshum |
Now I'm suspecting screen resolution |
11:01 |
bshum |
The person complaining is running 800x600. Maybe the buttons are sliding off the screen ara |
11:01 |
csharp |
lemme rebuild my test vm and try to replicate |
11:01 |
bshum |
*area |
11:01 |
csharp |
oh |
11:02 |
dbs |
ooh, 800x600. fun. |
11:22 |
bshum |
But as the other user, they couldn't see it. |
11:22 |
bshum |
Weird...... |
11:22 |
csharp |
that would be a different openils profile, right? |
11:22 |
bshum |
Or... wait |
11:23 |
bshum |
That the user is a member of admin and debugger? |
11:23 |
bshum |
Must be groups or something |
11:24 |
* bshum |
throws his hands up in the air in disgust |
11:24 |
bshum |
windows-- |
12:00 |
|
dMiller joined #evergreen |
12:06 |
bshum |
Hmm |
12:07 |
bshum |
csharp: When placing a hold in the staff client, I'm seeing that if the staff member doesn't have an email address, it populates the email field with something like "no email address configured, check account" |
12:07 |
bshum |
And then it doesn't update the field with the actual user's email when you key in different barcodes. |
12:07 |
bshum |
If the staff member does have an email, it starts with their email, and then keying in different patrons updates the field accordingly |
12:08 |
bshum |
My thinking is a bug since 2.4's rewrite of the code in that area |
12:08 |
bshum |
And maybe it's just not initializing the email variable (or refreshing it if it starts as NULL) |
12:09 |
bshum |
csharp: If you get a chance to test that on a 2.4/2.5/master system, let me know :D |
12:09 |
bshum |
I'm going to eyeball some more code |
12:09 |
* bshum |
loves how "upgrades" shakes loose all the bugs nobody ever saw before |
12:13 |
|
rfrasur joined #evergreen |
12:14 |
phasefx |
bshum: I think someone here said that they announce upgrades that don't actually happen for just that reason :) |
12:15 |
bshum |
phasefx: I've done that before :) |
11:05 |
bshum |
senator: I didn't backport bug 1233340 because when I reported the issue, I was only aware of it being unhappy in master/2.5. I think dbwells must have added backport targets after I had done my dance with master. |
11:05 |
pinesol_green |
Launchpad bug 1233340 in Evergreen 2.4 "2.5 serials receiving error" (affected: 2, heat: 12) [Undecided,Fix committed] https://launchpad.net/bugs/1233340 |
11:05 |
bshum |
senator++ |
11:06 |
senator |
cool. thanks for testing and all in the first place |
11:06 |
bshum |
As far as milestones go though |
11:06 |
bshum |
I think I'll go ahead and make new ones for you if you don't think the maintainers will repackage. |
11:07 |
bshum |
Because otherwise, it could easily get lost in shuffles |
11:07 |
* senator |
pings them about it real quick |
11:07 |
bshum |
Okay, I'll wait a bit then |
11:07 |
dbwells |
Yeah, I looked at it, and really couldn't remember. It seems odd that the series targetting doesn't show up in any of the listed change history. Sorry if I dropped the ball on it. |
11:08 |
senator |
no problem. didn't mean to make it a blame-y thing for anybody, just wanted to be sure i still have the right idea of what the test/merge/backport practice is |
11:09 |
eeevil |
I have something that I'd like to get into 2.4 sooner rather than later as well, and since we haven't updated the downloads page, or committed the tag versions, we could announce a delay and release early next week. |
11:11 |
bshum |
Sounds good to me. |
11:11 |
eeevil |
wrapping is a pain, but waiting another month on known bugs is worse |
14:57 |
tsbere |
jeff: Ditto that here. <_< |
14:57 |
bshum |
jeff: Sounds like what I end up doing every time I start from scratch too :) |
14:57 |
jeff |
scipted_installs++ |
15:05 |
bshum |
berick: For the purposes of testing new bug 1254146 and if we already had an opac entry in actor.org_unit_custom_tree (ours is set to false) what should we expect to see or not see? |
15:05 |
pinesol_green |
Launchpad bug 1254146 in Evergreen 2.4 "Custom org tree with no org units causes TPAC server error" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1254146 |
15:05 |
bshum |
I'm firing up a test VM to try with a blank system |
15:06 |
berick |
bshum: if you have a non-active tree or a tree with entries, the bug will not manifest |
15:06 |
bshum |
berick: Gotcha. |
15:06 |
bshum |
So really I'll test with a clean system then. |
15:07 |
berick |
bshum++ |
15:07 |
bshum |
Ah right... forgot I had to reload apache to see it take effect |
15:07 |
bshum |
Yep, okay |
08:36 |
csharp |
I'm pretty sure that's set in PINES - lemme check |
08:37 |
csharp |
yes it is |
08:37 |
csharp |
hmm |
08:37 |
kmlussier |
csharp: I'm pretty sure a message displays. I kept forgetting to turn off that OU setting when testing the holds ratio, so I saw it a few times. |
08:37 |
|
mmorgan joined #evergreen |
08:38 |
csharp |
yeah - that was my original assumption - then I started digging around in the template code and didn't see anything :-/ |
08:42 |
|
ericar joined #evergreen |
11:09 |
jeff |
thus, unless there are other overdue circs that are past the grace period, the fine generator will not trigger a calcualtion of system penalties. |
11:10 |
jeff |
that's probably what's causing what you're seeing. |
11:10 |
Bmagic |
jeff: That is the issue then |
11:11 |
jeff |
and it's a bit of an inconsistency, since a manual recalc will add the penalty. we should probably determine if the penalty should count overdues within the grace or not. |
11:11 |
jeff |
while this is based on a reading of the code and my current understanding of things, please keep in mind that i haven't tested this theory. :-) |
11:12 |
Bmagic |
jeff: right on, sound like an interesting debackle |
11:12 |
Bmagic |
jeff: right on, sound like an interesting debacle |
11:19 |
Bmagic |
jeff: For now, it sounds like I can use that script that you directed me to on a cronjob? Long term, perhaps the code for fine_generator.pl could be discussed in dev? |
12:16 |
|
smyers_ joined #evergreen |
12:17 |
|
dMiller__ joined #evergreen |
12:18 |
jeff |
anyone present using non-3M SIP-based self checkout terminals? i'm wondering how other vendors react to "charge privileges denied" in the patron status field. |
12:19 |
jboyer-isl |
JCPL was running Bibliotheca machines when I left. If you've some simple steps to test what you're interested in I could pass them on. |
12:20 |
jeff |
in evergreen, standing penalties 1 and 2, as well as any standing penalty with a non-empty block list will result in "charge privileges denied" being set to Y. |
12:20 |
jeff |
(this is for standing penalties with an org_unit based on the home_ou and ancestors of the patron in question) |
12:21 |
jeff |
so, if you define a max items out limit of 40, a patron with 40 items out has a standing penalty which blocks circ. |
12:22 |
jeff |
i'm interested in changing the behavior on the evergreen side of things, and would like to better understand how other SIP clients react to "charge privileges denied" |
12:23 |
jeff |
so, it would be interesting to know if patrons with the max number of items out can use a bibliotheca terminal, or if they're refused outright. |
12:27 |
eeevil |
jeff: sound primarily like the impedance mismatch between SIP2 and ILSen, where the latter has a separate idea of "renewal" but the former does not, and ties renewal to "charge privileges" ... some ILSs lie about the patron's status and deny circs at attempt time, which the EG SIPServer driver could do, I suppose |
12:30 |
jeff |
huge impedance mismatch, yes. |
12:30 |
jeff |
and eg does reject at attempt time, of course. |
12:31 |
jeff |
and (at least in our environment) we do have at least one case where we want to alert when the patron scans their card -- when they're expired. |
12:31 |
jeff |
i'm going to reach out to 3M to see if they can provide more details, but thought i'd seek out others with other vendors here. i don't see sal_, but maybe I'll e-mail her. |
12:33 |
jeff |
incidentally, there is also a "renewal privileges denied", which... oh hey, which evergreen sets to match the charge privileges denied value. i suppose it's time to test. |
12:34 |
jeff |
because if i can make evergreen "do the right thing" with regard to renewals being permitted as long as there isn't a RENEW-blocking ausp, that would be logical and would avoid a new config for "don't report these standing penalties" or similar. |
12:35 |
jeff |
semi-related, does anyone know if we've ever populated a csp block value of INET, or is that just something in our db? |
12:37 |
jeff |
_bott_: any idea about the INET block type on some standing penalties? was that a GRPL/ME thing? |
12:38 |
|
linuxhiker1 joined #evergreen |
12:39 |
tsbere |
jeff: First I have heard of such a thing |
12:45 |
|
hopkinsju_ joined #evergreen |
14:39 |
bshum |
I occasionally dabble looking at our yaz logs to see what people search against when they look at our z39.50 from EG |
14:39 |
jeff |
not a particularly focused or productive question, but something i've been thinking about a little bit. |
14:40 |
tsbere |
jeff: I find that answer varies. Including on "who you ask". Some people insist that no logic should be done in the DB other than what is required for things like foreign key relationships and not null constraints and such, after all. |
14:41 |
jeff |
sure, there's purists like that. i wasn't asking from that point of view. :-) |
14:42 |
jeff |
i suspect that things like in-db ingest are not cpu bound, but haven't tested. it might be. |
14:55 |
mceraso |
This may be a silly question, but I'm asking anyway :) Would it be okay to join the merchandising committee for Evergreen? Rogan sent out an email yesterday |
14:55 |
mceraso |
Apologies, wrong window :) |
14:55 |
|
mrpeters joined #evergreen |
11:22 |
* dbs |
will add something about that to the README |
11:26 |
csharp |
--help++ |
11:27 |
dbs |
okay, --help and --load-all-sample are now documented |
11:28 |
rfrasur |
bshum: do you have a quick link to the set of test data? |
11:28 |
pinesol_green |
[evergreen|Dan Scott] Document how to load concerto sample data - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=28915dd> |
11:29 |
bshum |
dbs++ |
11:29 |
ericar |
Angela and I are unable to access the google hangout for the DIG hack. I will be working on the Serials doc that we signed up for. |
12:19 |
|
mjingle joined #evergreen |
12:20 |
gmcharlt |
rfrasur: can we help? |
12:20 |
dbs |
to just generate html, asciidoc on windows only needs python; you only need cygwin if you're doing pdf / epub etc |
12:20 |
bshum |
gmcharlt: We're testing it. |
12:20 |
rfrasur |
I'm not sure :-), Ben is taking a look. |
12:20 |
* Dyrcona |
thought Windows was just for games. |
12:21 |
csharp |
dbs: oh - good to know |
13:40 |
|
stevenyvr2 joined #evergreen |
13:40 |
eeevil |
dconnor: reducing queries is great. there are already several mechanisms for running arbitrary queries that don't suffer from injection attacks |
13:47 |
|
RoganH_ joined #evergreen |
13:56 |
jeff |
dconnor: going back to my earlier suggestion -- a json query lets you construct a query at the perl layer that returns fieldmapper objects that you can then use without further need to parse/map them. i can't guarantee that you can do everything in a json query that you are doing in your asset.get_holdings_maintenance_page function, but at first glance I think it's do-able. |
13:56 |
jeff |
might be worth testing and comparing performance / complexity. |
13:56 |
|
akilsdonk_ joined #evergreen |
13:58 |
dconnor |
jeff: Ok, I'll check it. thanks! |
13:59 |
|
rjackson-isl joined #evergreen |
14:11 |
eeevil |
I don't think you can use filter syntax for classes, no |
14:12 |
paxed |
the requirements list we went through in the meeting had something like 1600 requirements... some were pretty interesting ones, which our current ils can do |
14:12 |
paxed |
the mathematical comparisons was one |
14:13 |
kmlussier |
rfrasur: I used to use http://andrewk.webfactional.com/asciidoc.php to do simple testing of my asciidoc. But it's deactivated now. :( |
14:13 |
eeevil |
paxed: checked, and you can't use the alias trick today ... adding filter aliases would be another not-too-hard thing |
14:13 |
rfrasur |
kmlussier++ |
14:13 |
rfrasur |
gist.github is working pretty well. |
14:14 |
rfrasur |
I'm just testing snippets here and there. |
14:27 |
|
alexlazar left #evergreen |
14:34 |
|
kbutler joined #evergreen |
14:37 |
|
rangi joined #evergreen |
14:37 |
|
berick joined #evergreen |
14:38 |
|
_bott_ joined #evergreen |
14:38 |
|
rfrasur joined #evergreen |
14:41 |
rfrasur |
Btw, I can use both 2.2 and 2.5 on this computer. I just need to make sure that I'm using the right icon and change the servers. I forgot that'd worked before. |
14:46 |
|
kbeswick joined #evergreen |
14:48 |
rfrasur |
o0(github is friendly. They sent me a welcome email with a dude and a guitar.) |
14:48 |
bshum |
dbs: The link to the asciidoc for "Introducing SQL to Evergreen administrators, round two" on your site isn't working. |
14:48 |
bshum |
It seems to be linked to the older epub file and not the raw text |
14:49 |
bshum |
Someone expressed interest in seeing v2 merged back into the core docs. |
15:22 |
bshum |
Or maybe it's label_sortkey |
15:23 |
* bshum |
always gets his variable wording mixed up |
15:26 |
|
bwicksall joined #evergreen |
15:36 |
yboston |
what is a good combo of options to test parse the full docs. I usually use asciidoc -a data-uri -a icons -a toc -b html5 root.txt |
15:36 |
yboston |
but I am getting an error |
15:36 |
yboston |
asciidoc: WARNING: RELEASE_NOTES_2_5.txt: line 163: filter non-zero exit code: source-highlight -f xhtml -s bash: returned 127 |
15:36 |
yboston |
asciidoc: WARNING: RELEASE_NOTES_2_5.txt: line 163: no output from filter: source-highlight -f xhtml -s bash |
15:40 |
|
kmlussier joined #evergreen |
15:42 |
mmorgan |
Can someone help me understand user activity types? |
15:42 |
mmorgan |
"OPAC Login (tpac)" I get, but what is "Login via opensrf"? The users I'm looking at aren't staff. |
15:54 |
senator |
yboston: i would guess you just don't have the source-highlight package installed |
15:56 |
|
kbeswick joined #evergreen |
15:57 |
kmlussier |
yboston: I don't have the source-highlight package installed and get a similar error. But it isn't a problem once the documents are added to the official repository. I've just learned to ignore them. |
15:58 |
yboston |
senator: that is what I suspected, but I still wodered what parameters were recomended, since I am also having issues with the "icons" parameter. I am trying to figure out how to install this filter |
15:58 |
yboston |
kmlussier: I just don't want to commit something that breaks the asciidoc build, so I wnated to test it first, and so far it won't build |
15:59 |
kmlussier |
yboston: Oh, then that's different. I can usually get it to build even with the source-highlight package warnings. |
15:59 |
mmorgan |
kmlussier: Looks like there are a number of users in the syrup tables for those students, so that could certainly be part of it. Thanks! |
16:00 |
* kmlussier |
heads out for her long commute. |
17:03 |
jeff |
hooray. |
17:15 |
|
mmorgan left #evergreen |
17:20 |
phasefx_ |
jeff: lp still sucks ;) |
17:20 |
jeff |
for those working with postgresql 9.3 and perl DBI, you'll likely hit this failed test at install time for DBD::Pg, known and safe to --force past: https://rt.cpan.org/Public/Bug/Display.html?id=88865 |
17:32 |
|
linuxhiker joined #evergreen |
17:35 |
paxed |
hmm ... the comments on get_ac_key in EGCatLoader/Record.pm seem to indicate it could be removed now? |
17:37 |
berick |
paxed: yes! good eyes. we can kill that now |
14:53 |
tsbere |
I am assuming 0.93 |
14:53 |
tsbere |
I could be wrong |
14:53 |
Dyrcona |
You're probably right. I have 0.90. |
14:53 |
jeff |
0.23 2009-12-18T23:03:39Z |
14:53 |
jeff |
* Added `is_empty()` to test that a query returns an empty set (no results). |
14:53 |
jeff |
oh. |
14:53 |
jeff |
isnt_empty |
14:54 |
Dyrcona |
Yep. the latter. |
14:54 |
jeff |
0.92.0 2013-01-16T00:41:07Z |
14:54 |
jeff |
* Added `isnt_empty()` to ensure that a query does not return the empty set. |
15:00 |
csharp |
jeff: once I'm out of the woods of our 2.5 upgrade (scheduled |
15:00 |
kmlussier |
jeff++ :) |
15:00 |
jeff |
csharp: step 1: log in to https://eg.example.com/jasperreports/ ;-) |
15:00 |
csharp |
...MLK weekend), I plan to set up jasperreports for PINES in a test instance |
15:01 |
* csharp |
would love that |
15:01 |
jeff |
csharp: great to hear! |
15:01 |
jeff |
(that you'll be experimenting) |
15:01 |
csharp |
yeah |
15:37 |
paxed |
dbwells: yeah, i just read the email |
15:43 |
eeevil |
dbwells: do you think you'll have a chance to look at the branch on https://bugs.launchpad.net/evergreen/+bug/1251353 soon? |
15:43 |
pinesol_green |
Launchpad bug 1251353 in Evergreen 2.4 "QP query generation is incorrect with two or more bool ops in a row" (affected: 1, heat: 6) [Undecided,New] |
15:50 |
dbwells |
eeevil: thanks for working on that bug. I have looked at the branch, but I have little hope of grasping what it is actually doing in the time I have for it right now. My plan is to push it into production and test it empirically, but not until after 5:00pm (in order to limit civilian casualties). |
15:52 |
eeevil |
dbwells: cool, and thanks |
16:01 |
|
kbutler joined #evergreen |
16:03 |
bshum |
Callender: Can you describe the situation you encountered that led to bug 1251424 ? |
16:05 |
Callender |
but for some libraries, that button would still be greyed out and you couldn't make a hold for yourself |
16:05 |
bshum |
Callender: In the staff client, that's expected I would think... unless you click the radio button to say "Place this hold for me (insert my name here)" |
16:05 |
Callender |
but if you first clicked the radio button for making it for another patron, and then clicked back to yourself, without ever even entering anything, then the place hold would open up |
16:05 |
bshum |
Or you keyed in a barcode that actually worked |
16:06 |
* bshum |
tests |
16:06 |
Callender |
it doesn't always do that though.. my test system and other systems I tested, you can go in and place hold for yourself just fine |
16:06 |
bshum |
Oh I see what you're saying now. |
16:06 |
Callender |
it was just certain circumstances that I couldn't re-create.. but it always happened for certain libraries.. it was a very weird bug |
16:07 |
Callender |
that change I made on launchpad, that fixed it across the board on systems I tested it on, and didn't seem to harm systems that weren't broken. I need someone though familiar with the code to kind of double check what I'm doing there |
16:09 |
bshum |
Yeah, I was able to reproduce the issue now. |
16:10 |
bshum |
The radio button starts with the placing hold for someone else. |
16:10 |
bshum |
But if you click on the option for placing a hold for the staff account itself |
16:10 |
bshum |
Sometimes it wouldn't change the color right away |
16:10 |
bshum |
Callender++ # the change works as you described. |
16:10 |
Callender |
ok, I'm glad you were able to see it.. beacuse this one drove me crazy for a little while :) |
16:10 |
bshum |
If memory serves, this probably affects 2.4 and 2.5 only |
16:15 |
bshum |
Your description confused me at first |
16:15 |
bshum |
Cause I thought maybe your change made the submit button always available again. |
16:15 |
bshum |
Which it shouldn't be. |
16:15 |
bshum |
But testing seems to bear out no issues on my end so far. |
16:16 |
Callender |
ahh ya, I see what you're saying. It wasn't so easy for me to describe |
16:18 |
bshum |
I'll tweak the commit message a bit to be more concise on what we're doing here. |
16:18 |
bshum |
Then I'll commit it through |
17:39 |
|
stevenyvr2 left #evergreen |
17:44 |
dbs |
alas, "[source,conf]" in the 2.5 release notes appears to be breaking PDF output? |
18:15 |
|
BigRig_ joined #evergreen |
18:22 |
pinesol_green |
[evergreen|Dan Scott] Add basic docs for testing with pgTAP - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3c86315> |
18:26 |
|
edoceo joined #evergreen |
19:06 |
|
hopkinsju joined #evergreen |
19:06 |
|
hopkinsju left #evergreen |