Search in #evergreen

Results

Result pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139

Results for 2014-04-11

00:17	Guest40233	I'm curious...what does Evergreen need to know about RDA?
00:17	Guest40233	^bshum dbs
00:21	bshum	dcook: Well, the thing we're working on is some new work to show more RDA 264 tag elements in the catalog. Thing is, we don't have any sample bib records in our test dataset that ships with Evergreen that include 264 (or other RDA tags)
00:22	bshum	dcook: dbs' idea is to get some sample bibs that do contain these new tags into our test dataset so that future testing / work with RDA can be checked using those test bibs.
00:22	dcook	Mmm. Fair enough. I can certainly get behind that idea.
00:22	dcook	It would be nice to have a quintessial RDA record set
00:22	dcook	Man, that wasn't even spelled anywhere near correctly
01:02	dcook	It makes showing multiple 264s a breeze. At the moment, I don't think we differentiate between the different types of 264, but it would be a trivial change to make.
01:02	dcook	In any case, sleep well!
01:57		zerick 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>
07:38		akilsdonk joined #evergreen
08:05		Dyrcona joined #evergreen
08:07	Dyrcona	So, I get daily promotional emails from Packt Publishing because I've bought some ebooks directly from them in the past.
08:44	* bshum	wonders how this became popular again
08:48	Dyrcona	bshum: If its there, someone will use it.
08:48	bshum	I suppose that's true.
08:48	dbs	bshum: to follow up on your convo with dcook, no, koha doesn't have a sample set of RDA records; I always load sample records from Evergreen's test datasets into Koha :)
08:49	bshum	Dyrcona: Maybe we need something in Questions on LP like what jcamins did for our issues tracker in github: https://github.com/evergreen-library-system/Evergreen/issues/9
08:49	bshum	But to subtly point people at the lists
08:49	dbs	The "trawl LoC for sample RDA records" approach could work, although it's not as though LoC hasn't made errors before.
08:50	Dyrcona	dbs: I can throw some records with some of the 264 data at you.
08:50	Dyrcona	OCLC be damned. :p
08:51	dbs	Some is better than none.
08:51	Dyrcona	I'll see if I can dig up the IDs of the two or three that I used for testing.
08:52	* dbs	also hopes, like bshum, that the 3xx were taken into account with all the MVF/CRA stuff
08:53	* dbs	peers with interest at http://www.loc.gov/standards/mods/mods-conversions.html - nope, still no MARCtoMODS3.5 XSLT
08:54	dbs	Although there is an RDAtoMODS3.4 XSL (as in, Excel spreadsheet; and it's horrible)
11:54	csharp	mmorgan: that assumes that you chop your logs up by date/hour like we do
11:56	mmorgan	csharp: Thanks, that's helpful. Yes we do chop them up by hour.
11:57	csharp	mmorgan: you can also search the threadtrace in the activity.log (assuming that's there too)
11:59	Dyrcona	mmorgan: Circulation code is a mess, I see things going through it 3 and four times, even when testing and I know I only checked it in once.
12:00	Dyrcona	mmorgan: There's a) too much logging and b) too much bouncing back and forth among different methods.
12:00	mmorgan	yes, activity is there, too. I get a single line from activity for one of these threadtraces, and a whole bunch of stuff going on with the other one.
12:01	mmorgan	I know we have had a few situations where the same item was captured by two different holds. That's what brought me to this.
12:59		hbrennan joined #evergreen
13:03		fparks joined #evergreen
13:27	eeevil	dbwells: just a head's up, if gmcharlt's fixed field seed data ends up getting into 2.6.0, that needs to come /before/ the MVF/CRA conversion dance, so that the existing values are seen as controlled instead of uncontrolled
13:39	* csharp	really dislikes "does program X work with Evergreen?" questions
13:39	csharp	my pat answer is "test it and see"
13:42	tsbere	csharp: My first desire is to turn around and say "Does it have any reason to interact with the ILS directly?" For example, "Does Office work with Evergreen?" Well, since it doesn't actually interact with Evergreen at all to begin with....
13:47	_bott_	Reporter creates .xls files, so yes. In a 7 degrees of Kevin Bacon kinda way.
13:48	jeff	i need to work on guidelines for transitioning some willing initial staff members from "one account for all" to "this is my patron account" and "this is my staff member account"
13:48		bibliophylum joined #evergreen
13:51	csharp	tsbere: this particular question is more about extending the OPAC with vendor widgets
13:51	tsbere	csharp: Ahhh. That can be more complicated and/or annoying. <_<
13:51	csharp	usually both in my experience ;-)
13:52	csharp	and I'm usually dealing with it after a library has purchased said service on the breezy assurances of the vendors
13:52	csharp	rather than after a rigorous test, which I'm happy to coordinate on our end ;-)
13:53	csharp	at least this particular library asked ahead of time, so I should be happy, not complaining
13:53	* csharp	is just tired today
13:54	csharp	jeff: are you doing that in a software-based way, or from a "this is my staff card, but this is my patron card" way?
13:55	_bott_	jeff: we chose to transition unwilling staff into "this is your only account and you'll like it"
13:58	* tsbere	would like to move to either of those setups at MVLC, but can't
13:59	bibliophylum	Hey folks... I'm trying to explain to non-technical bosses what the implications of Heartbleed on Evergreen systems are. I've already covered, "we're aware of this because it's open source" and "no, there's no way of telling if a system was targeted", and "yes, it's patched". Any thoughts/tips?
14:46	gmcharlt	tsbere: on the face of it, looks much nicer than an attribute reingest
14:49	eeevil	agreed. purty
14:49	gmcharlt	tsbere++
14:50	* tsbere	almost finds the WITH block abuse scary, though
14:53	tsbere	eeevil / gmcharlt: I very lightly tested it. Was thinking it might be best set up as a cron job, but not sure.
14:53	jeff	for evergreen specific impacts, if your ssl-speaking front-ends were apache linked against a vulnerable version of openssl, it was trivial to steal recently used session keys as well as cleartext credentials for recent logins. (or not-so-recent in terms of "wall clock time" if the target system was idle).
14:54	* eeevil	grumbles about CHAP ... ;)
14:54	* Dyrcona	just read some articles saying that exploits may have been circulating as long as last November.
14:55	jeff	if your front end was pound or nginx linked against a vulnerable version of openssl, i make no assertions because i didn't test that. :-)
14:55	jeff	we were happily on squeeze for ssl-speaking production systems. :-)
14:57	Dyrcona	'Ow nice for you.
15:24		ldwhalen joined #evergreen
15:54	jboyer-isl	Does anyone else have any issues with Clark processes piling up around midnight (when most "I don't care when" reports are run)? Ours can creep up to 40+ processes a night, triggering an icinga alert almost daily. (we only run with -c 5, so that's over 8x the expected number of processes)

Results for 2014-04-10

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...
17:35	dbwells	Well, we've been teetering on the edge of a 2.6.0 release for a while now. Anyone wishing to push us over, please do: https://launchpad.net/evergreen/+milestone/2.6.0
17:37	yboston	bshum: also, movie bib records also tend to be slighly different than books, often they don't have 1xx fields and I guess in this case they have a distributor and not a publisher>
17:37	yboston	?
17:37	dbwells	I wish I could recreate the acq bug, so I could have a bit more confidence that we've solved it, but I just don't have a test server big enough right now.
17:38	bshum	yboston: I could see that. I'm trying to trace back where in the code this might have gone off the rails.
17:38	bshum	I have an idea.
17:38	bshum	dbwells: I wish we could have tested it more fully too. Other than the limited, "seems to work" that we quickly did
17:38	dbwells	The acq bug is the only true blocker, at the moment at least :)
17:39	bshum	dbwells: I have nothing new to add to it at this time though :\
17:40	yboston	bshum: feel free to post the bug if you want, but if not I will do it tomorrow morining (need to finsish somehting else tonight)
17:50	pinesol_green	[evergreen\|Dan Wells] LP#1304559 Fix slow Vandelay-based imports - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d42fbec>
17:50	pinesol_green	[evergreen\|Ben Shum] LP#1304559 - stamping upgrade script for vandelay_record_attr_to_flat - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f1fa38c>
18:02		jboyer-isl joined #evergreen
18:05	bshum	Huh
18:05	bshum	args.pubinfo = "$args.pubplace $args.publisher $args.pubdate";
18:05	bshum	But then later on, it also sets
18:05	bshum	args.pubinfo = (args.pubinfos.size) ? args.pubinfos.0 : '';
18:06	bshum	So wouldn't that mean that it'll replace pubinfo with the results from the graphic_880s hunt for tags 260 and 264
18:06	bshum	Which is probably why it doesn't narrow it to only 264 with ind2=1
18:07		csharp joined #evergreen
18:09	* bshum	ponders this more.
18:17	bshum	Yep, I think that's the problem
18:20	bshum	Maybe we should just explicitly name all the different parts pubplace, publisher, pubdate in the results, same as we do for record.
18:20	bshum	And skip this combined pubinfo, and reserve that for the 880s dance
18:21		Dyrcona joined #evergreen
18:23	bshum	At that point, if we desired, we could add Dyrcona's additional RDA 264 definition types as other things to be displayed in the more details instead of publisher, etc. but with the right designations. Distributor instead of publisher, and so forth.
18:24	bshum	Hmm
18:25		Dyrcona joined #evergreen
18:43	bshum	And boo, dbs is right, there are no 264 samples in the test data.
18:43	bshum	Guess we really ought to make several to test all the variations out.
18:45	bshum	Maybe after dinner.
18:45	bshum	@monologue
18:45	pinesol_green	bshum: Your current monologue is at least 16 lines long.
18:57	bshum	Hmm, maybe an IF publisher, ELSIF distributor, and down the list of potential 264 types for results...
19:24		csharp joined #evergreen

