Evergreen ILS Website

IRC log for #evergreen, 2013-12-17

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

Time Nick Message
00:23 jeff_ joined #evergreen
00:39 mrpeters left #evergreen
03:05 zxiiro joined #evergreen
04:27 gsams joined #evergreen
07:00 timf joined #evergreen
08:01 ningalls joined #evergreen
08:03 collum joined #evergreen
08:10 kmlussier joined #evergreen
08:20 mrpeters joined #evergreen
08:25 mdriscoll joined #evergreen
08:30 RoganH joined #evergreen
08:37 kbeswick joined #evergreen
08:38 akilsdonk joined #evergreen
08:51 mmorgan joined #evergreen
08:59 rfrasur joined #evergreen
09:00 Shae joined #evergreen
09:00 ericar joined #evergreen
09:10 dbs joined #evergreen
09:11 dbs joined #evergreen
09:21 Dyrcona joined #evergreen
09:37 gdunbar joined #evergreen
10:19 yboston joined #evergreen
10:42 bshum Dyrcona: While not explicit, the logo links back to search for the reason that we removed search from being seen.
10:42 Dyrcona bshum: Add that to the bug, please.
10:43 bshum Sure thing.
10:43 Dyrcona Apparently, our members voted to change that: silly members.
10:44 bshum I guess it could be more explanatory, but everything counts in screen real estate that small.
10:44 Dyrcona Yes, of course.
10:44 * bshum still wants less stuff everywhere.
10:44 Dyrcona There should be nothing, but a search box and a search button.
10:45 tsbere Our members voted on the logo being a link to the library back when the default was it linking to evergreen-ils.org
10:46 tsbere The fact that has changed since in default is a different story entirely for us
10:46 dbs Yeah. The idea was to do what your members did with the logo, originally
10:47 * Dyrcona thinks the two questions are orthogonal to one another.
10:47 dbs Then the logo got a more specific purpose with the MOPAC work
10:47 dbs but it's not necessarily intuitive either way if it's just a logo
10:48 dbs mystery navigation
10:50 bshum Dyrcona: I added a reply to the bug and marked it as "triaged" while we look for further discussion and refinement of the approach I guess.
10:51 Dyrcona Feel free to set it to invalid.
10:51 Dyrcona You won't hurt my feelings. :)
10:51 bshum I was thinking to mark it "Opinion" :)
10:51 bshum Until someone were to champion it as an area for change
11:03 bshum Maybe something to do is to add a "Go back to search" type link in your footers that only displays in mobile view.
11:04 bshum Well
11:04 bshum I guess that could also be useful in the main view too
11:05 bshum Basically if using the footers for navigation, that's an option I guess
11:05 bshum For fun reading, I'm enjoying the many options suggested with http://responsivenavigation.net/
11:24 pinesol_green [evergreen|Angela Kilsdonk] Documentation for 2.5 - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=2423f2a>
11:27 rfrasur am I right in assuming that Circ datas and Publisher datas are from diff sources (with reference to reports)?
11:29 tfaile joined #evergreen
11:31 bshum akilsdonk: Hmm, I think in that last commit I see a potential typo for a missing underscore with Default_Patron_Billing Screen.jpg (between Billing and Screen) in the circulation_patron_records.txt file
11:31 akilsdonk bshum: argh.  I thought I got them all.  thanks for pointing it out!
11:32 bshum akilsdonk++ #documenting for the rest of us :D
11:36 dMiller_ joined #evergreen
11:38 pinesol_green [evergreen|Angela Kilsdonk] Asciidoc fix - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=ed8434b>
11:39 akilsdonk fixed!  bshum++
11:45 ktomita_ joined #evergreen
11:55 dbs what's the convention for hours of operation for days the library is closed: 12:00 - 12:00?
11:56 bshum It's either that or 00:00 to 00:00
11:56 bshum I'll double check
11:56 linuxhiker anybody having problems with oom killer nailing opensrf on 2.4?
11:56 eeevil bshum: you're correct
11:56 dbs bshum++
11:56 dbs eeevil++
11:57 bshum Yep, clearly I've been staring at the database too long.
11:58 bshum linuxhiker: I haven't seen that occur in our systems (we're master/master, Evergreen/OpenSRF respectively), but our application servers have so much extra RAM on them that we never touch the limit.
11:58 bshum I think in our case, I've been watching usage and it hovers around 25 GB or so, while we have 48 GB available overall.
11:59 bshum linuxhiker: Do you have more specific information on the bricks and how they're configured?  Perhaps the opensrf.xml is setting things too high and the physical hardware isn't up to snuff to handle as many child processes for Evergreen services and needs to be rescaled.
12:00 bshum (just guessing, I might just as easily be making stuff up)  :D
12:00 linuxhiker bshum: Well we certainly don't have that level of resources but then against we have 6 apache servers and 12 app servers, that we load balance
12:00 eeevil linuxhiker: if you are sure you wont run out of ram+swap, and the oom killer is just being too aggressive, you can disable it.   The loss of a service listener process is catastrophic in a full-stack server that does not participate in router cross-registration with other opensrf nodes
12:01 eeevil and listeners are likely candidates for oom killing IME, when there's high mem pressure
12:07 * dbs plugging away at providing sample library data (hours, addresses) to use in generating per-library info pages in the TPAC that (naturally) have schema.org markup
12:11 smyers__ joined #evergreen
12:11 bshum dbs++ # saw your working branch, looks fun!
12:12 dbs bshum: there will be much squashing to do, but I think it will be a nice feature for 2.6
12:17 bshum Heh
12:24 dbs A commit with the only comment being "OMG" sums up my brain power at the moment
12:25 dbs BUT... what is there works now. a nice mix of sample address and hours data for branches, with corresponding display pages
12:25 dbs Need to add some sample contact info now...
12:38 dMiller__ joined #evergreen
13:09 kmlussier joined #evergreen
13:12 stevenyvr2 joined #evergreen
14:35 dMiller___ joined #evergreen
14:35 bshum Dyrcona: So I applied the other commit from bug 1243280 and so far no pointless warning errors anymore.
14:35 pinesol_green Launchpad bug 1243280 in Evergreen 2.5 "'TypeError: obj.active_services is undefined' error when entering z39.50 MARC import UI" (affected: 2, heat: 10) [Medium,Confirmed] https://launchpad.net/bugs/1243280
14:35 bshum I'm testing the different parts of the client and so far, so good.
14:35 bshum Might apply both commits
14:36 Dyrcona OK. The other one just makes a useless console warning disappears.
14:36 Dyrcona It checks if some field exists before using it.
14:36 bshum Yeah, that's what I thought
14:36 Dyrcona Should be mostly harmless. :)
14:36 bshum It seems safe then.
14:37 bshum Looking at the error/warning log makes my head hurt
14:37 Dyrcona I have it on my development server and have not noticed anything, but I haven't used it much either.
14:37 dMiller____ joined #evergreen
14:43 pinesol_green [evergreen|Jason Stephenson] Eliminate an annoying and useless warning in the JavaScript Console. - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=bb4a797>
14:43 pinesol_green [evergreen|Jason Stephenson] Break out of focus() in cat/z3950.js if obj.active_services is undefined. - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=cf9a0d4>
14:51 bshum phasefx: dbwells: Looking over bug 1260481 and I think that it was decided during 2.5's development not to do the i18n stuff with upgrade scripts?  Or that it didn't really matter either way because the function wasn't working properly anyways?
14:51 pinesol_green Launchpad bug 1260481 in Evergreen "The label on the desk renewal global flag is misleading" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1260481
14:51 bshum Eyeballed Callender's patch and it makes sense to me
14:51 bshum Other than the i18n question
14:52 bshum Or wait, let me re-read it again
14:52 bshum Because actually I think it's wrong
14:52 dbs the oils_i18n flag isn't processed in upgrade scripts, only on the base schema
14:53 bshum dbs: Ah, cool.  Thanks for confirming that.
14:54 bshum Okay, I had to read it like 5 times to be sure.
14:55 bshum Callender++
14:55 bshum I just can't read
14:55 Callender lol thanks Ben
14:56 bshum Calling 0849
15:05 pinesol_green [evergreen|Steven Callender] Updated the label on the desk renewal global setting. - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=7853a5f>
15:05 pinesol_green [evergreen|Ben Shum] Stamping 0849 - desk renewal description - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=d0d6a7d>
15:14 berick looks like latest safari works fine w/ staff prototype. coool
15:15 bshum I'm sure that'll make iPad users happy?  :P
15:18 RoganH bshum: the mobile safari and desktop have some big differences despite having the same name so no guarantee lol
15:18 bshum RoganH: Yeah I believe that...
15:19 berick ditto Opera
15:19 RoganH Actually it's odd, I have no trouble with your dev server Bill under Safari but Chrome on my Macbook doesn't seem to like it
15:19 berick if you feel like sharing, i'm all ears
15:21 RoganH Let me see the error again.
15:22 RoganH Nevermind.  I think I was doing something stupid repeatedly like capitalizing the 'a' or something.
15:22 RoganH It's one of those days.
15:24 dbs bug 1261896 is in, more to come
15:24 pinesol_green Launchpad bug 1261896 in Evergreen "Move sample library data from seed data into sample data" (affected: 1, heat: 6) [Wishlist,New] https://launchpad.net/bugs/1261896
15:24 bshum dbs++
15:24 berick RoganH: gotcha, thanks for checking
15:24 berick dbs++ indeed
15:38 mrpeters so, what is the proper path from 2.3.12 > 2.4.0 these days?  when i upgraded someone about 3 months ago you had to run the 2.3-2.4.alpha1-upgrade-db.sql > 2.3-2.4.0RC-upgrade-db.sql > 2.3-2.4.0-upgrade-db.sql  > 2.3-2.4-supplemental.sh -- is that still the case or were the scripts fixed to avoid having to use the pre-release upgrade scripts?
15:40 bshum Err
15:40 bshum I would have gone with just the final version of the scripts and none of the development ones.
15:40 bshum Or at least, that's what I would have expected.
15:41 mrpeters yeah, in the past, like i say, i ran the dev ones but maybe ill try skipping them this time
15:43 bshum Running a quick 3-way comparison on them as they exist in master
15:43 bshum Maybe we can nuke away the alpha1 and RC ones
15:44 mrpeters yeah, perhaps...that would be great if so
15:44 bshum Just my quick eyeballing it, they look like the same thing just iterations over time.
15:44 bshum I would imagine you could just run 2.3-2.4.0-upgrade-db.sql
15:45 bshum And you can ignore the other development ones
15:47 bshum Huh
15:47 bshum The only thing really different about the final 2.4.0 is that it doesn't say at the end to run the 2.3-2.4-supplemental.sh file
15:48 bshum Which the RC says to do
15:48 bshum Otherwise, it reordered only one thing 0788 to pull it out of the main body, probably cause there's a backported version in one of the minor point releases of 2.3's series.
15:49 bshum So probably just need to add in that echo statement at the end to run the supplemental script
15:49 bshum And then we can remove alpha1 and RC from the version-upgrade directory
15:49 bshum But I'll defer to eeevil in case I'm missing something else entirely.
15:52 eeevil yes, you can skip the pre-release upgrade scripts. they are superseded by the 2.4.0 one. and the reason why 2.4.0 does not mention the supplemental script is that it should happen /after/ you run the 2.4.1 script
15:53 bshum Ahh, right
15:53 bshum Now I remember, thanks eeevil
15:53 bshum eeevil++
15:54 * eeevil really needs to write down his plan for no more minor-version upgrade scripts and only major version number reification of the baseline schema... sorry for the delay on that, folks
15:55 mrpeters eeevil++ bshum++
15:56 mrpeters ah, i remember this old friend
15:56 mrpeters ERROR:  cannot drop view metabib.full_rec because other objects depend on it
15:56 mrpeters needs to be a drop cascade
15:58 bshum mrpeters: What are the other dependent objects?  MIght be non-stock stuff at play that wasn't shown during testing.
15:58 bshum (there was lots of that and we noted a few with the reporter views)
15:58 mrpeters hmm whats the easiest way to tell?
15:59 mrpeters DETAIL:  view reporter.steve_old_super_simple_record depends on view metabib.full_rec
15:59 mrpeters heh, yeah thats probably not stock :P
15:59 bshum steve_old_super_simple_record... lol
15:59 bshum :)
16:00 mrpeters sorry about that guys, glossed over the detail line
16:13 gdunbar joined #evergreen
16:15 csharp mrpeters++
16:17 csharp mrpeters: I hit several bumps in the 2.3-2.4 script - had to do some manual dropping of old crufty tables, functions, and indexes
16:19 csharp http://git.evergreen-ils.org/?p=evergreen/p​ines.git;a=shortlog;h=refs/heads/rel_2_5_1 has examples of what I did
16:24 mrpeters yep, i remember :)
16:24 mrpeters all of this is coming back to me like deja vu hehe
16:32 xtanya joined #evergreen
16:41 signora joined #evergreen
16:45 bshum berick++ # prototype fun
16:46 dMiller_ joined #evergreen
16:55 mdriscoll left #evergreen
16:56 bshum jboyer-isl: Around?
17:01 mmorgan left #evergreen
17:03 pmurray_away joined #evergreen
17:05 pmurray_away joined #evergreen
17:09 dbs berick++ # thanks for giving the library sample data branch a test run
17:10 pmurray left #evergreen
17:10 * dbs scoots
17:16 netadres joined #evergreen
17:22 mceraso joined #evergreen
17:22 bshum joined #evergreen
17:24 sseng anyone able to export to (print/email/cvs) when using the "Marc Batch Import / Export" while having the queue filters "Limit to Records with Matches" checked? going to head over and submit as a bug on LP with more details
17:27 kmlussier sseng: I have heard reports of this locally, but I never had time to confirm the problem.
17:28 pinesol_green [evergreen|Remington Steed] Docs: bug fixes in new files - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=3f2a30d>
17:28 sseng kmlussier: sounds good, submitting bug now
17:37 dcook joined #evergreen
17:46 kmlussier joined #evergreen
17:52 sseng bug regarding export submited: https://bugs.launchpad.net/evergreen/+bug/1261973
17:52 pinesol_green Launchpad bug 1261973 in Evergreen "Hanging progress bar when tyring to export to Print/Email/Cvs using "Marc Batch Import / Export"" (affected: 1, heat: 6) [Undecided,New]
17:53 kmlussier bshum++ #for general awesomeness. :)
17:53 dcook Quick question for Evergreen folks!
17:53 kmlussier sseng: If I have a chance, I'll try to confirm it tonight.
17:53 * bshum waves at dcook!
17:53 dcook Hey, bshum!
17:53 sseng kmlussier: great, thanks!
17:53 dcook How's it going?
17:54 bshum dcook: It's good times, plotting out my eventual trip overseas to visit Australia and other places :D
17:54 dcook \o/
17:54 dcook I'm still trying to get everything shipped back to Australia from my last trip to North America ;). Accidentally left a laptop charger in Vancouver..
17:55 dcook As for Evergreen, could you confirm that you can export bib records, modify them using an external program, and then re-import and overwrite existing records in the ILS?
17:55 * dcook is writing a little article on metadata management and wants to make sure he's giving correct info on Evergreen
17:55 bshum dcook: I would generally say that is possible based on the workflow and how it was being done.
17:56 bshum More specifically, Evergreen does tag every record in it with a custom 901 tag that usually keeps the bib's ID as the subfield c portion.
17:56 dcook Cool beans. I took a little look at the documentation last night and it looks pretty similar to Koha in that regard.
17:56 bshum So that'd a good way of noting which bib is the same for overlaying
17:56 bshum I imagine there'd be ways of using other conventions too
17:57 dcook For sure. I suppose I was thinking more about the existence of matchers in Evergreen but I seem to recall seeing some
17:57 dcook One of these days, I really need to install it myself
17:58 bshum It's not exactly apt-get install, but I like to think it's come very much farther along compared to where it was when I first started :)
17:58 dcook :)
17:59 dcook Yeah, I briefly looked at the install instructions a few months ago and was a bit intimidated ;)
17:59 dcook I'm sure it's one of those things where you need to try it until you get it, and then it makes sense
18:00 bshum There's occasionally some demo servers floating around too
18:00 dcook Hmm. That would be cool.
18:00 bshum http://evergreen-ils.org/dokuwik​i/doku.php?id=community_servers
18:01 dcook I suppose I'm curious about this server/client architecture
18:01 dcook Is Evergreen a desktop app?
18:01 bshum The 2.5.0 one from ESI should work
18:01 bshum Yeah, the app runs on Windows or Linux (though I'm not sure if the Linux builds are linked)
18:01 bshum (and Mac if you know how to build a custom mac app)
18:06 dcook Wow, I'm really digging the catalogue
18:07 bshum Really the green didn't scare you off? ;)
18:08 dcook Green is my favourite colour :p
18:08 bshum Heh
18:09 dcook The staff client is a bit...interesting
18:09 dcook Oh my, something isn't good
18:10 dcook !! This software has encountered an error.  Please tell your friendly system administrator or software developer the following:\nmenu_frame.xul\nTypeError: obj.data.hash.aous is undefined\n
18:10 bshum Heh
18:10 bshum Sounds like whoever set up the demo server didn't run autogen properly
18:11 dcook Maybe I pressed too many buttons as well? :p
18:12 dcook I thought it was a desktop staff client...but I assume it had a web staff client like Koha
18:12 dcook Yep, I think it might've been me
18:13 dcook Unless I'm using the standalone interface and don't know it?
18:13 bshum Heh
18:13 * dcook will start over
18:14 dcook I try logging in...
18:14 dcook Now it shows a greyed out username and no password
18:14 dcook As well as a greyed out Login button
18:14 dcook What's the next step? :S
18:14 bshum There's a part of the process for workstation registration
18:14 bshum The right upper part of the screen should have a location selector and a part to fill in a name
18:15 dcook Yeah, I've already set up that part :/
18:15 bshum Ah
18:15 bshum Well then
18:17 bshum And you got the loading stuff across the bottom right?
18:17 bshum Well, what's normally expected
18:17 dcook Only after I clicked on "Standalone interface"
18:17 bshum is that you see the loading stuff, and then it's supposed to open another window with the actual client interface
18:18 bshum With that other thing as a background window
18:18 dcook I think it might've loaded?
18:18 bshum Try closing out the whole thing and logging in again then
18:18 dcook Hehe. That's what I did just try ;)
18:18 bshum Or there's a button for "Open New Window" too
18:18 bshum That's super strange.
18:18 dcook Ah, so that's the standalone interface..
18:19 dcook It did open the regular interface (after I opened the standalone)
18:19 dcook I don't recall seeing any loading info at the bottom (except for the standalone) but it definitely worked
18:19 dcook Just maybe slower than I thought
18:19 bshum It is slow
18:19 bshum :)
18:19 dcook The "Open New Window" button definitely works as well
18:19 bshum Or rather, the negotiation with the server can be.
18:20 dcook Yeah, I'm thinking that's what it probably is
18:20 dcook I think it's Equinox's server and there's probably how many proxies between it and me
18:21 dcook This is a very interesting experience though!
18:22 * dcook can feel his experience points piling up
18:22 dcook Ohh, there's a batch edit as well..
18:22 bshum Yeah, I was going to mention that before.
18:22 bshum Depending on what you're doing, you could edit bibs that way in the client (though I know folks have expressed concern about knowing how to do so)
18:23 bshum And also, it's unclear how many bibs are easily processed through the interface vs. faster to do in the backend direct with the database if you have access and/or tricks
18:24 dcook For sure
18:24 dcook Yeah, the batch editor seems a bit confusing
18:24 bshum I think there's regex involved.
18:24 dcook Does Evergreen use helper tables or does it just use the MARC record as the only record?
18:24 bshum Which means not for end user staff catalogers :)
18:24 dcook Probably not, eh?
18:25 dcook My intent with the article is to get more librarians to try getting their hands dirty with things like MarcEdit and programming libraries though, so you never know..
18:25 bshum MarcEdit is a neat little tool
18:25 bshum I know our catalogers use it from time to time to poke at bibs before loading
18:26 bshum I'm not sure what a "helper table" would be exactly.
18:27 bshum But as far as storing information goes, MARC is a big central point.  But item and volume data are stored in other tables.
18:27 bshum So I guess it doesn't include that as part of the bib record
18:28 bshum Evergreen's database stores volume and copy data in their own tables.
18:28 bshum So you could have one bib, with multiple volumes, with the volumes having multiple copies of their own too.
18:29 bshum But it's not reflected in MARC as a holding line or such.  Though I think you can export it that way.
18:29 * bshum smells pasta cooking... and should disappear for a bit
18:29 dcook Mmm pasta
18:29 bshum dcook: Happy poking, feel free to pass along questions or such.  If not IRC there's always our general mailing list too.
18:30 dcook Thanks, bshum
18:30 dcook I might have to put this off to the side for a little while, but this helps a lot. Have a good...evening?
18:30 dcook Yes, evening. Good evening, hehe.
18:30 bshum dcook: Heh, yes, evening.  Thanks and you too have a nice day.
19:31 stevenyvr2 left #evergreen
19:47 afterl1 left #evergreen
21:55 mrpeters joined #evergreen
22:04 mrpeters left #evergreen
22:10 stevenyvr2 joined #evergreen
22:10 stevenyvr2 left #evergreen
23:20 book` joined #evergreen

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat