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 140 141 142 143

Results for 2014-04-23

09:09	dbwells	eeevil: please do, thanks
09:09		kbeswick joined #evergreen
09:10	jl-	so RoganH, what would the SQL look like? :) would this go into asset.copy?
09:11	dbwells	jl-: for quick creation of fake assets, I'd check out the stuff in the "Concerto" test set.
09:11	RoganH	jl-: I'm not sure what data you're working off of. the concerto stuff would be a good jumping off point.
09:11	dbwells	jl-: specifically, the functions in Open-ILS/tests/datasets/sql/env_create.sql and their use in Open-ILS/tests/datasets/sql/assets_concerto.sql
09:11	RoganH	jl-: basically you need entires in asset.call_number that reference bib records
09:12	RoganH	jl-: then entries in asset.copy that reference the call numbers
09:12	eeevil	dbwells: done, sir
11:00	csharp	happy to help!
11:00		tspindler joined #evergreen
11:00	* csharp	looks around for what bshum is mumbling about ;-)
11:21	bshum	Random question
11:21	bshum	Right now, we pull in Business::ISBN via CPAN
11:21	bshum	is there any reason we can't use the packaged version like libbusiness-isbn-perl
11:22	bshum	(since the version in Trusty is 2.0.7, same as CPAN, I think?)
11:22	bshum	Or is this the sort of thing we're teasing out
11:22	bshum	With testing and breaking
11:23	bshum	Oh, nevermind I can see we already covered this with Wheezy
11:24	* bshum	ponders some edits to the section of the README about standalone DB requirements
11:26	jeff	bshum: you neverminded, but to the best of my knowledge, the only reason for bringing that in via CPAN was where it wasn't packaged by the distro in question.
11:27	bshum	jeff: That makes good sense. I guess that means we really ought to update the standalone DB portion of the README since it still uses CPAN and not packages that may exist.
11:27	bshum	I'm setting up a new standalone DB and it suddenly occurred to me to check on what packages may or may not exist
11:28	* bshum	will do some poking and whip up a branch for this later on.
11:41	* jeff	had fun killing a test vm repeatedly yesterday
11:41	csharp	@blame the test vm
11:41	pinesol_green	csharp: the test vm stole bradl's tux doll!
11:42	jeff	(intentional triggering of OOM conditions and adjusting Apache settings to avoid said conditions)
11:42	* Dyrcona	had "fun" upgrading his laptop to Ubuntu 14.04.
11:42	jeff	creating endless loops in php designed to quickly use as much memory as the php memory limit would allow, etc :-)
11:58		kmlussier left #evergreen
11:58	Dyrcona	Erick316: I don't think the importer is going to deal very well with 35,000 records with match sets all at once.
11:58	Dyrcona	Erick316: The staff client is likely to time out waiting on the server.
11:58	jl-	yes start with 1k
11:59	jl-	or even 1
11:59	jl-	just for testing
11:59	jboyer-isl	Start with 5 to make sure the match set works the way you want, after that your upper limit is determined by the complexity of your matches and your hardware.
11:59	jboyer-isl	It will be a lower limit than you would hope.
12:01	Erick316	yeah actually I have 10 records only for testing
12:02	Erick316	but the expression for the record match set, I don't know if it is correct, have anyone some expression to make another test?
12:02	jboyer-isl	How many are already in the system? Match set timing is effected by both incoming and existing.
12:03	Erick316	I' ve already used this : Your Expression: (020 ‡a OR 022 ‡a OR 024 ‡a OR 028 ‡a) and Your Expression: (item_lang AND (240 ‡a OR 245 ‡a))
12:03	Erick316	are 3 queues already in system some of 300, another of 600, and other of 3500
13:10	jl-	this script makes me very happy
13:16	mrpeters	possible to accomplish alternate tpac skins without the ability to create new vhosts? have a customer who is super locked down on what hostnames the city will let them create and they don't see the need for a second one for the library. their goal is one hostname for the "in the building" TPAC and then their current one for the public, outside the building.
13:18	tsbere	mrpeters: Er, if they have two hostnames (internal vs external) then, er, you have two hostnames already?
13:20	jl-	SELECT id FROM biblio.record_entry WHERE id <= 1000 ORDER BY RANDOM() LIMIT 1 berick
13:20	jl-	ceiling
13:20	jl-	tested
13:20	jl-	;)
13:21	bshum	Heh
13:21	berick	jl-: cool, glad it's working
13:21	jeff	mrpeters: i think it might be possible with creative apache config, but i haven't tried yet.
17:18	bshum	Probably right, holds don't have audit trails by default.
17:19	gsams	mkay, that'll have to do then
17:19	bshum	At least you have the exact moment when the hold was cancelled.
17:19	pinesol_green	Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html>
17:19	gsams	I think I know what happened though, and timestamps are enough for any local damage that might have been done.
17:19	bshum	That'll help with log sifting
17:19	gsams	csharp++
17:36	gsams	bshum: that did the trick, thank you very much. Saving me from a lot of headaches down the line.
17:36	gsams	bshum++
17:37	gsams	phasefx++ # for helping disable the clear shelf expired holds option back in September of 2013
17:41	bshum	csharp: I'm building a new trusty demo to poke at the ubuntu makefile you setup for Evergreen.
17:41	bshum	OpenSRF seems fine with the revisions I threw in my working branch
17:41	bshum	Or at least, the basic test passes
17:42	csharp	cool
17:42	csharp	yeah - I was updating the Evergreen makefile to be able to test the opensrf makefile ;-)
17:43	csharp	beyond the math test, that is
17:43	bshum	Hehe, yeah
17:43	bshum	On paper, all the changes you suggest look alright.
17:43	bshum	I'm still not entirely sure what gmcharlt was warning us to watch for, some change in perl I think.

