| # | Time | Nick | Message |
|---|
| # | 00:49:12 | jeffdavis has joined #evergreen |
| # | 01:14:47 | maheshwar has joined #evergreen |
| # | 01:44:31 | denials | so tired |
| # | 04:30:23 | kivilahtio | me too |
| # | 04:58:10 | thethomaseffect has joined #evergreen |
| # | 06:17:41 | kivilahtio has quit IRC |
| # | 07:27:08 | claudiu has joined #evergreen |
| # | 07:27:19 | claudiu has left #evergreen |
| # | 07:59:27 | fortin has joined #evergreen |
| # | 08:07:23 | akilsdonk has joined #evergreen |
| # | 08:27:43 | Dyrcona has joined #evergreen |
| # | 08:30:36 | AaronZ-PLS has joined #evergreen |
| # | 08:31:08 | jeff has quit IRC |
| # | 08:38:28 | bwicksall has quit IRC |
| # | 08:42:18 | avinash has joined #evergreen |
| # | 08:43:11 | avinash | hi, i anyone can help me regarding virtualbox |
| # | 08:43:57 | avinash | hi,can anyone help me regarding virtualbox ?? please reply |
| # | 08:51:00 | avinash | help |
| # | 08:54:59 | dbwells | avinash: I am no expert, but I have used it a handful of times. Can you be more specific about the problem you are having? What have you tried so far? |
| # | 08:55:59 | avinash | i am hosting opensolaris as guest os on ubuntu host os |
| # | 08:56:26 | avinash | i want to access shared folder from guest os |
| # | 08:56:38 | jeff has joined #evergreen |
| # | 08:56:38 | avinash | but its showing error |
| # | 08:57:51 | avinash | dbwells: can u tell me how to access shared folder from opensolaris |
| # | 08:59:18 | Dyrcona | avinash: I suggest you try a more appropriate forum to ask your questions: one dedicated to virtual box for instance. |
| # | 09:00:13 | Dyrcona | Also note that Evergreen is not supported on opensolaris at the moment, so unless you intend to the work to make it work on opensolaris, I'd advise you find a different os to install it on. |
| # | 09:00:43 | dbwells | avinash: Sorry, I have zero experience with opensolaris. I also agree with both of Dyrcona's suggestions. |
| # | 09:00:56 | bwicksall has joined #evergreen |
| # | 09:01:04 | avinash | k thanx |
| # | 09:01:46 | avinash | dbwells: i send u some apk files on your gmail have u checked them. |
| # | 09:01:59 | berick kicks launchpad |
| # | 09:02:27 | avinash | dbwells: please provide me next step on android development |
| # | 09:02:38 | tsbere | berick: That just isn't right. You need to find a bat or other blunt instrument. Otherwise you might hurt your foot. :P |
| # | 09:02:57 | berick | tsbere: so true |
| # | 09:03:12 | Dyrcona prefers shotguns. |
| # | 09:04:58 | hopkinsju has joined #evergreen |
| # | 09:05:43 | dbwells | avinash: I have looked at them briefly and will try to reply via email later today. As for the Evergreen-Android GSoC project, we haven't even reached the student application period yet, so it is premature to get too specific. Your next step is to work up and application and proposal for consideration. |
| # | 09:06:03 | umashankar has joined #evergreen |
| # | 09:07:27 | avinash | i am new at gsoc can u tell me how to make proposal for consideration |
| # | 09:07:34 | Meliss has joined #evergreen |
| # | 09:08:58 | dbwells | avinash: I would start here: http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2012/faqs |
| # | 09:09:46 | Gentlecat has quit IRC |
| # | 09:10:13 | avinash | k thanx dbwells sir |
| # | 09:10:14 | denials | avinash: That should lead to http://en.flossmanuals.net/GSoCStudentGuide/ as well, which is targeted at students new to GSoC |
| # | 09:29:20 | kmlussier has joined #evergreen |
| # | 09:35:22 | umashankar has quit IRC |
| # | 09:36:35 | umashankar has joined #evergreen |
| # | 09:38:36 | jenny2 has joined #evergreen |
| # | 09:41:19 | tspindler has joined #evergreen |
| # | 09:49:26 | fortin has quit IRC |
| # | 10:10:06 | gmcharlt has quit IRC |
| # | 10:13:05 | denials wonders if anyone will dare to try out today's unapi changes |
| # | 10:13:40 | kmlussier raises her hand |
| # | 10:13:55 | bshum | Dare? Dare? |
| # | 10:13:56 | bshum | :) |
| # | 10:13:59 | denials | kmlussier: You're a trooper |
| # | 10:14:30 | kmlussier | denials: Wasn't sure you really wanted me to raise my hand. ;-) |
| # | 10:14:44 | csharp | if I wanted to set up a two-tiered setup for Evergreen, ideally System -> Branch, would that work? or is the Consortium level required? |
| # | 10:15:01 | avinash has quit IRC |
| # | 10:15:37 | denials | csharp: I think there has to be a depth = 0, no matter what it's called |
| # | 10:15:44 | tsbere isn't sure if kmlussier gets to raise her hand unless Dyrcona is on board ;) |
| # | 10:15:52 | csharp | denials: okay - that works for me |
| # | 10:16:03 | tsbere | csharp: Make the system depth 0, and branch depth 1? |
| # | 10:16:11 | csharp | tsbere: yeah |
| # | 10:16:15 | denials hums "The Long and Winding Road" for poor kmlussier |
| # | 10:16:27 | kmlussier | I believe Dyrcona has already loaded it. And many thanks to Dyrcona for providing me with a test environment. |
| # | 10:16:37 | csharp | depth 0 can be considered a "Consortium" as long as I can have a branch just under it |
| # | 10:16:55 | denials | Dyrcona++ kmlussier++ |
| # | 10:17:07 | csharp | PINES is 3-tiered, so this is a new approach for me |
| # | 10:17:17 | jeff | it's a matter of defining your org unit types in terms of "can have users" "can have volumes", etc. |
| # | 10:17:59 | bshum | csharp: Hmm, 2-tier? What's new? |
| # | 10:18:02 | tsbere | csharp: I have in the past had test setups with a *single* org unit defined. As in "We have....a branch." |
| # | 10:18:17 | csharp | okay - that's good to know |
| # | 10:18:37 | csharp | jeff: okay - I wasn't thinking about that - thanks for the tip |
| # | 10:18:41 | tsbere | csharp: Don't forget to update permission depths on permission groups, though. |
| # | 10:18:51 | csharp | tsbere: just thought of that too ;-) |
| # | 10:19:12 | tsbere forgot that at first on his "we have a branch" test and wondered why nothing worked for staff |
| # | 10:19:36 | csharp | on a related note, what is the best way to delete org units from the example tree? |
| # | 10:19:50 | jeff | level dictates type, so if you have a stock three-layer and you want to add "just a branch" under the consortium, that's not going to work unless the "branch" is really a "system" in the eyes of evergreen, and then you'd have to let all systems have users and volumes at the system level, and... not recommended, I'd think. |
| # | 10:20:10 | csharp | jeff: good though |
| # | 10:20:17 | csharp | thought |
| # | 10:20:29 | fortin has joined #evergreen |
| # | 10:21:36 | tsbere | jeff: I disagree with "level dictates type". If you can find an example where the system actually pays attention to depths other than 0 and treats them specially, though, I might be willing to change my mind. And default permission depths don't count ;) |
| # | 10:21:44 | csharp | dojo-- |
| # | 10:22:41 | jeff | tsbere: sounds like i'm wrong. oops! |
| # | 10:24:01 | tsbere | jeff: For the record, MVLC has a "System Level branch" in our "Central Site" location. We called it an "office", granted, but it is depth 1 directly under the consortia entry and works like a branch otherwise. |
| # | 10:26:43 | jeff | actor.org_unit_type has a depth column, but what you're saying is that it (in practice) seems to matter not? |
| # | 10:26:43 | Dyrcona | jeff: my only grumble with it is that permission drop downs often show "Office" instead of System or vice versa, but it's minor when you realize what is happening. |
| # | 10:27:04 | jeff | or am I misunderstanding the function of the depth column there? |
| # | 10:27:35 | denials | csharp: you mean dojo2008? |
| # | 10:30:37 | Rohit has joined #evergreen |
| # | 10:30:40 | tsbere | jeff: The depth column is more of a shortcut, as far as I can tell, for determining where an org unit is in the tree. AKA, it should always be the org unit type's parent depth + 1. |
| # | 10:30:46 | Rohit is now known as rohit12 |
| # | 10:31:44 | tsbere | jeff: And yes, a number of parts of the system use that number. Other parts of the system ignore it. I favor ignoring it, but I may eventually make it automatically update itself if it isn't already. <_< |
| # | 10:32:03 | jeff | tsbere: so, in your example, you didn't put a "Branch" that was depth 2 elsewhere at depth 1 in the tree, but you made another type at depth 1 called Office and set can have vols/users on that? |
| # | 10:32:29 | tsbere | jeff: Yes. I have also moved the default system/branch entries under a new entry and updated depths accordingly. |
| # | 10:32:30 | jeff | so you have two types at depth 1, Office and System? |
| # | 10:32:36 | jeff | ah. |
| # | 10:32:43 | jeff | so, no to my last question? |
| # | 10:32:58 | denials | we have two types at depth 1 |
| # | 10:33:25 | denials | (IIRC, actually... been so long since we set that up...) |
| # | 10:33:26 | tsbere | our "Central Site" is of a type that is at depth 1 alongside system. We called that type "office" but it is otherwise identical in configuration to the default "Branch". |
| # | 10:33:46 | denials heads offline for a bit |
| # | 10:34:27 | tsbere | jeff: Similar to the default sublibrary/bookmobile at depth 3. They share a depth, doesn't mean they are equivalent to one another or have any special rules based on the depth value. ;) |
| # | 10:34:54 | jeff | tsbere: got it. thanks for pointing out the stock example. i had overlooked it. :-) |
| # | 10:35:19 | rohit12 has quit IRC |
| # | 10:39:46 | graced has joined #evergreen |
| # | 10:46:43 | tsbere | jeff: For the record, I believe that there *is* a magic depth value other than 0 (which is more of a "has no parent" really) - I recall mention of there being a max depth before some things stopped looking at the system properly. |
| # | 10:47:57 | dbwells has quit IRC |
| # | 10:49:23 | jeff | f=at-d and f=at-s -- the "a" is LDR/06, the d and s are the "Form of item" in the 008 (usually but not always position 23)... Is the t also referencing the LDR/06 (type = Manuscript), or something else? |
| # | 10:49:42 | jeff | is the dash a separator between "marc type" and "item form"? |
| # | 10:49:49 | jeff | guess i should look at the code |
| # | 10:51:07 | jeff | yep. |
| # | 10:51:44 | jeff | opac takes that and breaks it out to "item_type":["a","t"],"item_form":["s"] |
| # | 11:05:35 | tspindler | i'm looking at the acquisitions documentation for distribution formula, in the 2.0 documentation it says "Ignore the Skip Count field. It has no purpose in 2.0." does anyone know if this still does nothing in 2.1 or later? |
| # | 11:08:52 | jeff | "Ignore this field. Nobody alive knows what it does, but it must always be set to the fixed value of 'fraggle'." |
| # | 11:09:06 | jeff | tspindler: sorry, I don't have a helpful answer for you. |
| # | 11:10:14 | tspindler | jeff: thanks, I guess i could try and test it to see if it does anything, just more work than I wanted to put into it |
| # | 11:13:03 | collum has joined #evergreen |
| # | 11:34:52 | tspindler | jeff: tested it and still does nothing in 2.1 and I'm assuming it still does nothing in 2.2 and I'm assuming no developer has looked at it (not import to us either) |
| # | 11:41:58 | jeff | bah. no cover art for the isbn in the 020, but if you grab the isbn-looking string from the 856$u and try that... cover art! |
| # | 11:46:06 | denials | jeff: 856, ind2=2, $q = image/jpeg? |
| # | 11:46:09 | denials laughs at self |
| # | 11:47:22 | jeff | denials: you joke, but all of our OverDrive orders come with metadata that includes cover image urls. This is not the first time I've thought about making better use of them, rather than trying to rely on the general AC cover art source. |
| # | 11:47:52 | eby | overdrive-- |
| # | 11:50:24 | tsbere is tempted to change that to just a "vendors--" <_< |
| # | 11:52:13 | eby | wondering if anyone has seen open-ils.auth fail to load with oils_auth.so: undefined symbol: osrfAppSessionGetIngress |
| # | 11:52:31 | eby | was compiling from trunk but may switch to tag or do another pull if not |
| # | 11:53:06 | Dyrcona | eby: Nope. Never seen that, and I'm always compiling from master. |
| # | 11:53:25 | eby | k, i'll do another pull. was a march 12 |
| # | 11:53:33 | jeff | eby: ensure that you have recent-enough OpenSRF -- the ingress stuff was recently added. |
| # | 11:53:54 | jeff | eby: sounds like your Evergreen is new enough to have it, and your OpenSRF not. |
| # | 11:53:58 | Dyrcona | eby: Yeah, I was going to recommend what jeff just said. Get OpenSRF master and build that first. |
| # | 11:54:09 | eby | ah i think i used the latest tar of opensrf |
| # | 11:54:19 | eby | i'll use the git for that too |
| # | 11:54:21 | eby | thanks all |
| # | 11:54:26 | jeff | if doing 2.2-ish, there's no yet released version of OpenSRF that supports it. |
| # | 11:54:42 | Dyrcona | 2.1 alpha 1, I think.... |
| # | 11:55:06 | jeff | for various definitions of "released", i suppose. :-) |
| # | 11:55:11 | denials | mebbe we should cut OpenSRF 2.1.0 RC1 when EG 2.2 goes beta 1 |
| # | 11:55:18 | denials | stay one step ahead |
| # | 11:55:33 | Dyrcona | denials++ |
| # | 11:55:39 | Dyrcona | +1 to that. |
| # | 11:57:57 | luisb has joined #evergreen |
| # | 11:59:53 | tsbere | What, we aren't going to release Beta1 of OpenSRF alongside Beta1 of 2.2? :P |
| # | 12:05:41 | mrpeters-isl | i dont know when it happened, but THANK YOU to whoever made the permission profile selection in patron registration have different colors for groups that can't have users!! |
| # | 12:06:21 | bshum | Vaguely familiar |
| # | 12:06:26 | bshum | I think it was berick or tsbere |
| # | 12:06:43 | Dyrcona | I think we should release a 2.1.2 and 2.0.12 (or is it .11?). |
| # | 12:06:58 | denials | Dyrcona++ # I thought about that after the last meeting |
| # | 12:07:00 | bshum | It's .11 |
| # | 12:07:07 | bshum | Or supposed to be anyways |
| # | 12:07:10 | tsbere | mrpeters-isl: I think it also says "that is invalid" if you select one of the bad ones. And I think that might have been me. <_< |
| # | 12:07:19 | mtcarlson has joined #evergreen |
| # | 12:07:21 | bshum | Yeah it was tsbere |
| # | 12:07:41 | bshum | I remember bugging you about it during the time when you were redoing the patron registration page I think |
| # | 12:08:05 | tsbere | Or was mine the "make ORG UNITS that can't have users invalid"....... |
| # | 12:08:11 | mrpeters-isl | hmm, for me it just came up blank when clicking |
| # | 12:08:22 | bshum | Maybe that's the one |
| # | 12:08:23 | mrpeters-isl | but still, fantastic |
| # | 12:08:25 | bshum | So many |
| # | 12:09:23 | denials wonders if tsbere will be author of the year for 2012 according to http://git.evergreen-ils.org/gitstats/Evergreen/authors.html |
| # | 12:09:27 | mrpeters-isl wishes we could upgrade...so much great stuff coming |
| # | 12:09:53 | denials | knock that cocky berick off his perch :) |
| # | 12:10:04 | tsbere | mrpeters-isl: Looks like the profile group was berick. I did the "you can't select bad OUs" bit. |
| # | 12:10:23 | mrpeters-isl | cool, berick++ |
| # | 12:11:35 | denials | gitstats needs to be able to find an updated git repo, methinks :) |
| # | 12:12:05 | Dyrcona | denials: yeah, it looks a bit out of date. |
| # | 12:12:27 | tsbere | It gets confused when old commits are in place. What is the date on the last commit? <_< |
| # | 12:12:42 | mrpeters-isl | denials with a pretty massive number of lines (1372103) |
| # | 12:13:05 | mrpeters-isl | and thats just under the dbs name! |
| # | 12:14:46 | tsbere | Supposedly it updated without obvious errors this morning? |
| # | 12:15:24 | denials | mrpeters-isl: those are mostly i18n updates, artificial inflation |
| # | 12:15:49 | denials | tsbere: yeah, it's running "fine", it just doesn't seem to have updated the git repo since 2011-11 |
| # | 12:16:04 | maheshwar_ has joined #evergreen |
| # | 12:16:13 | csharp | denials++ # 1 million+ lines of i18n updates ;-) |
| # | 12:16:30 | tsbere | denials: Which is interesting since it is reading the master copies? |
| # | 12:16:46 | mrpeters-isl | the file count is fun |
| # | 12:17:10 | denials | tsbere: I have no idea what it's doing on git.evergreen-ils.org :) |
| # | 12:17:54 | tsbere | Some of the files haven't been touched since November. <_< |
| # | 12:18:27 | mrpeters-isl | we also have some night owls! almost 20% of the commits occur betwen 8PM and 7AM |
| # | 12:19:41 | kmlussier has quit IRC |
| # | 12:20:47 | tsbere | Ok, I tweaked the cron jobs and ran things manually. Lets see if *that* makes things happier. <_< |
| # | 12:21:51 | mrpeters-isl has quit IRC |
| # | 12:22:11 | Dyrcona | I am changing a bunch of bugs from in progress to new because it is my understanding that some devs filter out in progress bugs when looking for things that need testing. |
| # | 12:25:26 | gaiz has joined #evergreen |
| # | 12:29:19 | eeevil | pushing a pile of small fixes |
| # | 12:29:27 | gmcharlt has joined #evergreen |
| # | 12:32:31 | Dyrcona | eeevil++ |
| # | 12:33:05 | eeevil | just tiny fixes and ones already signed off by testers |
| # | 12:33:20 | Dyrcona | yep. some have been sitting for a while. |
| # | 12:33:29 | Dyrcona | mostly "in progress." :) |
| # | 12:34:28 | dbwells has joined #evergreen |
| # | 12:39:02 | Dyrcona thinks tsbere is going to need to rebase the new xulrunner branch. |
| # | 12:39:39 | tsbere knows he is going to need to rebase the new xulrunner branch, but is waiting to see for how many things ;) |
| # | 12:39:47 | Dyrcona | heh |
| # | 12:59:08 | tspindler has quit IRC |
| # | 13:01:55 | Michele_ has joined #evergreen |
| # | 13:03:17 | gaiz has quit IRC |
| # | 13:04:12 | Michele_ has quit IRC |
| # | 13:10:08 | umashankar has quit IRC |
| # | 13:17:24 | maheshwar_ has quit IRC |
| # | 13:22:11 | eeevil | bshum: have you had a chance to look at https://bugs.launchpad.net/evergreen/+bug/949466 again? |
| # | 13:22:11 | pinesol_green | Launchpad bug 949466 in Evergreen "TPAC: Improvement to serials display (under the "issues held" label)" (affected: 3, heat: 16) [High,New] - Assigned to Dan Wells (dbw2) |
| # | 13:22:50 | bshum | eeevil: Not quite yet. Our master build includes unapi changes from denials that conflicted with senator's patch |
| # | 13:23:41 | Dyrcona | I had problems merging that branch earlier, but didn't try the updated version today, fwiw. |
| # | 13:25:23 | jeff | dbwells, others: anyone aware of any foot cannons that could lead a user to open-ils.serial.reset_items across a large number of items resulting in a few dozen open-ils.cstore.direct.serial.unit.delete and the expected results of "where did these serial units go?" :-) |
| # | 13:28:11 | dbwells | jeff: any who tread into serials must wear leaden boots, that much is a given. I can't think of any way to accidentally reset a bunch of items, but yes, if you empty a unit of all of its items, the unit is deleted. |
| # | 13:30:51 | mrpeters-isl has joined #evergreen |
| # | 13:31:32 | jeff | tempted to install a long-running Morae instance on some workstations. Cataloging Flight Recorder. ;-) |
| # | 13:31:54 | artunit has quit IRC |
| # | 13:36:23 | mrpeters-isl | Dyrcona: what was wrong with https://bugs.launchpad.net/evergreen/+bug/867465? |
| # | 13:36:23 | pinesol_green | Launchpad bug 867465 in Evergreen "Default Shelving Location and Circ Modifier Do Not Work" (affected: 1, heat: 6) [Low,New] |
| # | 13:37:37 | mtcarlson has quit IRC |
| # | 13:38:17 | eeevil | grabbing 0686 |
| # | 13:40:23 | swills_ has joined #evergreen |
| # | 13:44:23 | dbwells | jeff: I just spent a few minutes trying to confuse the "Items" interface and found a bug related to selection. It's a little hard to explain, and I am not sure if it caused your problem, but it may have. I will get it fixed. Thanks. |
| # | 13:46:47 | swills_ | in the retail, where does the Format (types_of_resource) come from? I have poster items showing up as Text and was hoping to batch correct them via sql? |
| # | 13:48:31 | tsbere | eeevil++ on auditor boost goodness going in finally :D |
| # | 13:48:54 | tsbere | swills_: Did you mean rdetail? |
| # | 13:49:13 | jeff | dbwells: I'm looking at a call to reset_items where the search {"+sitem":{"id":null},"deleted":"f"},{"join":{"sitem":{"type":"left"}}} returned 182 items, thus unitize_items "cleaned up" all 182. :-) |
| # | 13:49:17 | swills_ | lol..gotta love auto correction |
| # | 13:49:19 | swills_ | yes |
| # | 13:49:54 | tsbere | swills_: I assume from primarily the overall marc record type and possibly the item form fixed field information |
| # | 13:49:57 | tsbere isn't sure though |
| # | 13:50:45 | swills_ | i traced this back through code to the mods types_of_resource field but don't understand how the metabib::virtual_record is created. I think what i really need is the underlying MARC field/subfield that governs this? |
| # | 13:51:15 | denials | swills_: generally the leader |
| # | 13:52:24 | denials | http://www.loc.gov/marc/bibliographic/bdleader.html - position 06 "Type of record" |
| # | 13:53:03 | denials | presumably you want to change an "a" to a "k" |
| # | 13:53:34 | fortin has quit IRC |
| # | 13:54:48 | denials | Dyrcona++ # eyes on the double-classed ball |
| # | 13:55:53 | dbwells | jeff: ouch. Well, that is good info, probably enough for me to find the problem and safeguard against it. |
| # | 13:56:43 | Dyrcona | autocowrecktion.... |
| # | 13:59:22 | jeff | dbwells: at this point, i'm still stumbling in the dark a bit with regard to the serial schema. somehow a number of serial.unit entries existed with (maybe?) no corresponding serial.item -- and unitize_items was the first thing to care. |
| # | 13:59:55 | jeff | dbwells: please let me know if more detail would be helpful. i can probably get you what you need. |
| # | 14:05:08 | gmcharlt | encouraging |
| # | 14:05:29 | gmcharlt | heh - wrong window |
| # | 14:06:01 | jeff | :-) |
| # | 14:17:43 | tsbere notes that the branch he wrote previously to deal with a different "we only see 10 holds" consequence conflicts with the one eeevil wrote |
| # | 14:17:48 | tsbere | <_< |
| # | 14:17:59 | tsbere | I suppose I could re-write mine on top of eeevil's |
| # | 14:21:40 | jeff | we went simple brute force, and just bumped it to 100. |
| # | 14:22:01 | jeff | effort_duplication-- |
| # | 14:22:15 | jeff | (bad on me for not creating a bug) |
| # | 14:22:34 | tsbere | jeff: So when 101 local holds won't fill due to age protection it still fails? :P |
| # | 14:22:44 | jeff | yes. |
| # | 14:22:58 | jeff | but not local. |
| # | 14:23:06 | jeff | because we were also using fifo. ;-) |
| # | 14:23:06 | tsbere | You using fifo? |
| # | 14:23:08 | tsbere | ahh |
| # | 14:23:09 | jeff nods |
| # | 14:23:26 | tsbere | Thus: So when the first 101 holds in the fifo list won't fill because of age protection it still fails? :P |
| # | 14:23:30 | jeff | i think before master, the issue may be unique to fifo + ahp |
| # | 14:24:25 | tsbere | I think the issue existed before master, and applies to non-fifo + ahp too |
| # | 14:24:33 | tsbere | Because we aren't fifo and we are seeing issues |
| # | 14:24:34 | tsbere | <_< |
| # | 14:25:29 | tsbere | We mainly have it reported with "why can they renew that? THERE ARE HOLDS ON IT!" but I suspect it is also doing "transit home just to reshelve" instead of "transit home to fill holds" too. |
| # | 14:27:27 | dbwells | jeff: I am thinking your suspicion is correct. Serial items are contents, and units are containers, and they exist to (optionally) provide copy-type information (e.g. call numbers, barcodes, locations) to one or more items. If a unit doesn't have any items (i.e. contents), it is not serving its intended purpose and is not going to function correctly. Keeping all the serials layers in sync (and deciding the best places for bumper rails) is a |
| # | 14:27:27 | dbwells | n ongoing effort. |
| # | 14:28:07 | tsbere doesn't want to know what needs to be done when doing "no renewal when there are holds" at the item owning and circ library but renewing at a location that *doesn't* say that.....who's rule do you follow? >_> |
| # | 14:28:40 | Dyrcona | consortia-- |
| # | 14:31:21 | jeff | dbwells: that helps my understanding a bit. thanks. do you have a lead / suspicion as to what may have resulted in units-without-items, or would you appreciate more data? |
| # | 14:32:12 | viper11 has joined #evergreen |
| # | 14:43:12 | dbwells | jeff: well, my simplest and best guess would be that someone received the items into units (which created the units), then deleted the items (probably thinking they were "done" with them). Ideally we would be more clear (both in the interface and programmatically) that items and units are fused and not independant "things". We are getting there. |
| # | 14:47:03 | Meliss has quit IRC |
| # | 14:53:29 | jeff | sometimes the obvious things... |
| # | 14:53:50 | jeff | "hey, why do so few of these bibs have any value in the mvr isbn field?" |
| # | 14:53:50 | jeff | grep "^020 " ~/safari/yaz.txt | awk '{print $2}' | sort | uniq -c |
| # | 14:53:51 | jeff | 1 $9 |
| # | 14:53:51 | jeff | 14617 $a |
| # | 14:53:51 | jeff | 10863 $z |
| # | 14:53:53 | jeff | that's why. |
| # | 15:09:25 | thethomaseffect has quit IRC |
| # | 15:09:45 | fortin has joined #evergreen |
| # | 15:15:49 | jamesrf | i just did an install from master, i set my prefix to /srv/openils for both OpenSRF and Evergreen, but it looks like it put ${prefix} instead of the actual prefix in O:U:CronScript.pm +62 |
| # | 15:19:54 | tsbere | jamesrf: Cronscript.pm is created by the configure steps, I think. |
| # | 15:20:22 | tsbere | And it appears to only have a @sysconfdir@ replace on that line? |
| # | 15:20:53 | tsbere | perhaps the sysconfdir replace is getting bad data somewhere |
| # | 15:21:21 | jamesrf | yeah it looks like it's getting ${prefix}/etc so it gets that part but the prefix part isn't getting replaced |
| # | 15:22:08 | jamesrf | like it's getting literally what's in the Makefile: sysconfdir = ${prefix}/etc |
| # | 15:25:55 | dmagick_ has quit IRC |
| # | 15:28:02 | yohan has quit IRC |
| # | 15:28:26 | tsbere | jamesrf: Typo on the command line option causing the prefix var to not be set properly? |
| # | 15:30:20 | jamesrf | well everything got installed to the prefix, it's just that one file that is broken, i just used --prefix=/srv/openils, maybe quotes are needed for the perl? |
| # | 15:33:11 | Dyrcona | jamesrf: what did you use for --sysconfdir? |
| # | 15:33:33 | jamesrf | i didn't specify one, i just wanted it to use the default |
| # | 15:34:06 | Dyrcona | maybe that's what broke. try specifying it as --sysconfdir=/srv/openils/conf |
| # | 15:35:05 | jamesrf | ok i'm rebuilding with --sysconfdir=/srv/openils/etc |
| # | 15:35:31 | Dyrcona | if that is the problem, then it is likely a bug in our configure/build system. |
| # | 15:35:56 | Dyrcona | i always specify --sysconfdir out of habit. |
| # | 15:36:12 | jamesrf | right so do I, but you shouldn't have to |
| # | 15:36:27 | jamesrf | yep that worked so it seems like the default value is broken |
| # | 15:38:05 | sal_ has joined #evergreen |
| # | 15:41:56 | jamesrf | reported it as LP 960552 |
| # | 15:41:56 | pinesol_green | Launchpad bug 960552 in Evergreen "automake default sysconfdir broken" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/960552 |
| # | 15:42:20 | Dyrcona | cool. I'll take a look. |
| # | 15:44:44 | berick wonders if the sole "CREATE FUNCTION" should be "CREATE OR REPLACE FUNCTION" in 0686.schema.auditor_boost.sql |
| # | 15:45:50 | tsbere | berick: Possibly. <_< I wonder how I missed that one. |
| # | 15:45:57 | Neil___ has joined #evergreen |
| # | 15:46:33 | tsbere | jamesrf: I bet I know what is wrong with that prefix value. Cronscript is being treated like a Makefile, not as a final product, by configure, but then not treated as such by make install. |
| # | 15:47:12 | tsbere | AKA, Configure is expecting it to be parsed such that the prefix value is substituted at runtime. :/ |
| # | 15:47:19 | eeevil | grabbing 0687 |
| # | 15:48:28 | kurgan_ has joined #evergreen |
| # | 15:55:31 | kurgan_ has quit IRC |
| # | 15:56:16 | Dyrcona | Solution: Change Cronscript.pm.in to a regular Cronscript.pm and run sed to do the substitution. |
| # | 15:56:53 | Dyrcona has an hour and a half to kill; will whip up a branch. |
| # | 15:59:04 | Florent_ has joined #evergreen |
| # | 16:01:31 | akilsdonk has quit IRC |
| # | 16:07:20 | Florent_ | Hi. I have some questions about GSoC, I don't know if someone is able to answer me? (I would know if dbwells is here -not afk- because I'm interested by one of his projects) |
| # | 16:07:24 | mrpeters-isl | any hints on how i can tie a message "mismatched tag at line 1, column 2140, byte 2140 at /usr/lib/perl5/XML/Parser.pm line 187" to a particular tag/subfield? |
| # | 16:07:58 | mrpeters-isl | record: http://evergreen.lib.in.us/opac/en-US/skin/default/xml/rdetail.xml?r=19260276 |
| # | 16:08:26 | phasefx_ | Florent_: go ahead and ask your questions, someone may be able to chime in |
| # | 16:09:05 | dbwells | Florent_: Let me guess, Android? We've been getting a lot of interest there. |
| # | 16:09:18 | Florent_ | Exactly... |
| # | 16:09:39 | Florent_ | I haven't many skills |
| # | 16:10:06 | Florent_ | So your project is interessant because Java is one of my programming language |
| # | 16:13:26 | dbwells | Florent_: well, since I do not expect any applicants to be Evergreen experts, I am really hoping to find an Android expert, as expecting to learn both Evergreen and Android in one summer is unrealistic. |
| # | 16:14:11 | eeevil | tsbere: so, f40b07363116b1133080f8d7d6d31c06d1d3c771 is a very slim race condition ... did you see that in practice, or just personal pedantry ;) |
| # | 16:15:06 | tsbere | eeevil: We had complaints that "grace periods no longer work, AT ALL!" that I traced back to that. And it isn't slim. Backdate a checkin to the last day of a grace period. |
| # | 16:15:31 | tsbere | The backdate code says "ok, lets use the time information from the original circ" which will be the end of day for a multi-day checkout..... |
| # | 16:16:45 | dbwells | Florent_: that said, enthusiam, demonstration of committment, and quality of application are also going to be factors in choosing a student. So I wouldn't say it isn't possible to be chosen, but you would be starting from an underdog position. |
| # | 16:17:54 | eeevil | tsbere: ahh... of course. well, it's in |
| # | 16:20:39 | tsbere | eeevil: Yay! That circ department head will be able to stop complaining. |
| # | 16:21:03 | tsbere | well, eventually |
| # | 16:22:29 | Florent_ has quit IRC |
| # | 16:23:21 | adbowling-isl has joined #evergreen |
| # | 16:23:47 | denials | Dyrcona / tsbere: Not sure that's the right solution for all of the *.in files |
| # | 16:24:30 | Dyrcona | denials: A code file is currently being treated as a configuration file by autotools. |
| # | 16:24:58 | Dyrcona | That is the root of the problem and why one *must* specify sysconfdir when configuring. |
| # | 16:25:18 | Dyrcona | No sysconfdir, then you have a busted Cronscript.pm. |
| # | 16:25:32 | Dyrcona | With a busted Cronscript.pm, no autogen. |
| # | 16:25:42 | Dyrcona | No autogen, no working ILS. |
| # | 16:25:56 | Dyrcona | At least, that's the chain of events, I've managed to recreate. |
| # | 16:26:33 | khoover has joined #evergreen |
| # | 16:26:55 | Dyrcona | Since a default sysconfdir depends on prefix being set, it looks like install is the right time to change the file. |
| # | 16:27:35 | Dyrcona | Since you could: ./configure --prefix=/blah ; make install prefix=/some/other/blah |
| # | 16:27:41 | denials | Dyrcona: Based on your understanding, sure |
| # | 16:28:06 | viper11 has left #evergreen |
| # | 16:28:57 | Dyrcona | Call me old-fashioned, but someone ought to be able to do ./configure; make install and have a working system. |
| # | 16:29:36 | denials | Dyrcona: Your assertion that autoconf is for Makefiles is questionable. And that's what the rest of your assertions rely on. |
| # | 16:29:49 | sal_ has quit IRC |
| # | 16:30:07 | denials | I agree that ./configure; make install should work, obviously. Please don't do that. |
| # | 16:30:30 | Dyrcona | denials: Cronscript.pm is listed in configure.ac as a configuration file. Cronscript.pm.in is therefore being treated like a Makefile, more or less. |
| # | 16:30:39 | denials | (i.e. please don't escalate this beyond a discussion, I'm trying not to be defensive) |
| # | 16:30:59 | denials | "Autoconf is a tool for producing shell scripts that automatically configure software source |
| # | 16:31:02 | denials | code packages to adapt to many kinds of Posix-like systems. |
| # | 16:31:05 | denials | " |
| # | 16:31:11 | Dyrcona | ok. I'll drop my branch and leave it to someone else then.... |
| # | 16:31:13 | denials | From the autoconf manual. It's not just about Makefiles. |
| # | 16:31:24 | Dyrcona | No shit, Sherlock! |
| # | 16:31:44 | denials | Thanks, again. Escalation is unnecessary. |
| # | 16:33:47 | tsbere | denials: I think the problem is that we are treating code files as build step files, and configure is thus doing the wrong thing. If automake/autoconf/whatever is to be used to replace that value in the code file then we need to tell it that it is a code file, and not a build step file. |
| # | 16:34:11 | tsbere | And I don't know, personally, how to tell the system that. |
| # | 16:34:31 | tsbere | This is further complicated by the Build.PL steps included for building and installing the perl libraries. |
| # | 16:35:38 | Dyrcona | The problem is, if you don't set sysconfdir at configure time, then you get a busted Cronscript.pm. |
| # | 16:36:51 | tsbere | Dyrcona: That is the symptom. It points us at a problem, but I think the problem is treating a code file as a build system file. |
| # | 16:38:28 | Dyrcona | sysconfdir needs to set at install time, since the variables it depends on can change at each step. |
| # | 16:38:40 | enhancin has joined #evergreen |
| # | 16:38:50 | Dyrcona | Cronscript.pm therefore needs to be munged during the install step. |
| # | 16:38:56 | enhancin | Has anyone come across a Makefile.install made for Ubuntu 11.04? |
| # | 16:39:19 | tsbere | enhancin: We tend to support LTS releases only and recommend you stick with them. |
| # | 16:40:18 | Dyrcona | We already sed a bunch of files elsewhere IANM. |
| # | 16:40:24 | enhancin | Ah, alright. So technically you'll just go from 10.04 LTS to 12.04 LTS? |
| # | 16:40:31 | enhancin | that's a good thing to know when I grab images :) |
| # | 16:40:47 | collum has quit IRC |
| # | 16:40:49 | Dyrcona | enhancin: 12.04 is already supported in the master branch. |
| # | 16:41:13 | enhancin | sweet, i was really puzzled at the lack of resources about 11.04 but I completely understand why now. |
| # | 16:41:17 | Dyrcona uses 12.04 on his development server. |
| # | 16:41:26 | enhancin | this is my dev server as well that I'm installing it on : ) |
| # | 16:42:33 | jamesrf | with respect to Cronscript.pm.in, ideally I'd think maybe you shouldn't even have a path hardcoded in a perl module like that? |
| # | 16:43:56 | tsbere | jamesrf: I think it is a default more than anything, overridable by command line options |
| # | 16:44:05 | denials | jamesrf: pulling the value at runtime from `eg_config --sysconf` for example? |
| # | 16:50:08 | jamesrf | so if that was the approach you'd need to pass everything in through Configure.pm to Cronscript.pm? |
| # | 16:51:19 | tsbere | jamesrf: If we switch to calling eg_config then Cronscript becomes a normal perl file and isn't treated specially. Otherwise we still need to munge it at some point. |
| # | 16:58:34 | Dyrcona | eg_config --sysconfdir looks like the way to go. |
| # | 16:59:17 | Dyrcona makes heavy use of Cronscript.pm, fwiw. |
| # | 17:27:15 | Dyrcona has quit IRC |
| # | 17:37:49 | jamesrf | Dyrcona: when you use Cronscript do you pass in an osrf-config? |
| # | 17:38:39 | sal_ has joined #evergreen |
| # | 17:39:26 | jamesrf | I've rewritten Configure.pm's methods that call Cronscript.pm to accept an opensrf_core.xml path and then pass that in from autogen.sh, getting it from eg_config |
| # | 17:39:38 | jamesrf | although it seems moot because there's still a hardcoded value in Cronscript.pm no matter what |
| # | 17:40:02 | sal_ | Is there documentation for the staff client MARC import screens? (I've managed to export 10 MARC records from one EG instance, and would like to import them to another.) I managed to read in the file successfully ;-) |
| # | 17:41:41 | sal_ | Or have I imported them already? *confused |
| # | 17:42:58 | jamesrf | sal_: sitka has some docs for Evergreen 2.0 here: http://docs.sitka.bclibraries.ca/Sitka/current/html/upload.html |
| # | 17:43:23 | sal_ | jamesrf: thanks. Apparently I *have* imported the MARC records! |
| # | 17:43:57 | sal_ | Need to document that too... |
| # | 17:45:09 | jenny2 has quit IRC |
| # | 17:59:27 | hopkinsju has quit IRC |
| # | 18:10:37 | fortin has quit IRC |
| # | 18:13:05 | avinash_ has joined #evergreen |
| # | 18:18:03 | avinash_ | hi, please help me in understanding the "Create Android client(s) for Evergreen" project. |
| # | 18:18:25 | avinash_ | I am comfortable with android |
| # | 18:23:17 | senator | avinash_: i believe the idea is to create anything useful to either libary patrons or library staff that interacts with evergreen from an android device. a good early step would be to become familiar with the basic functionality offered by evergreen |
| # | 18:24:23 | avinash_ | can u provide me some links |
| # | 18:25:19 | senator | http://evergreen-ils.org/ There you will find documentation, demo servers, and code which you can download, install, and test yourself |
| # | 18:25:53 | tsbere | jamesrf: I think you missed that Dyrcona left ten min before your question to him. |
| # | 18:32:28 | jamesrf | meh. yeah. |
| # | 18:32:49 | jamesrf | sort of at the point in the afternoon where more coffee is required |
| # | 18:35:29 | avinash_ | senator: So android app should communicate to evergreen server |
| # | 18:35:45 | senator | avinash_: yes |
| # | 18:40:34 | avinash_ | senator: i got this http://testing.evergreen.lib.in.us/updates/manualupdate.html |
| # | 18:40:45 | avinash_ | is this what i need to installl |
| # | 18:42:07 | senator | that is where you download a staff client to connect to the test server at testing.evergreen.lib.in.us. so yes. |
| # | 18:42:19 | senator | as for me, it's time for supper |
| # | 18:42:55 | avinash_ | its 4 am here |
| # | 18:44:44 | Gentlecat has joined #evergreen |
| # | 18:45:07 | avinash_ | from this http://testing.evergreen.lib.in.us/updates/manualupdate.html besides windows/linux di wee need to install other two too |
| # | 18:45:48 | avinash_ | do we nned to install other two |
| # | 18:46:12 | avinash_ has quit IRC |
| # | 18:47:29 | Gentlecat has quit IRC |
| # | 18:47:56 | Gentlecat has joined #evergreen |
| # | 19:34:14 | Neil___ has quit IRC |
| # | 19:51:16 | sal_ has quit IRC |
| # | 20:08:37 | finnx has joined #evergreen |
| # | 20:54:08 | khoover has left #evergreen |
| # | 21:12:11 | Gentlecat has quit IRC |
| # | 21:37:52 | swills_ | on the create/edit hold page, the place hold button does not appear to fire. I see nothing in any log server side. how does one debug the js in the staff client? |
| # | 21:58:20 | luisb has quit IRC |
| # | 23:10:09 | finnx has quit IRC |
| # | 23:19:07 | tecoripa has joined #evergreen |
| # | 23:19:57 | tecoripa | I have a question about the DCO text that should be submitted with new code, patches: |
| # | 23:20:15 | tecoripa | where does that text live? should it be included in the commit messages? |
| # | 23:20:36 | tecoripa | Or can I simply attach a signed copy as a file to the Launchpad ticket? |
| # | 23:20:46 | tecoripa | I do sign all my commits already |
| # | 23:35:02 | denials | tecoripa: if you sign off on your commit, you're asserting the DCo |
| # | 23:35:24 | denials | so you don't need to include it in a commit message or launchpad ticket |
| # | 23:36:29 | denials | (from http://evergreen-ils.org/dokuwiki/doku.php?id=contributing "For all significant code contributions, please use git's sign-off feature to assert that the code you are submitting is in accordance with the Developer Certificate of Origin (DCO) 1.1") |
| # | 23:39:30 | tecoripa | denials: OK, thanks. I was a bit confused by that and the text on the "Contributing" wiki page. |
| # | 23:41:14 | denials | The contributing page is pretty long :/ |
| # | 23:41:45 | denials glares at json_query |
| # | 23:43:41 | denials | swills_: Admin -> Developer -> JavaScript Console may be helpful (if I recall the menu names correctly) |
| # | 23:44:53 | swills_ | Received Data: [ |
| # | 23:44:53 | swills_ | { |
| # | 23:44:53 | swills_ | "jsonquery":stares back, |
| # | 23:44:53 | swills_ | "stares-at":"denials" |
| # | 23:44:54 | swills_ | } |
| # | 23:44:54 | swills_ | ] |
| # | 23:45:04 | swills_ | thanks, I'll try it. |
| # | 23:45:54 | swills_ | and thanks for not ping flood kicking me :) |
| # | 23:47:54 | tecoripa has left #evergreen |
April 10-13