| 03:31 |
|
tater joined #evergreen |
| 05:00 |
|
b_bonner joined #evergreen |
| 05:00 |
|
mtcarlson_away joined #evergreen |
| 05:20 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:24 |
|
TSU-evergreen joined #evergreen |
| 05:25 |
TSU-evergreen |
hii all |
| 05:28 |
TSU-evergreen |
can somebody help me ЫЫ |
| 08:45 |
dbs |
maybe we can borrow the @welcome plugin from zoia as well (it recognizes new visitors to the channel and sends them a quick summary message like kmlussier did) |
| 08:50 |
|
mmorgan joined #evergreen |
| 08:59 |
kmlussier |
dbs: This one?: https://github.com/code4lib/supybot-plugins/tree/master/plugins/Greeter |
| 08:59 |
DPearl |
Question: I'm looking at a change in /usr/local/share/perl/5.10.1/OpenILS/Application/Circ/Circulate.pm. What do I need to restart in order to test the changes in that file? |
| 09:00 |
jeff |
at a minimum, the open-ils.circ service. |
| 09:01 |
jeff |
that might be it. |
| 09:01 |
dbs |
kmlussier: that's it! |
| 09:01 |
DPearl |
jeff: Thanks! |
| 09:02 |
jeff |
in most cases when testing even small changes, i do the work in a local git branch, push that branch to a development server, stop apache and opensrf, then make, make install, start opensrf, start apache. sometimes i also restart memcached or perform a selective removal of keys from memcached. |
| 09:04 |
jeff |
thinking on that a bit, my only real reason for not doing a full memcached restart is usually just that i want to preserve my session -- i should probably either get used to just logging in again, or manually insert my session after a full restart. |
| 09:04 |
jeff |
(of memcached) |
| 09:04 |
jeff |
(or flush) |
| 09:05 |
jeff |
mostly because a partial deletion of keys and their values requires either that i know the exact key, or that i use memcdump and grep, and memcdump is not guaranteed to give you every key in every situation. |
| 09:05 |
tsbere |
jeff: I have aliases that do the entire install/reinstall process for me on my dev machine, and I use the automatic login options on the staff client. The only place I normally log into my dev machine is in the catalog, or if I want a different user than one of the normal three I use in the staff client. :D |
| 09:06 |
Dyrcona |
What tsbere said, plus I only do the makes and restarts when necessary. |
| 09:06 |
* tsbere |
even lets the browser remember the passwords for three "patron" accounts, though, so even the catalog isn't a big deal for logging in |
| 09:06 |
Dyrcona |
If I'm messing with tt2 fles or server side client files, I just copy them in place and clear the cache in the staff client or browser. |
| 09:07 |
* jeff |
nods |
| 09:07 |
jeff |
templates i often test without restarting, just cache-clearing |
| 09:07 |
Dyrcona |
DPearl: You'll want to restart open-ils.circ. Depends on your version of OpenSRF how you do that. |
| 09:07 |
jeff |
i wanted to get away from editing a perllib file in place on the dev system. |
| 09:08 |
Dyrcona |
I use git for this stuff definitely. |
| 09:10 |
jeff |
i edit code on my laptop, commit to a git branch, push that to a bare repo on the dev instance which is configured as a remote on itself |
| 09:11 |
Dyrcona |
Fun thing: On my laptop I have my bare repos set up to pull from an empty.git repo on the laptop and push to the remotes on the dev machine. |
| 09:11 |
Dyrcona |
This avoids errors when doing a git fetch --all and the remotes on the dev machine are not around. |
| 09:12 |
jeff |
mostly the changes i'll be testing do not involve large schema changes, so i don't have much in place for the database other than "create volume from snapshot, mount, configure postgres to use that path" -- where the snapshot in question is a block-level snapshot of a device with a filesystem containing a restore of our production db from sometime in the last month or so. |
| 09:13 |
Dyrcona |
I usually run upgrade scripts by hand, or for large changes I use a perl script that I wrote. |
| 09:13 |
jeff |
Dyrcona: nice. the local repo i'm usually doing this from isn't somewhere where i typically fetch --all, but that's handy. |
| 09:15 |
Dyrcona |
And this reminds me that I noticed memcached running on a machine where it doesn't have to and I want to disable it. |
| 09:21 |
Dyrcona |
Does anyone have a server running 2.6 besides me at the moment? |
| 09:21 |
_bott_ |
Unique is telling me that their collections calls are erroring out with "does not contain valid XML". I'm wondering if I mistakenly updated a Perl mod. Does anyone know if Precise has a version issue with any XML modules? |
| 09:21 |
Dyrcona |
I ask because I suspect something is wrong with SuperCat feeds in general, but I haven't looked hard enough, yet. |
| 09:21 |
_bott_ |
Dyrcona: test server, running, yes. I haven't touched it in a few weeks though. |
| 09:22 |
Dyrcona |
_bott_: Not that I am aware of, but could be. |
| 09:22 |
_bott_ |
I can't seem to locate my handy xml-rpc test scripts. Gotta go recreate them to test. |
| 09:23 |
Dyrcona |
_bott_: Oh. In that case, yeah, I had trouble with xml-rpc and precise all along, but never really narrowed it down. |
| 09:23 |
jeff |
_bott_: there was a change to XMLRPC calls which made our method names no longer valid. there's a new way of spelling those method names, and Unique knows how to do it, but they might not have enabled it for your system -- I don't think it was as simple as "use these names, they work everywhere" -- I think it was more of a "flag day per system" thing. |
| 09:24 |
Dyrcona |
Plus, what jeff just said. :) |
| 10:23 |
jboyer-isl |
I see. Not a bad use of !, letting you know that you're potentially wrecking the variable you're working with. |
| 10:23 |
jboyer-isl |
And saving a fair bit of typging. |
| 10:24 |
jeff |
can't say i prefer it, more of a "using the conventions of the surrounding code" thing. |
| 10:45 |
phasefx |
we don't have any metarecord examples in the test data do we? I grouped by master_record on metabib.metarecord to test |
| 10:47 |
jboyer-isl |
Sigh. on restore (of a 2.5.2-ish db) is anyone seeing this error: COPY failed for table "z3950_index_field_map": ERROR: new row for relation "z3950_index_field_map" violates check constraint "valid_z3950_attr_type" |
| 10:47 |
jboyer-isl |
It's a little disconcerting, as we have plenty of people that do z39.50 searches and there's obviously an entry in the production db being dumped each night. |
| 10:50 |
bshum |
You know, I did have that happen at least once during one of my restores... |
| 11:41 |
|
dreuther joined #evergreen |
| 11:53 |
bshum |
fwiw, gmcharlt, we applied https://bugs.launchpad.net/bugs/1296937 to our production to help speedup lookups and it hasn't been a problem as far as I know. |
| 11:53 |
pinesol_green |
Launchpad bug 1296937 in Evergreen 2.5 "SIP2 Patron Information times out on too many checkouts/holds" (affected: 4, heat: 20) [Medium,Confirmed] - Assigned to Galen Charlton (gmc) |
| 11:54 |
gmcharlt |
bshum: yep, I'm nearly done testing it |
| 11:54 |
bshum |
gmcharlt++ |
| 11:54 |
tsbere |
heh, I just poked him to say the same thing. We had people with a couple hundred holds complaining about overdrive not letting them log in. <_< |
| 11:55 |
bshum |
Yeah, that's the same thing we saw :( |
| 12:01 |
* tsbere |
recalls his testing: Insert a row into action.hold_request for every bib, then when that wasn't enough of a stress test adding one for every copy, for the test patron |
| 12:02 |
pinesol_green |
[evergreen|Thomas Berezansky] LP#1296937: (SIP2) Add ids_only parameter to _items functions - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9ce8743> |
| 12:02 |
pinesol_green |
[evergreen|Galen Charlton] LP#1296937: (follow-up) make $ids_only be the last parameter for ->charged_items() - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2f27b78> |
| 12:02 |
* tsbere |
wonders what Galen was doing with that follow up commit |
| 12:04 |
gmcharlt |
tsbere: bshum: Dyrcona: committed; note the follow-up |
| 12:04 |
tsbere |
gmcharlt: What did that follow-up commit get us beyond confusing things inside of SIPServer? |
| 12:04 |
gmcharlt |
tsbere: read the commit message on the Evergreen follow-up |
| 12:05 |
tsbere |
gmcharlt: I did. I still don't get why it was needed. The code that used that parameter existed only in the Evergreen side of things, and if SIPServer triggered the "force barcode" code it actually *improved* the patron information response from not doing so in my own testing. |
| 12:06 |
tsbere |
gmcharlt: Thus, as I said a moment ago: What does that get us beyond confusing things inside of SIPServer with different numbers of params needed for each summary call? |
| 12:09 |
eeevil |
tsbere: I'm having a hard time understanding when it's ever a good idea to reorder positional parameters as opposed to always adding to the end |
| 12:09 |
gmcharlt |
tsbere: prior to the follow-up, if one upgraded Evergreen but not SIPServer, it was unclear that the renew-all message would get the correct information to actually renew the items |
| 12:10 |
tsbere |
gmcharlt: Ummm.....the renew-all code in question is part of Evergreen, not SIPServer. Which is my point. If you upgraded Evergreen you got the new version of the renew all code too. |
| 13:48 |
tsbere |
gmcharlt: Wait, we care about breakage to JSPac? Since when? |
| 13:48 |
gmcharlt |
this is probably a really obvious Q and A, but I think it wouldn't hurt to be explicit: are we all agreed that we don't care about anything that would break JSPac? |
| 13:49 |
gmcharlt |
and no, I rather suspect we don't, but for as long as it lives in the code base, we should probably be crystal clear about expectations |
| 13:50 |
jeff |
Not having tested jspac on 2.6 in... ever, I'm not sure why I'm asking, but: are you planning to backport the change that breaks jspac to rel_2_6 or is it just master-and-forward? |
| 13:51 |
* kmlussier |
thinks we should break JSPac as much as we can to convince anyone who may be using it to get off of it. |
| 13:52 |
kmlussier |
We officially stopped supporting it in 2.4, right? |
| 13:52 |
gmcharlt |
something like that |
| 15:28 |
jeff |
I have a report for 245 tags where ind2 is 4 and the first characters of the $a are not "The " :P |
| 15:30 |
|
ldwhalen_mobile joined #evergreen |
| 15:31 |
hbrennan |
I'm going to flip flop the first and last of (6!) ISBNs for a title which is showing the wrong cover image... |
| 15:32 |
jeff |
hbrennan: keep in mind that that may do nothing. in the code you're running, there is no predictable way to ensure that a certain ISBN is used for a Syndetics lookup. |
| 15:33 |
jeff |
gmcharlt: does that code and that test pass for you? which version of Business::ISBN? It's been too many weeks since I was looking at Business::ISBN, but memory says it won't do what is expected there. |
| 15:34 |
dbs |
we put some extensive ISBN pre-cleanup code into database logic to work with Business::ISBN, should be able to reuse that |
| 15:34 |
gmcharlt |
jeff: that patch needed a couple follow-ups (also in the source tree) to deal with invalid ISBNs, but overall, it does appear to correctly normalize ISBNs, and produce variations of an ISBN |
| 15:35 |
* jeff |
looks to see if his memory is wrong, but also sees that there's a new-this-year version of Business::ISBN |
| 15:56 |
jeff |
tsbere++ for a very elegant proposed fix to key ordering |
| 15:57 |
hbrennan |
I have to say, Syndetics did not use blame language towards EG |
| 15:57 |
hbrennan |
it would be easy for them to do, but they didn't |
| 15:57 |
jeff |
certainly. they've been very helpful when i have worked with them in the past. |
| 15:57 |
jeff |
including providing us with a client code for development/testing, etc. |
| 15:57 |
hbrennan |
They called it a "small technical issue" on EG's part |
| 15:58 |
hbrennan |
And they did add the missing ISBNs in their database so our images would show.. at least for the two we were missing in the case |
| 15:59 |
|
ericar joined #evergreen |
| 16:59 |
gsams |
jeff: yeah that is basically what I will be trying to setup. |
| 17:00 |
|
dreuther joined #evergreen |
| 17:01 |
gsams |
just a bit smaller scale, as in one library in a 13 library system. |
| 17:03 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:07 |
|
dreuther joined #evergreen |
| 17:09 |
|
mmorgan left #evergreen |
| 17:09 |
dbwells |
Browser prompt: "You are about to close 793 tabs. Are you sure you want to continue?" |
| 18:16 |
|
zerick2 joined #evergreen |
| 18:37 |
|
kmlussier joined #evergreen |
| 19:53 |
* gmcharlt |
grabs 0880 |
| 20:01 |
pinesol_green |
[evergreen|Mike Rylander] LP#1312945: auth-auth linking: cache less agressively and look for all links - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=89f8e98> |
| 20:01 |
pinesol_green |
[evergreen|Srey Seng] LP#1312945: authority.calculate_authority_linking and multiple linked tags - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=663715d> |
| 20:01 |
pinesol_green |
[evergreen|Mike Rylander] LP#1312945: baseline schema update - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e7e9731> |
| 20:01 |
pinesol_green |
[evergreen|Galen Charlton] LP#1312945: add regression test - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=73aff25> |
| 20:01 |
pinesol_green |
[evergreen|Galen Charlton] LP#1312945: pin schema update - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4df12a9> |
| 20:13 |
pinesol_green |
[evergreen|Dan Wells] LP#1314902: Restore header bar styles on results pages - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e174630> |
| 21:21 |
|
kmlussier joined #evergreen |
| 22:04 |
|
kmlussier joined #evergreen |
| 22:09 |
|
Jimmy__ joined #evergreen |
| 22:15 |
bshum |
It's just letting you know that this hasn't been done and it's just using the localhost address 127.0.1.1 as the servername for the apache service. |
| 22:23 |
|
b_bonner joined #evergreen |
| 22:23 |
|
mtcarlson_away joined #evergreen |
| 22:23 |
PSM |
<bshum> Ok, I see. I guess should leave it this way then. My main concern is my staff client 2.6 on win xp machine is connecting fine to the server, but when I try Acquisitions, new brief record then to save the record I get the following error 'Event: 2002: DATABASE_QUERY_FAILED-> The attempt to query to the DB failed' on the server side it seems that it's running fine and I can do the srfsh test with no problems |
| 22:25 |
bshum |
PSM: I'm afraid that I can't speak to how acquisitions operates in that area, so I'm unsure how to instruct you on proceeding further, but yeah, that apache warning you noted is just a warning, not an actual error per say. |
| 22:26 |
PSM |
<bshum> I see, thanks for your help with Apache anyway. |
| 22:27 |
PSM |
<bshum> I wonder where would you recommend me to go for more help about this? |
| 00:41 |
|
zerick 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:09 |
|
_bott_ joined #evergreen |
| 05:46 |
|
john3213 joined #evergreen |
| 05:51 |
|
john3213 left #evergreen |
| 13:30 |
tsbere |
gsams: Did you double-check that the passwords in the SIP XML config are the ones provided to Evergreen *and* the clients are using the correct passwords? |
| 13:30 |
* tsbere |
points out that this has been an issue for him in the past on his dev machine, mis-typing the password in one of the three spots and not noticing |
| 13:31 |
|
mllewellyn joined #evergreen |
| 13:32 |
gsams |
tsbere: unfortunately yes again, I double checked that first, using the password from the xml file and copying it into Evergreen and then into a telnet sip session |
| 13:32 |
gsams |
I also tested a few of the other credentials that I have and they all pass except for the new ones. |
| 13:32 |
tsbere |
gsams: Did you ensure the permissions are properly set on the new accounts in Evergreen? |
| 13:33 |
gsams |
tsbere: yes, they have the same permission group and permissions as other working sip users |
| 13:33 |
tsbere |
gsams: Do your other sip users have secondary groups that the new ones may have had overlooked? |
| 13:35 |
Dyrcona |
OK, just checking the obvious. |
| 13:36 |
gsams |
Dyrcona: not a problem, I was hoping it was something obvious too. |
| 13:36 |
gsams |
tsbere: I'm not sure if they have secondary groups or not honestly. |
| 13:37 |
jcamins |
I have a suggestion of something else obvious. Did you check to make sure that you're connecting to the correct machine? |
| 13:38 |
jcamins |
I've definitely had moments of panic where the new login isn't working... only to realize that I'm logging into a test server. |
| 13:38 |
tsbere |
gsams: Perhaps run this for old vs new? If old doesn't return anything don't worry about the new. SELECT pugm.grp FROM permission.usr_grp_map pugm JOIN actor.usr au ON pugm.usr = au.id WHERE au.usrname = 'some username'; |
| 13:39 |
gsams |
jcamins: yeah, I've got that part correct as well |
| 13:39 |
gsams |
tsbere: nothing was returned for old users |
| 14:55 |
* csharp |
weeps over bug 1207533 |
| 14:55 |
pinesol_green |
Launchpad bug 1207533 in Evergreen 2.5 "Triggered event log times out for large-data sites" (affected: 13, heat: 70) [Medium,Confirmed] https://launchpad.net/bugs/1207533 |
| 14:56 |
csharp |
I kicked off the query like 4 to 5 minutes ago |
| 14:58 |
Bmagic |
Does anyone out there have some statistics on the preformace of their DB when running a full bib reingest? In testing I am measuring something like 22,500 bibs per hour. Does that sound right? |
| 14:59 |
csharp |
Bmagic: I didn't record stats before... I know that it took most of 24 hours last time I did one (1.7 million bibs) |
| 15:00 |
Bmagic |
csharp: that is 70,800 bibs per hour |
| 15:01 |
Bmagic |
csharp: I might be able to get up to that speed when I use my raw real production machine, so perhaps I am on track |
| 15:37 |
Dyrcona |
BTW, that git repo contains some other useful scripts. |
| 15:38 |
ktomita |
Dyrcona: thank you. I will check them out. Dyrcona++ |
| 15:39 |
Dyrcona |
http://git.mvlcstaff.org/ has some more useful and/or interesting repos of Evergreen-related things. |
| 15:43 |
remingtron |
kmlussier: I'm reviewing bugs for 2.6.1 and wondered if you've tested this: https://bugs.launchpad.net/evergreen/+bug/1078593 |
| 15:43 |
pinesol_green |
Launchpad bug 1078593 in Evergreen 2.6 "serials: deleting an issuance does not update the basic summary statement" (affected: 3, heat: 18) [Medium,Triaged] |
| 15:44 |
kmlussier |
remingtron: Not yet. I was just talking to Dyrcona about that one. He's going to add it to his dev server this week. I'll test it as soon as it's been loaded. |
| 15:45 |
remingtron |
kmlussier: okay thanks |
| 15:46 |
remingtron |
kmlussier: not sure if you have influence over that timeline, but dbwells mentioned he might cut 2.6.1 on wednesday |
| 15:46 |
Dyrcona |
I have a meeting in the morning and may be expected to attend another meeting in the afternoon. |
| 00:18 |
|
jl- joined #evergreen |
| 01:03 |
|
zerick2 joined #evergreen |
| 03:28 |
|
zerick2 joined #evergreen |
| 05:06 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:46 |
|
Shae joined #evergreen |
| 07:55 |
|
jboyer-laptaupe joined #evergreen |
| 08:04 |
|
artunit joined #evergreen |
| 12:52 |
mmorgan |
Awesome! |
| 12:58 |
kmlussier |
Bmagic++ |
| 13:05 |
|
ericar joined #evergreen |
| 13:12 |
phasefx |
anyone want to sanity check my logic on staff client bandwidth requirements? |
| 13:13 |
phasefx |
simply logging into an already registered staff client with stock test data seems to pull down 2.1MB of data in about 15 seconds. That seems to be the most demanding activity as far as bandwidth goes. Checking in 10 items, for example, only pulls 83.6KB and uploads 15.4KB |
| 13:14 |
phasefx |
so, let's take the login example, 2.1MB in 15 seconds = 143.36 KBps. If we had 10 staff doing that at exactly the same time, we'd have 143.36 KBps * 10 = 1.4 MBps = 11.2 Mbps |
| 13:15 |
phasefx |
residential Charter internet offers 30 Mbps down. So for 10 staff, residential Charter should be sufficient? |
| 13:16 |
* phasefx |
looks at the upload side of it |
| 13:17 |
phasefx |
4Mbps upstream for Charter |
| 13:19 |
phasefx |
so say we use checkin as our worst case scenario for upstream, 10 staff checking in 10 items each in...optimistic 10 seconds. 15.4KB/10s * 10 = .12 Mbps |
| 13:30 |
jeff |
latency and ack starvation from a saturated connection are bigger concerns than bandwidth. |
| 13:31 |
* phasefx |
can believe, but doesn't know how to tell folks to "shop" for that :( |
| 13:32 |
tsbere |
phasefx: At this point I generally tell people "if you can get X people browsing the internet on the connection then you can run that many staff clients" >_> |
| 15:15 |
krvmga |
even though i occasionally feel like i'm trying to gnarfle the garthok. |
| 15:17 |
phasefx |
twas brillig, and the slithy toves |
| 15:35 |
|
kmlussier1 joined #evergreen |
| 15:44 |
jeff |
* [new branch] container_date_sort -> user/jeff/container_date_sort |
| 15:44 |
jeff |
basic proof of concept, but it seems to work okay. |
| 15:44 |
jeff |
and hopefully the method i used wasn't too evil. |
| 15:46 |
jeff |
haven't tried breaking it too much yet. |
| 15:46 |
jeff |
that's forward-ported to master from testing on 2.5 |
| 16:11 |
jboyer-laptaupe |
phasefx: Do you think you could pull out a memory about a line of code you wrote 8 years ago? :D |
| 16:11 |
|
mceraso joined #evergreen |
| 16:11 |
|
bshum joined #evergreen |
| 16:12 |
jboyer-laptaupe |
I've gotten a question about changing the Type of a receipt in the receipt editor. Apparently that drop-down was enabled at some point in the past (at least here) but if we made any changes to enable it they never hit git. |
| 16:13 |
jboyer-laptaupe |
Do you know if there's a reason that the type of a receipt shouldn't be changed? The svn commit log where it was disabled got cut short in the transition to git. |
| 16:14 |
jboyer-laptaupe |
It's an easy one-line change, but if it's going to break things I'd rather leave it be. |
| 16:14 |
phasefx |
IIRC, the only role that type plays is in picking the test data for the preview pane. It's informational only |
| 16:15 |
phasefx |
I may had delusions in the past of letting you switch to different test data sets |
| 16:15 |
phasefx |
have had |
| 16:16 |
|
rfrasur_ joined #evergreen |
| 16:16 |
jboyer-laptaupe |
Hmm. I may need to see examples of what people are talking about here then. Someone wants to add billing info (balance_owed, etc.) to items_out, which I don't think will fly, though they claim it worked in the past. |
| 16:16 |
phasefx |
jboyer-laptaupe: what would you imagine the behavior might be if you could change the type? |
| 16:34 |
hbrennan |
to edit the form |
| 16:34 |
phasefx |
so I don't see any special perms for those in stock |
| 16:35 |
hbrennan |
No, sorry, those are some of the Library Settings I need to edit |
| 16:35 |
* phasefx |
will try it with his test user |
| 16:35 |
hbrennan |
so I need more permissions besides just UPDATE_ORG_SETTINGS |
| 16:35 |
phasefx |
maybe, not sure yet |
| 16:36 |
hbrennan |
someday I'll create a list of "If you want to do this" you need these permissions at these levels |
| 16:43 |
hbrennan |
Are you looking at permissions under Admin > server > Permissions? |
| 16:43 |
phasefx |
hbrennan: no |
| 16:43 |
hbrennan |
phasefx: Hmm, where are you? |
| 16:43 |
phasefx |
to see whether my test user had a permission or not, I was using the User Perm Editor |
| 16:44 |
hbrennan |
in your "patron" info? |
| 16:44 |
phasefx |
well, I went in through the Admin menu, but through the patron display is an option |
| 16:44 |
hbrennan |
okay |
| 02:12 |
|
ats_vin joined #evergreen |
| 04:50 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:40 |
|
b_bonner joined #evergreen |
| 06:41 |
|
mtcarlson_away joined #evergreen |
| 07:28 |
|
timf joined #evergreen |
| 12:09 |
jeff |
which is probably a good argument for any future "manual tuning" of metarecords to exist as overrides outside that table... maybe. |
| 12:17 |
|
john3213 joined #evergreen |
| 12:22 |
|
john3213 left #evergreen |
| 12:28 |
jboyer-isl |
As luck would have it we just got a test database server large enough to handle a full dump/restore of our production data. Maybe I'll try that out sometime. As for now though, I think I will give quick_metarecord_map.sql a looking-over. |
| 12:29 |
jboyer-isl |
Thanks! |
| 12:32 |
kmlussier |
remingtron: A question on the 2.6 features that need documentation. For the removal of open-ils.ingest service, does the removal of a service require documentation? |
| 12:33 |
kmlussier |
Or is there some documentation already that needs to be removed? |
| 12:34 |
remingtron |
kmlussier: I guess the task of that feature assignment would be to answer the second question. |
| 15:02 |
bbqben |
I wondered whether we might like to meet by phone perhaps at the next (or the one after) regular meeting. |
| 15:02 |
bbqben |
I'll get a survey out next week to see what you think |
| 15:02 |
kmlussier |
bbqben: Out of curiousity, why by phone? |
| 15:03 |
bbqben |
kmlussier: thought you'd never ask! |
| 15:04 |
bbqben |
Came to my attention at the conference that some folks feel a little je ne sais quoi about IRC - just wanting to test the waters on that especially around strategic discussions, e.g. |
| 15:05 |
bbqben |
Obviously IRC provides a very full record of the conversation, and is totally inclusive - not wanting to sacrifice that, but perhaps go after some of the tonal qualities |
| 15:05 |
bbqben |
e.g. a recorded teleconference once / twice a year |
| 15:05 |
bbqben |
anyways, you asked. I'll survey :) |
| 15:05 |
krvmga |
and there could be a transcript anyway |
| 15:06 |
bbqben |
ok, unless there's no other business (in 10 seconds...) |
| 15:07 |
bbqben |
our next meeting is 19.06.14 @ 11 Pacific |
| 15:57 |
berick |
Bmagic: actor.org_unit_setting has the values |
| 15:57 |
Dyrcona |
Bmagic: actor.org_unit_setting and config.org_unti_setting_type |
| 15:57 |
* Dyrcona |
prefers a confederacy of dunces. :) |
| 15:58 |
berick |
Dyrcona++ maketext testing |
| 15:58 |
Bmagic |
berick++ Dyrcona++ |
| 15:58 |
|
bbqben joined #evergreen |
| 15:59 |
kmlussier |
Did the ESI quassel server just crash? |
| 16:07 |
mmorgan |
Actually, this is more complicated. In our situation, age protect shouldn't be a failure at all. |
| 16:07 |
phasefx |
and, I'm not familiar with that code at all, so don't know how hairy it might really be |
| 16:08 |
kmlussier |
mmorgan: Because you have the auto-override setting set to True? |
| 16:08 |
phasefx |
mmorgan: yeah, it's really the fines reason that failed the entire hold for your test patron |
| 16:08 |
mmorgan |
kmlussier: Yes |
| 16:08 |
phasefx |
but the way it works now, is that all the failure reasons come across the wire, if the hold fails altogether |
| 16:08 |
phasefx |
and the UI picks one over another |
| 16:09 |
phasefx |
so one thought is that maybe the only failure reasons we should send over the wire are the ones held in common across all the items that were tested for the hold |
| 16:09 |
phasefx |
so in the example, only the fines one would get sent |
| 16:10 |
phasefx |
but let's say it was fines and long overdue... the UI as written today will still pick only one to display |
| 16:10 |
phasefx |
but, at least either would make sense |
| 16:11 |
phasefx |
it's only the failures that happen for a subset of the items tested that don't make sense |
| 16:11 |
mmorgan |
phasefex: Right. |
| 16:12 |
kmlussier |
phasefx: So let's say you only send reasons that are held in common across all items. What happens in a case where a patron is trying to place a hold on a title where all of the items are in a copy location, like reference, that doesn't allow holds? They have no other problems on their record that would prevent the hold. |
| 16:12 |
kmlussier |
Would they get a reason for the hold failing? |
| 16:24 |
mmorgan |
dessert cures many ills :) |
| 16:24 |
kmlussier |
csharp: So should I be adding Lemon Chess Pie to my list of things to try the next time I visit Atlanta? Along with fried chicken and waffles, which I missed out on during my last trip. |
| 16:24 |
csharp |
kmlussier: Chess Pie of any variety, yes. I actually prefer straight-up Chess Pie myself ;-) |
| 16:24 |
phasefx |
kmlussier: mmorgan: so right now, all failure events are trumping the PATRON_EXCEEDS_FINE event for display. We could reverse the order of that test, and let exceeds fine trump everything else :) |
| 16:25 |
phasefx |
that looks relatively simple |
| 16:25 |
csharp |
America's Test Kitchen's home cookbook has a great recipe for it, btw - it's very easy (as pie baking goes) |
| 16:25 |
phasefx |
well, almost all. if something isn't coded for in the error map, I'm not sure what happens to it |
| 16:25 |
kmlussier |
But what about events like exceeding overdue count or others that apply to all copies? |
| 16:26 |
mmorgan |
Seems like failures due to blocks on the patron should be more important, and trump failures due to items |
| 16:30 |
phasefx |
maybe in part, where it loops over items |
| 16:32 |
phasefx |
and there are two maps in hold_error_messages.tt2, FAIL_PART_MSG_MAP and EVENT_MSG_MAP. The first gets precedence over the second (and the second is where PATRON_EXCEEDS_FINES is defined/translated) |
| 16:32 |
mmorgan |
If a patron is blocked, and can't place a hold at all, does it still loop over all the items? Sounds like it does. |
| 16:33 |
phasefx |
let's say something is handled by FAIL_PART_MSG_MAP.. I'm not sure if it's the first event or the last event in the list of failure events that get returned |
| 16:33 |
phasefx |
mmorgan: I think that's a true statement |
| 16:34 |
phasefx |
and then if you override, it's looping through all the events, and testing for related .override permissions on each one |
| 16:35 |
mmorgan |
Doesn't seem very efficient ;-) |
| 16:35 |
phasefx |
this stuff evolves :) the tests used to be javascript, and it was efficient enough for a while |
| 16:36 |
phasefx |
then the move to in-db circ; much faster, but maybe room for improvement still |
| 16:36 |
kmlussier |
Patron Exceeds Fines is the only event in EVENT_MSG_MAP? Am I reading that right? |
| 16:36 |
phasefx |
of course, if we could get rid of all the flexibility, we could make it very efficient :D |
| 16:37 |
phasefx |
kmlussier: yeap |
| 16:38 |
phasefx |
looks like it'll eventually just return the raw fail_part or event textcode |
| 16:38 |
mmorgan |
Where is EVENT_MSG_MAP? |
| 16:38 |
phasefx |
so, if PATRON_EXCEEDS_FINE wasn't listed there, you'd actually see "PATRON_EXCEEDS_FINES" |
| 16:38 |
kmlussier |
phasefx: That's what I was thinking. But it should be easy enough for one of us to test. |
| 16:39 |
kmlussier |
You can see it in the hold_error_messages.tt2 file. I'm looking at it here: http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/templates/opac/parts/hold_error_messages.tt2;h=50a0ebff941e408770ce5b9f970ca61d6266563f;hb=HEAD |
| 16:39 |
phasefx |
would probably be an improvement to show the event's native description rather than the textcode at that point |
| 16:39 |
mmorgan |
Oh, ok, it's in the .tt2 file. Duh. |
| 16:40 |
phasefx |
place_hold_result.tt2 is where hold_error_messages.tt2 actually gets used |
| 17:18 |
|
mmorgan left #evergreen |
| 17:18 |
|
eby__ joined #evergreen |
| 17:21 |
|
wjr_ joined #evergreen |
| 17:24 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:31 |
|
kmlussier left #evergreen |
| 17:37 |
|
RBecker joined #evergreen |
| 18:06 |
|
phasefx_ joined #evergreen |
| 00:57 |
|
dac joined #evergreen |
| 01:14 |
|
zerick joined #evergreen |
| 03:39 |
|
dcook joined #evergreen |
| 04:34 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:38 |
|
timlaptop joined #evergreen |
| 07:47 |
|
Callender joined #evergreen |
| 07:52 |
|
rjackson-isl joined #evergreen |
| 09:17 |
phasefx |
jeff: I don't recall ever seeing that ejabberd error; but I've been out sick for more than a week |
| 09:18 |
RoganH_ |
phasefx: you have my empathy, I've been out sick too |
| 09:18 |
phasefx |
RoganH_: hello friend plague zombie |
| 09:19 |
jeff |
phasefx: similar but not identical test failure back in April, http://testing.evergreen-ils.org/~live/archive/2014-04/2014-04-26_16:00:02/ |
| 09:19 |
jeff |
phasefx: and welcome back! |
| 09:21 |
phasefx |
jeff: thanks :) if you ever need to, you can jump from the buildbot testing server by sudoing to 'live' and then ssh esi 192.168.25.129 |
| 09:21 |
phasefx |
from testing server to qa server, that is |
| 09:21 |
jeff |
phasefx: thanks. made a note of it. |
| 09:22 |
phasefx |
I see some Failed legacy authentication in the ejabberd log |
| 09:32 |
|
yboston joined #evergreen |
| 10:26 |
pinesol_green |
csharp: The answer is certainly yes. |
| 10:27 |
csharp |
pinesol_green++ |
| 10:27 |
* csharp |
will take it home to chew on it - it's possible the policy won't even be adopted |
| 10:31 |
eeevil |
RoganH: head's up, there's a 2.5-ish version of https://bugs.launchpad.net/evergreen/+bug/925776 if you want to test |
| 10:31 |
pinesol_green |
Launchpad bug 925776 in Evergreen "located URIs appear in staff client OPAC searches regardless of $9's" (affected: 8, heat: 46) [Medium,Confirmed] |
| 10:31 |
RoganH |
yboston: I blame you for ending up reading OCLC docs again. Ug. |
| 10:32 |
RoganH |
eeevil: I already put it on our test server, I'm waiting on feedback from users now. |
| 10:32 |
RoganH |
eeevil: and thank you! |
| 10:32 |
eeevil |
RoganH: cool! any initial up/down? |
| 10:32 |
dbs |
RoganH / yboston / dbwells : I pointed to this a week or two ago: https://www.mail-archive.com/code4lib@listserv.nd.edu/msg23252.html |
| 10:33 |
RoganH |
eeevil: not yet but I'll let you know. I'll probably get tired of waiting by this afternoon and test it myself. |
| 10:33 |
RoganH |
dbs: I just sent another email about it. I think there is a route for us but of course it's OCLC so it's going around your elbow to your knee to get there. |
| 10:35 |
RoganH |
dbs: I'm glad for Roy's sentiment but it comes down to your legal level of ease. Me, I say do it, I'm comfortable with it. But I feel I'm being dishonest if I said "there's no way someone couldn't raise a legal stink about it" - not that I think OCLC would, just that they could. |
| 10:37 |
dbs |
RoganH: Oh, I agree with you. That and/or the contributor of a given record to OCLC could (_highly theoretically_) raise a stink. |
| 12:23 |
|
jwoodard joined #evergreen |
| 12:32 |
Bmagic |
mmorgan: PATRON_EXCEEDS_HOLD_LIMIT.overrid permission doesnt exist in my database, do you have that in your database ? |
| 12:32 |
|
kmlussier joined #evergreen |
| 12:42 |
vlewis |
I'm working on Launchpad bug 914800. For testing, how do I set a patron's status to 'in collections' from the Staff Client and in which table is it recorded in the database? Thanks. |
| 12:42 |
pinesol_green |
Launchpad bug 914800 in Evergreen "Attempting to merge user in collections provides an unfriendly error message" (affected: 3, heat: 18) [Low,Confirmed] https://launchpad.net/bugs/914800 |
| 12:53 |
|
kayals joined #evergreen |
| 12:54 |
|
jihpringle joined #evergreen |
| 13:44 |
|
bmills joined #evergreen |
| 13:49 |
mrpeters |
anyone ever tried using fingerprinter to dedupe a set of authority records (in marcxml) against themselves? I've got a batch of about 30K that seem to be running into unique constraint collisions on " ERROR: duplicate key value violates unique constraint "unique_by_heading_and_thesaurus" |
| 13:50 |
mrpeters |
thought maybe i might be able to knock out some of these with fingerprinter, but i dont know that it was designed with authority MARC in mind or not... |
| 13:51 |
Bmagic |
I am trying to make a log entry by editing some Evergreen code. I am editing Holds.pm and adding the line $logger->warn("testing"); directly after the subroutine definition: sub create_hold { After restarting opensrf, that change should be live right? Why doesnt my log entry show up in /openils/var/log/ ? |
| 13:52 |
Bmagic |
mrpeters: Are you attempting to dedupe your database using your database and turning it back onto itself? |
| 13:53 |
|
hbrennan joined #evergreen |
| 13:57 |
Dyrcona |
Bmagic: Either your line didn't get called when you thought it should or your loglevel isn't logging warnings in osrfsys.log. |
| 15:01 |
Bmagic |
ok, I will move it around more |
| 15:01 |
Dyrcona |
It has been a while since I looked put there are multiple pathways through the holds code. |
| 15:05 |
|
Worch joined #evergreen |
| 15:10 |
tsbere |
Bmagic: Holds have a "test" phase and a "create" phase - The latter doesn't tend to happen unless the former says it is ok to place the hold. |
| 15:13 |
|
krvmga joined #evergreen |
| 15:14 |
Bmagic |
tsbere: I am making some headway now, I finally got it to put something in the logs and the corrisponding function that made it happen was test_and_create_hold_batch |
| 15:20 |
krvmga |
in our system (cwmars, eg2.4), if a patron tries to renew an item in their account and gets denied because of late fees, there is a link on the page that says they can override this (and, of course, they can't). i must have done something wrong if this is appearing in the patron's account but i don't know what. |
| 15:43 |
krvmga |
eeevil: i double checked. the exact wording is "You have permission to override some of the failed holds. Click Submit to override and place your hold on the selected items." This appears, though, for an attempted hold placement on one item. |
| 15:44 |
kmlussier |
krvmga: Is this for holds or renewals? |
| 15:44 |
mmorgan |
There is a launchpad bug for the holds message: lp 1194860 |
| 15:44 |
krvmga |
kmlussier: i just tested for holds. it was reported to me for a renewal. i'll double check it. |
| 15:44 |
pinesol_green |
mmorgan: Error: Could not gather data from Launchpad for bug #1194860 (https://launchpad.net/bugs/1194860). The error has been logged |
| 15:45 |
jeff |
@isitdown launchpad.net |
| 15:45 |
pinesol_green |
jeff: Try restarting apache. |
| 17:05 |
Pigimi |
ok, I see. |
| 17:07 |
Pigimi |
Can you tell me some details about the /usr/bin/apxs2 file, what it does for apache, and what should be its content? |
| 17:07 |
dbwells |
frank_____: changed file is here: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=blob_plain;f=Open-ILS/src/sql/Pg/version-upgrade/2.5.3-2.6.0-upgrade-db.sql;h=3814b720c50111cc7ebef6eb4bc09c88f79cc0ae;hb=ddfc59f4cae6813b05638d67bd567d851b8019b5 |
| 17:07 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:09 |
dbwells |
frank_____: file is in branch user/dbwells/rel_2_6_0_upgrade_test on working - http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbwells/rel_2_6_0_upgrade_test |
| 17:12 |
frank_____ |
ok dbwells I started to run it |
| 17:14 |
frank_____ |
it finished, I didn´t get the same error. I just get some NOTICES |
| 12:22 |
csharp |
jeff: also (I've been meaning to follow up on this myself), you mentioned you have an interface that staff can log into and upload images, right? is that code available? |
| 12:23 |
krvmga |
has anyone (or group of someones) gotten any study together to look at the online catalog *strictly* from a patron point of view? |
| 12:24 |
krvmga |
(by *strictly*, i mean disregarding whatever we think the patron wants/needs and just compiling data from patrons) |
| 12:25 |
csharp |
krvmga: you mean like actual usability testing, or something else? |
| 12:25 |
krvmga |
csharp: both usability and desire/wishlist |
| 12:26 |
csharp |
we haven't done anything formal on the first point, but we get a "wishlist" of sorts in our PINES annual survey feedback |
| 12:27 |
krvmga |
it seems i'm constantly running into things from the patrons that they wish they had: context sensitive help, information about holds - when the hold is place - about how the hold will be filled |
| 15:29 |
|
timhome_ joined #evergreen |
| 15:45 |
graced |
kmlussier: eeevil might know the answer to that since Equinox hosts that |
| 15:46 |
kmlussier |
graced: Thanks! I don't think I need to know now that I figured out my problem. |
| 15:46 |
jeff |
kmlussier: from the perspective of "more community demo/test servers in the near future", can I ask for details on why you ask, and what answer you're hoping for? :-) |
| 15:46 |
kmlussier |
But if eeevil answers, I'll add it to the wiki page. |
| 15:47 |
kmlussier |
jeff: I was testing something there because I was worried local tpac customizations were skewing my results. I then wanted to point to the record I was testing as an example of the bug. |
| 15:48 |
kmlussier |
I guess I was just hoping the example would be there for a couple of days before it was wiped out. |
| 15:49 |
kmlussier |
I should say I wanted to point to it as an example of what I thought was a bug. Alas, it turned out to be user error. :( |
| 15:50 |
csharp |
@dessert search velvet |
| 15:50 |
pinesol_green |
csharp: No matching desserts were found. |
| 15:50 |
csharp |
@dessert add Red Velvet Cake |
| 16:41 |
krvmga |
jeff: i checked if dojo was loaded with the method you suggested. i got the dojo version. |
| 16:41 |
jeff |
ah. |
| 16:42 |
jeff |
what is the URL of your advanced search page where you're seeing that error? |
| 16:42 |
krvmga |
yes, it did sound exactly like that bug, though. |
| 16:42 |
krvmga |
i'm afraid i can't show it to you. it's our training/test server and not open to the world. |
| 16:43 |
jeff |
ah. |
| 16:43 |
krvmga |
:( |
| 16:43 |
kmlussier |
tsbere: You had mentioned today that you were getting an error when tpac was trying to load consortium-owned copy locations? Is it similar to the one krvmga just posted? |
| 17:03 |
|
akilsdonk_ joined #evergreen |
| 17:03 |
krvmga |
yes, i think i'm going to have to come back to this tomorrow and approach it from the other side. |
| 17:04 |
krvmga |
jeff: thanks for your help, though |
| 17:12 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:20 |
|
jwoodard joined #evergreen |
| 17:28 |
|
mmorgan left #evergreen |
| 17:44 |
pinesol_green |
[evergreen|Yamil Suarez] Documentation: add a 'where' clause to bib record import stored procedure - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c04958b> |
| 17:53 |
|
ktomita_ joined #evergreen |
| 18:02 |
|
ktomita joined #evergreen |
| 18:46 |
|
mceraso joined #evergreen |
| 02:09 |
|
berick joined #evergreen |
| 02:20 |
|
flopaul joined #evergreen |
| 03:58 |
|
dreuther 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> |
| 06:39 |
|
timlaptop joined #evergreen |
| 07:27 |
|
Callender joined #evergreen |
| 07:32 |
|
jboyer-isl joined #evergreen |
| 10:33 |
* csharp |
hasn't seen issues using 14.04 on his desktops/laptop |
| 10:34 |
csharp |
Dyrcona: what software is incompatible? |
| 10:34 |
csharp |
Dyrcona: I'm working with EDI now too, FYI, if you want to compare notes at any point |
| 10:35 |
Dyrcona |
csharp: I understand that Perl 5.18 causes some issues with tests in CPAN packages as well possibly our tests. |
| 10:35 |
Dyrcona |
csharp: I know that Horde, ckeditor, and mobile jquery, are installed with incompatible versions. |
| 10:35 |
csharp |
eww |
| 10:35 |
Dyrcona |
csharp: The latter causes parts of Horde web mail not to function properly. |
| 10:38 |
csharp |
lots of moving parts |
| 10:38 |
|
montgoc1 joined #evergreen |
| 10:39 |
Dyrcona |
As for EDI, I'm using this documentation: http://docs.evergreen-ils.org/2.5/_installation.html |
| 10:39 |
Dyrcona |
I'll set that much up today, since I don't have the information to configure any testing with vendors, yet. |
| 10:40 |
|
rfrasur joined #evergreen |
| 10:40 |
Dyrcona |
After that, I think I'll try upgrading my development vm from Ubuntu 12.04 to 14.04 to see what breaks. |
| 10:41 |
csharp |
Dyrcona: see the message on e56f3e59 regarding the replacement PO JEDI template |
| 13:33 |
gmcharlt |
I'm not; not on that basis, anyway |
| 13:35 |
RoganH |
I understand and I can see your position even if I come to a different conclusion. |
| 13:36 |
RoganH |
I suspect my position will be in the distinct minority when it comes to voting anyway and I won't be heart broken to be out voted. |
| 14:06 |
jeffdavis |
So does 2.6 require Postgres 9.3, or is 9.1 fine? |
| 14:07 |
jeffdavis |
I'm running 2.6 on a test server with a 9.1 db now and haven't run into any issues, but haven't thoroughly tested so far. |
| 14:08 |
bshum |
jeffdavis: 9.1 is fine |
| 14:08 |
bshum |
9.3 should work though |
| 14:08 |
bshum |
Or at least, that's what a bunch of bugs were directed at fixing |
| 14:09 |
jeffdavis |
thanks! |
| 14:17 |
dbs |
9.3 should work as of 2.6, right? |
| 14:18 |
dbs |
So upgrade from 2.5 to 2.6 on 9.1, then upgrade from 9.1 to 9.3 |
| 14:18 |
bshum |
dbs: That's the general idea. |
| 14:18 |
bshum |
I think |
| 14:18 |
bshum |
I didn't test it that way though, now that you mention it. |
| 14:19 |
bshum |
I just did 9.1 to 9.3 first, then upgraded the rest of the way from where I left off in my numbered scripts. |
| 14:19 |
bshum |
Ignoring any broken parts of the restore (since those were broken things fixed with the upgrade SQL) |
| 14:20 |
dbs |
Yeah. I wonder if there are clear pros to either approach for "normal" sites |
| 14:20 |
bshum |
Depends on how you do the PG upgrade I guess. |
| 14:20 |
bshum |
I think we'll also be moving to new hardware at the same time for us. So we have *lots* of moving parts in our equation. :\ |
| 14:31 |
gsams |
huzzah! |
| 14:37 |
Dyrcona |
If you run the upgrade SQLs before doing the upgrade of the database to 9.3, then the database should restore just fine. |
| 14:38 |
* Dyrcona |
chimes in a little late. |
| 14:38 |
Dyrcona |
bshum: Are you doing your production upgrade or is this a test? |
| 14:39 |
bshum |
Dyrcona: This is the hardware we're using for production upgrade. |
| 14:39 |
bshum |
Though I guess we're testing it the next couple weeks. |
| 14:39 |
Dyrcona |
bshum: I misunderstood when you said "mceraso is doing our next upgrade." I think I get it now. |
| 14:39 |
Dyrcona |
We're upgrading this Sunday, Mother's Day, and I'm doing this one. |
| 14:40 |
bshum |
Dyrcona: Ah, cool. Our upgrade will be Memorial Day weekend. |
| 14:40 |
bshum |
Doing both the switch to new hardware and Evergreen upgrade |
| 14:40 |
Dyrcona |
We've had staff testing it on our training server for the past few weeks. |
| 14:40 |
dbs |
yous++ |
| 14:40 |
bshum |
Dyrcona++ # going first this time ;) |
| 14:41 |
Dyrcona |
Heh. |
| 15:04 |
jl- |
imo VM is really all you need for unix |
| 15:05 |
jl- |
I love my raspberry pi though |
| 15:06 |
Dyrcona |
jl-: I disagree. For some applications, I prefer to run them on a dedicated, real machine in production. |
| 15:08 |
Dyrcona |
VMs are awesome for testing and development, and for smaller things in production. |
| 15:08 |
bshum |
Heh, for want of a USB memory drive, Ubuntu could not be installed on this machine :) |
| 15:08 |
bshum |
(yet) |
| 15:08 |
Dyrcona |
Heh, funny you mention that..... |
| 16:11 |
pinesol_green |
jeff: Try restarting apache. |
| 16:11 |
jeff |
zoia++ |
| 16:12 |
berick |
heh, zoia muscle memory |
| 16:15 |
gsams |
csharp: as far as I can see everything seems to be working. My current predicament tells me otherwise though. |
| 16:15 |
gsams |
postgres isn't throwing any issues related to the permissions, and as far as I can tell it is returning both ADMIN_TRIGGER and UPDATE_TRIGGER at the same time |
| 16:18 |
gsams |
maybe it's just the test server... |
| 16:18 |
jeff |
berick: i was intentionally incrementing zoia for having @decide, where pinesol_green does not. ;-) |
| 16:19 |
bshum |
It probably could. |
| 16:19 |
berick |
jeff: ohh, missed that |
| 16:21 |
bshum |
Yeah it's part of the original Assorted plugin, which we've only adapted bits and pieces of over time. |
| 16:21 |
gsams |
it is the test server |
| 16:22 |
gsams |
something isn't configured correctly I guess... |
| 16:47 |
bshum |
So has anyone ever seen this before, where Linux reads off the network device as "em1", "em2", etc. and not "eth0", "eth1" |
| 16:47 |
bshum |
It's kind of freaking me out, but nothing seems quite right with it other than the name. |
| 16:47 |
berick |
i've seen all manner of names |
| 16:49 |
bshum |
Thanks everyone, not going to freak out for now. |
| 16:55 |
jeff |
berick's "i've seen all manner of names" came across in a james earl jones voice. |
| 16:56 |
jeff |
"I'm interested in all kinds of astronomy." |
| 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> |
| 17:00 |
berick |
heh, too bad instead of wise / world-weary, I was really going for, "it's all crazy talk to me" |
| 17:04 |
|
mmorgan left #evergreen |
| 17:12 |
bshum |
jeff: That's one of my favorite movies :) |
| 03:48 |
|
eby__ joined #evergreen |
| 04:57 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:04 |
|
serflog joined #evergreen |
| 06:04 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged. | Large pastes at http://paste.evergreen-ils.org |
| 06:28 |
|
dac joined #evergreen |
| 09:28 |
|
jwoodard joined #evergreen |
| 09:28 |
* csharp |
wonders if it's worth trying to backport the new marc_export script to 2.5.1 |
| 09:29 |
csharp |
I'm doing a full DB + holdings export, and that takes us about 48 hours with the "old" script |
| 09:31 |
bshum |
csharp: It's not scientific, but doing a parallel export test when that new marc_export was merged got me my whole DB in less than two hours what used to take 26 hours consecutive extracting. |
| 09:32 |
bshum |
(i.e. it might be worth it, if you're not planning to upgrade again for awhile) |
| 09:34 |
|
yboston joined #evergreen |
| 09:39 |
* Dyrcona |
thinks the new marc_export will just work on 2.5.1. |
| 09:39 |
jeff |
i don't think there's much to backport, yeah. |
| 13:01 |
Dyrcona |
Then you can git merge the custom branches into it. |
| 13:02 |
Dyrcona |
We base our custom branches on the master branch, because when we upgrade, we checkout from the master branch. |
| 13:02 |
Dyrcona |
For instance, we're upgrading this coming weekend. |
| 13:02 |
Dyrcona |
We also loaded everything on our training server in advance to give our members a chance to look at things and find any bugs that we missed during preliminary testing. |
| 13:03 |
eeevil |
csharp: sorta ... sick day :| |
| 13:04 |
Dyrcona |
We made the branch on the 16th of April and named it mvlc_20140416. |
| 13:04 |
csharp |
I'll just ask my question to the full channel (though I'd be happy if eeevil sees it) - I am making some edits to the reporter.classic_item_list definition in fm_IDL.xml, and wanted to know if it is correct to denote the "rel" attribute of the link between reporter.classic_item_list and our "legacy" stat cats as "might_have" rather than "has_a" |
| 13:05 |
Dyrcona |
It has had two or three bug fixes applied as well as our custom branches. |
| 13:05 |
|
tjspindler joined #evergreen |
| 13:05 |
csharp |
for reference http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=0e114d1d33e4f23e28c43c3a5ef04bc8718348e3 |
| 13:06 |
Dyrcona |
It is a good idea to rebase your custom branches periodically to keep them up to date with changes or when you want to test a new branch, like going from 2.5 to 2.6 . |
| 13:06 |
eeevil |
csharp: checking something before answering ... working from memory is not a good idea today ;) |
| 13:06 |
csharp |
eeevil: understood |
| 13:08 |
|
mrpeters joined #evergreen |
| 17:27 |
|
vlewis joined #evergreen |
| 17:29 |
kmlussier |
All kidding aside, the thing that concerns me about all of our lists is that a new person entering the community might send a request for help to a low traffic list not knowing that he/she may get more responses if the same request were sent to the general list. |
| 17:30 |
kmlussier |
I'm primarily thinking of the sys admin list, where I've seen a couple of questions languish. |
| 17:30 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:34 |
|
krvmga joined #evergreen |
| 18:58 |
|
mjingle joined #evergreen |
| 20:02 |
|
doug joined #evergreen |
| 08:59 |
pinesol_green |
kmlussier: The operation succeeded. Dessert #8 added. |
| 09:07 |
tspindler |
bshum: thanks, I have a vague understanding about what they might mean but I don't want to assume, you know what they say about assuming |
| 09:08 |
|
jeff___ joined #evergreen |
| 09:10 |
bshum |
tspindler: I just sent the reply, I think I'll take some of what I said and add it to the bug wrangler wiki page for the milestone section of the page. |
| 09:11 |
bshum |
tspindler: Thanks for asking the question, it's something I've been a bit delinquent in getting fully explained in my past roles. |
| 09:12 |
|
akilsdonk joined #evergreen |
| 09:13 |
bshum |
tspindler: I just realized I didn't say anything specific about the one bug you linked to |
| 09:14 |
bshum |
I note in https://bugs.launchpad.net/evergreen/+bug/1086550/comments/13 that I guess I removed the pullrequest tag off the bug because there were conflicting approaches being suggested and we hadn't reached a final conclusion over what code we were testing/reviewing. |
| 09:14 |
pinesol_green |
Launchpad bug 1086550 in Evergreen "TPAC: Not clear to patron how to deselect a facet" (affected: 5, heat: 24) [Wishlist,Confirmed] |
| 09:14 |
bshum |
Without an active pullrequest and the unfinished discussion, I guess this one slipped through the cracks during development cycles for 2.5, etc. |
| 09:17 |
bshum |
My recommendation is to take back the conversation and get a new pullrequest on the bug with the code that should be reviewed. |
| 09:27 |
bshum |
That said, historically, our core group of bug wranglers have been a bit lax in this department. :( |
| 09:28 |
dbs |
bshum: suggestion for the "deleted record" that might make everyone happy - just add an extra @class value that sites that don't want greyed-out bibs can just override in their CSS with background-color: inherit; or whatever? |
| 09:29 |
kmlussier |
Since LP already allows any LP user to mark it as confirmed, I expect some people will do it whether it's part of our best practices or not. And I don't think that's a bad thing. We just need to be aware that there may be a valid reason why an importance isn't set when somebody marks a bug as confirmed. |
| 09:29 |
tspindler |
If i can chime in, i thinnk keeping the status changes to the bug wrangler team is important, i think it could really muddy things if all users could do this. A regular user can argue in a comment section for its importance or indicate it was tested. |
| 09:29 |
kmlussier |
+1 to dbs' suggestion. |
| 09:29 |
kmlussier |
tspindler: I'm not advocating that all users set the importance level. But I do think it's a good thing that they can mark it as confirmed. |
| 09:29 |
bshum |
dbs: That's a fair suggestion. I'm not even sure how much my users will even notice or complain about its return. I was just being grumpy yesterday :\ |
| 12:11 |
kmlussier |
Yeah, 33 doesn't look right to me. |
| 12:11 |
krvmga |
kmlussier: this search http://bark.cwmars.org/eg/opac/results?query=guns%20of%20navarone;qtype=keyword;locg=1;detail_record_view=1;page=1 number 19 |
| 12:11 |
krvmga |
kmlussier: the last library is not in alphabetical order |
| 12:11 |
kmlussier |
I have another thought. Hold on, let me look up the bug number... |
| 12:12 |
kmlussier |
I know https://bugs.launchpad.net/evergreen/+bug/1234845 was loaded on your test server a while back, and we talked about loading it in production because it looked good under my testing. |
| 12:12 |
pinesol_green |
Launchpad bug 1234845 in Evergreen "possible optimization for evergreen.ranked_volumes database function" (affected: 2, heat: 12) [Medium,Triaged] |
| 12:13 |
kmlussier |
Do you know if it ever was loaded in production? Because, if so and if my testing didn't catch something, that's where you would see the problem. |
| 12:14 |
krvmga |
kmlussier: i do not know if it was. i'll see if i can find out. |
| 12:14 |
kmlussier |
Nice. I actually listed what the expected ranking behavior was in my testing notes. It should be preferred library -> search library name ->call number label -> availability. |
| 12:17 |
jeff |
asking because it just came up in conversation: does anyone have an example of where you might use a copy's "reference" attribute vs the copy's "circulate" attribute (or perhaps more commonly, the copy's location's "circulate" attribute)? |
| 12:18 |
jeff |
i.e., is there a situation where "reference" wouldn't just be an inverse of "circulate"? |
| 12:19 |
gmcharlt |
jeff: to explain why it doesn't circulate, particulary for reference books that are interfiled with circulating material |
| 16:48 |
bshum |
Then give it to you for a quick glance and merge ;) |
| 16:48 |
gmcharlt |
ok |
| 16:55 |
bshum |
gmcharlt: Bug updated https://bugs.launchpad.net/opensrf/+bug/1315525 |
| 16:55 |
pinesol_green |
Launchpad bug 1315525 in OpenSRF "Add Ubuntu 14.04 makefile target for OpenSRF" (affected: 1, heat: 6) [Medium,Confirmed] |
| 17:08 |
|
bmills joined #evergreen |
| 17:17 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:30 |
pinesol_green |
[opensrf|Chris Sharp] LP#1315525: Updating Makefile.install for Ubuntu 14.04. Removing lucid support. - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=be5c3d8> |
| 17:30 |
pinesol_green |
[opensrf|Ben Shum] LP#1315525: Add trusty target and remove lucid from README - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=65ce998> |
| 17:41 |
bshum |
Thanks gmcharlt! Now the fun part, getting Evergreen squared away.... |
| 17:58 |
|
edoceo joined #evergreen |
| 18:09 |
bmills |
https://bugs.launchpad.net/evergreen/+bug/1315552 |
