2011-01-11T06:54:07 *** CmptrWz has joined #evergreen 2011-01-11T06:54:15 *** tsbere has quit IRC 2011-01-11T07:27:12 *** rickd_ has joined #evergreen 2011-01-11T08:13:01 *** rickd_ has quit IRC 2011-01-11T08:15:49 *** kmlussier has joined #evergreen 2011-01-11T08:21:02 *** Ghidorah has quit IRC 2011-01-11T08:23:43 *** collum has joined #evergreen 2011-01-11T08:26:30 *** Dyrcona has joined #evergreen 2011-01-11T08:27:30 *** CmptrWz is now known as tsbere 2011-01-11T08:44:19 *** mjg_ has joined #evergreen 2011-01-11T08:44:35 *** mjg_ has left #evergreen 2011-01-11T08:50:57 *** ebyr has joined #evergreen 2011-01-11T08:54:50 *** kmlussier has quit IRC 2011-01-11T08:59:49 *** kmlussier has joined #evergreen 2011-01-11T09:01:11 *** yboston has joined #evergreen 2011-01-11T09:07:20 *** Meliss has joined #evergreen 2011-01-11T09:08:07 *** ebyr has quit IRC 2011-01-11T09:13:44 *** Dmagick-home has joined #evergreen 2011-01-11T09:25:52 *** rsoulliere has joined #evergreen 2011-01-11T09:30:12 *** alxp has joined #evergreen 2011-01-11T09:40:05 *** bshum has joined #evergreen 2011-01-11T09:46:51 *** jenny has joined #evergreen 2011-01-11T10:04:56 *** dbs has joined #evergreen 2011-01-11T10:07:35 are folks still using the bootstrap cgi scripts in 1.6 for circ rule durations, etc? or are you just hand-entering things directly into the database? 2011-01-11T10:18:03 phasefx: I've been entering things by hand directly for 1.6 2011-01-11T10:18:10 2.0 has a GUI for that I think? 2011-01-11T10:18:27 Haven't used bootstraps since 1.4 :( 2011-01-11T10:18:35 (successfully anyways) 2011-01-11T10:18:36 Trunk does for sure, I think 2.0 also 2011-01-11T10:19:03 *** rickd_ has joined #evergreen 2011-01-11T10:20:18 *** atheos_ has joined #evergreen 2011-01-11T10:25:39 @later tell jamesrf Saw this bug post - http://ur1.ca/2t77h about adding org-unit context to circ/hold editors and thought how great it would be to have! Curious to discuss it with you. 2011-01-11T10:25:39 bshum: The operation succeeded. 2011-01-11T10:34:04 phasefx: I created all of mine by handSQL. What do the official 1.6 docs say to do? 2011-01-11T10:34:17 * phasefx looks 2011-01-11T10:35:27 I don't see anything for configuring circ/hold behavior 2011-01-11T10:37:23 bah, who needs that anyways? :) 2011-01-11T10:40:29 you get some behavior out of the box, that's all that's needed :) 2011-01-11T10:43:32 I think circ/hold policy editing sections are still needing writers. Last I recalled anyways. 2011-01-11T10:43:37 *** ebyr has joined #evergreen 2011-01-11T10:43:45 For the official 1.6 documentation. 2011-01-11T10:43:53 (and 2.0 I suppose) 2011-01-11T10:50:33 If you want documentation, read the source. ;) 2011-01-11T10:53:35 * phasefx votes for rewriting Evergreen in cobol 2011-01-11T10:53:53 lol 2011-01-11T10:54:47 why not just go for assembly? 2011-01-11T10:55:20 mov ah, 0 2011-01-11T10:55:31 would that coblol, then? 2011-01-11T10:55:53 * Dyrcona is having finger-coordination issues, please stand by. 2011-01-11T10:56:00 * phasefx can write in machine language on x86. copy con > foo.com alt+198 control+z 2011-01-11T10:56:10 sorry, copy con foo.com 2011-01-11T10:56:23 or was alt+195 2011-01-11T10:56:31 one will simply return, the other might fry your monitor 2011-01-11T11:09:22 *** rickd_ has quit IRC 2011-01-11T11:09:45 *** rickd_ has joined #evergreen 2011-01-11T11:28:55 *** tspindler has joined #evergreen 2011-01-11T11:32:26 *** ebyr has quit IRC 2011-01-11T11:40:41 *** granitize has joined #evergreen 2011-01-11T11:41:59 *** r123 has joined #evergreen 2011-01-11T11:44:15 * dbs goes to get a coffee prior to the dev meeting 2011-01-11T11:44:21 anyone else want one? 2011-01-11T11:45:12 dbs: yes, please 2011-01-11T11:45:45 * phasefx is mixing cocoa with his 2011-01-11T11:45:57 * gmcharlt continues working on pot he brewed in hotel room 2011-01-11T11:46:19 * tsbere considers going to make a hot chocolate 2011-01-11T11:46:36 * tsbere also considers the pros and cons of being able to apply "revoke" permissions to groups 2011-01-11T11:47:48 when permissions and anti-permissions combine... 2011-01-11T11:47:58 miker_ explodes 2011-01-11T11:50:08 I can see wanting to have a "restricted" group that prevents someone from gaining certain permissions. Perhaps a "no-overrides" group that has all the .override permissions revoked. 2011-01-11T11:50:35 I can also see having such a group to begin with as being a sign of bad permission granting to begin with 2011-01-11T11:51:06 * phasefx would like to see a UI supporting multiple groups for a given user 2011-01-11T11:51:16 * tsbere plans on that in multiple ways 2011-01-11T12:01:00 Time 2011-01-11T12:03:07 Volunteers for 1) minutes 2) leading? 2011-01-11T12:04:09 *** ChanServ changes topic to "Dev meeting agenda: http://ur1.ca/2t85c | Welcome to the #Evergreen library system channel! | We are publicly logged. | Large pastes at http://paste.lisp.org/new/evergreen" 2011-01-11T12:04:17 dbs: I can do one of those 2011-01-11T12:04:43 I'll minute 2011-01-11T12:04:44 Unless someone else wants the honor? 2011-01-11T12:04:59 Okay 2011-01-11T12:05:30 So, leading... 2011-01-11T12:05:40 3. (10 min) Review Action Items from previous meeting 2011-01-11T12:06:04 I. a. release notes for OpenSRF 1.6.2 still being written? 2011-01-11T12:06:12 I. b. Implement proper library versioning using autotools for Evergreen release. 2011-01-11T12:06:25 Still no release notes for OpenSRF. But I did add library versioning for Evergreen (./autogen.sh ; ./configure ... ; make clean; make ; make install) 2011-01-11T12:07:01 the last set of commands is necessary if you're building out of the same Evergreen 2.0 or trunk checkout as prior to the library versioning commit 2011-01-11T12:07:09 dbs++ 2011-01-11T12:07:59 Okay, II. Mike Rylander to write release notes for Evergreen 1.6.1.5 (6?) 2011-01-11T12:08:16 Mike's traveling 2011-01-11T12:08:31 Okay, deferred. 2011-01-11T12:08:45 III. Chris Sharp to respond to the feasibility of setting up an “anyone can post” moderated list made up of the LaunchPad security team members 2011-01-11T12:09:15 I gather from the email that's a "coming soon"? 2011-01-11T12:09:33 He did respond at http://markmail.org/message/bxlhrcw2m6fk23vz - any updates on timing csharp? 2011-01-11T12:12:03 Alright, we'll poke csharp on that more later, I guess. 2011-01-11T12:12:06 actually, http://markmail.org/message/j2wzi6lju4c7btgn is the more recent response 2011-01-11T12:12:18 okay 2011-01-11T12:12:42 IV. Adoption of the release checklist -> http://evergreen-ils.org/dokuwiki/doku.php?id=dev:evergreen:release_checklist 2011-01-11T12:13:43 I don't think Mike has posted about that to the list. I can respond to Chris's email about mailing lists and add that as a request 2011-01-11T12:14:11 also ... if anyone else has looked at the checklist and has any thoughts about additions / changes, have at it 2011-01-11T12:14:57 Sounds good. Feedback requested 2011-01-11T12:15:12 V. 1.6.2.1 release (done!) 2011-01-11T12:15:13 * Dyrcona will give it another look. 2011-01-11T12:15:22 VI. Dan Scott to backport some authority work from trunk to address see / see from references (somewhat) 2011-01-11T12:16:08 I guess you did that 2011-01-11T12:16:15 Since VII. Cut of 2.0 RC2 2011-01-11T12:16:17 Happened already 2011-01-11T12:16:26 Yep, existing changes were backported and miker cut 2.0RC2 2011-01-11T12:16:41 There have been a few more authority changes since then, but minor 2011-01-11T12:17:49 Cool. 2011-01-11T12:17:50 IX. James Fournie / SITKA to test 2.0RC2 and report back 2011-01-11T12:18:02 you skipped viii. 2011-01-11T12:18:11 Bah, thanks Dyrcona 2011-01-11T12:18:21 VIII: Mike Rylander to create a bug (and possibly fix!) for moving custom index definitions around during upgrade to make room for the pinned-ID indexes added in stock 2.0 2011-01-11T12:19:19 any suggestions for testing this or does it still need testing? 2011-01-11T12:19:51 More testing is always good; it worked for our 6 or 7 custom indexes, including the subject|complete 2011-01-11T12:19:56 dbs: I haven't had the opportunity to test your changes there yet. We also use some extra custom indexes. 2011-01-11T12:19:57 * Dyrcona notes a question mark after the "Done" on the agenda. 2011-01-11T12:20:05 dbs: I'll give it a try this week then. 2011-01-11T12:20:27 Dyrcona: yeah, given that miker probably had an approach in mind, I would like it if he could glance at what I've done to see if there are any obvious holes 2011-01-11T12:20:31 bshum++ 2011-01-11T12:20:38 *** jamesrf has joined #evergreen 2011-01-11T12:20:47 jamesrf, just in time :) 2011-01-11T12:21:19 Indeed! 2011-01-11T12:21:30 IX. James Fournie / SITKA to test 2.0RC2 and report back 2011-01-11T12:21:35 What were you testing? 2011-01-11T12:22:12 we haven't really started so nothing to report 2011-01-11T12:22:27 we are planning to test as much as possible core daily production functionality 2011-01-11T12:23:03 only thing of note so far is some inconsistency in date formats but that's not really a deal breaker for anything 2011-01-11T12:24:27 Alright, jamesrf, let us know what you find out! Some of us are testing too, so we'll compare notes. 2011-01-11T12:24:35 X. Mike Rylander to continue the ”DVCS? and if so, which one and when and how?” discussion on the mailing list 2011-01-11T12:25:02 Haven't heard from him yet. We need to fork miker 2011-01-11T12:25:40 all your rebase are belong to us 2011-01-11T12:25:56 bzr branch eeevil or git clone eeevil 2011-01-11T12:26:32 fork() && exec() 2011-01-11T12:26:42 Heh, alright, discussion continues then! 2011-01-11T12:26:54 XI. Dan Scott to post a notice to the -dev mailing list to call for ideas and discussion about any other major infrastructure changes that we should consider for post-2.0 2011-01-11T12:27:13 There was a wiki for this before right? 2011-01-11T12:28:02 bshum: there are some really outdated wiki pages that I can think of 2011-01-11T12:28:25 * Dyrcona needs to respond to the thread on the list. 2011-01-11T12:29:04 wiki pages in and of themselves don't seem to generate discussion, whereas a mailing list hopefully gets some thoughts front and center - and then we could extract relevant parts to a wiki page 2011-01-11T12:29:28 * dbs keeps hoping for a testing regime to move in 2011-01-11T12:29:37 That's what I was wondering. To summarize things after. 2011-01-11T12:30:26 * dbs will create a "pipedreams:" namespace 2011-01-11T12:30:50 to replace http://evergreen-ils.org/dokuwiki/doku.php?id=sofware_bounties and http://evergreen-ils.org/dokuwiki/doku.php?id=development_proposals 2011-01-11T12:31:12 heh sofware 2011-01-11T12:31:44 Alright, last item: 2011-01-11T12:31:46 XII. Dan Scott to post a notice to the -dev mailing list to find out if there's support / start planning for an extra day or two at the end of the conference for an in-person dev team meeting / planning session / coding session 2011-01-11T12:32:38 If there's interest, go reply to the thread! 2011-01-11T12:33:44 fwiw, i know a place we can meet that's not too far from the conference ;) 2011-01-11T12:34:39 Okay: 2. Evergreen release status: 2011-01-11T12:35:44 About the LP milestones, when we cut a release, do we create new milestones for the next anticipated releases? Or is that all need to be part of how we do the release checklist? 2011-01-11T12:35:51 1.6.1.6 was released, and Launchpad needs to be updated to reflect that (create release, create new 1.6.1.7 milestone); like, if we were coordinating our releases our something 2011-01-11T12:36:30 bshum: yeah, exactly, these should be tasks on the release checklist, and someone needs to be held responsible for doing them :) 2011-01-11T12:37:27 sounds like we need to have the release checklist email discussion. 2011-01-11T12:37:40 Indeed. 2011-01-11T12:38:20 Any big bugs we need to talk about right now? 2011-01-11T12:38:22 from the looks of it, there's no outstanding bugs in 1.6.1? 2011-01-11T12:39:09 dbs: So far. I'm reviewing the slew of bugs waiting 1.6.1.x confirmation/testing 2011-01-11T12:39:12 well - https://bugs.launchpad.net/evergreen/1.6 2011-01-11T12:39:29 Well, helping to review 2011-01-11T12:39:31 yay bshum++ 2011-01-11T12:39:38 I wasn't sure how to target things 2011-01-11T12:39:51 Since 1.6.1.6 was already released and I couldn't target a branch, it seemed. 2011-01-11T12:39:53 i need to go through the recent bugs. i'll do this today if I can figure out why some of my org_unit drop downs are empty. 2011-01-11T12:41:19 Guess we'll be working on bug wrangling for the next time. 2011-01-11T12:41:40 Any other items on the agenda to discuss before we schedule the next meeting? 2011-01-11T12:41:43 * Dyrcona has been a bit of a slacker since the holidy. 2011-01-11T12:41:48 Or 2.0-related bits? 2011-01-11T12:42:17 dbwells just posted something about serials and call numbers which looks like it would require a schema change? 2011-01-11T12:42:44 yes. i was thinking that would be a good addition to the post 2.0 discussion, myself. 2011-01-11T12:42:55 yeah, sorry for my really poor timing on getting that out after the meeting already started. 2011-01-11T12:43:36 *** b_bonner has joined #evergreen 2011-01-11T12:43:39 I expect some people may want to digest it first before commenting. 2011-01-11T12:43:43 If we can nail down a solid 2.0 release (it feels like we're close) and then work towards a quick iteration for 2.1 to include new features, including schema changes, I'd be happy 2011-01-11T12:44:11 dbs: me, too. i'd like to see the goal be 2.1 in April as planned. 2011-01-11T12:44:35 be a nice announcement for the conference. 2011-01-11T12:44:55 +1 # we have a bunch of stuff in our queue, but if we hold up 2.0 for it, it will never get released 2011-01-11T12:46:00 do any of the ESI people know if eeevil will be able to cut a 2.0RC3 real soonlike? 2011-01-11T12:46:28 dbs: travel delays aside, I would imagine so 2011-01-11T12:46:48 If we could cut that, and really hammer on it, I think we could get a final release out in the next two weeks, assuming no blockers turn up 2011-01-11T12:46:53 is miker the only one who can cut a release? 2011-01-11T12:47:22 i mean technically and, i guess, politically. 2011-01-11T12:47:52 Dyrcona: there are parts of the release process that aren't well documented - creating the Dojo layer, for example 2011-01-11T12:48:31 it's more complex than the opensrf release process (http://evergreen-ils.org/dokuwiki/doku.php?id=dev:rolling_a_release) but documenting it would be the first step towards automating it 2011-01-11T12:48:40 ok. that basically answers my question. 2011-01-11T12:48:43 and automating it is the first step towards a build server 2011-01-11T12:48:46 In the case of what I just wrote, I think April is too far out for the resolution I am asking for. I really wouldn't be suggesting it now if I didn't feel it was very important to resolve pre-2.0. The schema change portion could be postponed if that is the main sticking point. 2011-01-11T12:52:21 Sounds like something that'll need to be hashed out on list / chats. Action item to check on this topic for next week's agenda? 2011-01-11T12:52:42 (just aiming to close off the meeting, discussion can continue) 2011-01-11T12:52:43 bshum: that sounds fine, thanks 2011-01-11T12:52:43 Yes, let's keep discussing post-meeting (list and/or IRC) 2011-01-11T12:53:14 Scheduling of next meeting is tentatively set for next Tuesday, January 18th, same time 2011-01-11T12:53:31 Let's lock that in unless someone has an objection? 2011-01-11T12:53:53 *** agJohn has joined #evergreen 2011-01-11T12:54:02 Seems to be enough precedent now to keep it same time / same place 2011-01-11T12:54:03 none from me 2011-01-11T12:54:11 +1 2011-01-11T12:54:28 Okay, next meeting confirmed. I'll send out a reminder and work with dbs on minutes/agenda for next week. 2011-01-11T12:54:41 tsbere: are you going to chime in with your thoughts on revamping permissions on the "post 2.0 planning" thread? 2011-01-11T12:55:18 dbs: I am still working on how I want to revamp them. Will chime in when I get to that point. 2011-01-11T12:55:24 tsbere: cool 2011-01-11T12:55:47 btw, remember that conf. submission deadline is friday 2011-01-11T12:56:00 berick++ 2011-01-11T12:56:10 should we try to coordinate submissions? 2011-01-11T12:56:22 yeah.. cuz I need a talk idea ;) 2011-01-11T12:56:25 e.g. "I hope somebody talks about XXX"? 2011-01-11T12:57:11 is there a way to see what's already submitted? 2011-01-11T12:57:17 not that I know of 2011-01-11T12:57:20 Hi Folks. (Meeting over?) The 1.6.1.x to 2.0 upgrade script has ID's for inserts into config.metabib_field; this really is not the way things should be done. These (and other) IDs do not need to be included (makes a real pain when the DB you're upgrading has more entries than expected). Interested in a patched script that excludes the explicit IDs (and still works)? 2011-01-11T12:57:24 * dbs hasn't submitted anything over either 2011-01-11T12:57:45 berick: I think afterl has the list of what's been submitted. I asked her to remind me what the title of my presentation proposal was. 2011-01-11T12:57:59 agJohn: not really - have you seen the work I did on the upgrade script post 2.0RC2? 2011-01-11T12:58:22 No, just grabbed the RC. 2011-01-11T12:58:44 agJohn: there was an oversight in not setting the sequence value for config.metabib_field to 100 for custom indexes way back when, so we're dealing with it in 2.0 2011-01-11T12:58:48 bshum: thanks 2011-01-11T12:59:23 agJohn: we reserve the right to have pinned IDs in most of the customizable tables, otherwise madness can ensue in subsequent upgrade scripts 2011-01-11T13:00:07 berick: I do wish we knew what proposals were around out there though. I'll mention it to afterl, she's traveling today. 2011-01-11T13:00:22 OK. (I register my objection that reserved IDs are not the way to go, IMO. But I bow to established practice.) So, we should grab the trunk version of the upgrade and all will be hunky-dory? 2011-01-11T13:00:23 bshum: great, thanks. 2011-01-11T13:00:37 * dbs was considering offering a talk about authorities in 2.0 (and beyond) - not wildly interesting to me, but I imagine there would be a good general audience for it 2011-01-11T13:01:08 dbs: seems like there's a lot of new functionality around that for 2.0+.. i could see that being useful 2011-01-11T13:01:10 *** BryanK has joined #evergreen 2011-01-11T13:02:04 agJohn: yes, please do! and post bug(s) if you run into problems so we can coordinate efforts 2011-01-11T13:02:44 dbs: I have a question about LP translations. I submitted a PO (which I've since deleted since it has errors in there that I have to fix and then add back), but looked at how the translation queue works. There seems to be quite a few PO files in the upload queue. Is anyone checking on those? 2011-01-11T13:03:15 bshum: we don't really have a translation lead, so I would say "no" 2011-01-11T13:03:24 For a future version, a flag on the table that defaults to false and indicates a predefined code is a lot more flexible. What happens when 100 is not enough? Then you have to do the renumbering thing all over again, potentially breaking people's scripts. 2011-01-11T13:04:37 *** ebyr has joined #evergreen 2011-01-11T13:04:38 agJohn: if we need more than 100 default indexes, we probably also need a different database 2011-01-11T13:04:45 and/or a different product 2011-01-11T13:05:22 Before heading off to lunch, I must also add (concerning my list message) that when I say resolve, I do not mean decide definitively and permanently. I simply do not want to release something as 'gold' without all the stakeholders at least aware of the situation. 2011-01-11T13:06:03 I also expect whatever is decided will be a relatively simple compromise of some sort. 2011-01-11T13:06:31 bshum: just checking the translation import queue, looks like most of the "Needs review" entries are from the automated import side of things 2011-01-11T13:07:17 dbs: Ah okay 2011-01-11T13:09:36 dbwells: do you have this code working in a branch somewhere? 2011-01-11T13:12:34 dbwells: it's also not clear to me how disruptive your proposed changes would be to existing code: "Print spine label" UI, OPAC display, holdings maintenance... would all of these (and probably more) need to be revised? 2011-01-11T13:15:20 dbs: When I have a PO thatmore correct, I'll bug you again. Unless you'd like me to check back with someone else on LP. 2011-01-11T13:15:23 *that's more 2011-01-11T13:16:30 *** jenny has quit IRC 2011-01-11T13:17:50 Alternatively I guess I could copy/paste all the strings by hand :) 2011-01-11T13:18:10 But I think it's good to establish how they operate. 2011-01-11T13:33:03 *** Bryan has joined #evergreen 2011-01-11T13:33:34 *** Bryan is now known as Guest56504 2011-01-11T13:35:50 *** BryanK has quit IRC 2011-01-11T13:40:25 *** Ghidorah has joined #evergreen 2011-01-11T13:41:28 Hello everyone. When I attempt to run a report I get a Not Found The request URL /reporter/6/7/7/reporter-data.html was not found on this server. 2011-01-11T13:41:36 Does anyone know what may cause this? 2011-01-11T13:41:48 Ghidorah: is Clark Kent running/ 2011-01-11T13:42:08 you might also want to make sure that path actually does exist, and is writable by Clark 2011-01-11T13:42:15 usually the postgres user 2011-01-11T13:42:25 Clark Kent? 2011-01-11T13:42:29 It's a script 2011-01-11T13:42:37 clark-kent.pl, located in /openils/bin by default 2011-01-11T13:43:54 Starting that process is in a part of the install docs called "Setting up support for reports" 2011-01-11T13:49:13 *** b_bonner has quit IRC 2011-01-11T13:50:14 *** jamesrf_ has joined #evergreen 2011-01-11T13:50:54 *** jamesrf has quit IRC 2011-01-11T13:52:06 * dbs has created 2.0rc3 and 1.6.1.7 milestones in Launchpad and created releases for 2.0rc2 and 1.6.1.6 2011-01-11T13:52:15 Hi, could I ask a couple of migration tool related question? 2011-01-11T13:52:37 dbs: Yay, thanks. I'll begin assigning targets to bugs that could use some love 2011-01-11T13:53:00 rsoulliere: always. you're not guaranteed to get answers, though :) 2011-01-11T13:53:41 Dyrcona: I was thinking about your problem yesterday that required open-ils.cstore max_children to be bumped up 2011-01-11T13:54:04 dbs: and? 2011-01-11T13:54:05 1) is the marc_export perl script found in support-scripts the most effective/efficient way to export records from Evergreen database? 2011-01-11T13:54:22 Dyrcona: Maybe we should teach opensrf to generate a log message saying "Hit max_children limit - you might want to consider increasing that value in OpenSRF configuration" 2011-01-11T13:54:42 ok 2011-01-11T13:54:47 s/limit/limit for opensrf application XXX/ 2011-01-11T13:55:00 rsoulliere: That's certainly one way to go. We use a modified version of the marc_export script at our site. Using different item holdings formating than the default. 2011-01-11T13:55:27 rsoulliere: Admittedly, I haven't tried any other ways yet, I think there's an export option in the staff client? 2011-01-11T13:55:40 2) Has anyone used the Equinox-Migration tool set for migration? Is this the best tool for the job at this time? 2011-01-11T13:56:00 rsoulliere: i've used it religeously 2011-01-11T13:56:03 dbs: it would be helpful. should i lower the number of queries back to 200, then? 2011-01-11T13:56:04 Open-ILS/src/extras/fast_extract is another candidate for a fast export, although the format might not be what you want 2011-01-11T13:56:17 Dyrcona: yeah, I think the max_children was the root cause 2011-01-11T13:56:39 any specific questions about Equinox-Migration? 2011-01-11T13:56:50 been using it for about 18 months now with great results 2011-01-11T13:57:43 Thanks for your help 2011-01-11T13:57:51 get it working, Ghidorah? 2011-01-11T13:58:18 mrpeters-ils: Well, I am just starting to test for documentation purposes. 2011-01-11T13:58:44 cool. if you run into anything, i'll be happy to try an answer 2011-01-11T13:59:05 i have something that might kind of help you 2011-01-11T13:59:12 Yes sir. 2011-01-11T13:59:23 Good to know that it has been used successfully. 2011-01-11T13:59:30 *** b_bonner has joined #evergreen 2011-01-11T14:00:17 rsoulliere: http://pastie.org/1449312 2011-01-11T14:00:18 Dyrcona: looks like there's an easy spot to add an else stmt to generate that log message; will do 2011-01-11T14:00:32 my REALLY short hand notes of what each step in the bib load process 2011-01-11T14:00:51 of course, patron/item data really varies from migration to migration 2011-01-11T14:01:01 but that should at least help you get the bibs loaded, and extract holdings information 2011-01-11T14:02:00 *** youdonotexist has joined #evergreen 2011-01-11T14:04:07 mrpeters-isl++ those notes will help me get started... 2011-01-11T14:08:41 *** jenny has joined #evergreen 2011-01-11T14:10:33 *** Ghidorah has quit IRC 2011-01-11T14:13:35 dbs: Thanks for the questions. I do benefit from reality checks now and then :) 2011-01-11T14:14:20 Dyrcona: actually - your logs should be filled with "No children available, waiting..." entries - are they? 2011-01-11T14:14:31 dbwells: No problem! Sober chamber of second thought and all that 2011-01-11T14:15:20 Kind of like our holds-driven recall stuff - we want that when we migrate to Evergreen 2.x, but were willing to keep it out of 2.0 to enable all of the 2.0 stuff to shake down 2011-01-11T14:16:26 My intention was to have a minimum number of "unit aware" interfaces in the initial 2.0 release, which in my mind meant a units tab and some OPAC display code and not much else. My primary concern was getting the right data in at this point. 2011-01-11T14:17:24 It was in the process of working out this OPAC code that I realized the ideas currently in play were a little less compatible than I thought. 2011-01-11T14:18:46 * Dyrcona has just seen the dumbest trigger error message ever: Server 'SYBASE', Procedure 'circ_parameter_matrix_iu_trig', Line 14: 2011-01-11T14:18:48 * Dyrcona May only insert/update one row at a time 2011-01-11T14:19:20 dbwells: If I didn't mention it before, I think there's some overlap with how volumes of encyclopedia, etc, need to be handled too 2011-01-11T14:20:46 dbs: yes, certainly. Limiting the idea to serials was really just a relatively open starting point. 2011-01-11T14:22:57 I have at least one idea of how to not hold up 2.0 while also not boxing us in (which is really my main reason for urgency) here. I'll reply on list. 2011-01-11T14:24:22 Dyrcona: if you still have your logs, do they feature the line "No children available, waiting..." from the holds shelf stuff from yesterday? 2011-01-11T14:24:41 * Dyrcona is busy with something else, will check in a bit. 2011-01-11T14:34:47 dbs: I've uploaded a PO with some updated Spanish translations for strings in opac.dtd that was contributed by one of our libraries. 2011-01-11T14:35:10 Conifer apparently didn't hit that "No children available" condition in December 2010 2011-01-11T14:35:26 bshum: cool, let's keep an eye on it 2011-01-11T14:36:15 dbs: I could try emailing back that other translator who was working on Spanish files to ask them to help us review it. 2011-01-11T14:40:23 bshum: I say go for it 2011-01-11T14:47:58 berick: reading the OpenSRF 1.6 vs. 2.0/trunk source for Perl, it looks like there's a subtle change in the configuration 2011-01-11T14:48:33 max_requests comes from the direct child of the parent elements in opensrf.xml stanza in 1.6, but from the unix_config section in 2.0/trunk 2011-01-11T14:50:26 berick: crap, might be reading that wrong - needed more context than grep was giving me 2011-01-11T14:52:03 well, both-ish: In 1.6, lib/OpenSRF/UnixServer.pm pulls max_requests from appname/unix_config/max_requests, while lib/OpenSRF/AppSession.pm takes max_requests directly from appname/max_requests 2011-01-11T14:52:42 *** jenny has quit IRC 2011-01-11T14:52:52 *** senator has quit IRC 2011-01-11T14:56:13 *** senator has joined #evergreen 2011-01-11T14:56:29 In trunk, lib/OpenSRF/System.pm pulls max_requests from appname/unix_config/max_requests, and lib/OpenSRF/AppSession.pm appears to take it directly from appname/max_requests 2011-01-11T14:57:50 dbs: Our logs indeed had a few thousand of those on one of our servers. (Figured I would respond for Dyrcona) 2011-01-11T14:57:53 dbs: To answer your question at 14:24, yes. 2011-01-11T14:57:59 heh. 2011-01-11T14:58:11 dbs: hm, did I swap them? 2011-01-11T14:58:19 tsbere: you're off the clock. stop working. :) 2011-01-11T14:58:55 berick: no, looks like "max_requests" gets pulled from two different places in the Perl code 2011-01-11T14:58:57 Dyrcona: One of my hobbies is open source, on the clock or not. ;) 2011-01-11T14:59:20 tsbere: does the log message identify which service can't spawn a new child? 2011-01-11T14:59:26 (and thanks) 2011-01-11T14:59:35 one of my hobbies is having my flights cancelled and getting stuck in san diego! 2011-01-11T14:59:43 dbs: They all appear to be "open-ils.cstore" sourced 2011-01-11T15:00:03 (just checking in for the dev meeting) 2011-01-11T15:00:04 (at least on one server) 2011-01-11T15:00:30 eeevil: You are 3 hours late for the dev meeting. Or did you want to do a post-meeting check? 2011-01-11T15:00:38 dbs: well, there are 2 different types of max requests... (the C and python server code may not support both versions). 2011-01-11T15:01:04 tsbere: awesome, thanks - so I'll just add in a "check your max_children value and consider raising it" bit to the log message 2011-01-11T15:01:07 tsbere: huh... I thought it was at noon pacific. geez, sorry guys! 2011-01-11T15:01:30 berick: ungh 2011-01-11T15:01:55 from what I've seen the C and Python code both poll unix_config/max_requests only 2011-01-11T15:02:06 dbs: the unix_config max requests is the main one. 2011-01-11T15:02:07 yeah 2011-01-11T15:02:57 that's the "how many top-level requests will each child process honor" setting 2011-01-11T15:03:29 vs the "maximum required opensrf requests within a stateful connection" top-level one (according to the comment in open-ils.auth, which is a C service and doesn't actually use it?) 2011-01-11T15:04:07 the other should be called something like max_session_requests -- how many REQUESTS per connected/stateful session will each child allow before forcably ending the conversation. 2011-01-11T15:04:19 yeah, that one.. 2011-01-11T15:04:34 i'm pretty sure the C doesn't support it, but I can check 2011-01-11T15:05:14 berick: IIRC, it used to ... cstore would like that to be true 2011-01-11T15:05:22 well, obviously it doesn't if it's not pulling the value from the config.. 2011-01-11T15:05:35 indeed 2011-01-11T15:05:38 I'm sure it isn't, at least not in plainjane OpenSRF 2011-01-11T15:07:45 *** jamesrf_ has quit IRC 2011-01-11T15:08:30 dbs: I wanted to ask about exporting PO files from LP for the next RC ... can we? 2011-01-11T15:08:48 eeevil: sure! 2011-01-11T15:13:20 *** pmplett has joined #evergreen 2011-01-11T15:13:20 *** _bott_ has quit IRC 2011-01-11T15:13:48 * dbs pulls from https://code.launchpad.net/~denials/evergreen/translation-export 2011-01-11T15:15:29 *** _bott_ has joined #evergreen 2011-01-11T15:17:12 *** b_bonner has quit IRC 2011-01-11T15:19:52 *** b_bonner has joined #evergreen 2011-01-11T15:28:22 Man. Launchpad translations are all messed up, with stuff split between 2.0 and trunk 2011-01-11T15:28:24 * dbs weeps 2011-01-11T15:31:13 * dbs issues another feeble call for an i18n maintainer 2011-01-11T15:32:03 * phasefx bleats, "outlook bleak 2011-01-11T15:32:40 *** collum has left #evergreen 2011-01-11T15:36:23 * tsbere would consider taking up that position if he had time to, had interest in it, or had any clue how it works right now. He has none of the above right now, and is probably the wrong person for that particular job anyway. 2011-01-11T15:39:59 *** kbeswick has quit IRC 2011-01-11T15:40:33 On a different note, I think I finally mapped out how I want my permissions overhaul to work. I have no clue yet if it can be coded in an efficient manner. 2011-01-11T15:40:35 I have to think about that part some more. 2011-01-11T15:40:40 *** alxp has quit IRC 2011-01-11T15:41:02 * dbs waits for bzr branch to finish... 2011-01-11T15:42:53 *** kbeswick has joined #evergreen 2011-01-11T15:44:54 *** kmlussier has quit IRC 2011-01-11T15:54:32 *** Meliss has quit IRC 2011-01-11T15:59:02 *** ebyr is now known as eby 2011-01-11T16:01:30 *** jenny has joined #evergreen 2011-01-11T16:01:39 * dbs updates https://translations.launchpad.net/evergreen/2.0/+translations-settings to automatically export translations to https://code.launchpad.net/~denials/evergreen/translation-export-2.0 2011-01-11T16:02:00 eeevil: don't expect an i18n update until tomorrow :/ 2011-01-11T16:02:29 *** jenny has left #evergreen 2011-01-11T16:03:10 hrmm, specifying ?ol= for rel_2_0 and rel_1_6 opac's appears to break the library selector, but trunk is okay 2011-01-11T16:09:23 *** rsoulliere has quit IRC 2011-01-11T16:09:28 *** bshum has quit IRC 2011-01-11T16:23:05 phasefx: works ok for us on our enviornment 2011-01-11T16:23:16 but not sure how we compare to rel_1_6 2011-01-11T16:23:22 we use that quite often, actually 2011-01-11T16:23:47 also, my beta 5 works with ?ol= 2011-01-11T16:23:54 I think it may be related to the org hiding stuff I added 2011-01-11T16:23:58 * mrpeters-isl needs to get on upgrading dev server 2011-01-11T16:24:03 berick: I'm ripping out the element for language = C in opensrf.xml.example and making open-ils.acq be the commented example 2011-01-11T16:24:04 so might be setting dependent, testing 2011-01-11T16:24:34 dbs: ok. no objections 2011-01-11T16:25:16 also going to comment out open-ils.resolver in the active apps section 2011-01-11T16:28:48 mrpeters-isl: yeah, broken in trunk too once I removed that org hiding setting. bah 2011-01-11T16:32:14 dbs: re i18n, I'll be driving cross-country for the next 30-40 hours, no worries 2011-01-11T16:32:51 eeevil: awesome, you guys are going for it? 2011-01-11T16:32:52 eeevil: OMG 2011-01-11T16:33:20 though, in retrospect, maybe not so awesome 2011-01-11T16:33:31 bloody weather 2011-01-11T16:33:35 eeevil: safe travels man 2011-01-11T16:33:40 berick: yeah. ROADTRIP! 2011-01-11T16:33:44 dbs: thanks 2011-01-11T16:34:01 bonding experience :) 2011-01-11T16:34:10 berick: and... the threat of sl driving ;) 2011-01-11T16:34:16 phasefx: indeed 2011-01-11T16:34:29 eeevil: hah ;) 2011-01-11T16:36:31 eeevil: avoid Houston at rush hour! 2011-01-11T16:36:53 I10 all the way baby! 2011-01-11T16:36:53 * berick made that mistake once 2011-01-11T16:40:37 avoid houston. check 2011-01-11T16:44:55 *** pmplett is now known as pmpafk 2011-01-11T17:05:16 *** yboston has quit IRC 2011-01-11T17:11:31 *** pmpafk is now known as pmplett 2011-01-11T17:21:21 *** eby has quit IRC 2011-01-11T17:24:50 berick: nothing seems to call load_app() in osrf/server.py - should I just rip that out? 2011-01-11T17:25:46 *** bshum has joined #evergreen 2011-01-11T17:27:26 * berick looks 2011-01-11T17:28:34 dbs: ah, yes. functionality replaced (nay, implemented) by opensrf.py 2011-01-11T17:28:42 will do 2011-01-11T17:29:03 also generally cleaning up pylint warnings while moving through 2011-01-11T17:29:21 dbs: are you running pylint/pychecker ? 2011-01-11T17:29:23 oh, heh 2011-01-11T17:29:33 dbs++ 2011-01-11T17:31:15 *** Dyrcona has quit IRC 2011-01-11T17:32:20 dbs: I received a failed import message about the PO I uploaded earlier, so I'm checking the errors it died with. Will resubmit once resolved. 2011-01-11T17:32:37 PS: the failed import message is very handy in explaining what went wrong :) 2011-01-11T17:54:31 *** b_bonner has quit IRC 2011-01-11T17:55:43 *** corretico has joined #evergreen 2011-01-11T18:24:14 *** corretico has quit IRC 2011-01-11T18:30:04 *** dbs has quit IRC 2011-01-11T18:57:30 *** pmplett has quit IRC 2011-01-11T19:12:43 *** b_bonner has joined #evergreen 2011-01-11T19:27:09 dbwells, gmcharlt, and any mfhd experts: i would appreciate it if you could look at http://svn.open-ils.org/trac/ILS/changeset/19162 to make sure my understand of weekly chronology codes in subfield $y isn't wrong 2011-01-11T19:27:59 gah, when i used s/// to put some dollar separators in my example marc i was overzealous. you'll see what i mean anyway though. 2011-01-11T19:28:40 *** r123 has left #evergreen 2011-01-11T19:36:14 *** b_bonner has quit IRC 2011-01-11T20:02:37 senator: you've found a hole in the specifications (and near as I can tell, there's actually no generally accepted definition of the nth week of a month) 2011-01-11T20:03:01 the interpretation you're proposing in the patch looks fine to me 2011-01-11T20:06:48 gmcharlt: gotcha, thanks. 2011-01-11T20:09:18 senator: I'm going to forward the question to somebody who's involved in writing the standard 2011-01-11T20:10:38 neat, thanks again! 2011-01-11T20:47:50 *** youdonotexist has quit IRC 2011-01-11T21:40:26 *** b_bonner has joined #evergreen 2011-01-11T21:40:44 *** b_bonner has quit IRC 2011-01-11T22:41:25 *** jennam has quit IRC 2011-01-11T23:21:13 *** agJohn has quit IRC 2011-01-11T23:39:09 *** agJohn has joined #evergreen 2011-01-11T23:57:58 *** tpham has joined #evergreen