Results for 2014-04-09

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>

Results for 2014-04-08

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.

Results for 2014-04-07

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

Results for 2014-04-06

02:31	RBecker	wow, i'm late :)
08:28		dbs_mob joined #evergreen
08:29	dbs_mob	@later tell grace_ you have a typo: "opeils"
08:29	pinesol_green	dbs_mob: The operation succeeded.
16:16		BigRig_ joined #evergreen
16:16		geoffsams joined #evergreen
16:38		remingtron_ joined #evergreen
16:51		zerick joined #evergreen
16:51		dbs joined #evergreen
16:55		Sato`kun joined #evergreen
17:14	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	rangi	eeevil: who is your office is EM .. whoever they are, thank them for signing for the laptop for me please :)
19:44		olirna joined #evergreen
22:58	jeff	dbs++

Results for 2014-04-05

00:26		zerick joined #evergreen
03:56		mxmwine joined #evergreen
04:07		buhareva 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>
10:55		jeff_ joined #evergreen
11:45		RBecker joined #evergreen
11:54		ogio71 joined #evergreen
14:01		daffodil joined #evergreen
16:51		gsams joined #evergreen
16:53		geoffsams joined #evergreen
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>
18:12		abbacchio left #evergreen
23:10		gsams joined #evergreen
23:42	grace_	Help? http://paste.evergreen-ils.org/46

Results for 2014-04-04

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

Results for 2014-04-03

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

Results for 2014-04-02

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.