| # | Time | Nick | Message |
|---|
| # | 00:13:32 | pmplett has quit IRC |
| # | 00:18:38 | pmplett has joined #evergreen |
| # | 00:45:18 | Callender has quit IRC |
| # | 00:45:42 | drdata_esi has quit IRC |
| # | 00:46:55 | Dmagick has quit IRC |
| # | 00:47:00 | mtate has quit IRC |
| # | 00:47:01 | phasefx has quit IRC |
| # | 01:31:24 | phasefx has joined #evergreen |
| # | 01:56:37 | Callender has joined #evergreen |
| # | 01:57:16 | drdata_esi has joined #evergreen |
| # | 03:17:36 | Callender has quit IRC |
| # | 04:35:31 | AndyWitter has quit IRC |
| # | 04:43:36 | phasefx has quit IRC |
| # | 04:45:57 | phasefx has joined #evergreen |
| # | 05:51:47 | tsbere | @later tell bshum The version doubling would be for purposes of setting the installer tag to, say, 2.1 for folder and such when the version is 2.1.x. I can explain stopping the doubling if you want. |
| # | 05:51:47 | pinesol_green | tsbere: The operation succeeded. |
| # | 05:52:07 | tsbere | @later tell bshum Also, "make rigbeta" and "make rigrelease" work wonders for some stuff now |
| # | 05:52:07 | pinesol_green | tsbere: The operation succeeded. |
| # | 05:53:26 | Andy_ has joined #evergreen |
| # | 05:53:52 | Andy_ is now known as Guest66265 |
| # | 06:45:46 | rsinger has quit IRC |
| # | 07:05:34 | Guest66265 is now known as AndyW |
| # | 08:17:40 | remingtron has quit IRC |
| # | 08:17:52 | jenny has joined #evergreen |
| # | 08:22:43 | Petaris has joined #evergreen |
| # | 08:22:58 | kmlussier has joined #evergreen |
| # | 08:28:26 | Petaris | Morning all |
| # | 08:28:28 | Petaris | :) |
| # | 08:30:08 | Petaris | I trying to create the Evergreen db but I get an error when I issue the command "createlang plperl evergreen", the error is: createlang: language installation failed: ERROR: could not access file "$libdir/plperl": No such file or directory |
| # | 08:31:36 | Petaris | also I checked on the contrib directory and its not in /usr/share/postgresql/8.4/contrib like it should be. Do I need to create this manually or is there something wrong with my postgresql install? |
| # | 08:40:12 | tsbere | Petaris: What version of Eg you installing? |
| # | 08:40:26 | Petaris | 2.0.5 |
| # | 08:41:52 | Petaris | hrm |
| # | 08:42:19 | Petaris | does the debian squeeze postgresql build have perl enabled? |
| # | 08:42:34 | Petaris | That seems to be what google is telling me is the problem |
| # | 08:45:22 | rsinger has joined #evergreen |
| # | 08:47:48 | Petaris | tsbere: Hrm, more googling and I found this: http://open-ils.org/irc_logs/openils-evergreen/2009-08/%23openils-evergreen.19-Wed-2009.log |
| # | 08:48:13 | Petaris | Do I need to do this: 2009-08-19T11:58:24 <mrpeters-isl> did yoiu do echo "export PERL5LIB=/openils/lib/perl5:\$PERL5LIB" >> ~/.bashrc |
| # | 08:48:51 | eeevil | Petaris: no, you need to: apt-get install postgresql-plperl-8.4 |
| # | 08:49:03 | Petaris | ahh, ok |
| # | 08:49:10 | Petaris | I didn't see that in the instructions |
| # | 08:49:57 | eeevil | make -f Open-ILS/src/extras/Makefile.install install_pgsql_server_debs_84 # should have done that for you |
| # | 08:50:28 | Petaris | ahh, I didn't do that as I had already installed postgre with apt |
| # | 08:50:45 | dbs | Petaris: are you following the wiki instructions? |
| # | 08:50:55 | Petaris | yeah |
| # | 08:50:59 | Petaris | these: http://www.open-ils.org/dokuwiki/doku.php?id=server:2.0:install |
| # | 08:51:09 | dbs | Yeah. See 2. II. |
| # | 08:52:12 | dbs | alternately, if you're feeling very experimental, http://archive.georgialibraries.org/ |
| # | 08:52:28 | dbs | (for experimental DEBs for installing on Debian) |
| # | 08:52:43 | Petaris | ok, thanks dsb |
| # | 08:52:45 | dbs | Note that those DEBs are unofficial and most of us have no idea how they were created |
| # | 08:52:48 | Petaris | er, dbs |
| # | 08:53:39 | AndyW | yes these are experimental at the moment. recommend install on a fresh squeeze |
| # | 08:55:35 | kmlussier_ has joined #evergreen |
| # | 08:56:25 | kmlussier has quit IRC |
| # | 08:56:32 | kmlussier_ is now known as kmlussier |
| # | 08:59:32 | Petaris | dbs, I'm running that script now |
| # | 08:59:56 | Petaris | I guess I just mis read that note |
| # | 08:59:59 | Petaris | sorry |
| # | 09:00:19 | dbs | Easy to do |
| # | 09:02:32 | eeevil | AndyW: just putting it out there, but between the GSOC project and other interested parties, I think everyone (emerald, gpls and the community) would benefit greatly from some interaction on the DEB front ... I realize you're trying to build knowledge, but there are others that would love to /help/ that, and I'm more than a tiny bit concerned about technical decisions you're potentially making in packaging that could make your output less useful that it |
| # | 09:03:10 | tsbere | eeevil: Dunno if there was more, you ended at "useful that it" for me |
| # | 09:03:15 | eeevil | AndyW: so, consider this a gentle prod to write the -dev list, as a community member, about what you folks have been doing |
| # | 09:03:40 | eeevil | ... less useful that it might otherwise be, simply due to not having as many eyes as possible on the problem ... (thanks, tsbere) |
| # | 09:05:40 | collum has joined #evergreen |
| # | 09:05:48 | AndyW | thx we are still just in the early stages of getting the packages built. Definitely plan on doing all of that. |
| # | 09:06:07 | AndyW | I think bjwebb is going to work wiht us on it too |
| # | 09:06:48 | eeevil | AndyW: my point is, we'd all benefit from /open/ communication as early as possible. like, during the decision making period about structuring the debs, etc |
| # | 09:08:12 | Dyrcona has joined #evergreen |
| # | 09:08:21 | AndyW | understood. we plan on putting it up on git somewhere |
| # | 09:08:47 | AndyW | csharp is going to beat on that for us when he gets a chance |
| # | 09:08:50 | dbs | AndyW: bjwebb and I certainly hope we can work with you! but for him, at least, it is a requirement for all of his work to be in the open - mailing list, IRC, repository |
| # | 09:09:36 | dbs | and to the benefit of us all, as eeevil suggests (oh yeah - I'll be happy to set you up with wiki accounts if you don't already have them) |
| # | 09:09:45 | AndyW | coool that will work. |
| # | 09:10:08 | dbs | great - just pm me name, desired username, and email address and I'll hook you up |
| # | 09:10:17 | AndyW | k thx |
| # | 09:12:19 | bshum | tsbere: Ah yes, I did notice that make rigbeta step and included it during my creation of the 2.1 staff client. |
| # | 09:12:57 | bshum | I went back to find it when I noticed that the icons weren't being setup correctly. |
| # | 09:13:49 | tsbere | bshum: I try and document all of the changes I make on the page phasefx linked you to last night. What others do is a different story ;) |
| # | 09:14:06 | bshum | Heh, tsbere++ |
| # | 09:21:01 | yboston has joined #evergreen |
| # | 09:28:21 | tsbere | Question: Is there documentation as to what the check digit function is supposed to be doing? It doesn't look anything like the one we use, and in some ways looks inefficient to me. |
| # | 09:30:11 | gmcharlt | tsbere: there are multiple checkdigit algorithms that could be used; IIRC, the one in Evergreen implements the "codabar" algo |
| # | 09:30:58 | tsbere | "codabar" has no algo for that, and ours is /also/ referred to as that. |
| # | 09:31:50 | tsbere | The one there could be generating the same checksum as ours, I will have to run some tests to see |
| # | 09:33:00 | gmcharlt | tsbere: http://www.makebarcode.com/specs/codabar.html is the one I see most often |
| # | 09:33:43 | tsbere | That is what ours use. Yet that doesn't look like what exists in util/barcode.js to me. :/ |
| # | 09:36:05 | gmcharlt | tsbere: at first glance, looks like they're equivalent |
| # | 09:36:10 | mtate has joined #evergreen |
| # | 09:36:44 | gmcharlt | the util/barcode.js one just being yet another entry in the Obfuscated Codabar Checkdigit Function Contest :) |
| # | 09:36:54 | tsbere | Yea |
| # | 09:39:56 | tsbere feels that the methods he uses would generate different results on odd length barcodes than the one in util/barcode.js, though |
| # | 09:40:15 | dbs | easy to test :) |
| # | 09:40:33 | gmcharlt | test cases make the baby dbs weep... |
| # | 09:40:35 | gmcharlt | tears of joy! |
| # | 09:40:41 | tsbere | Well, my methods are harcoded to scream on anything but a 14 digit barcode. So I would have to adjust them slightly first ;) |
| # | 09:43:37 | tsbere | Hey, I was right. Even digit count in barcode, both make the same. Odd digit count, I get different answers. |
| # | 09:45:02 | dbs | heh, our system administrators just made me weep - they installed some HP tool that replace /etc/ld.so.conf the file with /etc/ld.so.conf a directory, presumably because they converted an RPM to DEB format to install on our system |
| # | 09:45:26 | dbs | Of course, that broke dynamic linking horribly. Took me a while to figure out what had happened though |
| # | 09:46:38 | tsbere sees why he gets a difference, though |
| # | 09:46:53 | bshum | dbs: Oh yes, that's a fun one. Happened to our HP servers that we use for DB. |
| # | 09:47:22 | dbs | bshum: I guess we should make it an FAQ, if it's happened to two of us it will probably happen to more |
| # | 09:47:48 | tsbere | I don't reverse the portion I am checksumming. On an odd number of digits to checksum (even length barcode) the even/odd position for doubling works out the same in both directions. On an even number of digits they are reversed.... |
| # | 09:48:30 | gmcharlt | that would do it |
| # | 09:48:36 | tsbere wonders which way is the "correct" way |
| # | 09:49:19 | gmcharlt has never heard of that checkdigit algo being applied to anything other than 14-digit barcodes, at least in library contexts, so I think we could just bake in a check on the barcode length |
| # | 09:51:15 | tsbere | I am tempted to de-obfuscate the function in barcode.js, but am not sure if the reversing is the "correct" way to do it or not. I don't have a "non-14-digit" doc set for that. |
| # | 09:51:45 | jeff | tsbere: as just another data point, all of our 14 digit item barcodes pass this test: https://gist.github.com/958974 -- you could try it for some of your odd-length barcodes? *shrug* |
| # | 09:52:34 | jeff | tsbere: i found this and some of the linked pages helpful: http://en.wikipedia.org/wiki/Luhn_algorithm |
| # | 09:52:55 | gmcharlt | or http://git.esilibrary.com/?p=migration-tools.git;a=blob;f=sql/base/base.sql;h=6d9de88b9a138f1af7965b85fcb83f08aa90c252;hb=HEAD#l674 |
| # | 09:53:50 | Petaris | When I try to generate the web files for the staff client and catalogue I get this error:Can't call method "method_lookup" on an undefined value at /usr/local/share/perl/5.10.1/OpenSRF/Application.pm line 133. |
| # | 09:54:41 | jeff saves a copy of http://www.makebarcode.com/specs/codabar.html (linked from gmcharlt's code) for later |
| # | 09:55:49 | Petaris | That line is: my $coderef = $app->method_lookup( $method_name, $method_proto, 1, 1 ); |
| # | 09:56:57 | bshum | dbs: HP tools are quirky and strange. And I spent too many days looking at forums to figure their stuff out :( |
| # | 09:58:51 | tsbere | Ok. Knowing the "correct" way to do it, I can further simplify the check. |
| # | 10:01:21 | bshum | Petaris: This error occurs during the autogen.sh process I'm guessing? |
| # | 10:02:09 | bshum | Petaris: You may find additional information in logs, but I think whenever I encounter that error, I just go back and restart all the services on my Evergreen server (stop opensrf, restart memcached, ejabberd, start opensrf) |
| # | 10:05:08 | dbs looks sideways at upei's bug report - 856 subfield $u with parentheses around a second copy of the URL? |
| # | 10:05:41 | Ilmarinen has joined #evergreen |
| # | 10:06:51 | jlamos has joined #evergreen |
| # | 10:08:09 | Petaris | bshum: Ok, I'll give that a try. I just ran it again and got a different error |
| # | 10:08:27 | dbs | Petaris: how much RAM does your VM have? |
| # | 10:09:19 | Petaris | dbs: I gave it 1 GB as I'm not running any graphical enviornment |
| # | 10:09:31 | dbs | Petaris: okay, that should be plenty :) |
| # | 10:10:20 | bshum | Eh |
| # | 10:10:23 | bshum | Maybe |
| # | 10:11:56 | jeff | dbs: two second copies of the url, with some escaped and some unescaped ampersands? Dunno... |
| # | 10:13:45 | Petaris | bshum: hrm, when I tried to restart ejabberd it failed this time |
| # | 10:13:51 | dbs | jeff: yeah, I'm going to call that out. The "Equinox thinks there's some internal limit on the length of the URL" bit makes no sense to me. It's probably just a parsing error. |
| # | 10:14:23 | Petaris | ok, I just tried doing stop and start instead of restart and it worked |
| # | 10:14:25 | Petaris | weird |
| # | 10:14:39 | bshum | Maybe there was some stale process that it didn't like. |
| # | 10:14:51 | Petaris | could be |
| # | 10:15:35 | eeevil | it's surely the fact that there are 2 URLs in there |
| # | 10:15:39 | Petaris | trying the autogen command again |
| # | 10:15:54 | Petaris | same error as last time |
| # | 10:15:57 | eeevil | ... not sure where a length diagnosis came from ... |
| # | 10:16:20 | jeff | it shouldn't break that way, but it might be something other than length. |
| # | 10:17:46 | eeevil suspects "there are two" was translated somehow to "you can only have one", which was then translated to "2 is too many" which was translated to "it's too long" |
| # | 10:18:18 | eeevil | jeff: I like your escaping theory, except that the marc editor should be escaping amps |
| # | 10:18:44 | eeevil | not to say it isn't doing something wrong... |
| # | 10:19:31 | jeff | eeevil: i was just noting that in the message as i viewed it -- which may have been mangled by both the sender and recipient's MUAs, and/or by mailman... i see a mess of escaped and unescaped. |
| # | 10:19:56 | jeff | step 1 would probably be to get an unmolested copy of the record to test with. |
| # | 10:20:00 | dbs just sent a reply to mbelvadi, didn't see jeff and eeevil's latest comments until now |
| # | 10:20:10 | dbs | jeff: luckily, the record ID is in the message |
| # | 10:20:23 | dbs | 847956 |
| # | 10:20:40 | jeff | (assuming the record was even created/saved -- the error may require manual editing to reproduce :) |
| # | 10:21:33 | dbs | http://islandpines.roblib.upei.ca/opac/en-CA/skin/roblib/xml/rdetail.xml?r=847956 |
| # | 10:21:40 | tsbere | Any thoughts on http://paste.lisp.org/display/121806 (making barcode.js more readable, IMO, maybe more efficient) ? |
| # | 10:22:53 | dbs | http://islandpines.roblib.upei.ca/opac/extras/supercat/retrieve/marcxml/record/847956 |
| # | 10:25:33 | bshum | Petaris: Hmm, that's too bad. Have you tried any of the steps listed on this page for checking for errors? http://www.open-ils.org/dokuwiki/doku.php?id=troubleshooting:checking_for_errors |
| # | 10:27:26 | bshum | Petaris: Also, maybe check to make sure ejabberd is actually running (given your problems earlier): ps -aef | grep ejabberd |
| # | 10:32:13 | Callender has joined #evergreen |
| # | 10:33:05 | Ilmarinen has quit IRC |
| # | 10:37:19 | moodaepo finishes reading scrollback |
| # | 10:38:09 | moodaepo | I still maintain the "previews" dir is a good idea |
| # | 10:38:12 | bshum gives moodaepo a thumb's up sign |
| # | 10:38:35 | bshum | I retained it for now, and updated wiki pages where I saw issues so far. |
| # | 10:38:38 | dbs | moodaepo: maybe do some fancy-pants rewrites so that old links don't break? |
| # | 10:39:03 | Petaris | bshum: ejabberd is running |
| # | 10:39:14 | Petaris | I haven't tried that page but I will look at it now |
| # | 10:39:22 | Petaris | Thanks |
| # | 10:39:29 | moodaepo | dbs: That could be one way but it's pretty easy to copy the wiki content to vi and do a find replace (which is how I update install instructions) |
| # | 10:39:55 | dbs | moodaepo: I was thinking of other links that may exist out in the wild |
| # | 10:40:00 | moodaepo goes to get some tea real quick |
| # | 10:40:05 | dbs | beyond the reach of your vi powers |
| # | 10:40:41 | moodaepo | dbs++ # ah right there maybe tools for dokuwiki to do that...or just find replace the dokuwiki/data folder : ) |
| # | 10:41:31 | dbs | moodaepo: well, or other web sites like freshmeat, ohloh, wikipedia |
| # | 10:42:13 | dbs | but then most of the links to old preview releases probably don't matter |
| # | 10:42:59 | bshum | Bleh, code_museum.... |
| # | 10:44:12 | mrpeters-isl_ has joined #evergreen |
| # | 10:46:13 | rsinger has quit IRC |
| # | 10:50:49 | dbs stares at UPDATE authority.record_entry SET active = active; and wills it to move faster over his 1M auth records so that he can restart postgresql and enable a connection from a remote server (d'oh) |
| # | 10:51:24 | berick | dbs: reload won't work? |
| # | 10:51:40 | dbs | berick: not for listenaddresses |
| # | 10:51:51 | dbs | restart required |
| # | 10:51:59 | berick | ah |
| # | 10:53:02 | mrpeters-isl_ has quit IRC |
| # | 11:00:01 | remingtron has joined #evergreen |
| # | 11:02:00 | shopkins has joined #evergreen |
| # | 11:04:15 | jeff waves to remingtron |
| # | 11:05:32 | jeff | dmagick++ |
| # | 11:08:50 | dbs | remingtron++ # good to see you in-channel |
| # | 11:09:01 | youdonotexist has joined #evergreen |
| # | 11:09:30 | gmcharlt | wordpress++ # link in kmlussier email was line-wrapped, but WP did the right thing anyway |
| # | 11:10:01 | remingtron | thanks, dbs and jeff. just getting my feet wet, so far so good. |
| # | 11:10:43 | jeff | gmcharlt: my mail client "did the right thing" here. upon testing, i see that wordpress also accepts the truncated url -- nice! |
| # | 11:12:03 | kmlussier | gmcharlt: Ah, that explains it. I thought Outlook did something special to it, which is very unlike Outlook. |
| # | 11:12:15 | Petaris | bshum: I just went through that troubleshooting page and everything went well until the autogen bit, same error as before |
| # | 11:15:41 | bshum | Hmm |
| # | 11:16:43 | bshum | I went back through the scrollback... after you corrected the postgresql packages, did it create the evergreen db properly using the eg_db_config.pl script? |
| # | 11:18:25 | bshum | Wondering if maybe something went wrong with the db creation and that's causing your undefined error. |
| # | 11:18:46 | dbs | Petaris: might also be helpful to paste error output from /openils/var/log/osrfsys.log to a pastebin |
| # | 11:19:26 | kmlussier has quit IRC |
| # | 11:19:46 | Petaris | bshum: The database seemed to create just fine |
| # | 11:19:49 | Petaris | no errors |
| # | 11:19:55 | Petaris | but who knows |
| # | 11:20:03 | Petaris | dbs, ok will do |
| # | 11:20:04 | kmlussier has joined #evergreen |
| # | 11:21:11 | dbs | huh, that's great. restarted postgresql after the authority update finished, greeted by "postgres: startup process recovering 000000010000001200000076" in the processes |
| # | 11:24:28 | Petaris | hrm, it says the paste is too big |
| # | 11:24:28 | Petaris | lol |
| # | 11:24:51 | dbs | Petaris: uh, trim it down to relevant bits (like "ERROR" lines) to start with |
| # | 11:25:19 | dbs bets that Debian's init scripts forcefully killed postgresql rather than waiting for it to shutdown cleanly. could be a long recovery. #&@*@ |
| # | 11:26:07 | Petaris | dbs, most of it is DEBG |
| # | 11:26:25 | dbs | DEBUG? huh, that's some serious logging |
| # | 11:26:32 | Petaris | as instructed on the troubleshooting page I enabled debug level logging |
| # | 11:26:41 | dbs | I would strongly recommend grepping for ERR to begin with |
| # | 11:28:10 | moodaepo | Checked freshmeat, ohloh, and wikipedia no worries about pre-release link issues at those sites. Updated wikipedia while I was there with 2.0.6 as stable release, the other two need to be updated when we get a chance. |
| # | 11:28:48 | dbs | moodaepo: cool, I think Amy had volunteered for that role on the "release team" |
| # | 11:28:58 | dbs | also blog-posting the news about new releases |
| # | 11:29:46 | bshum | Already tweeted about 2.0.6 last night ;) |
| # | 11:29:58 | moodaepo | dbs: Yea I was going to do that yesterday, but right now I really need to figure out why the new server is not processing mails to feedback/docs. |
| # | 11:30:05 | dbs | moodaepo++ |
| # | 11:30:09 | moodaepo | bshum: Hey blog that also will ya? : ) |
| # | 11:30:12 | dbs | sounds like the right priority |
| # | 11:30:20 | bshum | moodaepo: I don't have blog powers. |
| # | 11:30:25 | dbs | bshum: yeah, or create a blog post that links to the tweet for posterity |
| # | 11:30:35 | moodaepo | bshum: I am getting you one now! |
| # | 11:30:45 | moodaepo | I thought I did that during the conf |
| # | 11:30:52 | Petaris | dbs: The paste form isn't working for me. It just sits there after I hit submit |
| # | 11:31:05 | bshum | dbs: Someone retweeted my 2.0.6 tweet that I don't recognize, so folks are apparently following the hashtags or something... |
| # | 11:31:09 | dbs | Petaris: your link is on paste.lisp.org |
| # | 11:31:33 | Petaris | ok |
| # | 11:31:47 | Petaris | hrm, when I go there I get a remote server error |
| # | 11:32:25 | Petaris | anyway, can you see the paste? |
| # | 11:32:27 | dbs | bshum: some folks apparently are. perhaps I could construct a pseudo-blog composed of hashtags that could appear on the planet on the daily basis. for those poor souls who don't look at twitter |
| # | 11:32:38 | dbs | Petaris: nope, looks like paste.lisp.org is down. again |
| # | 11:32:45 | dbs | try pastebin.ca perhaps? |
| # | 11:32:55 | Petaris | ok, I'll paste it elsewhere |
| # | 11:33:22 | ChanServ changes topic to "Welcome to the #Evergreen library system channel! | We are publicly logged. | Large pastes at http://pastebin.ca or http://paste.lisp.org/new/evergreen or something like that" |
| # | 11:33:24 | bshum | dbs: Speaking of the planet, should poke moodaepo to help update the menu links on the planet page. |
| # | 11:33:37 | dbs | bshum: it's not under his control |
| # | 11:33:40 | Petaris | dbs: http://pastebin.ca/2054578 |
| # | 11:33:41 | moodaepo | bshum: dbs hosts that and I don't have access |
| # | 11:33:44 | bshum | dbs: Ah, right, that's you :) |
| # | 11:34:29 | dbs | *JSON Parser Error in pcrud is interesting |
| # | 11:35:10 | dbs | actually, in opensrf.math and open-ils.auth too. weird |
| # | 11:37:40 | Petaris | There are some "does not exist" stuff too |
| # | 11:40:13 | dbs | Petaris: you can ignore that stuff |
| # | 11:40:22 | Petaris | dbs: ok |
| # | 11:40:42 | dbs | I have no idea why you're getting JSON parser errors |
| # | 11:41:10 | dbs | It's as though something is injecting random crud into the XMPP messages that is busting JSON |
| # | 11:41:54 | dbs fears this postgres recovery is recovering the hours-long authority.record_entry update that ran just before postresql's restart |
| # | 11:42:27 | dbs | Petaris: can you paste some log messages from around the JSON Parser error messages? |
| # | 11:42:44 | Petaris | sec |
| # | 11:43:01 | Petaris | I just archived those and set the loglevel back to info |
| # | 11:43:10 | Petaris | let me see what the new log says |
| # | 11:44:21 | moodaepo has now given bshum access to blog hope that was ok (didn't ask community permission) |
| # | 11:44:38 | moodaepo | He better post something soon before they take away the powers |
| # | 11:45:00 | moodaepo | 2.0.6 and beta availability |
| # | 11:45:35 | Petaris | dbs: http://pastebin.ca/2054583 |
| # | 11:45:41 | dbs | moodaepo: I think we generally try to do at least a straw poll in IRC before granting access like that, for transparency; not that I think anyone would object to bshum being able to blog |
| # | 11:46:29 | moodaepo | dbs: I know I remembered that after the fact and decided to come clean. Apologies |
| # | 11:46:36 | dbs | Petaris: opensrf.math 2011-05-06 10:41:03 [INFO:6648:transport_session.c:667:] Received <error> message with type cancel and code 503 |
| # | 11:47:57 | dbs | sound like you have something messed up in your opensrf_core.xml or ejabberd config, maybe a wrong username/password combo for one of the opensrf or router public or private domains |
| # | 11:48:37 | Petaris | dbs: Ok, I'll check the usernames and passwors |
| # | 11:48:40 | Petaris | er, passwords |
| # | 11:50:50 | dbs | Petaris: also ensure that you made all of the required changes to ejabberd.cfg (like number of concurrent user logins) |
| # | 11:54:31 | yboston | Hello, question about OpenSRF download URLs vs EG download URL capitalization... |
| # | 11:54:37 | yboston | Right now the stable OpenSRF tar.gz file is named with all lowercase letters, but the EG tar.gz is mixed case |
| # | 11:54:44 | yboston | I am planning to submit a patch to the official EG documentation to change an OpenSRF download link that is broken because it is using mixed case |
| # | 11:55:05 | yboston | example: http://docs.evergreen-ils.org/2.0/draft/html/upgradingevergreen-upgradingOpenSRF.html |
| # | 11:55:14 | yboston | I wanted to know if there was any plans to change the OpenSRF download file back to mixed case, or if I should continue to make the documentation point to the OpenSRF all lowercase file name? |
| # | 11:55:37 | dbs | yboston: I plan to keep the OpenSRF download link all lowercase for any releases I make |
| # | 11:56:10 | yboston | dbs: THanks, just making sure. I will update the EG documentation accordingly |
| # | 11:56:52 | dbs | yboston++ |
| # | 11:57:38 | AndyW | That will be great for building debs as the deb system complains about "package not in lower case" |
| # | 11:58:27 | AndyW | also for Evergreen-ILS -> evergreen-ils |
| # | 11:59:32 | dbs | AndyW: that's actually why I switched the OpenSRF tarballs to lowercase |
| # | 11:59:48 | AndyW | this is great |
| # | 12:00:00 | AndyW | one less step to building the debs |
| # | 12:00:40 | dbs | AndyW: please open bugs on bugs.launchpad.net/evergreen with packaging-related requirements - so that, say, for 2.1 final release perhaps Evergreen can move to evergreen-ils.2.1.0.tar.gz |
| # | 12:01:40 | jlamos | oh, speaking of which, random curiosity: why is it evergreen-ils and not just evergreen? |
| # | 12:01:49 | Petaris | dbs: both files checked and ok |
| # | 12:02:10 | dbs | jlamos: because there are bazillions of "evergreen" things out there |
| # | 12:02:38 | jlamos | k, just wondering if there was a specific software conflict |
| # | 12:06:23 | bradl | that's why we should have called it what I wanted to call it from the beginning: turpentine |
| # | 12:07:04 | Petaris | dbs: Could it be the JSON perl module |
| # | 12:07:05 | Petaris | ? |
| # | 12:07:20 | dbs | Petaris: perhaps. did you have a problem installing it? |
| # | 12:07:41 | dbs | (although that seems unlikely, as the errors are coming from C services) |
| # | 12:07:58 | Petaris | no, not that I recall |
| # | 12:09:34 | kmlussier has quit IRC |
| # | 12:10:47 | Petaris | dbs: I'm going to try rebooting the machine |
| # | 12:11:04 | Petaris | I tried stopping ejabberd and it said it stopped but still showed a process |
| # | 12:11:16 | Petaris | I tried to kill it and it just came back with no process found |
| # | 12:11:24 | Petaris | but ps -aef still showed it |
| # | 12:11:25 | dbs | Petaris: hmm, good luck |
| # | 12:11:46 | Petaris | maybe a zombie process in there |
| # | 12:12:01 | Petaris | nothing was in /var/run/ejabberd/ either |
| # | 12:12:46 | dbs | was it epmd or beam? |
| # | 12:12:59 | Petaris | epmd I think |
| # | 12:13:04 | dbs | I think it's normal for epmd to hang around |
| # | 12:13:08 | Petaris | ahh, ok |
| # | 12:13:23 | Petaris | still doesn't explain why it wasn't killable |
| # | 12:13:37 | dbs | you could always change the logging level for ejabberd and watch /var/log/ejabberd/ejabberd.log for anything interesting |
| # | 12:14:37 | senator | http://www.ejabberd.im/epmd |
| # | 12:14:56 | senator | before i figured that out i always kill -9'd epmd like a bad admin :-( |
| # | 12:15:24 | Petaris | senator: ahh, ok |
| # | 12:20:01 | Petaris | I'm running through the troubleshooting guide again |
| # | 12:20:09 | Petaris | see if anything is different |
| # | 12:20:27 | moodaepo | Petaris: That is mentioned in our OpenSRF installation docs...maybe one should add it into the troubleshooting guide. |
| # | 12:20:32 | moodaepo <-- one |
| # | 12:20:40 | rsinger has joined #evergreen |
| # | 12:21:25 | dbs | Petaris: did OpenSRF work on its own (the opensrf.math 2, 2 test), before you installed Evergreen? |
| # | 12:22:30 | Petaris | yep |
| # | 12:22:38 | Petaris | and I did try that again, and it did work again |
| # | 12:25:51 | Petaris | ok, I have stopped, and verified they are stopped, all the relevant services |
| # | 12:26:00 | Petaris | I then archived all log files |
| # | 12:26:12 | Petaris | Now starting them up one at a time |
| # | 12:26:30 | Petaris | order: apache2, ejabberd, memcached |
| # | 12:26:47 | Petaris | Going to walk through starting OpenSRF one bit at a time |
| # | 12:28:53 | Petaris | hrm, before I even start that there are two files in /openils/var/log named gateway.log and osrfsys.log that have new error messages, even though OpenSRF hasn't been started |
| # | 12:29:03 | Petaris | maybe, because it hasn't been started |
| # | 12:29:11 | Petaris | but just to check |
| # | 12:30:20 | Petaris | in gateway.log I am seeing this a bunch: gateway 2011-05-06 11:21:18 [INFO:1713:osrf_system.c:628:] Bootstrapping system with domain public.localhost, port 5222, and unixpath (none) |
| # | 12:30:20 | Petaris | gateway 2011-05-06 11:21:18 [WARN:1713:socket_bundle.c:362:] socket_open_tcp_client(): Cannot connect to server public.localhost: Connection refused |
| # | 12:31:23 | Petaris | In osrfsys.log I am seeing this, over and over: [2011-05-06 11:21:18] /usr/sbin/apache2 [ERR :1713:EX.pm:66:] Exception: OpenSRF::EX::Jabber 2011-05-06T11:21:18 OpenSRF::Transport::SlimJabber::Client /usr/local/share/perl/5.10.1/OpenSRF/Transport/SlimJabber/Client.pm:145 Jabber Exception: Could not open TCP socket to Jabber server: IO::Socket::INET: connect: Connection refused |
| # | 12:32:17 | Petaris | neither log files seems to be adding anything new now |
| # | 12:33:06 | dbs | probably because apache is still running |
| # | 12:33:44 | dbs | once you install OpenSRF and set up your apache config files, apache gets upset if the opensrf stack isn't running |
| # | 12:34:06 | Petaris | ahh, ok |
| # | 12:34:48 | Petaris | I'm going to start loading OpenSRF one piece at a time |
| # | 12:34:52 | Petaris | see what happens |
| # | 12:36:29 | Petaris | hrm, I just tried starting router but it said it was already started |
| # | 12:36:32 | Petaris | but I never started it |
| # | 12:37:26 | moodaepo | Petaris: Just to note - the order to stop is Apache > Evergreen/OpenSRF > memcached > ejabberd. The start order is then the reversed. |
| # | 12:37:52 | Petaris | ok, thanks moodaepo |
| # | 12:38:30 | dbs | Petaris: if the router died (say, because ejabberd was killed before osrf_ctl.sh -a stop_router was issued), then a PID file will hang around confusing osrf_ctl.sh |
| # | 12:38:49 | Petaris | dbs, ok |
| # | 12:38:51 | dbs | (at least until opensrf 2.0, which has a nice patch from joe lewis to make osrf_ctl.sh smarter) |
| # | 12:38:58 | Petaris | I don't think that was the case but maybe |
| # | 12:47:57 | Petaris | dbs: This time autogen ran successfully |
| # | 12:48:06 | dbs | huzzah |
| # | 12:48:09 | Petaris | who knows what the issue was though |
| # | 12:48:25 | Petaris | it kind of bothers me as I didn't "fix" anything |
| # | 12:48:27 | Petaris | :/ |
| # | 12:48:54 | pmplett has joined #evergreen |
| # | 12:50:12 | dbs suspects a problem in start/stop order |
| # | 12:50:49 | tsbere | eeevil: You way want to note for the future that the product tag thing in windowssetup.nsi should probably just be "2.1" instead of "2.1whatever". The version (pulled from README by default) will be the more specific piece afterwards. |
| # | 12:51:09 | tsbere would actually recommend just doing that to the rel_2_1 branch now |
| # | 12:51:32 | Petaris suspects a zombie process |
| # | 12:52:03 | Petaris | Before the reboot I tried stopping everything and starting in the right order and it didn't help |
| # | 12:52:16 | Petaris | same procedure after the reboot, and now it works |
| # | 12:53:29 | dbs | Petaris: okay, never seen that myself but as long as it works |
| # | 12:53:45 | dbs | The_IT_Crowd++ |
| # | 12:54:34 | Petaris | dbs: Who knows but your right, at least its working |
| # | 12:57:23 | tsbere | bshum: Aside from not knowing about rigbeta/rigrelease, did you run into any other gotchas during setting up the installer that I might be able to improve upon? |
| # | 12:57:42 | bshum | Sure |
| # | 12:57:58 | bshum | tsbere: It was pretty silly that I hadn't actually installed nsis first ;) |
| # | 12:58:09 | tsbere already documented that issue |
| # | 12:58:17 | Petaris | dbs: Well if it didn't start working soon I would have had to toss it away like yesterdays jam ;) |
| # | 12:59:17 | bshum | tsbere: There are some warnings about not finding the extras.nsi file, but that seems to be safely ignorable. |
| # | 12:59:26 | tsbere | bshum: Think it is worth putting in an attempt to detect if nsis is there with a "wait, you may want this first"? |
| # | 12:59:40 | bshum | tsbere: I did get a new "Variable "MUI_TEXT" not referenced or never set, wasting memory!" message |
| # | 13:00:11 | tsbere | I could make the extras.nsi warnings go away with some extra makefile stuff. And that MUI_TEXT is from the graphical piece of the installer, you didn't have permachine, automatic updates, or devbuild active. |
| # | 13:00:21 | bshum | Aha |
| # | 13:00:35 | eeevil | tsbere: so, just: !define PRODUCT_TAG "2.1" |
| # | 13:01:08 | tsbere | eeevil: Yea. Then the installer will be slightly less redundant. blah 2.1 2.1-beta1 or 2.1 2.1.0 instead of 2.1-beta1 2.1-beta1 ;) |
| # | 13:01:27 | eeevil | righto |
| # | 13:02:13 | tsbere | bshum: The MUI_TEXT warning has to do with not having options for parts. I don't show that screen at all if there is nothing to check off. The instant you devbuild, permachine, or activate automatic updates that screen shows up. |
| # | 13:02:32 | bshum | Ah okay |
| # | 13:02:58 | bshum | I originally used devbuild but then stopped using it on subsequent runs |
| # | 13:03:00 | bshum | That explains that |
| # | 13:03:48 | tsbere | If you personally want to stop seeing the extras.nsi warning just "touch extras.nsi" and it will be including an empty file ;) |
| # | 13:04:30 | tsbere could also just add that to the makefile, causing the make process to create the file if it isn't there and then move on to the installer |
| # | 13:07:09 | collum has quit IRC |
| # | 13:07:41 | bshum | tsbere: Writing a more friendly failure is nice, but eh, I wouldn't worry about it. For those of us using this process, we ought to just have it documented somewhere in the instructions that nsis is supposed to be installed first. Or have it be part of Evergreen 2.1 generally |
| # | 13:08:15 | bshum | Have you seen any strange line formatting with the installer screen? |
| # | 13:08:51 | bshum | For example, in mine, the initial title that I'm installing Evergreen 2.1-beta1 2.1-beta1 seems to leave some part of the line obscurred in the area below |
| # | 13:09:02 | tsbere | bshum: No. As for documenting, have you read the "Packaging the staff client" section? Specifically the windows part? http://evergreen-ils.org/dokuwiki/doku.php?id=mozilla-devel:building_the_staff_client#windows_client |
| # | 13:09:23 | tsbere | Well, unless you count "Evergreen Staff Client <tag> <version>" being too long |
| # | 13:09:24 | tsbere | ;) |
| # | 13:10:08 | bshum | Firing up my Windows VM to see if I can get a screenshot |
| # | 13:11:10 | bshum | Yeah, it's definitely obscuring something |
| # | 13:11:55 | bshum | "Welcome to the Evergreen Staff Client 2.1-beta1 2.1-beta1 Setup"... and then you can see the tips of another word underneath |
| # | 13:11:59 | bshum | Wizard? |
| # | 13:12:20 | bshum | The text of the paragraph underneath is blocking that word |
| # | 13:12:40 | bshum | Guessing due to length of that string as you indicated |
| # | 13:14:11 | tsbere | I am working on removing the product tag from that part entirely. |
| # | 13:14:29 | bshum | +1 to that |
| # | 13:16:25 | bshum | Other than that I think it all made sense to me. |
| # | 13:16:46 | bshum | I had to re-read the paragraphs about BUILD_ID vs. STAMP_ID a couple times |
| # | 13:16:54 | bshum | But it was late last night |
| # | 13:20:08 | bshum | Assuming that STAMP_ID is the one we care about, if only to make sure it matches up with what's on server side? |
| # | 13:20:39 | dbs | eeevil: would you mind if i moved http://evergreen-ils.org/dokuwiki/doku.php?id=scratchpad:build-cutting under dev:release_process:evergreen ? |
| # | 13:20:57 | Petaris | Is there a special port that the staff client uses? |
| # | 13:21:08 | jeff | Petaris: 80/tcp and 443/tcp |
| # | 13:21:15 | dbs | And then I would move http://evergreen-ils.org/dokuwiki/doku.php?id=dev:rolling_a_release to dev:release_process:opensrf and have a nice dev:release_process page pointing to each |
| # | 13:21:17 | Petaris | jeff, ok thanks |
| # | 13:21:19 | jeff | Petaris: so, nothing that special. |
| # | 13:21:38 | Petaris | yeah, I just am trying to figure out why I can't login from the client |
| # | 13:21:40 | dbs | then maybe bshum/tsbere could integrate the staff-client instructions into the dev:release_process:evergreen page |
| # | 13:21:47 | Petaris | but it can wait until after lunch |
| # | 13:22:15 | dbs bets admin-user / admin-pass |
| # | 13:22:40 | Petaris | they work with srfsh |
| # | 13:22:50 | dbs | gmcharlt++ |
| # | 13:23:02 | dbs | Petaris: restart apache again? |
| # | 13:23:13 | tsbere | bshum: 2.1 cares about different things that 2.0 and before. I assume that is some of the confusion. The 2.1 readme for setup is different on the make install step as a result. 2.0 and before say build id there, 2.1 (and later) say stamp id there. |
| # | 13:23:49 | kmlussier has joined #evergreen |
| # | 13:23:50 | dbs | cool. dev:release_process:evergreen:2.0 vs. dev:release_process:evergreen:2.1 then! |
| # | 13:24:11 | Petaris | dbs, that didn't work either. Anyway lunch time |
| # | 13:24:18 | Petaris | talk to you guys in a bit |
| # | 13:24:19 | dbs | idea being that all steps should be documented as granularly as possible so that we can automate as much as possible |
| # | 13:24:25 | bshum | tsbere: Good call... the 2.1 wiki steps do not clarify that distinction. I'm starting to see the merits of dbs' suggestion to consolidate all these install steps... |
| # | 13:25:29 | dbs | (not to mention make it possible for other people to take over release duties... poor eeevil) |
| # | 13:28:47 | tsbere | Which do we prefer there? "Evergreen Staff Client <version> Setup", "Evergreen Staff Client <tag> Setup", or just "Evergreen Staff Client Setup"? Examples for the first couple: Evergreen Staff Client 2.1-beta1 Setup, Evergreen Staff Client 2.1 Setup |
| # | 13:29:15 | bshum | I like version. |
| # | 13:29:44 | tsbere | The title bar will still be verbose, though. |
| # | 13:32:34 | eeevil | dbs: move away, sir |
| # | 13:34:02 | tsbere | While I am in here, we want to change the text on the welcome page at all? |
| # | 13:34:35 | bshum | Hmm |
| # | 13:35:07 | bshum | It seems okay to me, but others should read it I guess. |
| # | 13:35:52 | tsbere | Take note it is currently the default 100% and will adjust according to language. I am actually breaking the ability for it to translate the word "Setup" in the title by forcing it to be something else, I thik. |
| # | 13:36:37 | tsbere could also just skip the word Setup in the title of the welcome page entirely |
| # | 13:37:43 | tsbere | s/thik/think/ <_< |
| # | 13:42:52 | dbs | okay, moved to http://evergreen-ils.org/dokuwiki/doku.php?id=dev:release_process |
| # | 13:42:57 | tsbere | bshum/dbs/eeevil: Any thoughts on dropping the word "Setup" from that point in the installer? |
| # | 13:43:27 | pmplett has quit IRC |
| # | 13:43:30 | dbs | tsbere: I almost never see the installer, so am not a very good person to ask |
| # | 13:44:50 | bshum | tsbere: From the title at the top? Or you mean within the body of the text? |
| # | 13:45:11 | tsbere | bshum: From the previously too-long line-wrapping title at the top. |
| # | 13:45:17 | bshum | Oh that thing |
| # | 13:45:49 | tsbere | The one I am already working on making shorter ;) |
| # | 13:46:53 | bshum | tsbere: A suggestion from the floor is to replace the words "Setup Wizard" in there with "Install Wizard" |
| # | 13:47:09 | bshum | If only so that people don't worry so much that there's actual "setup" involved, but just installing |
| # | 13:48:11 | tsbere | issue with that, thinking about it, is having to put the entire thing into the installer script. If I am only changing one word it isn't worth it ;) |
| # | 13:48:27 | bshum | Heh |
| # | 13:49:53 | tsbere | Removing the big bold "Setup" at the top is doable, though. |
| # | 13:50:45 | tsbere suspects very few people ever read the normal sized text anyway |
| # | 13:51:33 | dbs can't remember - can you have a 1.6 client and a 2.0 client installed via the normal installer on the same machine at the same time? |
| # | 13:51:39 | gmcharlt | dbs: yep |
| # | 13:51:54 | dbs | excellent |
| # | 13:52:09 | tsbere | And 2.1 doesn't know anything about either's installer ;) |
| # | 13:52:41 | gmcharlt | the real question is, who here has ended up having *every* client version between 1.4 and present installed on their computer ;) |
| # | 13:54:25 | tsbere | At once? Or one by one? ;) |
| # | 13:54:32 | christoph_ has joined #evergreen |
| # | 13:55:07 | tsbere can't claim either, not having had a computer with 1.4 and 1.6 clients on it |
| # | 13:55:58 | gmcharlt is uncomfortable close to all them all installed simultaneously |
| # | 13:57:30 | berick | gmcharlt: let me know if you want me to install the alpha opac on any of your test servers |
| # | 13:57:35 | bshum | tsbere: So wait, when you remove the Setup in bold, that'll move the Wizard back into the line right? |
| # | 13:57:46 | gmcharlt | berick: aiieeee! |
| # | 13:58:12 | tsbere | bshum: I think without the "remove Setup", just removing the tag fixes that. Removing the setup in addition will pretty much guarantee it. |
| # | 13:58:36 | bshum | tsbere: So the line would just be "Welcome to the Evergreen Staff Client 2.1-beta1 Wizard"? |
| # | 13:59:09 | bshum | Cause that seems strange now :) |
| # | 13:59:24 | tsbere | Wait, it says "Wizard" by default too? |
| # | 13:59:32 | bshum | http://imageshack.us/photo/my-images/638/screenshotup.png/ |
| # | 13:59:34 | tsbere didn't save a copy of the default before trying the new |
| # | 13:59:48 | bshum | Is what I've been looking at. |
| # | 14:00:06 | tsbere | How about I just set it to "Evergreen Staff Client <version>" WITHOUT all of the welcome to wrapping? |
| # | 14:00:09 | bshum | Been guessing that last word in the bold title is "Wizard" |
| # | 14:00:46 | tsbere | Oh, cool, I made the MUI_TEXT warning go away too |
| # | 14:03:51 | rsinger has quit IRC |
| # | 14:04:09 | christoph_ | db upgrade from 1.6.0.3 to 1.6.0.4 script seems to have an error, as no default tsearch configuration exists, it seems to be fixed insofar to that error by doing CREATE TEXT SEARCH CONFIGURATION public.default ( COPY = pg_catalog.english ); |
| # | 14:05:00 | justin_hopkins has joined #evergreen |
| # | 14:05:02 | christoph_ | Now I'm getting another error: psql:Open-ILS/src/sql/Pg/1.6.0.3-1.6.0.4-upgrade-db.sql:100: ERROR: duplicate key value violates unique constraint "materialized_simple_record_pkey"....any suggestions asto how to fix it? |
| # | 14:06:31 | bshum | tsbere: I guess it says that because that's what it's always said in recent times. The welcome part |
| # | 14:06:41 | bshum | Or at least, it's like in that in the 2.0 installers |
| # | 14:07:02 | tsbere | bshum: No, it says that because NSIS does that by default. |
| # | 14:07:46 | bshum | Eh, I kind of like the "Welcome" part. It seems more friendly :) |
| # | 14:08:12 | bshum | Or maybe I'm so used to seeing it that not seeing it seems unfriendly... |
| # | 14:08:33 | tsbere | Well, stripping off the tag means it won't translate. Should I just kill the alternate translations too? (Does anyone ever use the other two languages I left in there from the template I used?) |
| # | 14:08:59 | dbs | christoph_: you might want to look at the upgrades leading up to 1.6.1.0 and consolidate the bits that update one another, if you're comfortable with SQL |
| # | 14:12:55 | Petaris | Does the staff client care about the hostname? I have the machine entered as its real hostname in the staff client, but everything in the setup was set to localhost |
| # | 14:16:00 | christoph_ | dbs: I thought I should go through all the steps from 1.6.0.0 to 1.6.1.8 and and then a bigger script. what do you mean with consolidate the bits that update one another? |
| # | 14:17:38 | dbs | christoph_: you may find that 1.6.0.5 has a fixed version of whatever broke in the 1.6.0.4 script |
| # | 14:18:12 | christoph_ | dbs: I also noticed that the upgrade files of lower versions are in the evergreen tar-ball. could I also download the highest version and let all the upgrade scripts work through my database instead of going through the different upgrade wikis? |
| # | 14:18:29 | dbs | (this happened a lot in 2.0.x so far, which is why I consolidated all of the 2.0.x updates into the 1.6.1-2.0 upgrade script in place - customized for our instance) |
| # | 14:19:11 | dbs | christoph_: yes, that's the idea. Although unfortunately it seems that sometimes the version of the upgrade script in a given tarball doesn't match the script in a different tarball |
| # | 14:21:27 | mrpeters-isl_ has joined #evergreen |
| # | 14:22:52 | christoph_ | dbs: does that mean that I still can download the 1.8.0.8 or even to 1.6.1.8 and do all the upgrade scripts? and after this the mentioned 1.6.1.-2.0 scipt? |
| # | 14:23:50 | tsbere | bshum: So far I have made the makefile yell if you win-client without makensis, win-xulrunner yell if you don't have unzip, eliminated the extras.nsi and MUI_TEXT warnings, and adjusted the welcome page title. Anything else before I commit this and push? |
| # | 14:24:44 | dbs | christoph_: yes, that should work |
| # | 14:25:03 | dbs | (again, subject to the "the same script is different in different tarballs" |
| # | 14:26:22 | christoph_ | dbs: thanks, I'll try that now |
| # | 14:29:23 | mrpeters-isl_ has quit IRC |
| # | 14:30:06 | bshum | tsbere: Sounds pretty great to me so far. We'll see what else shakes loose when more eyes get on it. |
| # | 14:34:17 | tsbere | bshum: Think I should have it yell if it doesn't find xulrunner-stub.exe and evergreen.ico in the right places? |
| # | 14:34:44 | bshum | tsbere: Sure, what are the right places supposed to be? :S |
| # | 14:35:12 | tsbere | bshum: Ideally, if you don't have them, I prompt "you should really run 'make rigbeta' or 'make rigrelease'" ;) |
| # | 14:35:37 | tsbere | It will put them in the right places |
| # | 14:36:47 | justin_hopkins has quit IRC |
| # | 14:41:57 | mrpeters-isl has joined #evergreen |
| # | 14:49:42 | tsbere | phasefx: You around? My installer branch could use a cherry-picking ;) |
| # | 14:50:05 | tsbere | (or anyone else who cares to, I guess) |
| # | 14:50:20 | pmplett has joined #evergreen |
| # | 14:51:33 | bshum | tsbere: Ahh, that explains how those magically appeared in my directory then. |
| # | 14:53:50 | tsbere | I am aiming for this to become as easy as possible. Just because *I* like easy ;) |
| # | 14:55:55 | bshum | tsbere++ |
| # | 14:59:40 | mrpeters-isl has left #evergreen |
| # | 15:00:45 | justin_hopkins has joined #evergreen |
| # | 15:03:49 | shopkins has quit IRC |
| # | 15:26:39 | phasefx | tsbere: will look |
| # | 15:26:41 | christoph_ is now known as natschil |
| # | 15:27:07 | phasefx | anyone know off-hand if the 852 holdings format for vandelay, $z status expects an id or a string? $z 0 versus $z Available |
| # | 15:27:20 | natschil | I ran all the upgrade scripts up to the 1.6.1.7 to 1.6.1.8 ignoring all errors that related to duplicate key constraints, and all of them went somewhat fine except for the last one, which said this: |
| # | 15:28:20 | natschil | psql:1.6.1.7-1.6.1.8-upgrade-db.sql:64: ERROR: cannot change name of view column "xact_start" to "billing_location" |
| # | 15:28:44 | natschil | any suggestions as to whether it's dangerous or not.... I looked at the sql code, but I couldn't make heads or tails to as to why I got this error. |
| # | 15:32:31 | Dyrcona | think I have another metabib indexing bug, but I need to do some more digging to be sure. |
| # | 15:38:52 | dbwells | phasefx: hard for me to recall the reason or the history, but we have $k as the status, and it is a string |
| # | 15:40:14 | phasefx | dbwells: thanks |
| # | 15:40:54 | natschil | btw, anyone know why all of the upgrade scripts are full of inserts that were made before? I mean, there's no point inserting some configuration into a table if a previous eg version already has done that, right? |
| # | 15:44:04 | tsbere | natschil: In theory they haven't been made before. Which is why they should be in an upgrade script. |
| # | 15:44:19 | tsbere | But if you manually applied backported patches in the past.... |
| # | 15:44:42 | Dyrcona | Ah. Never mind. Upon further inspection: PEBKAC. |
| # | 15:45:02 | natschil | tsbere: that's really weird though... as I had a "normal" 1.6.0.0 running here, and I'm still getting all those errors. |
| # | 15:46:23 | natschil | anwho, I'm going to leave this computer now, and let christoph_ back on... |
| # | 15:46:23 | tsbere | natschil: Which upgrade script(s) are you running? |
| # | 15:46:28 | natschil is now known as chts |
| # | 15:46:32 | chts is now known as natschil |
| # | 15:47:12 | natschil | tsbere: the ones in the Open-ILS/src/sql/Pg folder that look like version1-version2.sql |
| # | 15:47:21 | natschil is now known as christoph_ |
| # | 15:50:46 | Petaris has left #evergreen |
| # | 15:54:44 | moodaepo | Any objections to setting up piwik as our new site statistics monitor/analyzer? |
| # | 15:55:30 | tsbere wasn't aware there was an existing statistics monitor/analyzer. Or at least a public one, if there is. |
| # | 15:56:30 | moodaepo | tsbere: Till last week > http://evergreen-ils.org/webalizer/ |
| # | 15:56:46 | tsbere | Ahhh. See, I hadn't known that. |
| # | 15:56:56 | tsbere | Then again, I am not sure I cared either ;) |
| # | 15:57:01 | moodaepo | Right : ) |
| # | 15:57:18 | tsbere is more concerned with the actual ILS code than the website stats |
| # | 15:57:58 | moodaepo | Most definitely, it is not like we are selling/having a marketing campaign but it's nice to have |
| # | 15:58:37 | bshum | moodaepo: +1 to piwik. I've found it to be very interesting so far. |
| # | 15:59:49 | tsbere | I figure it is someone else's job to worry about website stats. Oh, look, you are worrying about website stats! Must be your job! ;) |
| # | 16:00:12 | gmcharlt | heh |
| # | 16:01:43 | dbs | tsbere++ |
| # | 16:02:23 | dbs | piwik stands for "Privacy Invasion ...." ? |
| # | 16:02:44 | moodaepo | Well in other news mail for feedback and docs @evergreen-ils.org seems to be working, I went the easy route and replaced exim4 with postfix |
| # | 16:03:23 | dbs | (kidding, +1 to something google-analytics-like but being under our control) |
| # | 16:03:33 | moodaepo | Privacy Invasion With Intrusive Kookies |
| # | 16:04:05 | moodaepo | and javascript |
| # | 16:22:41 | kmlussier has quit IRC |
| # | 16:25:39 | christoph_ | Hi, does anyone know what the errors that natschil posted earlier mean? |
| # | 16:31:03 | tsbere | The cannot change name of view error? THAT would be a typo in the upgrade script. |
| # | 16:31:20 | tsbere | me hadn't noticed that line before he looked at his scrollback |
| # | 16:31:40 | tsbere | ... |
| # | 16:31:46 | tsbere wants to know where his / went |
| # | 16:37:45 | justin_hopkins | gmcharlt: We should have server access for you guys any time now. I wanted to discuss which Evergreen version to install. Got time? |
| # | 16:38:07 | christoph_ | tsbere: how would I fix this typo? |
| # | 16:38:30 | tsbere | christoph_: No clue. I do not (currently) deal with the combined upgrade scripts. |
| # | 16:40:10 | moodaepo | tsbere: I know you care about more important things but look shiny pretty web 5.0 and more : ) > http://evergreen-ils.org/piwik/ |
| # | 16:40:37 | tsbere | web 5.0? WHAT HAPPENED TO 3 AND 4? :P |
| # | 16:41:10 | moodaepo | tsbere++ |
| # | 16:42:15 | bshum | moodaepo: I want to just sit here and click refresh a billion times waiting for more countries to fill in the colors :) |
| # | 16:42:40 | bshum | Speaking of which, huzzah, first Canada hit |
| # | 16:42:43 | hopkinsju has joined #evergreen |
| # | 16:42:56 | moodaepo | bshum: I don't think you need to his refresh : ) |
| # | 16:43:01 | justin_hopkins has left #evergreen |
| # | 16:43:08 | bshum | moodaepo: I know ;) |
| # | 16:46:10 | dbs | christoph_: I'm not sure if there have been any bug reports about the 1.6.1.8 upgrade script on bugs.launchpad.net/evergreen or on the mailing list |
| # | 16:46:24 | hopkinsju | gmcharlt: I switched users/irc clients, but I'm still here. |
| # | 16:47:05 | dbs | but it wouldn't surprise me if there are bugs; we don't have any automated tests or particularly stringent manual tests for testing upgrade scripts, so it has been a roll of the dice each release |
| # | 16:56:01 | gordonja has joined #evergreen |
| # | 16:56:07 | christoph_ | dbs: no bug reports there.... seeing that there are so many upgrade scripts that all produce errors here, and I am not at all familiar with sql at all, is there some other backup and restore mechanism i could use to transfer data from one server running old evergreen to a new server running new evergreen? |
| # | 16:56:30 | christoph_ | dbs: with data I mean mainly the books that are in the system, not the users or anything like that. |
| # | 16:56:58 | moodaepo | christoph_: You could dump the marc data and import it into the new server |
| # | 16:57:53 | dbs | I suspect christoph_ would want holdings information at the very least (call numbers and copy barcodes) |
| # | 16:58:12 | hopkinsju | gordonja: Hey |
| # | 16:58:57 | dbs | hopkinsju: I recommend 2.0.6 :) |
| # | 16:58:58 | christoph_ | dbs: moodaepo: yes that's true, call numbers and barcodes are important |
| # | 16:59:57 | hopkinsju | dbs: Yes, but we are implementing a library that really wants a faster OPAC experience. I was talking with Bill at the conference and I'm wondering if we should look at 2.1 |
| # | 17:00:03 | dbs | christoph_: depending on which version of Evergreen you're on (heh), an export will probably provide those for you, and an import into 2.0.6 should recreate them, but there is still some pain |
| # | 17:00:23 | jlamos | the services starting order is ejabber, memcache, opensrf, apache2 correct? |
| # | 17:00:30 | dbs | hopkinsju: bleeeeeeding edge eh? |
| # | 17:00:55 | dbs | jlamos: postgresql goes in with ejabberd and memcached |
| # | 17:01:11 | christoph_ | dbs: 1.6.0.0. to 2.0.5. |
| # | 17:01:37 | hopkinsju | dbs: Well yeah, the thinking is that if we go with 2.1 it might help speed along the development of the OPAC improvements |
| # | 17:01:47 | jlamos | so really ejabberd == memcached == postgres > opensrf > apache2? |
| # | 17:02:00 | dbs | jlamos: yep |
| # | 17:02:44 | dbs | hopkinsju: I guess that depends on the terms of your contract :) |
| # | 17:03:14 | jlamos | is this new behavior for the 2.0 series? I coulda sworn we've restarted *just* opensrf in our tests |
| # | 17:03:31 | hopkinsju | It's really a question of whether we want to launch bleeding edge and do bug fix upgrades or launch stable and deal with a more major upgrade *and* migrating the OPAC design into the new system |
| # | 17:05:34 | dbs | hopkinsju: it has taken 6 point releases to get 2.0 to a truly stable release, IMO; if you have dev talent, then jumping onto 2.1 at this point might be reasonable, as long as you're willing to invest the time (and accept that some bits will go south) |
| # | 17:05:35 | moodaepo | jlamos: I've always done (pstgresql|ejabberd|memcached) > (opensrf|evergreen) > apache2 for start sequence |
| # | 17:06:16 | moodaepo | hopkinsju: And be really nice to library folk (which includes patrons) |
| # | 17:06:33 | AndyW | yea i was always able to restart opensrf without having to restart anything else |
| # | 17:06:46 | hopkinsju | dbs: We've got a platinum support contract with Equinox so I guess it's a question of whether or not I can convince them ;) |
| # | 17:06:47 | moodaepo should have said especially patrons...the staff can stay or leave : ) |
| # | 17:07:36 | moodaepo | AndyW: Yes you can do that but then for Evergreen to work nice it's recommended to restart apache2 |
| # | 17:07:59 | moodaepo | The rest are only restarted for a full clean restart process |
| # | 17:08:41 | AndyW | so basically an init script for opensrf should call a restart of apache as a process of restarting opensrf? |
| # | 17:09:27 | dbs | AndyW: yep |
| # | 17:11:51 | atz | that won't jive for packaging purposes, methinks |
| # | 17:13:33 | atz | not that you should be stopped by that, but whoever is packaging will have to rework it |
| # | 17:14:58 | dbs | atz: agreed, but there are plenty of hurdles to be cleared before debian would ever accept evergreen debs |
| # | 17:15:04 | atz | tons |
| # | 17:16:11 | jeff | i suspect the better way to rework that would be to have the various perl handlers grow reconnect logic |
| # | 17:16:26 | jeff | so that they can survive an opensrf services restart without requiring an apache restart |
| # | 17:16:43 | AndyW | yep |
| # | 17:16:58 | dbs | sounds like a good direction, I'll buy shares in that :) |
| # | 17:17:07 | AndyW | cant that be fixed in evergreen though? |
| # | 17:17:22 | christoph_ | dbs: would there be pains doing an export and then an import with that? Also, would I need to create org units first? |
| # | 17:17:25 | jeff | AndyW: think so, with enough tuits. |
| # | 17:17:44 | adrienne has joined #evergreen |
| # | 17:18:14 | AndyW | to make it more robust so we wont have to worry about fixing it in init scripts and the like wich break debian conventions |
| # | 17:18:23 | jlamos | ok, do any of the services report the're ready when the're actually not? I.E. are there any services we should sleep after? |
| # | 17:18:25 | jeff | it gets complex, i'm sure. what about opensrf restarts to effect an IDL change -- how do your apache clients tell the difference between retrying and reconnecting and services restarts and what do they do differently for each... |
| # | 17:18:26 | dbs | christoph_: I've never done it myself, so I can't say on #1; on #2, probably (assuming a string-based match is required) |
| # | 17:18:31 | jeff | ...and that turned into a bit of a run-on |
| # | 17:19:21 | hopkinsju | adrienne: Hi |
| # | 17:20:01 | adrienne | hopkinsju: Hey |
| # | 17:20:43 | natschil has joined #evergreen |
| # | 17:20:48 | moodaepo | jlamos: This is what I currently use > http://svn.mnpals.net/viewvc/evergreen/egdemo/var/system-scripts/evergreen-init_d?annotate=94 |
| # | 17:21:34 | jlamos | that's actually what we started with |
| # | 17:21:47 | jlamos | and it's been working great until today |
| # | 17:22:12 | natschil | IDoing a db upgrade from 1.6.0.1 to 2.0.5 is a pain, as it gives a ton of errors etc... so what steps would need to be taken to export everything from 1.6 to |
| # | 17:22:28 | jeff | natschil: your message truncated at "from 1.6 yo" |
| # | 17:22:37 | natschil | s/IDoing/I'm here with christoph? and/ |
| # | 17:22:37 | jeff | er, s/yo/to/ :) |
| # | 17:22:50 | moodaepo | jlamos: Oh what happened today? |
| # | 17:23:05 | natschil | jeff: I pressed enter by mistake :) |
| # | 17:23:12 | jeff | natschil: understood :) |
| # | 17:23:16 | moodaepo | I saw you were looking at the order |
| # | 17:23:18 | natschil | 2.1 without doing a full db upgrade. |
| # | 17:23:27 | natschil | s/2.1/2.0.5/ |
| # | 17:24:17 | natschil | The old server is at a separate location, so I was wondering what exactly to get from there when we do. |
| # | 17:25:53 | dbs | natschil: I'm not convinced that you'll have any less pain with an export/import approach |
| # | 17:26:27 | dbs | You're just paying all of the pain of working through each point release all at once, and to make it worse, extremely old point releases that most of us have forgotten :( |
| # | 17:26:43 | natschil | dbs: Is there an alternative to working through each point release? |
| # | 17:26:54 | jlamos | lol don't know. Discovered things not working right after reboots. |
| # | 17:27:31 | moodaepo | natschil: I agree with what dbs said but I have done the same trip and would suggest going this route - 1.6.0.* to 1.6.1.* |
| # | 17:27:33 | dbs | natschil: at some point, we started introducing database upgrade scripts for each change to the schema; meant for developers, really |
| # | 17:27:42 | moodaepo | Then doing the db upgrade + 2.0.* |
| # | 17:28:08 | natschil | dbs: so how would I use those? |
| # | 17:28:17 | jlamos | we had S17ejabberd, S18memcached, S18postgres,S19opensrf,S20apache2.... was working, now we have to manually bounce opensrf and apache2 or we get cstore errors |
| # | 17:28:19 | moodaepo | jlamos: I put in a sleep in the script I use a while back and have not seen any issues with reboots |
| # | 17:28:19 | dbs | hopkinsju: fwiw, we hope to upgrade to 2.1 in the July time frame |
| # | 17:28:47 | natschil | dbs: It would be nice if one could upgrade evergreen without knowing the internals though.... |
| # | 17:29:23 | Dyrcona has quit IRC |
| # | 17:29:56 | hopkinsju | dbs: We are launching the last week of June, so yeah. |
| # | 17:29:57 | dbs | natschil: there's a script, build/tools/update_db.sh, that has been used for that purpose |
| # | 17:29:59 | dbs | YMMV |
| # | 17:30:05 | moodaepo | jlamos: I have - S19postgresql S20ejabberd S20memcached S90evergreen S91apache2 |
| # | 17:30:45 | natschil | dbs: allright. I shall try that. |
| # | 17:30:47 | dbs | natschil: I agree. Unfortunately, we have not done a great job at bullet-proofing / testing our database upgrade scripts. |
| # | 17:31:59 | dbs | hopkinsju: I still expect to have a lot of work to do once we cut over. Planning on updating to 2.0.6 at the end of May, as the 1.6->2.0 upgrade is the biggest hurdle by far. |
| # | 17:32:11 | dbs whispers encouragement to his test db server |
| # | 17:32:45 | natschil | dbs: I guess most people setting up and maintaining evergreen know a lot about the internals, but it's not so much the case here. I will try update_db.sh....is there any documentation as to how to use it? |
| # | 17:33:24 | dbs | natschil: I don't think so. If anything, it's much less non-dev friendly than the upgrade scripts |
| # | 17:33:36 | dbs | but you asked for alternatives, so... |
| # | 17:33:36 | natschil | dbs: basic syntax? |
| # | 17:33:57 | natschil looks at the code. |
| # | 17:34:02 | dbs | usage: $0 db_host db_user db_name |
| # | 17:34:18 | dbs | I would suggest running the version from Evergreen trunk |
| # | 17:34:19 | christoph_ | dbs: what about version numbers? |
| # | 17:34:26 | jenny has left #evergreen |
| # | 17:34:29 | dbs | what about version numbers? |
| # | 17:34:29 | christoph_ | dbs: does it find those by itself? |
| # | 17:34:43 | dbs needs to go to his daughter's birthday dinner |
| # | 17:35:17 | dbs | btw, use the script from trunk, but drop it into a 1.6.1.8 checkout - don't upgrade all the way to trunk :) |
| # | 17:35:24 | dbs | later |
| # | 17:37:01 | natschil | dbs: if you're still there... we only have 1.6.0.1 working here, I will drop it into there. |
| # | 17:37:30 | natschil | s/1.6.0.1/1.6.0.0 |
| # | 17:39:38 | natschil | nevermind, I misunderstood, I will put it into 1.6.1.8 |
| # | 17:51:15 | christoph_ is now known as natschil_ |
| # | 17:54:01 | natschil_ | Ok, so now I am trying to completely do the db upgrade from the start. Something Ihadn't noticed before is that I'm getting a lot of errors like psql:evergreen_db.backup.2011-04-26:3689: ERROR: function "connectby" already exists with same argument types, which leads me to think that maybe the sql restore function is trying to recreate functions created in e.g. tsearch2.sql |
| # | 17:54:09 | natschil_ | would such suspicions be unfounded? |
| # | 17:58:17 | natschil_ | I'm also getting errors like psql:evergreen_db.backup.2011-04-26:3667: ERROR: could not find function "concat" in file "/usr/lib/postgresql/8.4/lib/tsearch2.so" |
| # | 17:58:35 | natschil_ | which is quite strange. |
| # | 17:59:04 | natschil_ | and I don't want to ignore these errors, as they'll probably rear their ugly heads soon in the future. |
| # | 18:14:08 | yboston has quit IRC |
| # | 18:28:20 | natschil_ has quit IRC |
| # | 18:28:26 | natschil has quit IRC |
| # | 18:33:37 | jenny has joined #evergreen |
| # | 18:35:27 | natschil has joined #evergreen |
| # | 18:35:35 | natschil_ has joined #evergreen |
| # | 18:42:07 | moodaepo | natschil_ I ignored those same errors and have a funny feeling about them. |
| # | 18:43:11 | moodaepo | natschil_: Look for the errors here and compare > http://paste.lisp.org/display/120094#1 |
| # | 18:43:38 | jenny has left #evergreen |
| # | 18:45:38 | moodaepo | If you hear from eeevil or dbs more about these errors it would be great. |
| # | 18:45:39 | natschil_ | moodaepo: yep, same errors here, as far as I can see... and your system works? |
| # | 18:45:52 | moodaepo | er more or less : ) |
| # | 18:46:00 | natschil_ ignores the errors too. |
| # | 18:46:12 | moodaepo | I believe it does work I'll know better in a couple of weeks |
| # | 18:46:25 | moodaepo | When I do production upgrades and let the users do the testing ; ) |
| # | 18:47:39 | natschil_ | moodaepo: :D |
| # | 18:50:39 | youdonotexist has quit IRC |
| # | 19:14:18 | natschil_ has quit IRC |
| # | 19:14:38 | natschil has quit IRC |
| # | 22:47:35 | moodaepo_ has joined #evergreen |
| # | 22:53:22 | moodaepo_ | The page was getting really long and after a chat with Bob Molyneux I started thinking about a re-org and have changed it so, we can always move back if folks feel it's not working > http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen_libraries |
| # | 22:54:34 | moodaepo_ | Plan is to just list by country, we can always re-org the page and divide it up by region when we see the need. |
| # | 22:54:48 | moodaepo_ | I also want to move away from "Forests" and "Single Plantings", sounds cool but not very informational. |
| # | 22:54:59 | moodaepo_ goes to watch Community |
| # | 22:55:03 | moodaepo_ has quit IRC |
| # | 23:07:56 | dbs | @later tell moodaepo Fancy, I like the direction of the evergreen libraries page (didn't know about the new twisty wiki syntax - neat) |
| # | 23:07:56 | pinesol_green | dbs: The operation succeeded. |
April 10-13