Results for 2014-04-22

04:56	pinesol_green	Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html>
06:57		kmlussier joined #evergreen
07:03	kmlussier	@coffee
07:03	* pinesol_green	brews and pours a cup of Sumatra Lintong, and sends it sliding down the bar to kmlussier
10:08		yboston joined #evergreen
10:08		atlas__ joined #evergreen
10:08		phasefx joined #evergreen
10:11	dbs	yboston: finally took a look at those RDA records--great start! We also need some that have multiple 264 fields, too, to really exercise our tests, but that's going to be more work (trawling through records to find candidates)
10:13	yboston	dbs: I was planning on writing the cataloging list to ask for more non-OCLC records (while we confirm what we can do with OCLC records)
10:13	dbs	Also, today I learned that "Slackers" is a valid LCSH heading, thanks to Pineapple Express: id.loc.gov/authorities/subjects/sh2005006709.html
10:14	yboston	:)
17:01	eeevil	just shaped the same
17:01	tsbere	eeevil: Plus I had decided I didn't want "single org unit buckets" nor two columns nor things like "negative number means go look up a bucket" tricks
17:03	eeevil	hrm... well, making single-OU buckets easy to do via a "streamlined" interface ("select an org" creates a 1-org bucket) would allow the fkey
17:03	pinesol_green	Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html>
17:03	eeevil	just a thought
17:04	tsbere	eeevil: Time to go home today. I will see about finishing up some thoughts in my current notes and finding a place to post them soon.
17:04	eeevil	tsbere: thanks! (btw, did you have a chance to test the array-ish pcrud stuff? if you have a sec to answer)
17:04		bbqben joined #evergreen
17:05	tsbere	eeevil: I haven't tested it fully, but I believe it at least compiled and seemed to return results. I don't recall trying to write with it though.
17:05	eeevil	tsbere: cool. if you hit issues, let me know. I think that may open up some broader improvements where we currently have global_required ... but we'll need to add more general array support...
17:06	eeevil	(array-writing support, I mean)
17:08	* eeevil	skee-daddles

Results for 2014-04-21

