| 01:25 |
|
bwicksall joined #evergreen |
| 03:25 |
|
ldwhalen joined #evergreen |
| 03:51 |
|
atlas__ 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> |
| 07:47 |
csharp |
@later tell jeff yeah - it was to update openssl, etc. |
| 07:47 |
pinesol_green |
csharp: The operation succeeded. |
| 08:06 |
|
kmlussier joined #evergreen |
| 09:42 |
csharp |
jeff: sorry - looking at dpkg.log and it appears I read "openssh" as "openssl" |
| 09:45 |
jeff |
csharp++ mischief managed! |
| 09:54 |
jboyer-isl |
jeff: my memory appears to have failed me. I know I saw it somewhere, but it's possible it was on a forum or something not quite official. (I'd imagine the official advice is always "update everything unless you have a good reason not to") |
| 09:55 |
csharp |
gmcharlt: following up on my testing the 14.04 install scripts for OpenSRF/Evergreen... you probably saw that I stalled on libdbi location issues - I haven't had a chance to get back to it, FYI |
| 09:55 |
|
denishpatel joined #evergreen |
| 09:56 |
* csharp |
is busy today and tomorrow putting in hardware orders, troubleshooting something that has broken multiple PINES reports templates, and other paperwork-y things |
| 10:04 |
|
atlas__ joined #evergreen |
| 10:07 |
|
kmlussier joined #evergreen |
| 10:13 |
|
jwoodard joined #evergreen |
| 11:29 |
kmlussier |
@marc 240 |
| 11:29 |
pinesol_green |
kmlussier: The uniform title for an item when the bibliographic description is entered under a main entry field that contains a personal (field 100), corporate (110), or meeting (111) name. [a,d,f,g,h,k,l,m,n,o,p,r,s,6,8] |
| 11:40 |
dkyle |
In 2.6, anyone else see marc expert search queries take way too long, resulting in nothing found? |
| 11:41 |
yboston |
Dyrcona: I loaded up your RDA changes to my EG 2.5.x test server. Waiting for cataloger feedback |
| 11:42 |
Dyrcona |
yboston: OK. |
| 11:42 |
* dbs |
adds "Add schema.org to RDA branch" to his actual to-do list, not just his mental overload list |
| 11:45 |
gmcharlt |
heads up -- I will be running apt-get upgrade on the Git server shortly |
| 13:10 |
|
kbeswick_ joined #evergreen |
| 13:10 |
eeevil |
there we go |
| 13:13 |
|
rfrasur joined #evergreen |
| 13:15 |
gmcharlt |
I've just discovered an annoying little dependency glitch |
| 13:15 |
|
hbrennan joined #evergreen |
| 13:17 |
gmcharlt |
Business::Stripe has POD test cases that are broken, so if Test::Pod is installed (which it would be on Debian and Ubuntu if you follow the OpenSRF install instructions), cpan Business::Stripe fails |
| 13:18 |
gmcharlt |
so I think that for the moment Business:Stripe will need to be moved to CPAN_MODULES_FORCE |
| 13:18 |
eeevil |
gmcharlt: do we have a "force" list? |
| 13:18 |
gmcharlt |
just curious whether anybody else had run into this |
| 13:18 |
eeevil |
heh ... so, yeah |
| 14:18 |
kmlussier |
I concur. yboston is awesome! :) |
| 14:18 |
tonyb_ohionet |
and I have some 2.6 stuff bit size to try but we're still at 2.4 |
| 14:18 |
kbutler |
yboston++ |
| 14:18 |
* yboston |
blushes |
| 14:19 |
yboston |
ESI has a 2.5 server that can be used for updating docs |
| 14:19 |
yboston |
Eventually they can provide a 2.6 test server |
| 14:19 |
dkyle |
eeevil: will sign off... trying to figure out how, i haven't used git much lately |
| 14:19 |
jihpringle |
yboston: the Sitka 2.6beta server can still be used at the moment |
| 14:19 |
tonyb_ohionet |
gotcha...I could start with that then... |
| 14:19 |
akilsdonk |
yes, the ESI test server will be upgraded for 2.6 |
| 14:19 |
yboston |
akilsdonk: cool |
| 14:20 |
yboston |
so should those that can commit to the July 1st deadline add ourselves to one of the wiki pages, then we can start assigning stuff to ooursleves or each other? |
| 14:21 |
kmlussier |
Let's start with the 2.6 wiki page to make sure those features are done. |
| 14:39 |
remingtron |
and asking the developers is a great idea too. they can explain more about their features. |
| 14:39 |
kmlussier |
I'm happy to pair up with someone too. |
| 14:40 |
remingtron |
who wants a DIG partner for this round of features? |
| 14:40 |
jl- |
I'm currently in the process of migrating 18 libraries (for test purposes) from voyager -> eg, so I'm hoping I can add something about migration or voyager specific migration at some point. migration seems to be rather undocumented (because ILS.* are unfortunately so different) |
| 14:40 |
yboston |
I always want to ask developers where they envisioned the documentation living, in case they had thought about it. it can be tricky deciding in a vacuum if it should be in admin settigns or in OPAC settings, etc |
| 14:40 |
yboston |
hence why I suggest teaming up for the first month |
| 14:41 |
dbs |
yboston: devs might not be the best people to ask about where docs should live; different mindsets |
| 15:08 |
jeff |
shart290: first question -- was the machine in question running just the staff client, or was it running the server components of Evergreen as well? |
| 15:08 |
jeff |
ah, sounds like it was running server components as well. |
| 15:08 |
shart290 |
it was running everything. It was the server. |
| 15:09 |
jeff |
Was this a testing/development instance of Evergreen, or something that was being used in production for real work? |
| 15:09 |
|
Dyrcona1 joined #evergreen |
| 15:09 |
shart290 |
it was production, something happened to the machine a couple of months ago and nobody said anything til last week. I got in yesterday, never having laid a finger on it before. |
| 15:10 |
shart290 |
I am familiar and comfortable with Linux, but I have hit a dead end in my expertise |
| 17:27 |
bshum |
That's why I'm concerned as to why the misc_util.tt2 seems to be lying to us |
| 17:27 |
yboston |
in the reults |
| 17:27 |
yboston |
*resutls |
| 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:31 |
bshum |
Grr, finding a bib with actual holdings is such a chore sometimes |
| 17:31 |
* bshum |
is looking for a sample from my system |
| 17:32 |
bshum |
Interesting... |
| 10:52 |
Dyrcona |
Hmm. Our records are using OCLC elvl with capital letters sometimes. Could that a part of why it doesn't work for me? |
| 10:52 |
gmcharlt |
eeevil: I'm actually right at the end of that mode - was focusing on 2.6.0 bugs specifically, and you saw my request for somebody to deal with the fixed-field editor pullrequests |
| 10:53 |
eeevil |
I did indeed |
| 10:53 |
gmcharlt |
I may poke at testing and writing test cases for 1304559 later this afternoon, but that shouldn't be construed as a reason for anybody to not work on that one |
| 10:54 |
eeevil |
Dyrcona: shouldn't be ... the current content of the field should not matter to the existence (or not) of the context menu. only missing cmf and ccvm rows should cause what you're seeing. (a missing ELvl ccmv ctype and set of values, specifically) |
| 10:56 |
|
kbutler joined #evergreen |
| 10:57 |
Dyrcona |
No elvl in ccvm. |
| 11:10 |
pinesol_green |
[evergreen|Jeff Godin] Add alert in user editor for method errors - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3d59a01> |
| 11:10 |
Dyrcona |
I have 7 distinct ctypes in production and 11 in development. |
| 11:10 |
Dyrcona |
I wonder if an upgrade script is missing somewhere. |
| 11:11 |
bshum |
I have 13 ctypes in our test system |
| 11:13 |
* bshum |
wonders what the extras are |
| 11:13 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "My ctypes in development" (14 lines) at http://paste.evergreen-ils.org/52 |
| 11:14 |
bshum |
The only additional ones I seem to have are "biog" and "ser_type" |
| 11:14 |
Dyrcona |
Well, I dunno. |
| 11:21 |
eeevil |
let me retract that statement |
| 11:21 |
eeevil |
those are NOT stock |
| 11:22 |
Dyrcona |
Should they be? |
| 11:22 |
eeevil |
ideally, yes, but they were added by hand on a test system. |
| 11:22 |
eeevil |
by not-me ;) |
| 11:22 |
bshum |
Hmm |
| 11:24 |
bshum |
Well that's... special. |
| 11:24 |
* bshum |
waits for eeevil's next trick |
| 11:24 |
bshum |
:D |
| 11:24 |
gmcharlt |
Dyrcona++ # stumbling across a potential new release-blocker ;) |
| 11:24 |
eeevil |
Dyrcona: so, to test, you'd have to create a ccvm set attached to the enc_level crad |
| 11:25 |
eeevil |
well, now, getting the appropriate data is non-trivial, and it is 100% configuration (as in, you can do it all through the staff client) |
| 11:25 |
eeevil |
so I really hesitate to consider that a release blocker |
| 11:26 |
* bshum |
twitches |
| 11:32 |
Dyrcona |
Do the ctype values matter? I mean are those referenced in code somewhere? |
| 11:32 |
eeevil |
Dyrcona: they are fkeys to crad.name |
| 11:35 |
Dyrcona |
jeff: The plug-in? Or did the use the --app command line option? |
| 11:36 |
bshum |
Unrelated, I think the docs site is down :( |
| 11:36 |
gmcharlt |
eeevil: release blocker may be too strong, but IMO most of it *ought* to be in the seed data |
| 11:36 |
* bshum |
concurs with Dyrcona on the upgrade script being helpful to get everybody following along on the same page for testing consistently. |
| 11:37 |
eeevil |
I'm not against that in the least |
| 11:38 |
gmcharlt |
a timing and tuit issue, then |
| 11:41 |
Dyrcona |
I'll do it. |
| 12:02 |
|
kmlussier joined #evergreen |
| 12:12 |
|
Christineb joined #evergreen |
| 12:13 |
phasefx |
Dyrcona++ |
| 12:24 |
Dyrcona |
phasefx gmcharlt eeevil: Could one of you paste the results of "select * from config.coded_value_map" on that test server, please? That would speed up the work that I need to do to write an upgrade script. |
| 12:30 |
remingtron |
bshum: docs site is alive again |
| 12:30 |
kmlussier |
Yay! |
| 12:33 |
Dyrcona |
yay! |
| 12:38 |
|
atlas__ joined #evergreen |
| 12:39 |
|
ericar_ joined #evergreen |
| 12:55 |
|
hbrennan joined #evergreen |
| 12:59 |
eeevil |
Dyrcona: I can, but it contains both incomplete and test (read: fake, incorrect) values. if that's still of use to you, I'll grab it |
| 13:00 |
Dyrcona |
eeevil: Never mind, then. I'll see what I can come up with on my own, then. |
| 13:03 |
gmcharlt |
Dyrcona: a possiblity for you - http://git.koha-community.org/gitweb/?p=koha.git;a=tree;f=koha-tmpl/intranet-tmpl/prog/en/data;h=129c3a2518f0df1b1012ad3d2ee6851385c2f9eb;hb=HEAD |
| 13:04 |
gmcharlt |
specifically, it may give you something more readily parseable than screen-scraping LC's website |
| 13:20 |
* bshum |
will report back |
| 13:25 |
|
ldwhalen joined #evergreen |
| 13:25 |
|
kbeswick_ joined #evergreen |
| 13:30 |
dbwells |
bshum: rats. I will be in meetings from now through 3:30, but will try to check it out again after that. Thanks for testing. |
| 13:35 |
Dyrcona |
Oh forget it. I don't have time for that. |
| 13:41 |
|
Dyrcona joined #evergreen |
| 13:42 |
Dyrcona |
Damn laptop. |
| 14:12 |
hbrennan |
Where issuances can be edited or deleted |
| 14:12 |
kmlussier |
Oh, sorry. I misunderstood. |
| 14:12 |
hbrennan |
kmlussier: How is that possible? There are only a thousand different methods of looking at serials. :) No worries |
| 14:13 |
bshum |
dbwells: Using the replaced function the way you wrote it I guess for _flat, Mary reports successful linking in her test between bibs in the queue vs. catalog. |
| 14:14 |
bshum |
So that's better than hanging forever |
| 14:14 |
eeevil |
bshum: cool. let's go with that one, then |
| 14:14 |
kmlussier |
bshum: How is the speed? |
| 14:14 |
bshum |
kmlussier: Unsure |
| 14:15 |
kmlussier |
Phew! |
| 14:16 |
kmlussier |
mllewellyn++ bshum++ |
| 14:16 |
* rfrasur |
smiles |
| 14:16 |
bshum |
It's only a 3 bib file she says, but certainly faster than not completing at all. |
| 14:16 |
bshum |
:) |
| 14:16 |
bshum |
She's testing a vandelay load next. Her first test was with acq only. |
| 14:21 |
bshum |
Regular loader seems fine too |
| 14:21 |
bshum |
mllewellyn++ |
| 14:21 |
rfrasur |
mllewellyn++ |
| 14:22 |
kmlussier |
@dessert mllewellyn |
| 14:22 |
* pinesol_green |
grabs a scoop of Lemon Sherbert and sends it sliding down the dessert bar to mllewellyn |
| 16:14 |
Dyrcona |
I see why the bookmobile would not work outside of its parent branch. |
| 16:16 |
|
jwoodard joined #evergreen |
| 16:16 |
Bmagic |
Dyrcona: That's right! I think I can close the book on this one. I will check that next time. The answer here is that the patron's ou is not "branch" but instead "bookmobile" and the permissions for the staff is set to "branch" |
| 16:21 |
dbwells |
bshum: meetings ran over, just got back. Thanks for the testing on bug #1304559. |
| 16:22 |
pinesol_green |
Launchpad bug 1304559 in Evergreen "acq and cataloging loader broken in 2.6-rc" (affected: 4, heat: 22) [Critical,Confirmed] https://launchpad.net/bugs/1304559 |
| 16:23 |
Dyrcona |
Bmagic: Do your users have more than 1 work_ou in the work_ou_map? |
| 16:23 |
dbwells |
bshum: would you mind posting an update on the bug? I'm not sure if I'll be able to do anything with it right away, so I don't want to be the bottleneck if someone else can take your info and run with it. |
| 17:00 |
Bmagic |
Dyrcona: But doing that doesn't solve my issue. It souds like I need to elevate the staff client login to system |
| 17:00 |
Bmagic |
later |
| 17:00 |
Bmagic |
Dyrcona++ |
| 17:14 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:14 |
|
mmorgan left #evergreen |
| 17:18 |
* csharp |
runs apt-get update && apt-get dist-upgrade on lupin |
| 17:20 |
pinesol_green |
[evergreen|Mike Rylander] LP#1303987: Fully populate Ills from context menu - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f82055d> |
| 00:27 |
|
zerick joined #evergreen |
| 01:05 |
|
timlaptop joined #evergreen |
| 05:14 |
pinesol_green` |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:39 |
|
jboyer-isl joined #evergreen |
| 05:39 |
|
wjr joined #evergreen |
| 05:39 |
|
wjr joined #evergreen |
| 09:52 |
asimon |
What is the best way to delete all patrons from the database and load them again (with the same barcode numbers)? |
| 09:53 |
bshum |
asimon: Out of curiousity, what are you attempting to gain by doing so? |
| 09:53 |
Dyrcona |
asimon: Blow the database out and start over. |
| 09:54 |
asimon |
bshum: I'm trying to replace a test set of patrons with the latest information. |
| 09:54 |
asimon |
Dyrcona: I can't do that because of all the other information in the database. |
| 09:55 |
Dyrcona |
asimon: Then, you're mostly stuck because of referential integrity triggers. |
| 09:55 |
Dyrcona |
asimon: Assuming the patrons are tests, shouldn't the rest of the data be test data, too? [Though I guess not.] |
| 09:56 |
|
atlas__ joined #evergreen |
| 09:57 |
bshum |
In our system, we load student data during new schoolyears and overlay the original entry in Evergreen with new data based on a matching identifier (like student ID or barcode) |
| 09:59 |
asimon |
Dyrcona: No. I have deleted the sample bib and copy records and I am loading a new set beginning with a different id range, and I want to do the same thing with the patron records, but I'm getting: ERROR: duplicate key value violates unique constraint "usr_usrname_key" |
| 10:55 |
|
phasefx joined #evergreen |
| 10:56 |
|
jwoodard joined #evergreen |
| 10:57 |
|
Sato`kun joined #evergreen |
| 11:00 |
yboston |
Dyrcona++ # wading through RDA |
| 11:01 |
|
ericar joined #evergreen |
| 11:03 |
yboston |
Dyrcona: let me know how I can help. I don't have a 2.6.x VM set up right now but I can set one up to test RDA or authority code out, etc. |
| 11:06 |
|
pmurray_away joined #evergreen |
| 11:10 |
Dyrcona |
yboston: That branch should apply to 2.5 at least. |
| 11:10 |
yboston |
Dyrcona: that is what I was hoping as I looked at the code |
| 11:11 |
yboston |
Dyrcona: would you like me to try it out on my test 2.5.x server? |
| 11:11 |
|
Wyuli joined #evergreen |
| 11:11 |
Dyrcona |
yboston: If you want to, just cherry-pick the top commit. |
| 11:12 |
yboston |
Dyrcona: I will have to do it manually since the tests ervers I have are not git based, but it should not be too hard |
| 11:20 |
|
kmlussier joined #evergreen |
| 11:27 |
|
Guest25194 joined #evergreen |
| 11:34 |
Dyrcona |
Is the dev. meeting today? |
| 11:57 |
eeevil |
asimon: it does not. jeff: right |
| 11:57 |
* eeevil |
looks for that code... |
| 12:15 |
|
jihpringle joined #evergreen |
| 12:22 |
bshum |
kmlussier: I think they're required because PINES required them :) So we inherit that from them. |
| 12:25 |
bshum |
jihpringle: Huh... have you guys updated your test server to 2.6-rc yet? |
| 12:25 |
|
ningalls joined #evergreen |
| 12:26 |
bshum |
jihpringle: I've got some reports on our test system that the acq/cataloging loader (vandelay) isn't matching anymore and basically just running forever with no results. |
| 12:26 |
jihpringle |
bshum: not yet, but we're hoping to have a test server running 2.6rc soon |
| 12:27 |
bshum |
jihpringle: All good, I'm digging through things on my end to try figuring out what's happening with our system and if maybe we're just on the tail end of some bad setup |
| 12:27 |
bshum |
jihpringle: I'm crossing my fingers that it's something small and we didn't break acq and cataloging before 2.6.0 :\ |
| 12:27 |
jihpringle |
fingers crossed |
| 12:28 |
jihpringle |
I'll find out when we're getting our new test server and take a look at this as soon as we do |
| 12:41 |
Dyrcona |
bshum: I've emailed our catalogers to ask them to test Vandelay on our training server. It is up to date as of Friday. |
| 12:41 |
bshum |
Dyrcona: Cool, that's appreciated. |
| 12:41 |
eeevil |
asimon: http://pastebin.com/nDj80KVW ... that's from a pre-staging schema, custom thing, but I think it's close. it'll update or insert staged patrons, matching on the barcode |
| 12:42 |
kmlussier |
bshum / jihpringle / Dyrcona: I just loaded order records on Dyrcona's dev system without any problems. |
| 12:59 |
dbs |
Even the bestest RDFa in the world isn't going to smooth that over. |
| 13:01 |
kmlussier |
Dyrcona: How recent is master on your training server? I know this was working a couple of weeks ago, but if you've updated it since then, it might affect your acq pilots. |
| 13:04 |
Dyrcona |
kmlussier: I updated it Friday. |
| 13:05 |
Dyrcona |
kmlussier: I reloaded the database, too, forgetting that it would blow out their test acquisitions data. |
| 13:05 |
Dyrcona |
On the plus side, they get more acquisitions practice. :) |
| 13:06 |
Dyrcona |
+1 to release blocker status |
| 13:06 |
kmlussier |
Dyrcona: Heh. I'll send them a quick e-mail asking them to hold off on trying order record uploads for a while. |
| 13:24 |
pinesol_green |
Launchpad bug 1304559 in Evergreen "acq and cataloging loader broken in 2.6-rc" (affected: 1, heat: 6) [Critical,Confirmed] |
| 13:24 |
bshum |
I'll start looking for what's broken next, but I've filed the bug to start |
| 13:24 |
bshum |
Well, maybe right after lunch |
| 13:34 |
* jeff |
exploits a test wheezy system |
| 13:34 |
jeff |
yup. |
| 13:34 |
jeff |
that easy. |
| 13:46 |
bshum |
14 minutes till the dev meeting |
| 13:46 |
bshum |
There's a few action items on the list from past meeting |
| 13:46 |
bshum |
See agenda: http://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2014-04-08 |
| 14:24 |
kmlussier |
dbwells: Yes, looks like I fogot to do that. I can target it now. |
| 14:24 |
dbwells |
kmlussier: thank you! |
| 14:25 |
eeevil |
I'll raise my hand for 1304559 ... I think dbwells is on the right track in the bug comment |
| 14:25 |
bshum |
fwiw, we added the icons kmlussier mentions in the branch to our test system and it seemed fine. So I'd be happy to push things along. |
| 14:25 |
gmcharlt |
jeff: I think 1303940; since it looks like Dyrcona has reviewed it and given a (virtual) signoff, I'll do a final test and push it today |
| 14:25 |
gmcharlt |
s/1303940/1303940 is/ |
| 14:26 |
dbwells |
jeff: I guess we'll see :) |
| 14:26 |
Dyrcona |
I'd like to see some thought given to dbwells' suggestion on 1303940. |
| 14:26 |
gmcharlt |
(and look at dbwells comment) |
| 14:29 |
jeff |
#info Please review the acknowledgements for Evergreen 2.6 and make any additions/updates |
| 14:29 |
jeff |
#link https://bugs.launchpad.net/evergreen/+bug/1302113 bug 1302113 - acknowledgments in release notes |
| 14:29 |
pinesol_green |
Launchpad bug 1302113 in Evergreen 2.6 "acknowledgments in release notes" (affected: 1, heat: 6) [Undecided,New] |
| 14:29 |
dbwells |
eeevil: I did a very quick test of subbing in record_attr_flat for record_attr in vandelay._get_expr_push_jrow(). So far, nothing exploded, but I haven't tested it very hard yet. |
| 14:29 |
jeff |
#info Evergreen 2.5 bug fixes? |
| 14:30 |
jeff |
dbwells: you're still wearing the release maintainer hat for 2.5, correct? |
| 14:30 |
eeevil |
dbwells: that will work fine, I'm only concerned about performance ... my plan is to look directly at the vector |
| 14:33 |
jeff |
#info Evergreen 2.4 - final release? |
| 14:33 |
eeevil |
I'll align that with dbwells' next week |
| 14:33 |
eeevil |
after pushing in as many fixes as we can safely |
| 14:34 |
jeff |
#info Final planned Evergreen 2.4 maintenance release scheduled for April 16 |
| 14:35 |
jeff |
eeevil, dbwells: any specific things that either of you would like to call attention to in terms of things that you'd like more testing/eyeballs on for any of the above releases? |
| 14:35 |
dbwells |
jeff: nothing I can think of, thanks |
| 14:36 |
eeevil |
nothing specific |
| 14:37 |
jeff |
moving on! |
| 15:08 |
dbwells |
bshum: I was thinking of branching at RC, but at this point, we might as well wait for .0, I think. |
| 15:08 |
dbwells |
so, yest |
| 15:08 |
dbwells |
I mean yes |
| 15:09 |
bshum |
Cool deal. I'll try adding new things later this evening if I can carve out some time to test more and signoff |
| 15:09 |
dbwells |
bshum: kmlussier: here's a very quick attempt at ferreting out the Vandelay issue - http://pastebin.com/CtujPy6z |
| 15:09 |
bshum |
I can drop that into our test system and see what happens. |
| 15:10 |
dbwells |
I know eeevil is cooking up something better, but this should be really easy to test, and might tell us if we're on the right track. |
| 15:10 |
bshum |
Will do |
| 15:10 |
kmlussier |
dbwells++ |
| 15:10 |
kmlussier |
I'll leave it in bshum's capable hands while I head home. :) |
| 15:45 |
Melanion |
The CRs in question were added in 8/13, at which time our system was running..2.3? Maybe 2.2. So it could have happened before the fix. |
| 15:47 |
dbwells |
bshum: you can ignore my earlier function paste, I accidentally threw an extra '=' in there anyway. |
| 15:48 |
mmorgan |
Someone correct me if I'm wrong, but I believe nullifying action.circulation.xact_finish for those transactions would make them reappear on the patron records. |
| 15:48 |
dbwells |
bshum: We're better off testing this, since it's ready now: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/miker/1304559_and_1271661_vandelay_fixes |
| 15:49 |
Dyrcona |
mmorgan: I believe it would. |
| 15:52 |
bshum |
dbwells: That I can do. We didn't get to work on the first one, mary ended up heading out early for something else |
| 15:53 |
|
CleverNameHere joined #evergreen |
| 16:53 |
|
kmlussier joined #evergreen |
| 16:54 |
CleverNameHere |
So when running a report through evergreen it sends me a link to https://localhost/blah/blahblah/blahblahblah. Anyone know how |
| 16:54 |
CleverNameHere |
iI can configure that to our evergreen servers name |
| 16:57 |
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 |
jeff |
CleverNameHere: in your opensrf.xml configuration file, look at the value under reporter/setup/base_uri |
| 16:58 |
kmlussier |
I don't know the answer, but I wish I had come up with a screen name that's as clever as CleverNameHere's. :) |
| 17:03 |
|
Wyuli joined #evergreen |
| 17:18 |
* gmcharlt |
grabs 0854 |
| 17:19 |
gmcharlt |
bah |
| 17:19 |
gmcharlt |
correction, 0878 |
| 17:33 |
pinesol_green |
[evergreen|Jason Stephenson] LP 1303940: pg_tap regression test. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=16eec85> |
| 17:33 |
pinesol_green |
[evergreen|Galen Charlton] LP#1303940: improve readability of test case - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1764ceb> |
| 17:33 |
pinesol_green |
[evergreen|Mike Rylander] LP#1303940: Protect against bogus data that can breaking indexing - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c964cd4> |
| 17:33 |
pinesol_green |
[evergreen|Galen Charlton] LP#1303940: don't attempt to store NULL values in keyword, browse, or facet indexes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9984b11> |
| 17:33 |
pinesol_green |
[evergreen|Galen Charlton] LP#1303940: pin schema upgrade to 0878 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=149ffb3> |
| 17:33 |
jeff |
@who can breaking indexing? |
| 17:33 |
pinesol_green |
pmurray_away can breaking indexing. |
| 17:34 |
CleverNameHere |
Thanks Jeff. I found it. |
| 01:29 |
|
pinesol_green` joined #evergreen |
| 01:31 |
|
berick joined #evergreen |
| 01:33 |
|
DPearl 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> |
| 07:33 |
|
robbat2 joined #evergreen |
| 07:33 |
|
robbat2 joined #evergreen |
| 08:19 |
|
ericar joined #evergreen |
| 09:09 |
bshum |
Dyrcona: Yes, that happened to me. |
| 09:09 |
|
yboston joined #evergreen |
| 09:10 |
Dyrcona |
bshum: Did you figure it out? |
| 09:10 |
bshum |
Dyrcona: What I found was that local definitions were breaking things in browse for some reason. I never did get to the bottom of that with eeevil. |
| 09:10 |
bshum |
We had an added author entry that was also for browse and something in the xpath or such was breaking the indexing process. |
| 09:11 |
bshum |
I think I set it aside in my testing by making it not a browse entry for the moment and then things proceeded as expected. So something in how I defined a local index broke things. |
| 09:11 |
Dyrcona |
I'll check. We probably have a similar situation. |
| 09:11 |
bshum |
Though i'm not 100% sure why. |
| 09:11 |
bshum |
I think it was a combination of explicit marcxml definition vs. mods32 stuff |
| 09:11 |
Dyrcona |
I don't recall adding browse search definitions. As I recall, the one that I tried adding never worked. |
| 09:11 |
bshum |
And the browse-xpath entry borked something |
| 09:12 |
* dbs |
wonders if phasefx's live testing script could be repurposed to also leave a running system at dev.evergreencatalog.com at the end; and set up not just master, but also current stable for demo.evergreencatalog.com |
| 09:13 |
Dyrcona |
Heh. My laptop just updated "libmagic1." I wish it really lived up to the name. :) |
| 09:16 |
|
Guest37989 joined #evergreen |
| 09:17 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "Only browse_xpath we added" (3 lines) at http://paste.evergreen-ils.org/48 |
| 10:07 |
Dyrcona |
I think we might have changed one or two, but my memory is fuzzy. I'll have to compare with the stock entries in 950.*.sql or wherever. |
| 10:07 |
bshum |
Dyrcona: Unfortunately no, I was just messing with the function's definition directly in my pgadmin window and learning how to apply the raise statements. |
| 10:07 |
Dyrcona |
bshum: NP. Just thought I'd ask. |
| 10:07 |
bshum |
I don't think I have that anymore because we blew away that test system already :( |
| 10:08 |
Dyrcona |
I am going to run another browse ingest and capture all of the output to a file. |
| 10:08 |
Dyrcona |
Then, I'll know if it is every record or just some records. |
| 10:08 |
Dyrcona |
Maybe I'll try adding the raise statements beforehand. |
| 13:55 |
eeevil |
Dyrcona: k. you got an LP already? if not, I'll create one and toss this up |
| 13:55 |
Dyrcona |
eeevil: No, I didn't make a bug, yet. |
| 13:55 |
eeevil |
on it |
| 13:56 |
dbs |
For further win, add a pgtap test that triggers the problem (until the fix goes in, natch) |
| 13:56 |
|
hbrennan joined #evergreen |
| 13:56 |
eeevil |
dbs: this is a good point. Dyrcona, do you think you could do that? |
| 13:57 |
phasefx |
jeff: tsbere: do either of you know how to configure a staff client for a "silent" install? |
| 13:58 |
Dyrcona |
eeevil dbs: I don't usually use concerto, but I could add a record from our collection that triggers it. |
| 13:58 |
tsbere |
phasefx: What kind of silent install are you looking for? |
| 13:58 |
dbs |
Dyrcona: yeah, for a pgtap test you could just insert the record directly as part of the test. No need to rely on concerto |
| 13:58 |
eeevil |
Dyrcona: that, or forcing in a record shaped like this one at id=-2, say, and watching it blow up |
| 13:59 |
phasefx |
tsbere: the only context given to me was for "automated background installation", but I can solicit more info |
| 14:00 |
tsbere |
phasefx: Look into passing /S to the installer, if my memory is correct. If that doesn't work I can google the information. |
| 14:00 |
phasefx |
tsbere: thanks man |
| 14:01 |
Dyrcona |
dbs: I'll look into inserting the record. I recall seeing another test that does that. |
| 14:03 |
|
Wyuli joined #evergreen |
| 14:04 |
tsbere |
phasefx: I think that /autoupdate, /noautoupdate, /permachine, /nopermachine, and /developer are also accepted (when the client was built with those options) |
| 14:06 |
dbs |
Pg/t/regress/lp1242999_unbreak_new_encode.pg may be what you're looking for :) |
| 14:07 |
eeevil |
Dyrcona: a branch to base your tap test on: working/user/miker/lp1303940-browse-hates-null |
| 14:07 |
Dyrcona |
dbs && eeevil Thanks to you both. |
| 14:09 |
dbs |
eeevil is in my head |
| 14:10 |
eeevil |
dbs: it's very cold, but polite, in here |
| 14:11 |
jl- |
uhm, so about that bib_tag in the database for each record.. what is it? |
| 14:11 |
eeevil |
jl-: I confess, I have no idea what you are describing... |
| 14:11 |
jl- |
makes 2 of us |
| 14:13 |
eeevil |
oh! hah... that just pins the bib id of the records in that test dataset |
| 14:13 |
phasefx |
tsbere: invoking the installer works with /S, not sure if we can build an installer with that behavior enabled by default, but maybe /S to the installer will suffice. thanks man |
| 14:13 |
tsbere |
phasefx: I believe we could make it do so by default |
| 14:14 |
tsbere |
would require editing the nsi file, though |
| 14:16 |
* tsbere |
isn't sure that is the best idea and prefers the /S option |
| 14:16 |
* phasefx |
nods |
| 14:16 |
eeevil |
it looks to be used for constructing the last_xact_id. you can ignore that, unless you want to be able to use that to identify batches of records that you use marcxml_import() to pull in |
| 14:18 |
jl- |
eeevil: correct, but in my case it's not a test dataset I'm using it to load our university bibs |
| 14:20 |
eeevil |
jl-: so ... what's your question. last_xact_id is used for optimistic locking in the normal workflow. it can also do double duty as a way to identify records that came into the system in batch. you can ignore it, or use it, but it's just an opaque string, insofar as the software is concerned... does that help? |
| 14:20 |
jl- |
eeevil: yes, so it might be useful in the database, but it has no functionality in the frontend? |
| 14:22 |
jl- |
see the example here: http://paste.debian.net/92250 |
| 14:22 |
jl- |
of course I have ~200k following |
| 14:28 |
Dyrcona |
jl-: Note what eeevil said about "optimistic locking in the normal workflow." If a user has a record open while something else changes it in the background, the staff client won't save the user's changes if the last_xact_id has changed in the meantime. |
| 14:29 |
Dyrcona |
jl-: It's particular value is usually unimportant. |
| 14:31 |
jl- |
Dyrcona: in my case I'm planning ahead, we don't have any users. I'm running test-migrations |
| 14:32 |
Dyrcona |
jl-: I understand. We're telling you what that field is used for. Basically, it doesn't matter what you put into it at the start. |
| 14:33 |
Dyrcona |
jl-: I did something like IMPORT-{UNIX_timestamp} during our migration. |
| 14:37 |
|
RoganH joined #evergreen |
| 15:17 |
Dyrcona |
wifi-- |
| 15:18 |
bshum |
@blame wifi |
| 15:18 |
pinesol_green` |
bshum: wifi 's bugfix broke bshum's feature! |
| 15:18 |
kmlussier |
berick: I got a little lost in the discussion for bug 1187993. Would it indeed be useful for me to ask somebody to do a small JAWS test of a site using HTML5 datalist elements? |
| 15:18 |
pinesol_green` |
Launchpad bug 1187993 in Evergreen "Auto suggest causes significant accessibility issues for using basic search in some browsers" (affected: 3, heat: 18) [High,Confirmed] https://launchpad.net/bugs/1187993 |
| 15:18 |
Dyrcona |
So, is it normal for pg_tap to say that you gave it a bad plan if a test fails? |
| 15:18 |
kmlussier |
berick: If so, I'll do it ASAP. |
| 15:18 |
jeff |
I see no left joins, SET copy_id, or even UPDATE statements in that trigger. |
| 15:19 |
jeff |
anyone else who cares to, i'd be interested if this turns up a non-zero value: select count(*) from asset.opac_visible_copies where copy_id is null; |
| 16:57 |
jeff |
gsams: pay particular attention to the basics, like the reverse DNS (PTR) record for the mail server. |
| 16:58 |
gsams |
jeff++ #that will be super helpful! |
| 16:59 |
gsams |
jeff: yeah the basics, I'm pretty sure are solid. But the also recommend portion is definitely questionable for us. |
| 16:59 |
jeff |
also, generating some test messages to a gmail account you control can help when you get to the point of reviewing your SPF record, etc. -- it's useful to do a before and after there. |
| 16:59 |
jeff |
FWIW, we do not currently do DKIM or DMARC on our transactional email from the ILS, and have not had problems. |
| 17:00 |
jeff |
But we also have a pretty strong separation between transactional and promotional -- our promotional stuff goes through completely different channels. |
| 17:01 |
jeff |
The unfortunate truth is that in some cases, a handful of users hitting "this is spam" can hurt you regardless of what you do. |
| 17:01 |
jeff |
for sufficiently large values of "handful" :-) |
| 17:01 |
gsams |
yeah, that also had occured to me. I know at least this is purely transactional though, so I've got that going for me. |
| 17:02 |
gsams |
and SPF is setup already... |
| 17:02 |
jeff |
worth a test to ensure that your spf record as seen by and interpreted by google is resulting in a pass. |
| 17:03 |
jeff |
(headers as viewed in gmail "View Original" will help there) |
| 17:03 |
gsams |
well, the odd thing for me: v=spf1 include:_spf.google.com ~all |
| 17:05 |
gsams |
I'm honestly not sure if that is odd actually... |
| 17:05 |
jeff |
sounds like you're a google apps user, and sounds like that SPF record is intended to identify the mail for that domain that is sent through google apps. it does not appear to account for the mail being sent from the ILS. |
| 17:09 |
jeff |
with ~all and the sending server not in the list, you'll get a softfail. |
| 17:09 |
jeff |
which is in most cases worse than not having any SPF record. :-) |
| 17:09 |
jeff |
even with the "Receiving software SHOULD NOT reject the message based solely on this result" bit. |
| 17:26 |
gsams |
well a postfix test showed it heading to spam for my gmail. I've gone in and added an SPF record for our system, so we will see in a bit if it helps us out. |
| 17:26 |
gsams |
jeff++ Dyrcona++ |
| 17:26 |
gsams |
thanks again! |
| 17:26 |
gsams |
bshum++ as well |
| 17:27 |
bshum |
gsams++ # raising the question and getting me wondering about our own systems too.... |
| 17:31 |
gsams |
roanoke_patrons++ #for raising the issue enough times to get me to do that! |
| 17:31 |
pinesol_green` |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 18:46 |
|
book` joined #evergreen |
| 18:56 |
gmcharlt |
FYI, OpenSSL has released a major security fix http://heartbleed.com/ |
| 18:56 |
rangi |
yeah, upgrade all the things |
| 00:05 |
|
ningalls joined #evergreen |
| 00:10 |
|
torrie 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> |
| 07:36 |
|
Dyrcona joined #evergreen |
| 07:54 |
|
collum joined #evergreen |
| 08:12 |
csharp |
hmm - looks like the change in 80e3f6f may have borked some long-standing PINES reports templates |
| 08:13 |
|
timlaptop joined #evergreen |
| 08:13 |
|
asimon joined #evergreen |
| 08:15 |
|
akilsdonk joined #evergreen |
| 08:19 |
asimon |
*: I am trying to load a file of bib records into a test server. In order to preserve the rest of the data, I did a truncate cascade on the bre table (there are no copy records) and set record_entry_id_seq to 500000. When I load the records, the id numbering starts at 001. The load script is clearly using the TCN (which begins at 500001) as the id. How is this possible? |
| 08:22 |
csharp |
asimon: there's a "global flag" that determines that behavior, if I recall correctly |
| 08:23 |
csharp |
config.global_flag? (I don't have access to our DB right this second to check) |
| 08:24 |
csharp |
also available via the staff client in the Server Admin section, btw |
| 10:52 |
bshum |
New bug usually. |
| 10:53 |
bshum |
would be what I would recommend when dealing with something that's already been released. |
| 10:54 |
mmorgan |
I'll poke around some more and open one if warranted. Thanks! |
| 10:58 |
bshum |
Hmm |
| 10:58 |
bshum |
mmorgan: Can you tell us a little more about the org unit structure and which ou you're disallowing from hold pickup? |
| 10:59 |
bshum |
(when I tested it just now, it worked fine to disable the option on the place hold screen...) |
| 11:01 |
mmorgan |
Interesting. Here's a pic: http://screencast.com/t/AIs8afgOj0gZ |
| 11:02 |
csharp |
could it be autogen.sh related? |
| 11:02 |
mmorgan |
We have NOBLE(All libs) as consortium, then Phillips Academy as a system. It's some of the branches I'm trying to disallow, like Phillips Addison |
| 13:05 |
bshum |
Haha |
| 13:06 |
Dyrcona |
:) |
| 13:07 |
* dbs |
wonders if anyone is willing to add serial.* data to the --load-all side of things |
| 13:08 |
bshum |
berick: I have a question about websockets and upcoming changes to OpenSRF. |
| 13:08 |
bshum |
As I work my thoughts together about the XUL vs. web client |
| 13:09 |
bshum |
I'm wondering if any changes in the underlying architecture would require us to test also the XUL client to make sure we don't break things? |
| 13:09 |
bshum |
While we transition to the web client |
| 13:10 |
berick |
bshum: websockets will have no effect on the xul client. it has to be activated within the script / application to be used, and the browser client code is the only thing (for now, anyway) that activates it. |
| 13:10 |
berick |
the activation occurs within the base browser staff template |
| 13:10 |
bshum |
berick: Ah, cool deal. Then I feel slightly better on that front. |
| 15:20 |
dbs |
For that matter, the 69x mappings are supposed to be local too. There are only a couple that match even OCLC's definitions. |
| 15:20 |
yboston |
jl-: congrats |
| 15:20 |
yboston |
jl-: which import approach did you use? |
| 15:20 |
jl- |
I'm hoping to get one of our libraries as a gineau pig for a pilot now, maybe for a dvd collection, or something.. wean them off voyager |
| 15:21 |
jl- |
yboston: I used the sql_loader which is pretty close to the staging table from dbs |
| 15:21 |
jl- |
in /openils/Evergreen-ILS-2.5.1/Open-ILS/tests/datasets/sql/ |
| 15:22 |
jl- |
I made a script that formats them simialr to the concerto files |
| 15:26 |
jl- |
anyway, have a good weekend everyone |
| 15:27 |
jeff |
neat, we have an action.billable_cirulations view. i wonder if that's a known typo or something specific to us. :-) |
| 15:28 |
hbrennan |
jl-: Ugh, it's 11:30 here, but my body thinks it's later so I can leave too right? |
| 15:28 |
jeff |
(we also have action.billable_circulations) |
| 16:01 |
bshum |
That's the first time in a long time someone's used that... |
| 16:03 |
bshum |
I suppose we don't really use LP that way. |
| 16:05 |
|
madseumas joined #evergreen |
| 16:10 |
ericar |
bshum: out of curiosity, I just tried recreating what she's reporting. I can't reproduce the results. tested on 2.5.3b |
| 16:11 |
bshum |
ericar: Thanks for taking a look over. I wasn't too sure what all the circumstances are here. |
| 16:12 |
bshum |
The LP account who opened that question seems to be someone from Evergreen Indiana. |
| 16:12 |
ericar |
bshum: me either |
| 16:14 |
Bmagic |
csharp: Thanks for the info |
| 16:14 |
bshum |
mmorgan: Oh interesting... holding the key down does give me various JS errors. |
| 16:14 |
bshum |
For different Fn keys |
| 16:15 |
madseumas |
Hello, everyone. I just updated a small (20k items or so) library from 2.3.2 to 2.5.3b on a test VM. Upgrades all went fine, no db errors. She (it's my wife's library; I'm a unix admin by trade so I help her maintain it) was using jspac, which is gone now. Should the uncustomized tpac still be able to return records or does it need some basic level of customization before it will? Keyword searches that work on her liv |
| 16:15 |
bshum |
madseumas: You got cut off at "keyword searches that work on her live" |
| 16:15 |
bshum |
IRC has a cap on how much you can type at once. So just break up the sentences a bit :) |
| 16:16 |
madseumas |
argh sorry, will do |
| 16:16 |
madseumas |
should read " Keyword searches that work on her live system return nada on this test one." |
| 16:16 |
ericar |
mmorgan: yes, first time got TypeError: $("patronStrings").getString is not a function second try got TypeError: $("commonStrings") is null. Held the key for about 2 seconds |
| 16:16 |
madseumas |
haven't done IRC in 10 years or so :) |
| 16:17 |
mmorgan |
lp 1300789 |
| 16:24 |
rjackson-isl |
it is repeatable |
| 16:24 |
madseumas |
csharp: yes, ran reingests, very carefully followed DB script output from each |
| 16:24 |
rjackson-isl |
use F4 and before the screen pops up hit another F key |
| 16:25 |
dbs |
madseumas: does the test VM have enough memory? 2.0 GB of RAM or more? |
| 16:25 |
csharp |
madseumas: well, at the very least, VACUUM ANALYZE all of the metabib.* tables |
| 16:25 |
rjackson-isl |
other sequence such as F1 then F4 does not produce this |
| 16:25 |
madseumas |
dbs: test VM has 2GB of RAM. No memory pressure, catalog is quite small |
| 16:26 |
dbs |
although... if title searches are working, one would think all db calls should |
| 16:26 |
dbs |
madseumas: heh, 2.0 GB is barely enough for our ~200 test record set with all services running |
| 16:27 |
csharp |
yeah, I use a minimum of 4 GB, even on small test servers |
| 16:27 |
ericar |
rjackson-isl: I just reproduced the error you describe above. However, it was from holding the F4 key while still trying to use another F key. Also, holding the F4 too long will reproduce the results |
| 16:27 |
dbs |
bshum: 901c, yeah, that's something |
| 16:27 |
csharp |
but you should see swapping or i/o wait in top when the searches are processed |
| 16:32 |
dbs |
madseumas: wondering if it's the missing 901 fields, then, as bshum suggested |
| 16:33 |
|
mrpeters left #evergreen |
| 16:34 |
madseumas |
csharp: command line search, limit 10, I see 10 ids being returned |
| 16:34 |
dbs |
SELECT COUNT(*) FROM biblio.record_entry WHERE marc !~ 'tag="901"'; -- if you can query the database would be a good test |
| 16:34 |
dbs |
Result should be 0. |
| 16:34 |
madseumas |
dbs: will do, one sec |
| 16:35 |
madseumas |
dbs: result was 11780 |
| 16:35 |
bshum |
Oops |
| 17:26 |
hbrennan |
Access?! Oh jeez. |
| 17:27 |
madseumas |
yah, the forms allowed you to search by specific title or author but that was it. cataloging was a nightmare. |
| 17:27 |
hbrennan |
I can only imagine. |
| 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:32 |
madseumas |
quick question, where do the default book jackets in a tpac catalog search come from? |
| 17:32 |
madseumas |
I had thought google books stuff was turned off by default |
| 17:33 |
bshum |
madseumas: By default in newer versions I believe the added content handler is for OpenLibrary |
| 03:07 |
|
dbwells joined #evergreen |
| 03:25 |
|
dkyle joined #evergreen |
| 05:55 |
|
flopaul joined #evergreen |
| 07:37 |
csharp |
@later tell gmcharlt I'll need to re-review it. I have a fresh 14.04 vm to test with, so it'll be today |
| 07:37 |
pinesol_green |
csharp: The operation succeeded. |
| 08:10 |
|
tfaile joined #evergreen |
| 08:10 |
|
ktomita_ joined #evergreen |
| 10:55 |
* pinesol_green |
brews and pours a cup of Ethiopia Washed Yirgacheffe, Koke Grade 1, and sends it sliding down the bar to gmcharlt |
| 10:55 |
kmlussier |
Two lemon sherberts in one morning. :( |
| 11:05 |
|
collum joined #evergreen |
| 11:06 |
csharp |
gmcharlt: my ubuntu-14.04 OpenSRF Makefile branch installs fine and passes the opensrf.math test, but I haven't run Evergreen on it yet |
| 11:06 |
gmcharlt |
csharp: great - do you expect to have tuits to do an Evergreen test soonish? |
| 11:07 |
csharp |
sure - I'll install EG after lunch |
| 11:07 |
csharp |
virsh_snapshot-create++ |
| 11:12 |
jeff |
tspindler: i have more than one kringle from that bakery in Racine on my kitchen counter at this very moment. :-) |
| 12:53 |
Dyrcona |
csharp++ # for wrangling with the Trusty Tahr. |
| 12:53 |
Dyrcona |
heh, goatherding. :) |
| 12:53 |
jeff |
technically 14.04 isn't even out yet, so it's of course tricky claiming support for it. In theory, it should be pretty stable now. |
| 12:53 |
csharp |
jeff: it's pretty solid in our smoke tests |
| 12:54 |
jeff |
yeah, I meant "stable" as in "no longer a moving target" |
| 12:54 |
jeff |
i should have clarified. |
| 12:54 |
csharp |
though, I did hit a bug in the installer when configuring LVM |
| 13:36 |
berick |
antimarcite |
| 13:42 |
kmlussier |
@dessert |
| 13:42 |
* pinesol_green |
grabs a slice of Red Velvet Cheesecake and sends it sliding down the dessert bar to kmlussier |
| 13:59 |
bshum |
csharp: Fwiw, I put a copy of our full database into a PG 9.3 running on 12.04 and that seems to be fine so far. Or at least I haven't hit any significant pains yet. (once I upgraded to include the 9.3 fixes) |
| 13:59 |
bshum |
I'll be curious what you come up with for 14.04. We'll get to it sometime. |
| 14:00 |
bshum |
I'm still deciding whether during our next upgrade we'll move from 9.1 to 9.3 in production too. |
| 14:00 |
bshum |
That stuff I just said was for our test server only. |
| 14:03 |
csharp |
cool |
| 14:06 |
csharp |
okay - looks like we're down to 3 CPAN dependencies with 14.04 |
| 14:06 |
csharp |
so that's nice |
| 15:04 |
* csharp |
doesn't build from scratch very often nowadays |
| 15:05 |
dbs |
I think we agreed to deep-six Lucid support for 2.6, right? Add 14.04, drop 10.04. |
| 15:05 |
csharp |
yep |
| 15:07 |
bshum |
I think nobody's tested 2.6 with Lucid anyways. So... it's already dead to me! |
| 15:07 |
bshum |
(but probably works) |
| 15:08 |
* dbs |
tries removing ld.so.conf.d entry on Fedora 20 to see if that whole section can be wiped out |
| 15:08 |
csharp |
okay - this shows my limited autotools knowledge, but how does make find the right library? |
| 15:08 |
gmcharlt |
dbwells: needless to say, I'm perfectly fine with you squashing that branch mercilessly |
| 15:09 |
dbs |
Nope, still necessary on Fedora. |
| 15:10 |
dbs |
"Failed to dlopen library file oils_pcrud.so: libdbdpgsql.so" |
| 15:10 |
|
kmlussier joined #evergreen |
| 15:11 |
dbs |
csharp: very rough approximation, autotools runs a million tests to detect its environment and configure things as automagically as possible. and then you can override behaviour to boot. |
| 15:11 |
kmlussier |
gmcharlt++ #acknowledgements |
| 15:11 |
csharp |
dbs: okay - I figured |
| 15:13 |
|
gsams joined #evergreen |
| 16:42 |
|
tspindler left #evergreen |
| 17:07 |
|
bmills joined #evergreen |
| 17:08 |
|
gsams joined #evergreen |
| 17:13 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:22 |
|
mmorgan left #evergreen |
| 17:24 |
|
Dyrcona joined #evergreen |
| 17:35 |
|
tsbere joined #evergreen |
| 00:05 |
|
remingtron__ joined #evergreen |
| 03:39 |
|
b_bonner joined #evergreen |
| 03:39 |
|
mtcarlson_away 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:56 |
|
timlaptop joined #evergreen |
| 07:18 |
|
Callender joined #evergreen |
| 07:32 |
|
Callender joined #evergreen |
| 11:54 |
|
mrpeters left #evergreen |
| 11:54 |
|
mrpeters joined #evergreen |
| 11:57 |
phasefx |
bshum: no worries. I have no strong opinions about LP other than that its search function could use improvement, so I'm glad you care enough about it to act on things |
| 12:08 |
csharp |
ok, I'm trying to get EDI working on a test server... we create a purchase order and activate it. 5 minutes later I see the A/T event process, then the edi_pusher.pl script runs and by its feedback messages, it appears to be working (after enabling passive FTP). However, the vendor did not receive the file - any thoughts? The lack of error logs is handicapping me here |
| 12:10 |
csharp |
2014-04-01 15:33:38 acq ./edi_pusher.pl: [INFO:20745:RemoteAccount.pm:595:] OpenILS::Utils::RemoteAccount : successfully sent <vendorURL> /tmp/bzVbVKKjQp --> Out//bzVbVKKjQp |
| 12:14 |
|
mcooper joined #evergreen |
| 12:15 |
* csharp |
will rule out human error (e.g., wrong FTP directory) before continuing to beat on it |
| 12:25 |
rfrasur |
Cheesecake has arrived and pictures will be forthcoming since that's the only way I know to digitize them so far (and a 3D scanned and printed model would just be mean). |
| 12:26 |
Dyrcona |
rfrasur: There is talk of 3D printed "food." |
| 12:26 |
rfrasur |
Hmm, then there are better possibilities for the future than pictures. But not yet :D |
| 15:21 |
sseng |
jihpringle: acq |
| 15:21 |
jihpringle |
there are some claiming bugs in the manual process in acq depending on what version you're running |
| 15:22 |
sseng |
jihpringle: oh ok |
| 15:23 |
jihpringle |
we've tested manual claiming in acq but none of our libraries currently use it |
| 15:23 |
jihpringle |
the bug to watch out for is - https://bugs.launchpad.net/evergreen/+bug/1195063 |
| 15:23 |
pinesol_green |
Launchpad bug 1195063 in Evergreen "ACQ: Claim Vouchers Do Not Appear and Cause Problems with Profiles" (affected: 2, heat: 12) [Undecided,New] |
| 15:24 |
sseng |
jihpringle: having a hard time finding claimings documentation in terms of automated claming . and now that it's been clarified that it's currently manual only... thanks! |
| 15:24 |
jihpringle |
np |
| 15:31 |
jeff |
csharp: huh. well that's interesting. one of my working theories here was that the issue was related to trying to walk a bunch of holds that the copy wasn't eligible to fulfill, and that combined with something else was causing the breakage. |
| 15:31 |
jeff |
csharp: the example i had the other day was an age protected copy with 80+ holds at non-local libraries. |
| 15:31 |
csharp |
the first example was probably a fluke - a patron requested the title literally 90 seconds before staff began checkin and it captured for the new hold - staffperson assumed it was the "old" hold |
| 15:31 |
jeff |
so it did the hold permit test 80+ times... twice, I think. |
| 15:32 |
csharp |
jeff: ah |
| 15:33 |
pastebot |
"csharp" at 64.57.241.14 pasted "log messages for clear hold shelf checkin modifier failure" (5 lines) at http://paste.evergreen-ils.org/41 |
| 15:34 |
csharp |
jeff: ^^ this is what we see server side at the time of the network errors in our library's case |
| 16:46 |
krvmga |
kmlussier: you got the single layer icons? |
| 16:47 |
kmlussier |
krvmga: I did and I've rolled everything into a git branch. |
| 16:47 |
kmlussier |
krvmga++ |
| 16:57 |
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 |
yboston |
@marc 400 |
| 16:58 |
pinesol_green |
yboston: unknown tag 400 |
| 17:06 |
krvmga |
is there any way to do a call number search limited to the children's collection in eg 2.4? i'm thinking that it might be possible in 2.5. |
| 12:28 |
gmcharlt |
yboston: not to worry -- you would have to try very hard to do something that tsbere and I couldn't fix |
| 12:28 |
yboston |
gmcharlt: BTW I have been watching your Git tutorial video, good job |
| 12:29 |
gmcharlt |
how was the recording? |
| 12:29 |
yboston |
though not done watching yet. I also watched a 5 hour lynda.com training videeos that was good too |
| 12:29 |
yboston |
the audio and video are not perfect, but I had a very clear shot of the screen |
| 12:30 |
yboston |
I am watching it without any compression (audio or video), so if I post it to YOutube, etc it might nto be as goos |
| 12:30 |
yboston |
*good |
| 12:30 |
yboston |
I can prepare a sample on youtoube as a test |
| 12:31 |
gmcharlt |
ok |
| 12:37 |
|
jihpringle joined #evergreen |
| 12:46 |
|
mrpeters joined #evergreen |
| 13:51 |
dbwells |
I know bshum was poking it and got derailed, but if anyone can review and commit https://bugs.launchpad.net/evergreen/+bug/1259665 , I'd be very appreciative. It is the only thing holding up the RC at this point. |
| 13:51 |
pinesol_green |
Launchpad bug 1259665 in Evergreen "Series search in 2.5 does not retrieve 800 |t" (affected: 3, heat: 20) [High,Confirmed] |
| 13:52 |
dbwells |
It is my understanding the bshum's issues were not related to the minor changes in this branch, but I can't say that 100%. |
| 13:52 |
bshum |
dbwells: Correct, my issues seem unrelated. I did find a few 800t's to test with and they seemed fine on reingest. But I have to enable the browse stuff fully to check things out. |
| 13:53 |
bshum |
Pretty confident we can just merge though :) |
| 13:53 |
bshum |
I'll try and do that after a few more meetings end. |
| 13:53 |
bshum |
Sorry :\ |
| 13:57 |
Dyrcona |
@marc 800 |
| 13:57 |
pinesol_green |
Dyrcona: 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] |
| 13:57 |
Dyrcona |
t is the title? |
| 16:18 |
|
denishpatel joined #evergreen |
| 16:26 |
Dyrcona |
Hey, bartender! Hey, man! Lookee here! Draw one, draw two, draw three, four glasses of beer! |
| 16:26 |
* Dyrcona |
channels Floyd Dixon. |
| 16:28 |
yboston |
jl-: My biggest batch with that script was like 2200 records without holdings from EBSCO ebooks service via OCLC. It ran fine on my test server, but I had a timeout error when loading them to my production server hosted by ESI |
| 16:28 |
yboston |
jl-: which is a few states away from here, so there shoudl have been latency issues |
| 16:29 |
yboston |
jl-: BTW< did we meet at the conference? |
| 16:34 |
|
afterl left #evergreen |
| 16:38 |
|
afterl joined #evergreen |
| 16:45 |
|
afterl left #evergreen |
| 16:55 |
bshum |
Ack, rebase on other pushed commits. |
| 16:55 |
* bshum |
does the dance |
| 16:55 |
bshum |
And we're good |
| 16:56 |
yboston |
mceraso++ for testing OSRF |
| 16:56 |
|
mdriscoll left #evergreen |
| 16:56 |
kmlussier |
mceraso++ |
| 16:57 |
bshum |
mceraso++ |
