| # | Time | Nick | Message |
|---|
| # | 00:19:35 | phasefx has quit IRC |
| # | 00:19:37 | dbs has quit IRC |
| # | 01:16:06 | darshan has joined #evergreen |
| # | 01:17:54 | darshan | When I am taking reference of any record and importing that record ,I am receiving error mention in 1error.log file, After that when I am placing hold for my patron I am receiving error mention in 2error.log file, Then at time of capturing hold ,I am receiving error mention in 3error.log file. Atlast ,I want to set action trigger and for that I have set hook for hold.available and hold.capture but after doing set up also ,mail i |
| # | 01:18:08 | darshan | the links are-- 1error file-http://www.woofiles.com/dl-272575-iTt6ZCIw-1error.log 2error file-http://www.woofiles.com/dl-272576-q4Ru51P6-2error.log 3error file-http://www.woofiles.com/dl-272577-OxGOv9ye-3error.log |
| # | 01:18:31 | darshan | plz ans me if ne1 can..plzz :( |
| # | 07:20:01 | dbs has joined #evergreen |
| # | 07:21:27 | Dyrcona has joined #evergreen |
| # | 07:42:28 | collum has joined #evergreen |
| # | 08:01:22 | tspindler has joined #evergreen |
| # | 08:05:48 | dbs has quit IRC |
| # | 08:55:17 | akilsdonk has joined #evergreen |
| # | 09:19:45 | darshan has quit IRC |
| # | 09:31:05 | jenny1 has joined #evergreen |
| # | 10:05:18 | kivilahtio has joined #evergreen |
| # | 10:15:52 | dbs has joined #evergreen |
| # | 10:18:43 | dbs | tspindler: http://evergreen-ils.org/dokuwiki/doku.php?id=versioning has a summary of alpha / beta / release candidate requirements |
| # | 10:19:11 | phasefx has joined #evergreen |
| # | 10:20:33 | kivilahtio | Hello #Evergreen! What does a boy need to do to get the "Copy Summary" visible in the OPAC. I checked and I have 3 items bound to the call_number and the call_number is bound to the record I am searching. I get the copies in the main search listing, but not in the "Record Summary". |
| # | 10:21:06 | kivilahtio | Record Summary -> Copy Summary |
| # | 10:21:21 | tsbere | Click "Show all Copies" or whatever it is? |
| # | 10:21:27 | tsbere guesses at random without actually looking |
| # | 10:21:52 | tsbere | "View Copy information for all...." |
| # | 10:22:49 | tsbere | Oh, and maybe make sure you checked the copies in. :P |
| # | 10:22:58 | kivilahtio | hmm havent done that |
| # | 10:23:26 | kivilahtio | i think I have to modify hte import script I did to set all the items as present |
| # | 10:24:57 | phasefx | kivilahtio: oh, if you're importing these items in some way, make sure the opac_visible flag on them is set to true |
| # | 10:26:43 | kivilahtio | phasefx: yup it is set true on default |
| # | 10:26:59 | kivilahtio | googled on some leads |
| # | 10:27:04 | phasefx | other things that have opac_visible flags include copy locations and copy statuses |
| # | 10:27:17 | kivilahtio | checking on the status column possibilities |
| # | 10:27:54 | phasefx | but if your search is finding the record outside of the staff client, it's probably not visibility |
| # | 10:28:13 | kivilahtio | status is 0 |
| # | 10:28:37 | dbs | kivilathio: publicly visible URL? |
| # | 10:29:18 | kivilahtio | dbs: where can i set that? |
| # | 10:29:34 | dbs | kivilahtio: I mean, can you point us at a URL so we can poke directly? |
| # | 10:29:42 | kivilahtio | ah sorry not quite yet |
| # | 10:29:47 | kivilahtio | hmm |
| # | 10:30:16 | kivilahtio | http://193.65.112.189/opac/en-US/skin/default/xml/rdetail.xml?l=1&d=0&t=big%20knockover&tp=keyword&hc=1&r=400016&rt=keyword |
| # | 10:30:31 | kivilahtio | dbs: got it |
| # | 10:30:54 | kivilahtio | dbs: I am having some issues with the local it department and firewalls, but for the time being that port should be visible |
| # | 10:33:01 | phasefx | the page is dying with a javascript error |
| # | 10:35:21 | dbs | is there a mix of opac JS (maybe from master?) and middle layer Perl (maybe from 2.1?) |
| # | 10:35:52 | dbs grasping at straws as to why open-ils.search.peer_bibs.test 404s |
| # | 10:36:07 | kivilahtio | hmm |
| # | 10:37:05 | kivilahtio | I wil lmake a new install on our production test server on a clean ubuntu server, maybe that will solve such issues. Now I have few diferent versions of eg and perl and psql on my platform |
| # | 10:37:55 | dbs | heh, process gets easier every time you reinstall :) |
| # | 10:38:16 | kivilahtio | dbs: so true. First time I tried I failed, now I did it, and maybe next time with flying colours |
| # | 10:38:31 | kivilahtio | but now I can push some stress tests on the db |
| # | 10:38:50 | kivilahtio | we will see how your search algorithm compares to Kohas ;D |
| # | 10:39:21 | phasefx | the stock algorithm. It's configurable :) |
| # | 10:39:47 | kivilahtio | yeah, so is Koha. But I think we get a nice overview with factory settings |
| # | 10:40:12 | kivilahtio | back to python::mechanize |
| # | 10:41:10 | dbs | hmm. it looks like 2.1.0-2.1.1.sql is only in the tarball, not in rel_2_1 branch |
| # | 10:42:51 | rsoulliere has joined #evergreen |
| # | 10:42:53 | dbs | It only lives in the the tags/rel_2_1_1 branch, okay - so if we need to fix it, so that a person jumping from 2.0.11 to 2.1.2 doesn't hit a bug in the existing 2.1.0-2.1.1.sql script, that doesn't really work |
| # | 10:46:56 | tsbere | I may have overlooked a "put upgrade scripts generated during make release elsewhere" step. |
| # | 10:47:18 | dbs | tsbere: no, we've always been inconsistent in our practices with upgrade scripts |
| # | 10:47:39 | tsbere | I also badly named it. Future copies will be better named. ;) |
| # | 10:48:14 | tsbere | But yea, having no docs on what to do with it I just went with "stick it in the tags/ branch" as that was the easiest solution at the time. |
| # | 10:49:10 | dbs thinks it makes sense to treat version-upgrade scripts like a base part of the schema, so if you are sitting at 2.0.4, you could check out master and apply the upgrade scripts until you're current |
| # | 10:49:38 | dbs | otherwise, right now you have to download every frickin' tarball to get the right version of the script for that particular version |
| # | 10:50:16 | dbs | maybe to avoid polluting the Pg directory we could create a version-upgrade subdirectory to hold all of the point-to-point upgrades? |
| # | 10:51:04 | tsbere | I would have no complaints there |
| # | 10:51:07 | Dyrcona | google++ :) |
| # | 10:51:46 | kivilahtio | now to integrate python to Eclipse |
| # | 10:54:36 | dbs | kivilahtio: pydev ? |
| # | 10:54:41 | kivilahtio | yup |
| # | 11:03:30 | berick | +1 for version-upgrade dir |
| # | 11:04:12 | dbs will open a bug and begin the attempt to populate said dir with the canonical versions of all existing version-upgrade scripts |
| # | 11:11:39 | phasefx | dbs++ |
| # | 11:24:47 | rsoulliere | Hi all, we are getting these errors when running the MarkItemLost action trigger: |
| # | 11:26:17 | rsoulliere | http://paste.lisp.org/display/126038 |
| # | 11:28:10 | berick | rsoulliere: does your event_definition have a group field set? |
| # | 11:29:34 | rsoulliere | I tried a few options there: usr, owner... |
| # | 11:29:44 | berick | rsoulliere: you'll want to clear the group field |
| # | 11:29:54 | rsoulliere | I then tried to leave it blank. |
| # | 11:30:28 | bshum | Does your trigger have the editor param? |
| # | 11:33:47 | rsoulliere | bshum: that might be the answer. editor should be the para? Is there a good value to use, or do I enter a user ID of anyone with the proper permissions? |
| # | 11:36:38 | tsbere | I think we set ours to run as the admin user. |
| # | 11:44:24 | bshum | Same |
| # | 11:44:29 | bshum | We set ours to 1 for the admin user |
| # | 11:44:40 | bshum | Took us awhile to solve that quirk too. |
| # | 11:44:50 | bshum | It's "documented" in the perl mod that runs the triggers. |
| # | 11:44:56 | bshum | But not really well explained elsewhere. |
| # | 11:45:10 | bshum | I think as long as the user has the permission to mark an item lost, it can do so. |
| # | 11:46:20 | pmpcat has joined #evergreen |
| # | 12:00:30 | rsoulliere | Thanks guys, I have made the suggested changes and it looks very promising. |
| # | 12:02:29 | rsoulliere | It worked! Items have been updated to status lost. Thanks! |
| # | 12:02:56 | tspindler has quit IRC |
| # | 12:04:51 | tsbere grumbles about his previous putting too many things on the same server as he prepares to move all those things....to a single server |
| # | 12:09:33 | tsbere | Huh |
| # | 12:09:50 | tsbere | I would love to know how this FTP server is working without a config file. <_< |
| # | 12:10:03 | bshum | Yay! Glad it worked rsoulliere! |
| # | 12:15:38 | dbs wonders if tsbere is running exploitmeFTPd |
| # | 12:16:16 | tsbere would rather not run ftpd at all, but routers have limited "upload my config file to..." options |
| # | 12:38:58 | bshum | For the reshelving script, it seems that we should lower the value in the .srfsh from '24h' to maybe '1h' or less if we're supposed to be reshelving faster? |
| # | 12:39:22 | bshum | Doesn't seem to be following the entry set for reshelving interval in the library settings alone. |
| # | 12:39:36 | tsbere | I thought that was supposed to be a default if there was no setting |
| # | 12:39:38 | tsbere | I could be wrong |
| # | 12:40:08 | bshum | Well, I lowered it from '24h' to '1h' and over 14k items changed statuses. |
| # | 12:40:40 | tsbere | ok |
| # | 12:44:57 | tsbere waits on multiple "first time" backups to finish on the new backup server....so that he can start other "first time" backups |
| # | 12:44:58 | dbs | bshum: O:A:Storage:Publisher:action.pm says http://pastebin.com/NmFcfDid so it looks like it's getting a NULL value for the ac.circ_lib setting |
| # | 12:45:30 | bshum | dbs: Oh... well that's weird. |
| # | 12:45:45 | dbs | err, for the setting of that name for the circ_lib for those copies |
| # | 12:46:22 | tsbere | Alternatively, do you have it set for every circ lib? Looks like it doesn't fall through. |
| # | 12:46:32 | bshum | Ah, it's set at CONS level |
| # | 12:46:33 | dbs | tsbere: that's where I was heading |
| # | 12:46:49 | tsbere | dbs: Apparently we both were going the same route ;) |
| # | 12:46:52 | bshum | 1 - circ.reshelving_complete.interval - "1 hours" |
| # | 12:46:53 | dbs | damn you and your cut to the chase :) |
| # | 12:47:12 | bshum | So they have to be distinct at the library levels to work? Yuck... :( |
| # | 12:47:34 | tsbere | bshum: You could always submit a patch to change that. <_< |
| # | 12:47:59 | dbs | zactly! |
| # | 12:48:32 | dbs | Anyone from SC Lends on channel? |
| # | 12:51:37 | tspindler has joined #evergreen |
| # | 12:54:45 | Dyrcona | That would be an easy patch. |
| # | 12:54:48 | dbs watches the IRC-to-Twitter bridge (aka bshum) in action |
| # | 12:54:53 | dbs | bshum++ |
| # | 12:54:58 | bshum | :) |
| # | 12:55:09 | dbs | Dyrcona: yes. thought of opening it and marking it as "bitesize" |
| # | 12:55:21 | bshum | Rogan might be on vacation already but figured I'd pester him on your behalf anyways ;) |
| # | 13:10:24 | tsbere keeps getting tempted to do someone else's work for them |
| # | 13:10:37 | tsbere | So far I have resisted the temptation......... |
| # | 13:11:42 | bshum | dbs: tsbere: I'll poke at that setting thing, good thing for me to learn more about how all that works. I'll write up an LP and attach once I get something going. |
| # | 13:12:28 | bshum | Have to update that file on our servers anyways, it seems we're still using the old code from before the recent change. |
| # | 13:15:00 | Dyrcona | tsbere: my work? |
| # | 13:15:17 | tsbere | Scott's. |
| # | 13:15:19 | tsbere | <_< |
| # | 13:16:07 | tsbere | Dyrcona: 90% of your work I don't *want* to touch. ;) |
| # | 13:27:00 | tecoripa has joined #evergreen |
| # | 13:28:50 | rsoulliere has quit IRC |
| # | 14:07:47 | phasefx | Dyrcona: the 008 fixer script, what are the pre-reqs for that? Would/should it work on a 2.1 system? I'm getting a funny error from OpenILS::Utils::Cronscript, "GetOptionsFromArray" is not exported by the Getopt::Long module |
| # | 14:10:55 | Dyrcona | phasefx: It should work on a master, 2.1 or 2.0 system, since it uses nothing added to Cronscript.pm that I'm aware of, but I'll look at my code again to be sure. |
| # | 14:11:27 | tecoripa has left #evergreen |
| # | 14:12:01 | dbs | Could be the version of Getopt::Long at work (ergo the version of Perl, as it's a core module) |
| # | 14:12:23 | dbs | http://cpan.uwinnipeg.ca/htdocs/Getopt-Long/Changes.html - don't know what 2.36 lines up to in terms of Perl versions |
| # | 14:12:42 | phasefx | this is perl 5.8.8 |
| # | 14:13:05 | phasefx | 2.35 for Getopt |
| # | 14:13:21 | phasefx | 2.38 is what I see on cpan |
| # | 14:14:10 | dbs | perl 5.8.8? |
| # | 14:14:12 | dbs | jeez |
| # | 14:14:16 | Dyrcona | I have 2.38. |
| # | 14:14:20 | Dyrcona | and perl 5.10.1 |
| # | 14:14:39 | phasefx | this is a redhat system I think; not real familiar with it |
| # | 14:14:53 | dbs | must be - debian lenny comes with 5.10.0 |
| # | 14:15:58 | Dyrcona | I'm pretty sure that you can update just Getopt::Long. |
| # | 14:16:21 | dbs | another nail in the community-support coffin for RHEL (5, at least) |
| # | 14:16:46 | dbs | what's the point of an enterprise stable distribution if you're manually updating half of the packages |
| # | 14:17:09 | Dyrcona | We only support Debian, Ubuntu, Fedora, and FreeBSD. :p |
| # | 14:17:52 | phasefx goes and EOL's himself |
| # | 14:18:14 | phasefx | oh, smileys :) |
| # | 14:18:38 | Dyrcona | =-O |
| # | 14:22:01 | bshum | Dyrcona++ |
| # | 14:22:44 | bshum | With his guidance I think I've got something to fix our reshelving wackiness. Tested and it looks good so far in test server and production side too. I'll add an LP and mock up all the changes into a working branch to pull in. |
| # | 14:23:01 | Dyrcona | bshum++ |
| # | 14:23:21 | Dyrcona | Welcome to the Evergreen mutual admiration society. :) |
| # | 14:23:23 | moodaepo | bshum++ |
| # | 14:24:38 | moodaepo | phasefx: Only after you've released two stable release series! |
| # | 14:25:17 | Dyrcona | moodaepo: define "stable" :p |
| # | 14:25:42 | tsbere | moodaepo: I think you are allowed to EOL unstable release series without releasing stable ones ;) |
| # | 14:25:53 | moodaepo | It's all relative man : ) |
| # | 14:25:57 | moodaepo | tsbere++ |
| # | 14:26:25 | moodaepo goes back to listening to hippy music |
| # | 14:29:17 | Dyrcona has released 1 stable series and may EOL before another is released. ;) |
| # | 14:33:51 | Dyrcona | Think I'll get myself some FreeBSD 9.0 installation media so I can try out berick's steps this weekend. |
| # | 14:34:10 | Dyrcona has a 8.0 or 8.1 disc kicking around somewhere. |
| # | 14:36:02 | Dyrcona | "Creating an installation tape"!? Seriously.... |
| # | 14:54:29 | tsbere | bshum: You may still need the btrim to remove any " from around the setting |
| # | 14:55:00 | bshum | tsbere: Easy enough to add back I think. |
| # | 14:55:02 | Dyrcona | I thought btrim only removes spaces.... |
| # | 14:55:11 | Dyrcona | so, I told him he didn't need it. |
| # | 14:55:17 | Dyrcona | hmmm.... |
| # | 14:55:55 | tsbere | btrim takes two args. The string, and the bytes to remove from the start/end |
| # | 14:56:34 | tsbere | although replacing btrim with just trim may not be a bad idea either |
| # | 14:58:11 | bshum | So, uh |
| # | 14:58:18 | bshum | Which way do you suggest I go with that? |
| # | 14:59:32 | bshum | I mean, it works without it. But I suppose we'd need them in case someone put extra quotes in the setting? |
| # | 15:00:21 | tsbere | Is your setting valid json right now? |
| # | 15:00:31 | Dyrcona | bshum: you could add extra quotes in the setting and see what happens on your test server. that would be one way to test it. |
| # | 15:01:13 | Dyrcona | oh that's right. these are supposed to be valid JSON. |
| # | 15:03:06 | tsbere stands by his "you need a trim or btrim in there" as a result ;) |
| # | 15:03:12 | dbs notes that bare integers are valid JSON, but if he recalls correctly the settings UI treats everything as strings, so double-quoting is assumed |
| # | 15:03:22 | dbs stands by tsbere |
| # | 15:05:08 | bshum | I'll make the change then and add back the btrim that was there before. |
| # | 15:05:31 | bshum | Should I make it a different commit or find some way of changing the one I made already and force pushing it? |
| # | 15:06:33 | dbs | bshum: you could commit it separately, then rebase -i to squash the two commits together and then force push it |
| # | 15:06:46 | bshum | Ah, didn't realize that. |
| # | 15:07:03 | bshum | I'll try that. |
| # | 15:07:09 | dbs | bshum++ |
| # | 15:09:24 | Dyrcona | grrr. |
| # | 15:09:29 | Dyrcona | chromium-- |
| # | 15:09:47 | Dyrcona | It won't download the FreeBSD 9.0-RC2 ISO. |
| # | 15:10:09 | Dyrcona | It gets to 502 of 502 MB and then says, Interrupted and erases the file. |
| # | 15:10:31 | Dyrcona tries wget. |
| # | 15:11:21 | dbs | wget -c ++ |
| # | 15:18:59 | collum has quit IRC |
| # | 15:28:21 | Dyrcona | wget++ |
| # | 15:28:25 | Dyrcona | Dyrcona-- |
| # | 15:28:29 | Dyrcona | sshfs++ |
| # | 15:28:35 | Dyrcona | Stupid me. |
| # | 15:28:54 | Dyrcona | Pasted the wget line into a terminal where I was logged into my workstation at the office. |
| # | 15:29:04 | akilsdonk has quit IRC |
| # | 15:41:23 | gdunbar has quit IRC |
| # | 15:44:46 | bshum | Question |
| # | 15:44:54 | bshum | There's a 2.0.12 branch for milestone in LP |
| # | 15:45:01 | bshum | But 2.0.11 hasn't been cut yet, right? |
| # | 15:45:08 | bshum | Or have I missed a release somewhere |
| # | 15:46:07 | dbs | mmm, that series milestone is my fault |
| # | 15:46:37 | bshum | Ah okay. |
| # | 15:46:53 | bshum | No problem, just was starting to panic that I had forgotten to build a 2.0.11 staff client... |
| # | 15:46:58 | dbs | I had assumed that 2.0.11 would be cut when 2.1.1 was, or thereabouts |
| # | 15:47:26 | bshum | Can you mark the 2.1.1 release as released for us actually? |
| # | 15:49:09 | dbs | bshum: done |
| # | 15:50:04 | bshum | dbs++ thanks! |
| # | 15:50:46 | bshum | I've adjusted the one bug targeted at 2.0.12 back to 2.0.11 for now. |
| # | 15:54:44 | tsbere | dbs: I think eeevil wanted me to cut 2.0.11, but I don't have anything set up for the 2.0 series |
| # | 15:55:10 | tspindler has quit IRC |
| # | 15:56:15 | dbs can't wait for 2.2 to be released + 1 month to pass so all release-cutting will be automated :) |
| # | 15:56:26 | bshum | +1 |
| # | 16:00:19 | finnx has joined #evergreen |
| # | 16:16:19 | dbs | bshum: mmm - what happens when multiple rows are returned for an OU setting in your branch? |
| # | 16:16:32 | bshum | dbs: I... didn't test that. |
| # | 16:16:37 | bshum | I suppose I could try finding out. |
| # | 16:17:01 | dbs thinks a quick fix, if there is a problem, which there probably will be, would be to append "LIMIT 1" to the new SELECT clause |
| # | 16:17:10 | bshum | There was a patch awhile back that fixed something in the function I used |
| # | 16:17:41 | bshum | http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=b1be1ab9d3f6032e76cf3b519abe21d9cc476dae |
| # | 16:17:51 | bshum | Return only one applicable OU setting value |
| # | 16:17:54 | Dyrcona | dbs: does that function return more than 1 row ever? |
| # | 16:17:57 | bshum | At least that's what the function says |
| # | 16:18:03 | bshum | *commit |
| # | 16:19:39 | Dyrcona | What's the command to check if a branch has a commit? git contains? |
| # | 16:19:59 | tsbere | git branch --contains |
| # | 16:20:12 | tsbere | But that doesn't always work. Especially on pre-git branch splits. |
| # | 16:20:22 | dbs | oh yeah - now I remember discussing that behaviour with gmcharlt :) |
| # | 16:21:32 | dbs doesn't have that fix on his production system |
| # | 16:22:25 | Dyrcona | Looks like 2.1 has the commit, but not 2.0 or master. |
| # | 16:23:00 | dbs applies fix |
| # | 16:23:06 | Dyrcona | All of my rel_2_1 branches come back when I run git branch --contains b1be1ab9d3f6032e76cf3b519abe21d9cc476dae |
| # | 16:23:29 | dbs | no, "git show dfaa0791cbffbe4d625ace9812aa4a5d33366460" is in rel_2_0 |
| # | 16:23:39 | tsbere | dbs: git show ignores branches. |
| # | 16:23:54 | tsbere | Dyrcona: I bet 2.1, 2.0, and master have different hashes |
| # | 16:24:03 | Dyrcona | yeah, most likely. |
| # | 16:24:05 | dbs | tsbere: yes, but git log Open-ILS/src/sql/Pg/020.schema.functions.sql shows that commit hash in rel_2_0 |
| # | 16:24:15 | tsbere | ok |
| # | 16:24:29 | Dyrcona | ok. so panic is over. |
| # | 16:24:32 | Dyrcona | :) |
| # | 16:24:41 | dbs apologizes for skipping "git checkout origin/rel_2_0; git log Open-ILS/src/sql/Pg/020.schema.functions.sql;" |
| # | 16:24:59 | Dyrcona | I should have run the log myself. |
| # | 16:25:04 | tsbere just goes "git log origin/rel_2_0 <file>" |
| # | 16:25:56 | dbs | tsbere is awesome |
| # | 16:26:21 | dbs always forgets where to put the branch |
| # | 16:26:48 | tsbere | dbs: Putting a -- before the file name (as an argument) tells git (whenever files and branches are allowed) to stop looking for possible branches and start looking for files. Thus, files always go on the end. |
| # | 16:26:51 | Dyrcona | Ah, but I don't see it in master. |
| # | 16:26:54 | dbs | but even with my two-step approach I confirmed it faster :) |
| # | 16:27:08 | tsbere isn't actually looking ;) |
| # | 16:27:17 | dbs | tsbere: simple, all that I have to do is remember all of that and it's simple |
| # | 16:27:18 | tsbere | I am fighting with a backup server :/ |
| # | 16:27:33 | dbs will never remember that |
| # | 16:27:36 | tsbere | dbs: "branch" comes before "file" when sorting, thus branches come first ;) |
| # | 16:27:52 | dbs might have a chance of remembering that! |
| # | 16:29:02 | Dyrcona | ok. I find it when I look at the correct file. |
| # | 16:30:21 | Dyrcona needs to copy and paste more and type/command line complete less often. |
| # | 16:31:29 | Dyrcona | tsbere: mrbackup giving you problems? |
| # | 16:32:09 | tsbere | It appears to have stopped the aptitude update. But I started that when I had it backing up the mail server in another window, so it might just be unhappy about having both happening. |
| # | 16:34:54 | Dyrcona imagines the sound of disks grinding away in the background. |
| # | 16:35:24 | _bott_ has quit IRC |
| # | 16:36:28 | _bott_ has joined #evergreen |
| # | 16:51:03 | tsbere has just noticed that there is 49 GIG of email to back up |
| # | 16:53:10 | Dyrcona | wow. that built up in a hurry. everybody must have switched to IMAP. |
| # | 16:53:42 | tsbere | We only have 46 gig of file server to keep backed up. :/ |
| # | 16:55:14 | tsbere may need to re-think the whole "turn the mail server into a VM" if only for storage space reasons |
| # | 16:56:33 | matt_carlson has joined #evergreen |
| # | 17:02:46 | dbs | tsbere: time to impose radical mailbox size limits so that everyone just goes and uses gmail :) |
| # | 17:03:29 | dbs splits |
| # | 17:03:30 | dbs has quit IRC |
| # | 17:05:39 | moodaepo | So if I create a new facet in config.metabib_field and map it in config.metabib_field_index_norm_map I presume the records need to be reingested? |
| # | 17:06:13 | bshum | Probably |
| # | 17:06:32 | bshum | Any time we've created a new field, we've had to reingest all our bibs to have them populate out. |
| # | 17:06:54 | bshum | Reingest + vacuum analyze, whatnot. |
| # | 17:11:05 | moodaepo | bshum: So use the magic spell to update/reingest right? |
| # | 17:11:27 | bshum | moodaepo: http://paste.lisp.org/display/125221 |
| # | 17:11:31 | bshum | That's what I ran last time |
| # | 17:11:37 | bshum | You may choose to break it up into smaller chunks though |
| # | 17:11:54 | bshum | If you find you have lots of records |
| # | 17:12:08 | bshum | It's very similar to the reingest script we ran after upgrading to 2.0 |
| # | 17:12:19 | bshum | You could probably tailor something out of that. |
| # | 17:12:26 | moodaepo | Right the 1.6-2.0 one |
| # | 17:15:19 | Dyrcona | If you run it in the middle of the night, it should be no big deal. |
| # | 17:15:59 | bshum | Especially over Thanksgiving holiday, right? :) |
| # | 17:16:15 | bshum | Start it in screen, leave it, go have some turkey, check it next working day. |
| # | 17:17:01 | bshum | Speaking of turkey, now I'm really leaving. |
| # | 17:17:05 | bshum | Have a good one all! |
| # | 17:18:00 | moodaepo | bshum++ |
| # | 17:23:07 | tsbere | Only a couple gig to go on the mail backup. :/ |
| # | 17:29:41 | jenny1 has left #evergreen |
| # | 17:31:52 | moodaepo | Notices that to run the reingest in 2.0.10a the schema needs to be added as noted during 2.1 upgrade testing - https://bugs.launchpad.net/evergreen/+bug/825881 |
| # | 17:48:04 | Dyrcona thinks he'll disable his IRC account for the next couple of days, but leave his other chat accounts open. |
| # | 17:48:13 | Dyrcona has quit IRC |
| # | 18:34:37 | finnx has quit IRC |
| # | 18:51:12 | matt_carlson has quit IRC |
| # | 20:08:14 | fredericd has quit IRC |
| # | 20:08:19 | fredericd has joined #evergreen |
| # | 20:10:26 | bwicksall has quit IRC |
| # | 20:41:09 | jeff yawns |
| # | 20:46:21 | pmpcat has quit IRC |
April 10-13