10:59	denishpatel	eeevil: thanks for details
10:59	bshum	jl-: You know, I misread what you said earlier. 500k bibs sounds like a good amount (it occurs to me that our system is only around 1.1 million actives). 4 GB of RAM might not be covering that so well and it's slow for hitting disk.
10:59	jl-	has anyone thought of using apache solr? they have all kinds of search tweaking
11:00	denishpatel	eeevil: is there a way to download evergreen's postgres schema only to load into my test server?
11:00	jeff	jl-: someone did play with solr, but we never saw any code, and i don't think that it was at all integrated with evergreen, just searching an export of records from evergreen (but again -- never saw any code, so dunno)
11:01	jl-	vufind uses solr :)
11:01	jeff	shart290__: the error you pasted appears to be a timeout between the client and server -- the client (apparently) never received a response.
11:17	eeevil	jl-: bibs can be "owned" in (basically) one of two way, and the way you use depends on if it's an electronic resource or a barcoded, physical item
11:17	eeevil	for barcoded items, attach a call number and copy owned by the "owner"
11:17	eeevil	for e-resources, us a located uri (856 with an appropriate subfield 9)
11:20	bshum	jl-: Huh... so in your test system I can't find any copies. How did you make the bibs visible in search? (aka, did you just mark them as trascendent or something)
11:24	bshum	What I would normally expect in a migration is that the original MARC exported from the legacy ILS would have some sort of holdings tag containing basic info like barcode, call number, price, whatever. And then you would map those to callnumbers/copies in Evergreen, that linked to each given bib.
11:25	dbwells	jl-: If you are building an Evergreen instance from two (or more) catalogs that are currently independant (and it sounds to me like you are), you are going to want to combine and dedupe all the records from every system, preferably at an early point. This will not be a particularly straightforward task, and I doubt it's represented in the docs in any way. In fact, depending on how varied the records in your current catalogs are, it could be a monumen
11:25	dbwells	tal task by itself.
11:25	bshum	In Evergreen, bibs are all stored in biblio.record_entry, but there's the item holdings which are reflected in asset.call_number (which points back to a specific record ID), and then asset.copy (which points back at specific call number IDs) for each bib.
11:38	bshum	But that also depends on how the system is intended to be used / searched, I guess.
11:40	bshum	But let's say that having combined bibs saves you room in the database.
11:42	bshum	In any case, I would create all the libraries you think you're going to need as org-unit entries. Just so that you get the sorted. And then as you bring in new bib/copies, you just need to figure out how to correctly mark the volume/copies as owned by a specific org unit. You could leave bib deduplication to later on.
11:42	jl-	I understand, this seems very important but for now I think it would be overkill. If I can have two orgs with copies each, that would be fantastic
11:42	jl-	and if I have some duplicates, that's ok for testing the ILS
11:43	jl-	with this I mean deduplication
11:43	jl-	:)
11:43	bshum	yes, you can always create multiples of bibs, so basically like the "Star Wars" example, lots of times over. But you just set the ownership for each call number / copy accordingly.
11:43	bshum	And eventually poke at merging things.
11:43	jl-	anyway, so how do I actually attach copies, is there documentation? I have an items.txt with 400 entries
13:37	jeff	so you might have records with 856 tags that point to things like "author info" at loc.gov, etc. those aren't treated specially (assuming they don't have those values for ind1/ind2 and an appropriate subfield 9)
13:37	jl-	jeff: I want to create a subfield 9 in 856 and give it a shortname which I'll use for an org unit
13:40	jl-	marcedit will let me add any field and field data
13:41	jeff	i would recommend starting with a single test record.
13:42	jeff	ensure that you're getting the behavior you want before doing any kind of batch/mass updates.
13:50	jl-	yuo
13:50	jl-	yup
13:51	jl-	bshum: it seems like I can batch edit (and add) fields to records in the staff client, so it seems like adding an org shortname would not have to happen prior to importing ?
15:32	dbwells	bshum jeff: so what was the real reason for the ++s, or are you just going to leave us in the dark?
15:33	jeff	oh, sorry. i thought someone explained it.
15:33	bshum	Working on things for the community web server.
15:34	jeff	GPLS has taken some spare hardware and finished initial provisioning as a community VM host, so that things like the git and web servers can be on hardware that more than just csharp can restart, potentially other things like test servers/buildbots, etc.
15:34	hbrennan	Haha. Glad I wasn't the only curious one
15:35	jeff	A step toward csharp being able to go on vacation. :-)
15:35	dbwells	jeff: Is this what csharp and a few others of us were chatting about at the end of the conference?
16:35	jeff	jl-: and since none of the records appear to have visible copies, I'm assuming that their bib source is transcendent, which as eeevil noted is "the ballgame" :-)
16:36	jeff	at this point, i'm not sure we have enough information to recommend for/against the use of opac.located_uri.act_as_copy
16:36	jeff	(in jl-'s situation)
16:37	eeevil	jeff: true. if these are bibs that correspond to physical items on shelves in a library, the best thing to do would be to get that data from the current system and attache the items. minimally, that would be the call number label and the barcode. all else is of little import for a surface test of the system
16:38	eeevil	jl-: -^
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:25		atlas___ joined #evergreen
17:53		RBecker joined #evergreen
18:06		alynn26 joined #evergreen

Results for 2014-04-20

02:34		edoceo joined #evergreen
04:06		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>
06:32		dreuther joined #evergreen
06:32		ktomita_ joined #evergreen
12:38	csharp	@later tell gsams re: "stuck" reports, I usually update the reporter.schedule row with "set error_code = 1, error_text = 'Report failed - please open a support ticket'" or somesuch
12:38	pinesol_green	csharp: The operation succeeded.
12:39	csharp	@later tell gsams oh - and with 'complete_time = now()' - that's what keeps it from showing up as a currently running report ;-)
12:39	pinesol_green	csharp: The operation succeeded.
14:52		zerick joined #evergreen
16:56	pinesol_green	Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html>
22:33	dbwells	Heads up to all committers: rel_2_6 is now branched from master. Both are resting comfortably.
22:47		shart290__ joined #evergreen
22:49	shart290__	i got everything running. I just need to set up the staff client. what host do I enter into the staff client to connect if its on the local machine?

Results for 2014-04-19

02:17		dreuther_ joined #evergreen
03:13		mceraso joined #evergreen
04:56	pinesol_green	Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html>
05:55		zerick joined #evergreen
07:13		mceraso joined #evergreen
07:16	csharp	bshum: bug 1272937

Results for 2014-04-18

13:27	jeff	shart291: what distro and version did you start with?
13:28	shart291	Debian Squeeze, I initially began with the intent to preserve the existing system. When I learned the database wasnt recoverable I reinstalled With Wheezy. Thats when I was in the last couple of days trying to get things to run.
13:28	shart291	I'm tired and just want to get it going.
13:35	phasefx	demo.evergreencatalog.com is up if anyone wants to give it a spin. I only tested a search and logging in to the TPAC
13:36	kmlussier	phasefx: Do you mind if I send an e-mail to the DIG list letting people know?
13:36	phasefx	kmlussier: go for it
13:37	phasefx	I'll be back in a bit if anyone has trouble with it
13:58	* phasefx	is going to whip up a stored procedure to protect the admin user
13:58	kmlussier	graced: Yeah, but even with a better data set, I think it would be useful to have a handful of barcodes of patrons in a "good" status, and then some barcodes of patrons with overdues or outstanding bills.
13:59	graced	We can provide that - that's the plan with the better data set
13:59	kmlussier	So that if they are documenting something related to penalties, for example, they know which test users already have those penalties.
13:59	graced	Exactly.
13:59	kmlussier	graced++
13:59	graced	More like akilsdonk++ as she's doing all the hard work on this one
14:13	sseng	kmlussier: yep
14:14	kmlussier	Usually, I might select one to import non-matching and then select just one of the others to tell the system how to do the merge. I don't think it's typical to select all three.
14:15	kmlussier	We have some sites that only want the system to merge automatically if there is a single match, but if there are more they want to address it manually.
14:15	sseng	kmlussier: bshum: wanted to confirm that in master, whether the Marc batch importer/exporter works or whether i have somehing bad going on with my test environment
14:15	kmlussier	Other systems prefer to let Vandelay do all of the merging and will just tell it to select the best match.
14:16	bshum	In theory everything in master should be working, unless there's a bug filed about it. Or at least I like to dream that's the case.
14:16	bshum	:)
14:16	sseng	kmlussier: i am going to give that a try
14:16	sseng	bshum: =)
14:16	bshum	But in this particular case, please feel free to collect some details and let us know. Overall, the vandelay situation was complicated due to underlying changes made with MVF/CRA's addition
14:16	bshum	And we may not have shaken all the issues?
14:17	bshum	I would test more, but today is a "holiday" and nobody at Biblio is around. Other than those of us migrating our email to a new solution.
14:17	kmlussier	sseng: I did successfully do an acq upload on a recent version of master, but I didn't try anything in the batch import, so it's possible something else is going on there.
14:17	bshum	fwiw, mllewellyn did do a vandelay load of around 29 or so I think she said
14:18	bshum	And that seemed to go through without hijinks
14:18	bshum	But maybe it's size, or maybe it's the options used
14:18	sseng	bshum: kmlussier: going to do more testing, maybe a bad mrc file. (just wanted to do a quick check and see if anyone's used it recently)
14:19	bshum	Recently like... last week, sure.
14:19		hbrennan joined #evergreen
14:21	phasefx	who was trying out the smartfaq plugin in wordpress?
16:41	bshum	Line 263 of configure.ac
16:41	bshum	For OpenSRF
16:46		mllewellyn_ 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:27		mllewellyn joined #evergreen
17:50		kmlussier left #evergreen
23:09		artunit_ joined #evergreen

Results for 2014-04-17

03:29		bradl joined #evergreen
04:23		ldwhalen joined #evergreen
04:28		ldwhalen 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:40		b_bonner joined #evergreen
06:40		mtcarlson_away joined #evergreen
07:10		ldwhalen joined #evergreen
11:25	shart290	all xml files. opensrf.xml opensrf_core.xml and srfsh.xml
11:26	csharp	shart290: your opensrf.xml is for OpenSRF, not Evergreen
11:26	Dyrcona	shart290: There's a script to set it. I forget the name.
11:26	csharp	shart290: i.e., that's the file you need in place for testing OpenSRF connections, not running Evergreen
11:27	shart290	ok, so I need to copy the example from Evergreen-ILS-2.5.3/Open-ILS/src/examples/ ?
11:27	csharp	shart290: yep
11:29	shart290	ok, running a DIFF on the two, may search/replace for the LOCALSTATEDIR, SYSCONFDIR, and PREFIX
16:55	jeff	but bshum raises a good point -- postgresql does not appear to be listening on any port.
16:55	shart290	allow/enable on localhost?
16:55	bshum	What does ejabberd's config look like?
16:56	pinesol_green	Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html>
16:56	bshum	Maybe the listen addresses aren't quite right?
16:57	pastebot	"shart290" at 64.57.241.14 pasted "ejabberd.cfg" (644 lines) at http://paste.evergreen-ils.org/69
16:58	jeff	shart290: when you issue this command, do you get some XML back containing xml-not-well-formed? echo foo \| nc localhost 5222

Results for 2014-04-16

01:27		zerick joined #evergreen
04:41		dbs joined #evergreen
04:56	pinesol_green	Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html>
06:58		timlaptop joined #evergreen
07:51		collum joined #evergreen
08:04		rjackson-isl joined #evergreen
09:17	jl-	fgin=fine
09:18	RoganH	jl-: Is it fine for each cataloger to edit each bib record?
09:18	dbwells	jl-: Yes, search scoping can happen via the call number /copy ownership.
09:18	jl-	RoganH: at this point it's test run and there won't be any catalogers (library staff?)
09:18	jl-	it's more of a proof-of-concept
09:19	RoganH	jl-: Ah. Well, when you get to that stage that will be a big deal. If they feel territorial and each university has to "own" their bib that will be a big issue.
09:19	Dyrcona	Yeah, jl-, the more you learn now, the better off you will be later.
09:19	jl-	well they certainly own the individual books?
10:54	yboston	Any US citizens that want to give me tips of how to submit the RDA records I am acquiring to be added tot he communtiy dataset?
10:54	dbs	And then download the MARC (Unicode) records one by one. You could put them all together and submit them as a branch, after which they would get munged into the sample loader format
10:55	yboston	(nevermind)
10:55	dbs	(e.g. drop them into a Open-ILS/tests/datasets/RDA/ subdirectory and then they could get reformulated)
10:55	yboston	(thanks for the path, was just about to ask)
10:58	yboston	I assume it OK if I start with a branch with just a few RDA files , then create more branches later
10:58	yboston	s/it/it is/
11:05	mrpeters	one of our customers wants to become a target for the community so i'm just relearning the process. It was kind of a set it and forget it thing when I did it the other time.
11:08		ldwhalen joined #evergreen
11:09	jeff	Dyrcona: sounds like a bug (re: gists). have an example?
11:10	* dbs	doesn't know if there's a way to search catalog.loc.gov for 264 ind2 != 1 though, which is what we need to test Dyrcona's branch
11:14	Dyrcona	jeff: I would have said open any gist, click on the link for raw, right-click in the window, choose save as, and then open the file in a text editor to see the HTML.
11:15	Dyrcona	I've seen that twice.
11:15	Dyrcona	However, when I tried to repeat that just now, it didn't happen. I got plain text.
11:31	RoganH	asimon: it doesn't really affect availability per se, we are configured so that it can still be targeted for holds and checked out
11:32	asimon	*: TY to all. I have to run.
11:34		denishpatel joined #evergreen
11:35	dbwells	So, I've already cut 2.6.0 and am testing now, but can anyone take a look at the newly posted bug #1308590?
11:35	pinesol_green	dbwells: Error: Could not gather data from Launchpad for bug #1308590 (https://launchpad.net/bugs/1308590). The error has been logged
11:38	gmcharlt	hmm; LP isn't responding ATM
11:39	dbwells	eyeball test says it won't cause any harm, but better to be sure. Branch is here, since LP isn't responding: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbs/lp1308590_fix_schemaorg_type
11:39	gmcharlt	https://bugs.launchpad.net/evergreen/+bug/1308590
11:39	pinesol_green	Launchpad bug 1308590 in Evergreen "CCVM/icons broke schema.org type matches" (affected: 1, heat: 6) [Undecided,New]
11:41		mmorgan left #evergreen
11:41		mmorgan joined #evergreen
11:41	gmcharlt	dbwells: I can test and push to master in the next 15 minutes or so
11:41	gmcharlt	up to you whether to recut 2.6.0, but I certainly have no objection if your doing that
11:41	gmcharlt	*to your doing that
11:42	dbwells	gmcharlt: excellent, thanks
11:43		RoganH left #evergreen
11:44		jventuro joined #evergreen
16:45	shart290	already
16:46	Dyrcona	shart290: Yep. So, what happens if you do cd to go back to your home directory and then run osrf_control without the ./?
16:48	shart290	it worked when I entered a login session for opensrf but not when I use sudo -u opensrf
16:49	dbs	mrpeters: are the staff hitting the big red "X" button to delete the address?
16:49	dbs	'cause that's what ours do.
16:50	* dbs	just fired up the staff client for the first time in months and added a user on the test server
16:51	Dyrcona	shart290: osrf_control starts daemon processes and that may not work with sudo.
16:51	shart290	is there another way to execute as one user from another?
16:51	* dbs	does "sudo su - opensrf" and then runs the commands.
16:54	* csharp	usually does 'sudo -i' then 'su opensrf' so I can move between opensrf and root, but tomayto/tomahto
16:55	shart290	ok, lemme try this. I am so close and my head is about to implode
16:55	* dbs	confirms "sudo -i -u opensrf osrf_control -l --stop-all" works whereas "sudo -u opensrf osrf_control -l --stop-all" does not
16:56	shart290	bingo
16:56	shart290	thanks you all
16:57	shart290	dbs++ Dyrcona++, mrpeters++ csharp++
16:57	shart290	now to get the client to test. I will be setting up another computer to handle the staff client.
16:57	shart290	just need to get an interface.
16:58	Dyrcona	I always login to the server as the opensrf user, then sudo if I need root.
16:58	Dyrcona	Anyway, time for me to go.
16:59		mdriscoll left #evergreen
17:23	hbrennan	Haha
17:28	gmcharlt	Evergreen: keeping circ desk staff alert since 2007
17:28	gmcharlt	s/2007/2006/
17:29	pinesol_green	Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html>
17:31	shart290	gonna reboot.
17:42		shart290 joined #evergreen
17:47	pastebot	"shart290" at 64.57.241.14 pasted "Issues running evergreen after install" (58 lines) at http://paste.evergreen-ils.org/60

Results for 2014-04-15

01:28		eby__ joined #evergreen
04:17		tfaile joined #evergreen
05:12		phasefx joined #evergreen
05:30	pinesol_green	Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html>
07:00		timf joined #evergreen
07:03		Callender joined #evergreen
07:04		tfaile joined #evergreen
09:35	jl-	jcamins: what are the implications of that? I've been using equinox migration tools and they have served me well so far
09:36	jl-	mrpeters: http://paste.debian.net/hidden/46f59b30/
09:36	jcamins	jl-: potentially you'll run into a situation where existing tools don't seem to be giving you the expected result. That's all.
09:37	jl-	jcamins: yes, thankfully this is a test run
09:37	jl-	I've already had to do some costumizing
09:38	jl-	*custom
09:38	jl-	and thanks for the koha link jcamins, that is the next ILS we are wanting to test
09:39	jcamins	There are other versions of the migration toolkit, so you might want to look around to see if anyone has anything better.
09:39	dbs	jl-: mfhd for serials may end up going into serial.record_entry if your library doesn't circulate your serials
09:39	Dyrcona	jl-: Looking at the code that jcamins pointed out, it appears to expect some item information in the bibliographic (MARC) records. That gets matched up with other information from items.txt later.
13:23	Dyrcona	csharp: Did you do it as a consortial admin or did library staff do it?
13:23	csharp	library staff
13:23	Dyrcona	I agree that it sounds like a bug.
13:23	csharp	we tested it on our test system as a local admin
13:23	RoganH	did the local admin have all working locations assigned?
13:24	csharp	RoganH: I don't know who did it
13:24	RoganH	I want to say the issue for us came up when internal help desk staff who had all working locations did it.
13:24	csharp	it appeared on everyone's closed dates, though, and it's 2 weeks away (our normal checkout duration)
13:25	kmlussier	Looking at the Closed Dates Editor, my expectation would be that it would apply to all the children of the OU that's selected at the top of the screen.
13:25	csharp	could someone please test after me?
13:25	kmlussier	Even if the person using the editor had permission at more working locations.
13:25	csharp	it may be something local
13:25	RoganH	I'll test right now.
13:25	csharp	RoganH: much appreciated
13:34	RoganH	csharp: just tested with my 2 account. Account A has all working locations. Account B only has the locations in one system. In both cases the closed date applied to all locations where that account has working locations regardless of where in the org tree they applied the date.
13:34	RoganH	If the "apply to all my libraries" is checked.
13:35	RoganH	If that is not checked it is only applied to the individual library.
13:36	jeff	gmcharlt: thanks! (re: libki)
13:36	RoganH	In neither case does it go down the org unit tree and apply to child org units.
13:37	csharp	RoganH: thanks
13:39	dkyle	Jeff: we are testing libki. bott has done a few mods for EG integration
13:40	RoganH	csharp: one of the reasons I never reported it as a bug is I'm OK with it functioning like that. It means it's not practical for me to set the closed dates for each library system and they have to do it.
13:50		jwoodard joined #evergreen
14:16		mcooper joined #evergreen
14:18		RoganH joined #evergreen
14:23		geoffsams joined #evergreen
14:34		mrpeters joined #evergreen
14:36	dbs	Dyrcona: finally running your branch with test RDA bibs. Very interesting.
14:36		kmlussier1 joined #evergreen
14:37	dbs	Dyrcona: in the case of record matching (OCoLC)825763702, there's "264 4 ‡c℗2013" that doesn't appear to be displayed anywhere
14:38	* Dyrcona	is in a meeting. I'll look later.
14:39	dbs	Also looks like, with more descriptive 7xx fields, we're going to have to revise the added author stuff further (probably picking up from a discussion that bshum and I were having a while back)
14:39	dbs	cool
14:58		kayals_ joined #evergreen
15:05	dbs	@later tell Dyrcona dang, the batch of RDA bibs you supplied only has 18 records with "264 ind2=<anything other than 1>" and all of those simply have 264 ind2=4 $c<date>" which doesn't get displayed; that is,
15:05	pinesol_green	dbs: The operation succeeded.
15:06	dbs	@later tell Dyrcona that is, the test bibs don't really help with testing that part of the patch. Really useful for the added author / schema.org type matching though!
15:06	pinesol_green	dbs: The operation succeeded.
15:06	Dyrcona	dbs: Hmm. sorry. I grabbed records that had all the RDA fields that came up in the IRC discussion.
15:09	dbs	Dyrcona: no worries! if you want to hand-pick a few that have more interesting 264 fields for your patch's purpose, it would be easy to roll those in
15:10	Dyrcona	dbs: If I can find the ones that I tested with, sure.
15:10	Dyrcona	Movies seem to be good choices.
15:10	dbs	Dyrcona++
15:23	yboston	dbs & Dyrcona : the two Berklee catalogers will start picking RDA records to be added to the EG data set
15:33	kayals_	yes
15:34	kayals_	Electronic resources does NOT show in the search result page but does show up in record summary
15:34	kmlussier	kayals_: Does it show up in the search results after you click the "Show more details" button at the top of the page?
15:34	kayals_	i know other libraries have their search result page show Electronic Resource listed with links
15:35	kayals_	we do not use show/hide more details as we removed that tabs
15:35	kayals_	i can add it and test it
15:53	kayals_	kmlussier - I added back show/hide more details in the results.tt2 file still no luck
15:53	kayals_	it does not show electronic resource
15:56		kmlussier1 joined #evergreen
16:07	bshum	kayals_: URI entries for 856 only appear when making use of the $9 trick
16:07	rjackson-isl	right and don't you need to be logged in to the branch showin gin the $9 as well?
16:35	gmcharlt	yboston: sorry for the delay; it shoudl work now
16:40	yboston	gmcharlt: thanks, it works
17:07		RoganH left #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
18:43	bshum	Hmm
18:43	bshum	So in Open-ILS/xul/staff_client/server/circ/checkout.js

Results for 2014-04-14

00:33	bshum	@later tell kmlussier The LJ article about open source systems is up online now: http://www.thedigitalshift.com/2014/04/ils/open-source-options-library-systems-landscape/
00:33	pinesol_green	bshum: The operation succeeded.
01:12		b_bonner joined #evergreen
01:13		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>
05:45		pastebot0 joined #evergreen
05:47		jventuro joined #evergreen
08:04		collum joined #evergreen
11:32		asimon joined #evergreen
11:33	Dyrcona	kmlussier: Could be the version. I think bibliomation and MVLC are on a newer "release." We're on the equivalent of 2.5+.
11:34	kmlussier	Dyrcona: This is 2.5.3
11:38	asimon	I'm attempting to overlay the action_trigger schema using pg_restore, but I keep getting hung up on restoring the *pkey table constraints, even after using the --clean and --data-only options. Attempting to drop one of the constraints as a test suggest that I use CASCADE, but that affects indices. Is there an easier way to do this?
11:43	bshum	Yeah, we're like halfway to 2.6
11:43	bshum	Well, more like 75% of the way
11:44	csharp	asimon: so by "overlay" do you mean "remove the data that's there and insert new data"?
16:15	bshum	To get things to pop up
16:15	bshum	I remember this bug now
16:17	bshum	gmcharlt++ # thanks
16:18	eeevil	kmlussier: so phasefx ran the auth-auth linker on cwmars' test system, but that will only cause a reingest on the /unauthorized/ side of an auth-auth link (that's the record that changes with the addition of a $0). the remainder of the auth records would not have been reingested, thus the lowercased main entries. After the current auth-bib linking work, the plan is to do a non-propagating auth reingest, which will clear up those remainders
16:18	bshum	Good ol' https://bugs.launchpad.net/evergreen/+bug/1091885
16:18	pinesol_green	Launchpad bug 1091885 in Evergreen "Reingest bib needs to deal with missing metabib.record_attr entries" (affected: 2, heat: 12) [Medium,Confirmed]
16:19	kmlussier	eeevil: OK, I though they said a full authority reingest had been done, but they have misunderstood.
16:36	kmlussier	eeevil: I don't know if this makes a difference, but the lowercase display was not for the main entries. It was only for the unauthorized headings. If the auth-auth script reingested the unauthorized heading, shouldn't those be displaying in proper case?
16:36	kmlussier	Sorry if I'm missing something obvious.
16:42		finnx joined #evergreen
16:56	pinesol_green	Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html>
17:00	dbwells	eeevil: yboston: I've been in meetings all afternoon, sorry. The upgrading section of the docs is pretty generic. The salient instructions about reingesting are dumped to screen at the end of the big 2.5.0 upgrade script.
17:02	yboston	dbwells: good to know
17:03	dbwells	I do think it makes sense to get that info into the docs as well.

