| 04:59 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:04 |
|
riot joined #evergreen |
| 05:22 |
|
wjr_ joined #evergreen |
| 07:35 |
|
rjackson-isl joined #evergreen |
| 10:51 |
Dyrcona |
csharp: offline circulation and manualupdate.html |
| 10:52 |
csharp |
argh |
| 10:52 |
Dyrcona |
cgi-bin/offline alias also gives a nice warning when you start Apache on trusty. |
| 10:52 |
Dyrcona |
I haven't tested if it still works, yet. I probably should. |
| 10:53 |
dbs |
krvmga: probably need to provide an example like http://pastebin.com/cxHyWbHC along with some example template overrides for the likes of config.tt2 |
| 10:53 |
Dyrcona |
I'm not sure it is a general Apache 2.4 problem. It may only be a problem with trusty. I saw it after upgrading, and I think bshum saw it with a fresh install. |
| 10:53 |
bshum |
Dyrcona: Ugh, I just saw that error now in the restart I issued |
| 10:56 |
bshum |
Dyrcona: I guess we should file and fix that too |
| 10:57 |
Dyrcona |
It could be something in my configs that is unusual. |
| 10:57 |
Dyrcona |
The upgrade was a mess. |
| 10:57 |
Dyrcona |
I also configured a Dancer app for NCIP testing, but I get that with or without that configuration in place. |
| 10:57 |
bshum |
Well, my clean install gets the same "warning" but yeah. |
| 10:58 |
Dyrcona |
Oh, if you get it clean, then we should do something about it. |
| 10:58 |
bshum |
Course it didn't start giving me that warning till I turned on CGI :) |
| 11:03 |
bshum |
Seems easier to just add cgi to the makefile for trusty to me if that gets us there ;) |
| 11:04 |
csharp |
short term, I agree with bshum, long term, I agree with Dyrcona to move off of CGI if those are the only two things using it |
| 11:06 |
Dyrcona |
I want to make sure offline circ works with 2.4 on trusty before we do much of anything. |
| 11:06 |
* Dyrcona |
jots that down to test later today or tomorrow morning. |
| 11:10 |
bshum |
Yeesh |
| 11:10 |
bshum |
Using the offline gets me skull/crossbone errors |
| 11:10 |
bshum |
Unable to retrieve sessions, unable to create sessions |
| 11:13 |
bshum |
Meh |
| 11:13 |
bshum |
No, it's just an undefined error |
| 11:13 |
bshum |
But yeah, not promising |
| 11:15 |
Dyrcona |
Well, I have 4 books that came in delivery this morning that I can use for a test. |
| 11:18 |
bshum |
014-07-14 11:17:39 trusty gateway: [cgi:error] [pid 4845] [client 10.129.129.3:40991] script not found or unable to stat: /usr/lib/cgi-bin/offline |
| 11:18 |
|
kbeswick joined #evergreen |
| 11:18 |
bshum |
Oops, slightly less/more than I was going to paste. |
| 11:22 |
Dyrcona |
ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/ |
| 11:23 |
Dyrcona |
jeff: tried "WITH" queries and UNION? |
| 11:24 |
bshum |
Dyrcona: Yep, I see that now. |
| 11:24 |
Dyrcona |
I would try disabling it and testing, but I started a database reload, so I'll have to wait an hour or two. |
| 11:25 |
bshum |
Dyrcona: Disabling meaning commenting out that script alias portion? |
| 11:25 |
bshum |
It looks like it gets turned on when we turn on CGI? |
| 11:25 |
* bshum |
is going to do some reading |
| 11:33 |
bshum |
Yeah, it was. This is new to me. |
| 11:33 |
Dyrcona |
Yep. |
| 11:35 |
Dyrcona |
bshum: You want to add a commit to run a2disconf to my namevirtualhost branch, or do you want it separate? |
| 11:35 |
csharp |
<pedantry>Ubuntu LTS releases are synced with Debian testing, not sid</pedantry> so... |
| 11:35 |
csharp |
@blame jessie |
| 11:35 |
pinesol_green |
csharp: jessie stole csharp's ice cream! |
| 11:35 |
bshum |
Dyrcona: Might as well just make that the "fix Ubuntu 14.04 apache nonsense" branch :) |
| 11:35 |
* Dyrcona |
stands corrected by csharp. |
| 11:38 |
bshum |
for m in $(DEB_APACHE_DISCONF); do a2disconf $$m; done; |
| 11:38 |
mrpeters |
have they tagged 2.6.2 yet? or still just the release uploaded to the site |
| 11:39 |
mrpeters |
s/they/we/ |
| 11:39 |
bshum |
And then setup new params for that |
| 11:39 |
bshum |
mrpeters: I know dbwells uploaded previews and mceraso tested them last week. But I don't know if/when they'll be moved to official. Probably just a minor thing to push all that through. |
| 11:39 |
bshum |
He's probably waiting for the right moment to strike |
| 11:40 |
Dyrcona |
bshum: Why don't you add that to my lp 1341013 branch and put it in collab? |
| 11:40 |
pinesol_green |
Launchpad bug 1341013 in Evergreen "NameVirtualHost deprecated in Apache 2.4" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1341013 |
| 11:40 |
mrpeters |
yeah, we use the tag from Git to build our debs |
| 11:41 |
* Dyrcona |
figures out a configuration to auto-build a trusty VM. |
| 11:47 |
bshum |
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/bshum/lp1341013_apache24_tweak |
| 11:47 |
bshum |
Dyrcona: Signed off on your commit and added the changes I think we'll need for mod CGI |
| 11:48 |
Dyrcona |
bshum: Cool. I will add your branch to my dev branch and build a test vm first thing after lunch. |
| 12:05 |
|
gsams joined #evergreen |
| 12:11 |
|
b_bonner_ joined #evergreen |
| 12:15 |
|
hbrennan joined #evergreen |
| 12:46 |
csharp |
yeah - that includes us :-/ |
| 12:47 |
csharp |
same with open-ils.auth_proxy - should be a module |
| 12:47 |
dbs |
isn't it a module? |
| 12:48 |
Dyrcona |
I find the reason for the stripe failure to be humorous: The tests are broken by later versions of Perl. The module itself, still works. |
| 12:48 |
csharp |
dbs: I was told a while back that it was effectively non-disable-able |
| 12:48 |
csharp |
so we live with the constant log errors that look just like errors we would actually care about ;-) |
| 12:49 |
dbs |
csharp: oh, maybe from the TPAC side of things? |
| 16:36 |
bshum |
I wonder if that's SQL schenanigans more than bug in the staff client. |
| 16:36 |
bshum |
But I don't know what's being referred to specifically. |
| 16:38 |
|
kbeswick joined #evergreen |
| 16:42 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 16:43 |
bshum |
Huh |
| 16:43 |
phasefx |
psql:950.data.seed-values.sql:5019: ERROR: VALUES lists must all be the same length |
| 16:43 |
phasefx |
LINE 2124: ,('circ.use_lost_paid_copy_status', |
| 16:45 |
jeff |
tests++ |
| 16:52 |
Dyrcona |
Actually, I can fix that right quick. |
| 16:52 |
Dyrcona |
It's missing a ", null" at the end of the arguments. |
| 16:55 |
Dyrcona |
Any one have a problem with me pushing it? |
| 03:13 |
|
dreuther joined #evergreen |
| 04:57 |
|
mtate joined #evergreen |
| 05:03 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:44 |
|
b_bonner joined #evergreen |
| 06:44 |
|
mnsri joined #evergreen |
| 06:45 |
|
mtcarlson_away joined #evergreen |
| 07:48 |
|
jboyer-home joined #evergreen |
| 08:09 |
|
rjackson-isl joined #evergreen |
| 08:12 |
|
akilsdonk joined #evergreen |
| 08:13 |
jboyer-isl |
dbs++ ; Vacuum Analyze took care of the search timeouts on our migration testing server. Apparently when testing it’s no longer optional for us. Thanks! |
| 08:23 |
rjackson-isl |
dbs++ and jboyer-isl++ - now the next set of libraries migrating to EI can review initial data pull! :-) |
| 08:28 |
|
mrpeters joined #evergreen |
| 08:36 |
|
tspindler joined #evergreen |
| 15:21 |
* bshum |
is trying out the make_release dance for the first time |
| 15:21 |
bshum |
Entertaining! |
| 15:29 |
jeffdavis |
gmcharlt++ |
| 15:36 |
bshum |
Oh, yay, i18n dance at last |
| 15:36 |
bshum |
Figuring out all the dependencies was "fun" :) |
| 15:40 |
bshum |
So yeah, once the environment is setup right, this does seem easier than I recalled from our 2.0 days. |
| 15:46 |
|
mrpeters left #evergreen |
| 15:50 |
|
RoganH joined #evergreen |
| 15:56 |
bshum |
RoganH: Thanks for signing off on https://bugs.launchpad.net/evergreen/+bug/1198475 ; I'm planning to get a little more testing on that myself and then push it up to master next week |
| 15:56 |
pinesol_green |
Launchpad bug 1198475 in Evergreen "Support for Lost and Paid Status" (affected: 3, heat: 16) [Wishlist,Confirmed] |
| 15:56 |
RoganH |
bshum: I've been a bad tester but at least I got one in. I'm hoping to get another couple in tomorrow if it's quiet at work. |
| 15:56 |
bshum |
Unless someone else gets there first. |
| 16:16 |
tsbere |
jeff: I know of at least one SIP2 server app that prefers things in alphabetic order. <_< |
| 16:16 |
eeevil |
tsbere: which, as I'm sure you know, is /not/ the same as spec order for some messages :) |
| 16:16 |
jeff |
tsbere: which server? |
| 16:17 |
tsbere |
eeevil: For added fun, it blows up on any field it doesn't understand. |
| 16:17 |
tsbere |
jeff: Luckily it was just a test server for a PC reservation system, though the docs implied it was ripped out of an ILS and given a different database backend... |
| 16:17 |
eeevil |
tsbere: you have a strange sense of "fun", sir... ;) |
| 16:17 |
jeff |
@decide Standard Interchange Protocol or Binary Language of Moisture Vaporators |
| 16:17 |
pinesol_green |
jeff: have you tried local mean solar time for the named city as the reference point? |
| 16:33 |
jeff |
tsbere: does that take care of re-establishing a tunnel, or starting it automatically? The fact that putty-tunnel-manager claims to use plink makes me wonder if plink has those abilities on its own. |
| 16:33 |
bshum |
That's why I didn't catch it till now |
| 16:34 |
tsbere |
jeff: I wrapped it in a cmd file with a goto and helped libraries drop that into task scheduler. |
| 16:35 |
bshum |
Reverting that commit on my test server allows me to complete the make_release dance and get clients built. |
| 16:35 |
jeff |
tsbere: got it. thanks. |
| 16:37 |
jeff |
ah, and there's also http://www.bitvise.com/tunnelier |
| 16:39 |
jeff |
as well as MyEnTunnel and some other options referenced here: http://superuser.com/q/235395/9465 |
| 11:25 |
bshum |
If they're electronic records, then I'm even more concerned about how interconnected they might be. |
| 11:25 |
bshum |
Depending on what kind |
| 11:27 |
Dyrcona |
Then, you'll want to vaccuum full analyze the tables and put the rules and triggers back in place. |
| 11:28 |
bshum |
Well, in any case, just be careful how you identify which bibs to delete. And do it all on a test server a couple of times first. People have been known in the past to have removed their protections and then deleted the wrong bibs to dangerous consequences... |
| 11:28 |
Dyrcona |
Yep, that, too. |
| 11:29 |
bshum |
There's a decent number of instances in our IRC logs for those unhappy stories. |
| 11:31 |
Dyrcona |
IOW, unless you're going to get a major benefit from it, such as cutting your database by a significant %, I wouldn't bother. |
| 11:36 |
Dyrcona |
Deleted records also have the record status field set to 'd' if not already. |
| 11:36 |
Dyrcona |
However, if you're eliminating that many records. It might be worth it to try. It just won't be easy. |
| 11:37 |
asimon |
Dyrcona: TY |
| 11:39 |
Dyrcona |
asimon: Do you have a test/training database you can test it on? |
| 11:39 |
asimon |
Dyrcona: I'll use COPY (SELECT marc FROM biblio.record_entry WHERE deleted = 't') to a file and then convert the XML to MARC with yaz-marcdump. |
| 11:40 |
Dyrcona |
asimon: That sounds like it should work, thought it should already be xml. |
| 11:41 |
asimon |
Dyrcona: Yes, but I want MARC, not XMLMARC. |
| 12:07 |
jboyer-isl |
Self-signed, and I'm tunneling directly into the same LAN with an otherwise completely open machine. |
| 12:07 |
jeff |
tunneling how? you mentioned "direct connection" earlier. |
| 12:08 |
jboyer-isl |
Direct connection just means no load balancer, poor choice of words. The IP the name resolves to is the one running Apache and OpenSRF. |
| 12:10 |
mceraso |
dbwells: Just finished testing the maintanence release for 2.6.2 using Ubuntu LTS 12.04. It works well :) |
| 12:10 |
jboyer-isl |
Tunneled over SSH, though I'm testing a "normal" connection now also. |
| 12:11 |
jboyer-isl |
(It has a public IP) |
| 12:11 |
Dyrcona |
Added content? Could that be using https and the vendor doesn't support it? |
| 12:13 |
jboyer-isl |
I guess it's possible, I'll check. |
| 12:14 |
Dyrcona |
I've never seen searches be slow just over https, so I'm grasping. |
| 12:21 |
jboyer-isl |
Disabled added content to no effect, now we try the ages-old method of restart it and see. |
| 12:28 |
dbs |
jboyer-isl: tunneled over ssh with compression of the ssh tunnel enabled? |
| 12:28 |
dbs |
compression + encryption still shouldn't be that slow though. |
| 12:29 |
jboyer-isl |
dbs: Not that I'm aware of. I'm testing over a regular connection now just to avoid the possibility that it's tunnel related. |
| 12:29 |
jeff |
At the risk of sounding like SAPS, this could be an MTU issue. |
| 12:30 |
jeff |
It would be interesting to see if an HTTPS request for a small file (such as robots.txt) and an HTTPS request for a larger (ten meg or so) are any different from each other, and are any different from the searches. |
| 12:32 |
jboyer-isl |
Oh. It appears to be at least partially related to the hour+ long bib searches that were hung up on 4 of the postgres backends that serve that installation. I cleared that out and now it's returning results in the staff client again. |
| 14:35 |
dbs |
Did anyone drop or recreate indexes recently? |
| 14:35 |
dbs |
All sorts of potential problems. |
| 14:35 |
Dyrcona |
csharp++ bshum++ |
| 14:36 |
jboyer-isl |
The data is identical to production, we did a dump/restore, and ran a test migration. It's every search. |
| 14:37 |
jboyer-isl |
Osrf/Eg versions are also the same. |
| 14:38 |
Dyrcona |
Any problems with the restore? |
| 14:42 |
jboyer-isl |
The usual (rebuild those 2 authority indexes and the auditor schema since I didn't dump it) |
| 14:44 |
bshum |
remingtron++ # taking a look at bug 1210161 and it looks good. Testing the upgrade script and then I'll probably push that on in. |
| 14:44 |
pinesol_green |
Launchpad bug 1210161 in Evergreen "TPAC "my list" still referred to as "bookbag" in some places" (affected: 3, heat: 16) [Medium,Confirmed] https://launchpad.net/bugs/1210161 |
| 14:46 |
dbs |
jboyer-isl: oh, test migration == upgrade to newer version? |
| 14:46 |
jboyer-isl |
Dyrcona: Ah, and apparently all of config.z3950_index_field_map is missing. Is that table more important than it's z3950 prefix would suggest? |
| 14:47 |
jboyer-isl |
dbs: Nope, just adding a new lib. I've got another server for upgrade testing, it went great so far as I can tell though I don't have a client built for it yet. |
| 14:47 |
Dyrcona |
No, it isn't but I've had that happen seemingly randomly before. |
| 14:48 |
dbs |
ANALYZE run after the restore? |
| 14:48 |
bshum |
Calling 0884 |
| 16:57 |
jeffdavis |
it's aliiiiiiiive |
| 16:57 |
jeffdavis |
Someday I should get around to making that list of all the things I need to get around to doing. |
| 16:57 |
jeffdavis |
Finishing old half-finished bugfixes and new features, for example. |
| 17:01 |
bshum |
Hehe |
| 17:01 |
bshum |
eeevil++ # debian defender ;) |
| 17:01 |
bshum |
That's a fair clarification, I didn't quite word my part of that correctly. |
| 17:01 |
bshum |
I should have said we only officially test Ubuntu with that particular version. |
| 17:01 |
bshum |
But others are done as well. |
| 17:03 |
eeevil |
bshum: :) |
| 17:08 |
* dbs |
wades in with a hearty encouragement to use Fedora |
| 17:08 |
eeevil |
hrm... we need to get a debian 7 buildbot host going, and upgrade the live tester ... |
| 17:09 |
eeevil |
dbs: at least that still has a buildbot slave :( |
| 17:09 |
bshum |
dbs++ |
| 17:13 |
|
mmorgan left #evergreen |
| 17:20 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:29 |
bshum |
dbs: Ooh, just found http://stuff.coffeecode.net/2014/lld_preconference/search_engine_cse/ ... I will play through this one :) |
| 17:33 |
|
akilsdonk_ joined #evergreen |
| 17:40 |
sseng |
Question: anyone encountered this error when running osrf_control -l --stop-all? error is: Can't kill a non-numeric process ID at /openils/bin/osrf_control line 149. |
| 17:48 |
jeffdavis |
i.e. does one or more of those files contain an error msg or something, rather than a process id? |
| 17:49 |
Bmagic |
sseng: I have seen that error but it doesn't seem to matter for us |
| 17:50 |
sseng |
jeffdavis: Bmagic : unfortunately i ran the osrf_control with the --kill-with-fire option.... so no longer have access to those .pids with the errors....the good news running the usual --stop_all no longer produce that error! |
| 17:56 |
jeffdavis |
Seems likely that file perms/ownership were wrong on a pid file or the directory. osrf_control just does @pids = `cat $pid_file`; if cat gives an error like "permission denied" then @pids will contain the test of the error message. |
| 17:56 |
jeffdavis |
Anyway, glad it's working now. |
| 17:56 |
jeffdavis |
s/test/text/ |
| 17:57 |
sseng |
jeffdavis: yep, thanks a bunch, will look out for those in future! |
| 18:36 |
|
sseng joined #evergreen |
| 18:36 |
|
ktomita joined #evergreen |
| 09:12 |
krvmga |
csharp: yes, network issues ruled out |
| 09:14 |
csharp |
when I create a patron and save, it's about 5 seconds turnaround between clicking save and when the new page is fully loaded |
| 09:14 |
csharp |
we have 3 stat cats if that makes a difference |
| 09:15 |
krvmga |
csharp: just been testing loading/reloading; the quickest i can get the page is 7 seconds |
| 09:16 |
csharp |
krvmga: how many stat cats? and how many entries per stat cat? I can create a few and see if that adds to load time |
| 09:16 |
csharp |
rough estimate's fine |
| 09:17 |
krvmga |
csharp: two dozen |
| 12:15 |
gmcharlt |
jeff: in any event, the Win8.1 box in quetstion was indeed creating it locally |
| 12:15 |
bshum |
gmcharlt: Done. |
| 12:16 |
gmcharlt |
jeff: thanks for the catch |
| 12:17 |
jeff |
you're welcome! without a win8.1 box handy to test on, I can't say if it mattered or not. :-) |
| 12:17 |
jeff |
(with windows being so spotty with regard to file case) |
| 12:18 |
pinesol_green |
[evergreen|Galen Charlton] LP#1339767: follow-up: Thumbs.db, not Thumbs.DB - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=694d4fa> |
| 12:20 |
Dyrcona |
heh. |
| 12:24 |
jcamins |
jeff: I didn't know there was a global gitignore. |
| 13:42 |
bshum |
tsbere: Aha, okay, maybe that's what I'll check |
| 13:42 |
jeff |
the sip user will need the required override permission. |
| 13:43 |
tsbere |
bshum: Treat the SIP users as staff client users for the most part. Thus any permission a staff user might need to accomplish something SIP will likely also need. |
| 13:45 |
bshum |
tsbere++ jeff++ # thanks guys, we'll test and hopefully that'll be the end of that question |
| 13:58 |
gmcharlt |
jeff: no objection either |
| 14:30 |
|
ningalls joined #evergreen |
| 15:00 |
csharp |
bshum: I created a signoff branch for my ubuntu 14.04 makefile updates -FYI |
| 15:01 |
csharp |
see bug 1315531 for details |
| 15:01 |
pinesol_green |
Launchpad bug 1315531 in Evergreen "Need Ubuntu 14.04 Trusty Makefile target for Evergreen" (affected: 1, heat: 6) [Wishlist,Confirmed] https://launchpad.net/bugs/1315531 |
| 15:01 |
bshum |
csharp: Oh excellent. I'll take a look over that too |
| 15:01 |
csharp |
thanks - I was just trying to update my test box to current master, but couldn't because those commits aren't in yet ;-) |
| 15:05 |
|
ldw joined #evergreen |
| 15:06 |
jboyer-isl |
some quick followup for any interested parties: I've fed the same production 1-hour pg log through pgbadger and pgfouine and there's no comparison. pgfouine took 14 minutes to parse it, missed over 2000 queries, and doesn't give nearly the information pgbadger can. |
| 15:07 |
jboyer-isl |
It doesn't hurt that pgfouine is also hard to look at and pgbadger looks rather nice. |
| 15:23 |
bshum |
So if it was me, I would disable autosuggest, then tweak the template like I did in the file to re-enable dojo. |
| 15:23 |
bshum |
At least till we get deeper with code cleanup / removal / rewriting |
| 15:25 |
jboyer-isl |
bshum: ah, that does look more like it. If we end up turning off autosuggest I'll definitely be doing that. |
| 15:25 |
bshum |
In our case, dojo is turned on because of other config choices we made |
| 15:25 |
bshum |
Like using Google Books |
| 15:25 |
bshum |
Or Novelist |
| 15:26 |
bshum |
So I didn't catch that issue in my original testing when we wrote the patch to disable autosuggest by default. |
| 15:46 |
|
kbeswick joined #evergreen |
| 15:53 |
|
ldw joined #evergreen |
| 16:02 |
|
dMiller_ joined #evergreen |
| 16:40 |
|
rangi joined #evergreen |
| 16:55 |
Bmagic |
jeff: The error I was getting turned out to be due to the required SSL redirect when accessing /reporter. PP was configured to talk to the app servers on port 80 in the backend no matter what. They 301 redirected the clients to talk to port 443. PP answered, and talked to the app servers on 80 again. rinse and repeat |
| 16:56 |
jeff |
redirect loop. |
| 17:04 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:04 |
|
kbeswick joined #evergreen |
| 17:06 |
|
mmorgan left #evergreen |
| 17:41 |
pinesol_green |
[evergreen|Yamil Suarez] Documentation: added AsciiDoc version of old SIP docs from EG 1.6/2.0 docs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=df806b4> |
| 17:41 |
pinesol_green |
[evergreen|Yamil Suarez] Documentation: updated some SIP content - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5f75319> |
| 17:42 |
bshum |
yboston++ gmcharlt++ |
| 17:42 |
gmcharlt |
yboston++ bshum++ |
| 19:28 |
|
hbrennan joined #evergreen |
| 03:09 |
|
gsams joined #evergreen |
| 04:14 |
|
dcook joined #evergreen |
| 04:50 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 08:01 |
|
jboyer-home joined #evergreen |
| 08:06 |
|
rjackson-isl joined #evergreen |
| 08:21 |
|
dkyle left #evergreen |
| 10:16 |
|
dkyle joined #evergreen |
| 10:39 |
* dbs |
ponders adding a robots.txt.example like http://laurentian.concat.ca/robots.txt to the default install (.example to avoid blowing away existing ones) |
| 10:41 |
Dyrcona |
Ours is a sledgehammer: Disallow: / |
| 10:42 |
phasefx |
btw, that qatests failure, seems like a race condition: http://testing.evergreen-ils.org/~live/test.46.html Unable to retrieve settings from settings server, retrying.. and it looks like it succeeds on the retry |
| 10:42 |
Dyrcona |
phasefx: fwiw, we see a similar message with action triggers from time to time. |
| 10:43 |
Dyrcona |
except it reports, "going to sleep" |
| 10:43 |
dbs |
Dyrcona: huh. given a sitemap like https://bugs.launchpad.net/evergreen/+bug/1330784 and a decent robots.txt, wouldn't you want search engines to index your bib records and holdings? |
| 15:31 |
dbwells |
bshum: My best recollection is that I kept the code as targetted as possible in selecting eligible copies to reduce risk of bugs causing damage. I could imagine it being expanded to include other statuses, probably as a waterfall (e.g. In process, first, then On-order if no In process copies exist). |
| 15:34 |
dbwells |
I'm also not understanding an acq workflow where the receive step gets skipped, but I'm probably not being creative enough :) |
| 15:35 |
dbwells |
If your workflow is such that you can use copy ID as an overlay, I'd say that's much better overall. |
| 15:39 |
bshum |
Yeah I think that might be the way to go in this case. Course the fun part is figuring out the PO JEDI template entries. |
| 15:53 |
bshum |
Strange |
| 15:53 |
bshum |
copy_id => lid.id, # for INC_COPY_ID |
| 15:53 |
bshum |
So it sets the copy_id to the lineitem ID in the EDI template if we include copy data |
| 15:54 |
bshum |
But the label for the entry is copy_id |
| 15:54 |
bshum |
That's weird looking. |
| 15:54 |
bshum |
Maybe this is a weird interaction with whichever vendor was first testing the EDI GIR stuff? |
| 15:56 |
bshum |
Or maybe something to do with electronic invoicing? |
| 15:56 |
bshum |
Sigh... |
| 15:56 |
bshum |
@hate acq |
| 15:56 |
pinesol_green |
bshum: But bshum already hates acq! |
| 15:57 |
bshum |
Hmm |
| 15:58 |
bshum |
Or we add a part to the EDI message for eg_copy_id to pass the copy ID direct |
| 16:51 |
|
patrick left #evergreen |
| 16:54 |
|
pgardella joined #evergreen |
| 17:17 |
|
mmorgan left #evergreen |
| 17:23 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:28 |
|
gsams joined #evergreen |
| 19:02 |
|
vlewis_ joined #evergreen |
| 04:54 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:09 |
|
berickm joined #evergreen |
| 07:38 |
bshum |
@later tell eeevil Hmm, wondering on the performance speed of record_attr_flat when there ends up being lots of uncontrolled_record_attr_value to look for. I'm getting truly terrible query performance on things like "SELECT COUNT(*) FROM metabib.record_attr_flat WHERE attr = 'oclc'" (our custom definition for tag 001) vs. looking for something that is in vlist like 'search_format' |
| 07:38 |
pinesol_green |
bshum: The operation succeeded. |
| 07:47 |
bshum |
My end goal was to figure out how many bibs still need to be reingested with our custom record attribute. Generally counting from uncontrolled, I can quickly find out, but I couldn't use that to narrow exact bib IDs of what remains. |
| 07:48 |
bshum |
We've had to do them in small spurts cause it has been taking terribly long to reingest the one field. |
| 09:28 |
* dbs |
overlooked the "k" in those measurements at first |
| 09:28 |
eeevil |
bshum: I don't want to sound flippant, but that's not a use case that the software itself cares about. we can't make every single query fast, there will always be ones that could be faster if we changed the shape of the data, but that would in turn slow down some other query. the question "how many records don't have this uncontrolled attribute, globally" is not something that needs to be fast, because it's not something we'd put into, say, a |
| 09:28 |
eeevil |
search result or a checkout api call |
| 09:30 |
eeevil |
bshum: that query (and ones like it) are at the opposite end of the spectrum from how that view is used by the software and how they're designed to be used |
| 09:36 |
eeevil |
bshum: now, if you just wanted to know the count, you could likely make things faster by restructuring your query to build an array of the ids of the values from uncontrolled_record_attr that are used as oclc number, and test record_attr_vlist with the overlaps operator. or, a different tactic is to just join record_attr_vlist on uncon_record_attr with (vlist @> intset(un_rec_attr.id) and un_rec_attr.attr=$oclc_attr_def_id) ... that would be |
| 09:36 |
eeevil |
doing what the view does for exactly the one attr |
| 09:44 |
eeevil |
think of it this way, everything that lives in the metabib schema has a very targetted purpose that is /not/ storing data. that schema is, by design, a dumping ground for specific denormalizations of central, authoritative data, and each table and view is intentionally shaped so that its primary purpose (search record attributes, backing tsearch queries, turn one record's attribute-int-arrays back into something a human can use) is as fast as |
| 09:44 |
eeevil |
possible. all other purposes (that is, "how X performs in arbitrary queries") are, at best, secondary concerns, because if we need some other purpose or use case to be fast we can trade a little more disk space for that speed |
| 09:45 |
eeevil |
and, the use case for record_attr_flat is "give me the attribute names and values for this record (or some small set of records)" |
| 09:46 |
* eeevil |
disappears in a puff of uncontrolled smoke |
| 10:45 |
bshum |
eeevil++ |
| 10:46 |
bshum |
Thanks for the rundown. I understand what you're saying here. And appreciate the suggestion on ways of answering the question via database approaches |
| 10:47 |
bshum |
I'll tinker more with it once we finish moving our servers. |
| 14:42 |
remingtron |
berick: thanks. we're hoping to start drafting docs for the web staff UIs as development continues |
| 14:43 |
remingtron |
any comments on which UIs are most "stable" at this point? |
| 14:43 |
remingtron |
or ones to wait on? |
| 14:43 |
berick |
remingtron: this is the best general source -> http://evergreen-ils.org/dokuwiki/doku.php?id=dev:browser_staff:dev_sprints:1 -- however, given that none of these have been thorougly tested, "stable" is a relative term |
| 14:44 |
berick |
anything marked through is feature complete within the realm of the current "sprint" -- that is, there are missing features, but they will be done later |
| 14:46 |
berick |
documenting basic stuff, like login, the splash page, the nav bar, etc. is a good start. then moving on to simpler interfaces -- ones that are less likely to change -- is a good next step |
| 14:47 |
berick |
having said that, though, I have a hard time thinking of tnese UIS will change *drastically* regardless of bugs or missing features |
| 14:47 |
berick |
since they all mimic the XUL client very closely |
| 14:48 |
berick |
hmm, smells like hurricane outside |
| 14:48 |
csharp |
berick: are you in the storm's path? |
| 14:49 |
remingtron |
berick: thanks for the advice, feel free to run and board up the windows if needed |
| 14:49 |
berick |
csharp: just the outer swirly bits. we'll get rain and modest wind. |
| 15:19 |
csharp |
my patch http://git.evergreen-ils.org/?p=evergreen/pines.git;a=blobdiff;f=Open-ILS/src/templates/opac/parts/record/copy_table.tt2;h=c0fbbd2c98b08ca26cd9537b42e21584e464dc80;hp=c29a0171f94c3f4e526dae5cfd651a65d5de9d1d;hb=af5b18ef988dfe2b21f536dd963737a030801899;hpb=c5ee6b43f566ea65b3361cc8a4056edc1c32bbd8 |
| 15:19 |
dbs |
So it could be a bug in RDFa Play |
| 15:19 |
csharp |
oops - dead link |
| 15:19 |
bshum |
dbs: My quick googling finds me the LP bug where we chatted about the testing tool and its quirks :) |
| 15:19 |
csharp |
http://git.evergreen-ils.org/?p=evergreen/pines.git;a=commit;h=af5b18ef988dfe2b21f536dd963737a030801899 - this works |
| 15:19 |
csharp |
(for the logs) |
| 15:20 |
dbs |
bshum: Well, there are different testing tools, each with their own quirks |
| 15:20 |
bshum |
No doubt. |
| 15:22 |
dbs |
yeah, nevermind. As weird as that markup is (really? a div for hold counts that wraps the copy table?) that's not the issue with RDFa Play |
| 15:22 |
dbs |
RDFa Play gets sulky about circular references and refuses to play in that case. And we have one of those in standard markup. |
| 16:29 |
jeff |
there may be permissions required and there's certainly at least one org unit setting that you'll want to verify for this use case -- reset request time on hold uncancellation or somesuch. |
| 16:30 |
|
tspindler left #evergreen |
| 16:50 |
|
ningalls joined #evergreen |
| 17:11 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:16 |
yboston |
@marc 024 |
| 17:16 |
pinesol_green |
yboston: A standard number or code published on an item which cannot be accommodated in another field (e.g., field 020 (International Standard Book Number), 022 (International Standard Serial Number) , and 027 (Standard Technical Report Number)). The type of standard number or code is identified in the first indicator position or in subfield $2 (Source of number or code). (Repeatable) [a,c,d,z,2,6,8] |
| 17:19 |
hopkinsju |
Thanks jeff++ |
| 02:49 |
|
DPearl joined #evergreen |
| 05:13 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 08:02 |
|
rjackson-isl joined #evergreen |
| 08:13 |
|
collum joined #evergreen |
| 08:15 |
|
krvmga joined #evergreen |
| 14:39 |
kmlussier |
Under using the OPAC? |
| 14:39 |
remingtron |
yboston: good point, we don't want to release any docs before the web interface is released |
| 14:39 |
yboston |
I am sorry, under "using the staf client" |
| 14:39 |
kmlussier |
Ok, that sounds better. :) |
| 14:40 |
kmlussier |
I'm worried that things may still change as people offer feedback and testing begins. |
| 14:40 |
yboston |
in theory we could do it as part of an index with warnings that this is pre-release features or we can in theory create a new Git branch for syaf client documentation to be merged later? |
| 14:41 |
remingtron |
yeah, we could work in a collab branch and update things if they change |
| 14:41 |
yboston |
BTW, kbutler I see your email now |
| 14:57 |
yboston |
I can send an email to the list to slect amonst ourselves some older features to work on, hopefull we can get newcomers involved too |
| 14:58 |
remingtron |
yboston: yeah, let's focus on older features and web staff client updates now, then hopefully switch to new features as they come |
| 14:58 |
yboston |
OK |
| 14:58 |
kmlussier |
yboston: This list will give you an idea of what might be eligible for 2.7 http://bit.ly/1qyGrOx |
| 14:59 |
kmlussier |
But until the code is tested, I don't think there's any guarantee that anything will definitely make the cut. |
| 14:59 |
yboston |
thanks |
| 14:59 |
yboston |
kmlussier: yes, without testing nothing should be guranteed |
| 15:00 |
kmlussier |
So should we each commit to 1 to 3 features from the 2.5 list between now and the next meeting? |
| 15:00 |
yboston |
you read my mind |
| 15:00 |
* kmlussier |
is psychic. :) |
| 16:31 |
|
kmlussier1 joined #evergreen |
| 16:35 |
|
tspindler left #evergreen |
| 16:37 |
|
ningalls joined #evergreen |
| 16:56 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 16:58 |
|
kbutler_ joined #evergreen |
| 17:13 |
|
mmorgan left #evergreen |
| 17:15 |
|
kmlussier left #evergreen |
| 09:34 |
|
yboston joined #evergreen |
| 09:37 |
|
kmlussier joined #evergreen |
| 09:56 |
|
krvmga joined #evergreen |
| 09:57 |
krvmga |
when a patron is logged into the opac, is there a limit on how many items will be displayed in the Current Items Checked Out screen? |
| 09:58 |
krvmga |
a patron has told me he can only see 15 when he has over 30 checked out. i just tested it (checked out 37) and see all 37 in one screen. |
| 10:01 |
jeff |
krvmga: holds are paged at 15 now, i believe. if you have old templates, you won't have the right paging logic and you'll only be able to see 15. |
| 10:02 |
jeff |
krvmga: checked out items might be using the patron's search result preference? dunno. i haven't encountered the issue you describe, and haven't taken a moment to look at the code just now. |
| 10:03 |
krvmga |
i did my test with a dummy user. search results set to 10 per page. |
| 10:04 |
kmlussier |
krvmga: Did you verify that this patron does indeed have 30+ items checked out? |
| 10:05 |
krvmga |
kmlussier: yes, he currently has 32 out |
| 10:06 |
jeff |
mosh++ |
| 10:07 |
|
tspindler left #evergreen |
| 10:09 |
kmlussier |
krvmga: If you can see 30+ on the current items checked out screen and another user can't, my first guess would be differences in the files on your brick heads. Or maybe the patron is looking at another screen, not the current items checked out screen. |
| 10:09 |
kmlussier |
For example, I think the "my lists" screen used to limit the user to 15 titles. Or maybe it was 10. |
| 10:12 |
krvmga |
kmlussier: i just tested the display from all five brickheads. the 37 items in my dummy account show up on all of them. |
| 10:12 |
krvmga |
kmlussier: i think it was 10 |
| 10:13 |
* jeff |
nods |
| 10:13 |
krvmga |
this is exactly what the patron wrote to me: |
| 10:13 |
krvmga |
I regularly have more than 30 items checked out at a time, as well as many requests. In order to navigate to the second page of my Checked Out items (items number 16 and above), I have to go to the second page of items On Hold; then the second page of my items Checked Out appears. But if I have over 30 items checked out, I cannot see more than the first 30; the final 6 of today's Checked Out items do not display. If after look |
| 11:01 |
|
krvmga joined #evergreen |
| 11:03 |
kmlussier |
krvmga: I think I may have found something. |
| 11:03 |
kmlussier |
krvmga: If you start off on the second page of holds, and then clicked "Checked Out" in the patron dashboard, the paging linnks will persist. |
| 11:08 |
krvmga |
yes, i see that. i had tested only from the tabbed interface. |
| 11:08 |
kmlussier |
That is, the paging limiters. |
| 11:08 |
kmlussier |
I'll see if I can push a fix for it this afternoon. |
| 11:48 |
|
jtaylor__ joined #evergreen |
| 17:08 |
|
mmorgan left #evergreen |
| 17:11 |
Bmagic |
kmlussier: I dont get that message on our production environment (2.6.1). I also do not see it on our 2.4.1 installation |
| 17:14 |
bshum |
Bmagic: I think kmlussier found the library setting she needed to enable in order to get the message to appear. For the logs, it is in the OPAC category, called "Warn patrons when adding to a temporary book list" |
| 17:15 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:15 |
Bmagic |
bshum: right on |
| 17:16 |
Bmagic |
I have a question as well. One of our catalogers has noticed a difference of behavior from 2.4.1 to 2.6.1. When cataloging a new marc record with fast item add, after the item details window opens, and you "Modify Copies" - the main window DOES NOT refresh and show the newly imported bib. |
| 17:22 |
Bmagic |
Looking at the code, I dont see any differences in volume_copy_editor.js or volume_editor.js between 2.4.1 and 2.6.1, any thoughts? |
| 01:15 |
|
zerick joined #evergreen |
| 04:09 |
|
gsams joined #evergreen |
| 04:16 |
|
berickm joined #evergreen |
| 04:45 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:11 |
|
collum joined #evergreen |
| 07:15 |
|
kbeswick joined #evergreen |
| 07:48 |
|
rjackson-isl joined #evergreen |
| 09:30 |
kmlussier |
eeevil: Following up on my question from yesterday, I have a record with 2 Located URI's: one for MBI and one for MCD. I set my preferred search library to MCD (not the system). I search the consortium and see both links as expected on https://jasondev.mvlcstaff.org/eg/opac/record/1554276, but MBI is still appearing first. |
| 09:30 |
kmlussier |
In this case, it should be showing the preferred library, MCD, right? |
| 09:30 |
kmlussier |
That is, it should be showing the preferred library first. |
| 09:33 |
eeevil |
kmlussier: that's what I would expect from the code in the repo, and what noble saw in testing ... let me see if we still have the test server up with that (though ALA has removed most of my human resources for things like knowing where an old test server might be ...;) ) |
| 09:33 |
|
ldw joined #evergreen |
| 09:34 |
kmlussier |
eeevil: OK, thanks. I could probably take a look on noble's server too. |
| 09:42 |
jeff |
in some ways, asset.copy rows are like tree rings. |
| 11:18 |
Bmagic |
As far as I can tell, our database has never had this function, oddly enough, it didnt seem to matter, all of the vandelay stuff worked. Looking back at the sql upgrade scripts, the last time it was introduced was 0738 around version 2.2.3 |
| 11:51 |
csharp |
Bmagic: right - I found that too - it didn't make it into any upgrade scripts (on the paths I've taken, anyway) |
| 11:51 |
Bmagic |
csharp: You don't have it in your production database either? |
| 11:51 |
csharp |
correct |
| 11:52 |
csharp |
but... we don't really use Vandelay at this point - we found it when testing acq record import |
| 11:53 |
Bmagic |
csharp: weird, the situation here is: we upgraded to postgres 9.2 using pg_dump evergreen instead of pg_dumpall, Vandelay was working just fine before the upgrade. Now, postgres is complaining about the 2 argument function not existing. Odd, but if I use pg_dumpall, it works fine...... puzzle anyone? |
| 11:53 |
csharp |
hmmm |
| 12:01 |
jboyer-home |
Bmagic: what are the flags you’re using for dump and dumpall? |
| 12:02 |
Bmagic |
pg_dump evergreen > db1_pgdump.sql |
| 12:03 |
Bmagic |
and that is what is in production now.... later, after finding that vandelay wasn't working. I used pg_dumpall -o > pgdumpall.sql |
| 12:04 |
Bmagic |
After testing the restore on a dev box from the dumpall, the vandelay is working (even without the 2 argument function) |
| 12:08 |
jboyer-home |
They were getting errors whether they tried to use match sets or not? |
| 12:10 |
hopkinsju |
jboyer-home: Yes, but the funny part is, if you dont' specify an import queue the import *does* work. It goes into a queue that gets labeled "-" |
| 12:15 |
jboyer-home |
Does this return anything on either system? select * from vandelay.queue where match_set is not null; |
| 15:03 |
jcamins |
jeff: I seem to recall the BOFH pioneering that feature. |
| 15:19 |
jeff |
assuming there's an account or two found, it makes it far less important to worry about getting the proper spelling of their name. |
| 15:34 |
|
akilsdonk_ joined #evergreen |
| 15:35 |
pinesol_green |
[evergreen|Kathy Lussier] Documentation for Located URI Visibility - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d5eb3a3> |
| 15:44 |
|
eeevil joined #evergreen |
| 15:44 |
|
Callender joined #evergreen |
| 16:04 |
|
tspindler left #evergreen |
| 16:57 |
|
tsbere_ joined #evergreen |
| 16:58 |
|
dreuther joined #evergreen |
| 17:10 |
|
mmorgan left #evergreen |
| 17:18 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:23 |
|
akilsdonk joined #evergreen |
| 17:25 |
|
jcamins_ joined #evergreen |
| 17:31 |
|
shadowsp1r joined #evergreen |
| 02:15 |
|
gmcharlt joined #evergreen |
| 02:46 |
|
eeevil joined #evergreen |
| 04:05 |
|
Jane_ joined #evergreen |
| 05:04 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:22 |
Jane_ |
Hi guys.. I still have problem in check out item |
| 05:22 |
Jane_ |
sigh..... pplease help |
| 05:23 |
rangi |
Jane_: have you tried the mailing list? it might work better |
| 14:18 |
bshum |
It's on my very long to-do list to think about whether we're keeping ldirectord with Ubuntu and try it with 14.04. |
| 14:18 |
bshum |
When we did it with 12.04, it didn't work because the packaged version had bugs in it |
| 14:19 |
bshum |
So our load balancer VM is actually Debian |
| 14:19 |
hopkinsju |
bshum: No. We weren't actually planning on replacing it last night, but because we missed the lo:0 part of the network config on the app servers we tried to stand up a pound proxy we'd been testing with. |
| 14:19 |
hopkinsju |
That worked like a charm, except that we couldn't find a way to route the SIP traffic with pound. |
| 14:19 |
bshum |
Aha, interesting. |
| 14:20 |
jeff |
pound won't help with sip traffic. |
| 14:20 |
hopkinsju |
Yeah, from what we can tell pound is totally and exclusively for http/s traffic. |
| 16:07 |
* bshum |
doesn't use hold ratios |
| 16:07 |
bshum |
(and has no clue how those operate) |
| 16:08 |
silva |
wait let me screenshot again my configuration |
| 16:08 |
kmlussier |
I'm trying to remember how the holds ratios work, but I do know that we were testing them to be set at 1. |
| 16:09 |
kmlussier |
OK, I looked it up here: http://markmail.org/message/wy6d7cvhcwrvi3tq |
| 16:09 |
kmlussier |
silva: You basically are saying you need 25 total copies for each hold on that title for a renewal to go through. I don't think that's what you want. |
| 16:10 |
silva |
The faculty suggest that. |
| 16:11 |
kmlussier |
silva: I don't know how many copies you typically have on a title, but that rule is going to make it hard for any renewal to go through if there is an existing hold on the record. |
| 16:12 |
bshum |
Like if you only have one or two copies of a book, you'd never be able to renew the item because the copy/hold ratio is way above it at 25? |
| 11:06 |
kmlussier |
My favorite is Marvin the Martian. :) |
| 11:06 |
phasefx2 |
:D |
| 11:07 |
phasefx2 |
for Hanna-Barbera, Scooby Doo |
| 11:13 |
kmlussier |
I like Scooby Doo. I was also partial to Tom & Jerry. |
| 11:14 |
kmlussier |
I'm looking at the LP bugs with a signedoff tag. Some of those bugs have had signoffs for a few months now. |
| 11:14 |
kmlussier |
I'm wondering if there is a way to expedite review of those bugs since they have already gone through one round of testing from somebody in the community. |
| 11:23 |
bshum |
kmlussier: In theory that's something that I ought to poke at with other core committers. |
| 11:23 |
bshum |
I like to think it'll be quieter after ALA next weekend. |
| 11:24 |
jeff |
kmlussier: mentioning them here might be a good start. how many are you talking about? |
| 11:25 |
kmlussier |
http://bit.ly/1v1UGZD |
| 11:26 |
kmlussier |
The Lost and Paid one was just recently signed off and the MFHD one wasn't too long ago. But the others have been around for a while. |
| 11:27 |
bshum |
Championing bugs that are important to you is a good thing. We do our best, but there are so many hours in the day after all :) |
| 11:29 |
kmlussier |
True. One of the ways I try to champion bugs is to do some of the leg work in testing and signing off on them. ;) |
| 11:29 |
bshum |
kmlussier: Definitely, and we thank everyone for helping with signoffs :) |
| 11:33 |
|
gsams joined #evergreen |
| 11:50 |
|
ericar joined #evergreen |
| 16:56 |
|
bshum joined #evergreen |
| 16:56 |
|
mceraso joined #evergreen |
| 17:10 |
|
mmorgan left #evergreen |
| 17:21 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 18:34 |
|
kmlussier joined #evergreen |
| 20:18 |
|
gsams joined #evergreen |
| 22:00 |
* jeff |
yawns |
| 02:29 |
|
jeff_ joined #evergreen |
| 05:10 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:02 |
|
gmcharlt joined #evergreen |
| 06:54 |
|
Callender joined #evergreen |
| 07:36 |
|
collum joined #evergreen |
| 09:20 |
|
yboston joined #evergreen |
| 09:48 |
kmlussier |
Good morning all! |
| 09:51 |
jeff |
morning! |
| 09:53 |
kmlussier |
I'm curious abotu berick's code at bug 1308239. We had tinkered with the idea of using precats for ILL's from our statewide system, but in my testing, I found that Evergreen won't allow me to check out an existing precat. |
| 09:53 |
pinesol_green |
Launchpad bug 1308239 in Evergreen "Support targeting and fulfillment of precat copy holds (for ILL)" (affected: 1, heat: 6) [Wishlist,New] https://launchpad.net/bugs/1308239 |
| 09:53 |
kmlussier |
I'm wondering if that code would fix that issue. |
| 09:54 |
jeff |
I'm pretty sure we've had libraries that used precats for ILL, but I'm not certain of their workflow. They may not have been capturing and using the system for notification -- they might just have been calling the patron then checking out the item as a pre-cat (using the originating library's barcode, which is one of the reasons they moved away from that). |
| 09:56 |
|
krvmga joined #evergreen |
| 09:56 |
jeff |
I have interest in that feature / bugfix. I'm not grabbing the bug now, but will try to review when I can. |
| 09:56 |
kmlussier |
Our preference is to use precats, because the alternative is to use brief bib records that automatially deleted when the item is returned. But then it fills up the database with all of these deleted bib records. |
| 09:56 |
jeff |
kmlussier: That behavior is surprising, but I haven't tested it. |
| 09:57 |
krvmga |
we just upgraded to 2.5 and i'm getting complaints about the labeling of icons in search returns. i've been looking around but i can't see where to fix/alter the labels. anyone know off hand? |
| 09:57 |
jeff |
Yeah, we do that now with NCIP. It's not ideal compared with precats. |
| 09:57 |
jboyer-home |
I don’t know if ILL handling is consistent across Evergreen Indiana, but I know at my previous library they used the OCLC ILL number as the barcode, so there wasn’t a problem with re-using barcodes like that, then to keep things tidy the pre-cats are deleted later. |
| 13:53 |
jeff |
krvmga_: both both the ten and thirteen are there. |
| 13:54 |
krvmga_ |
jeff: since we started talking about it, one of our catalogers overlaid the record. :) |
| 13:54 |
krvmga_ |
she just told me. |
| 13:55 |
jeff |
the perils of testing theories on live systems. :-) |
| 14:00 |
|
DPearl1 joined #evergreen |
| 14:00 |
|
tspindler joined #evergreen |
| 14:01 |
|
krvmga_ joined #evergreen |
| 14:04 |
|
kbeswick_ joined #evergreen |
| 14:07 |
jeff |
Business::ISBN does the right thing and returns undef when you call as_isbn10 on a 979 isnb13 :-) |
| 14:13 |
jeff |
OpenILS::WWW::AddedContent::Amazon might fail on the 979 isbn13s, but probably not in a way that impacts anything else. |
| 14:19 |
|
bmills joined #evergreen |
| 14:23 |
|
tspindler left #evergreen |
| 14:23 |
|
tspindler joined #evergreen |
| 16:21 |
rangi |
the whole district has a pop of 30k .. its quite an amazing story really |
| 16:25 |
kmlussier |
I love seeing libraries that do so much to engage with their communities. Almost makes me wish I were working in a library again. Almost. |
| 16:32 |
|
tspindler left #evergreen |
| 16:53 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:04 |
phasefx2 |
bbl |
| 17:18 |
jeffdavis |
When upgrading a standalone db server from 2.4->2.6, it looks to me like there are no new dependencies that need to be installed. Can anyone confirm that? |
| 17:20 |
bshum |
jeffdavis: I haven't found anything specific yet. Though I think I did find that one of the upgrade scripts required an extra deb than before for me to run it on a fresh standalone DB. |
| 01:14 |
|
remingtron_ joined #evergreen |
| 01:14 |
|
dbwells_ joined #evergreen |
| 05:12 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:41 |
|
berickm joined #evergreen |
| 06:42 |
|
Callender joined #evergreen |
| 07:47 |
|
rjackson-isl joined #evergreen |
| 15:15 |
jboyer-home |
Bmagic: How many concurrent bibs is your parallel reingest running vs. the number of cores in your db? Depending on how hard it’s working, you may be pushing all of the necessary data out of cache and the db can’t keep up with searching and reingesting without the request timing out. We’ve had that problem during past upgrades. |
| 15:15 |
jboyer-home |
If you can eventually get results by performing the same search repeatedly that’s likely what’s going on. |
| 15:16 |
Bmagic |
jboyer-home: If we take the reingest out of the equation - the opac still does not return results. Which is what prompted me to do the ingest. I was thinking that perhaps I needed to reingest in order for the search results to start working. Is that right? |
| 15:18 |
jboyer-home |
Depends on how much of an upgrade you did and how much the search has changed. It’s possible that pre-reingest things can’t work, or it could also be that a cold start on your db takes a while to get runnning. (I think I have a 2.6 DB sitting around that hasn’t been reingested, but I don’t have any opensrf services pointing at it yet to test) |
| 15:24 |
|
gsams joined #evergreen |
| 15:26 |
|
vlewis joined #evergreen |
| 15:32 |
Bmagic |
jboyer-home: my current theory is the 9.1 -> 9.2 is the culprit - I am setting up another VM and this time I will leave it with 9.1 and upgrade to 2.6. Guess and check method |
| 15:50 |
bshum |
Hmm |
| 15:59 |
Bmagic |
bshum: I eliminated the old PG after the upgrade process |
| 16:00 |
Bmagic |
bshum: that could be part of the issue as well, because there are a ton of dependencies when removing 9.1.... and perhaps some needed by 9.2, so that is a little shakey to |
| 16:00 |
jboyer-home |
2 Minor data points: I finally got a 2.6 instance built and pointed at my 2.6 db which I’m certain hasn’t be reingested. It timed out 2-3 times (I assume no one has test db servers as nice as their prod machines) |
| 16:01 |
jboyer-home |
2nd data point: I’m going to squee like a schoolgirl about Ansible at the next Eg Intl conference. (Hint: a couple of hours ago there was no machine to even run 2.6 on) |
| 16:02 |
jboyer-home |
Re: searches: but it did eventually return results. (Had a concurrency error in my thought processes there) |
| 16:02 |
Bmagic |
jboyer-home: Are you saying that after the 3rd try, you got results? and yes, ansible is awesome |
| 16:02 |
jboyer-home |
3rd or 4th, yeah. |
| 16:03 |
Bmagic |
jboyer-home: See, I never got results, even after 15 tries... and waiting for the DB to stop processing... 20 minutes goes by, search again and nothing |
| 16:05 |
Bmagic |
bshum: I am now... some interesting things going on in there, but they finish after awhile... then I search the same search... no results |
| 16:06 |
Bmagic |
bshum: I do see my query getting to the DB, so I know for sure that my search is getting passed to my DB |
| 16:19 |
|
dconnor joined #evergreen |
| 16:22 |
Bmagic |
jboyer-home: bshum: tsbere: I am almost done upgrading this db to 2.6 from 2.4.1 - and then the search test again..... drumroll |
| 16:24 |
jboyer-home |
I am sick with jealousy. It takes close to overnight to go from 2.5.2 to 2.6.1 for us. (on an old antique server, but still) |
| 16:30 |
|
artunit joined #evergreen |
| 16:34 |
Bmagic |
jboyer-home: what is the results of du -sh /var/lib/postgresql/9.x/main for you? Ours is 61GB |
| 16:36 |
tsbere |
We are around 161GB as of Wednesday, dunno if it has gone up/down since then |
| 16:36 |
Bmagic |
1GB nics just dont cut it |
| 16:37 |
tsbere |
Our dump files, however, are only in the 8GB range. |
| 16:39 |
jboyer-home |
Our dumps take roughly 2-3 hours and are only 20-21GB (I don’t dump the auditor schema, we have 3 copies of the db on live hardware, the dumps are just for end of the world OH NOES and testing) |
| 16:39 |
jboyer-home |
It’s the test restoring that’s really rough. servers with 128GB of RAM take multiple days. :( |
| 16:43 |
Bmagic |
jboyer-home: I feel some of that pain over here. We are in a memory drought ourselves |
| 16:44 |
jboyer-home |
The real deals have 256GB, so it’s not as bad as it could be. |
| 16:45 |
Bmagic |
awwwwww, 30 minutes into 2.5.3 - 2.6.0 and this "Can't locate XML/LibXSLT.pm in" gotta install that and START AT THE BEGINNING |
| 16:45 |
jboyer-home |
Ouch. |
| 16:46 |
Bmagic |
But if that happened after 2 days, I would be really upset |
| 16:48 |
|
vlewis_ joined #evergreen |
| 16:48 |
jboyer-home |
I was curious and just checked, apparently a started a restore on our migration testing server last week. I know this because the COPY for asset.copy is still running with an xact_start of 6/13. D: |
| 16:51 |
|
ldw_ joined #evergreen |
| 16:54 |
jboyer-home |
Good luck, Bmagic! |
| 16:55 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 18:10 |
|
dbwells joined #evergreen |
| 18:28 |
|
mtcarlson_away joined #evergreen |
| 18:28 |
|
b_bonner joined #evergreen |
| 04:58 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:56 |
|
Callender joined #evergreen |
| 08:24 |
|
rjackson-isl joined #evergreen |
| 08:31 |
|
Shae joined #evergreen |
| 15:30 |
Bmagic |
tsbere++ |
| 15:33 |
|
geoffsams joined #evergreen |
| 15:52 |
tspindler |
I found my answer in the upgrade sql scripts, and it doesn't overwrite URLs. |
| 16:00 |
* dbs |
would love to see someone run the script at https://bugs.launchpad.net/evergreen/+bug/1330784 for generating sitemaps on a beefy test system |
| 16:00 |
pinesol_green |
Launchpad bug 1330784 in Evergreen "Evergreen needs automated sitemap generation" (affected: 1, heat: 8) [Wishlist,New] |
| 16:00 |
jeff |
dbs: are you looking for performance or for failures? |
| 16:01 |
dbs |
Runs on concerto et all but 227 records is different from 500,000 |
| 17:27 |
yboston |
@marc 800 |
| 17:27 |
pinesol_green |
yboston: An author/title series added entry in which the author portion is a personal name. (Repeatable) [a,b,c,d,e,f,g,h,j,k,l,m,n,o,p,q,r,s,t,u,v,4,6,8] |
| 17:28 |
yboston |
@marc 264 |
| 17:28 |
pinesol_green |
yboston: unknown tag 264 |
| 17:29 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:38 |
sal_ |
jeff: thanks muchly--the ISBN in CH SIP hack will do nicely for what my guy wants to test. And using the ID field(s)--the SIP3 thought is to allow multiple instances per item--might be an interesting extension. |
| 20:34 |
hbrennan |
This is non-EG question, but since it's later in the day I'll break the rules. Anyone taken CompTIA A+ certification and recommend the best book/study guide? |
| 20:34 |
hbrennan |
^Pardon my terrible grammar in both those sentences.... |
esilibrary.com>