Results for 2014-04-13

01:33		edoceo joined #evergreen
01:33		mcooper joined #evergreen
01:52		book` joined #evergreen
04:56	pinesol_green	Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html>
05:20		book` joined #evergreen
05:20		Sato`kun joined #evergreen
05:20		pastebot joined #evergreen

Results for 2014-04-12

14:07		robbat2 left #evergreen
16:19		kmlussier joined #evergreen
16:45		zerick 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>
19:09		ldwhalen joined #evergreen
20:07		edoceo joined #evergreen

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)
16:55	jcamins	(where body is a placeholder for the element, and styles might be called style)
16:55	jcamins	dbs: BTW, Laurentian's catalog looks fine without JS.
16:55	jeff	bshum: "swivels!" -- talk about missing some context. hopefully you didn't have a terrible run-in with an AMH/sorter? :-)
16:56	* jcamins	just tested it to see if TPAC handled no-JS pleasantly.
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:57	bshum	jeff: I was just remarking where dbs mentioned avoiding JS as much as possible and how berick and senator at the hackaway two years ago had thoughts about more swivels with JS to smooth out the transitions in record summary
16:57	bshum	For the added content, etc.
16:57	Dyrcona	jcamins: That was kind of the point of TPAC, no JS.
17:41		ldwhalen joined #evergreen
17:41		atlas__ joined #evergreen
17:48	hbrennan_at_lunc	It's possible I may be hungry
17:51	gmcharlt	hbrennan_at_lunc: enjoy testing that hypothesis empirically!
18:27	dbs	gmcharlt: I believe it's possible to issue multiple requests per Read API request; travelling back in time to when I was talking with the OpenLibrary folk about their rate-limiting etc
18:28	dbs	I brought up the exact same point: "So, you're not rate limiting the Read API, but I end up making _more_ requests than via the Cover API?" They agreed that was silly.
18:28	gmcharlt	dbs: I've verified that is is; possibly something for mark 2 of my patch for bug 1306258

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

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>