| # | Time | Nick | Message |
|---|
| # | 00:36:44 | dbs has quit IRC |
| # | 02:46:44 | adm_ils has joined #evergreen |
| # | 02:47:15 | adm_ils | i am receiving error -/openils/var/web/xul/rel_2_1_0/server/main/lang.js, /openils/var/web/opac/common/js/JSON.js, /openils/var/web/xul/rel_2_1_0/server/main/OpenILS, |
| # | 02:47:33 | adm_ils | file does not exist |
| # | 02:47:43 | adm_ils | what should i do |
| # | 03:11:41 | adm_ils has quit IRC |
| # | 03:53:11 | idm_ils has joined #evergreen |
| # | 03:53:58 | idm_ils | i am receiving an error in my error.log file .those are /openils/var/web/xul/rel_2_1_0/server/main/lang.js, /openils/var/web/opac/common/js/JSON.js, /openils/var/web/xul/rel_2_1_0/server/main/OpenILS, |
| # | 06:09:23 | idm_ils has quit IRC |
| # | 08:31:23 | AaronZ-PLS has joined #evergreen |
| # | 08:37:05 | Dyrcona has joined #evergreen |
| # | 08:42:43 | jeff | Hrm. Using the web /exporter on 2.1 I get records without a 901$c. That surprises me. |
| # | 08:42:49 | jeff digs |
| # | 08:45:56 | tspindler has joined #evergreen |
| # | 08:49:21 | csharp | berick: (or whomever is able to shed light on my issue) - I increased the log level for gateway to 5 and tried again to add a permission to a perm group: http://pastebin.com/fawMS0hx |
| # | 08:50:13 | csharp | this is what happens when I add a permission to a group in the Permission Groups UI |
| # | 08:50:26 | csharp | nothing is visible on the front end |
| # | 08:51:06 | csharp | the osrferror log reports a 404 error "remote-server-not-found" |
| # | 08:51:26 | csharp | tests with telnet (and all auth, etc. functions) work, however |
| # | 08:52:00 | csharp | as a test, I enabled the mem_cache apache module to see if that would help - but no change |
| # | 08:52:19 | csharp | the memcache server logs confirm that the messages are not getting there |
| # | 08:52:35 | _bott_ | jeff: on an ME host? |
| # | 08:57:20 | mdevilz has joined #evergreen |
| # | 08:58:07 | csharp resorts to manually mapping perms to groups in the meantime... :-/ |
| # | 09:02:00 | tsbere | a pcrud transaction commit failure... did your pcrud crash while you were connected? |
| # | 09:02:19 | csharp | tsbere: how would I tell? |
| # | 09:02:48 | tsbere | csharp: Well, I am guessing, because I can't see pcrud *not* having transaction.commit, or you getting that far without having done, say, transaction.begin......... |
| # | 09:04:06 | jeff | _bott_: yes. |
| # | 09:05:37 | csharp | tsbere: http://pastebin.com/4EXV8XZf |
| # | 09:06:17 | tsbere | Huh. That is weird. |
| # | 09:07:07 | jeff | _bott_: the export also seems to have fallen short. this would have been on the 27th. I seem to have requested 260993 bibs and received 75166. |
| # | 09:07:50 | csharp | tsbere: full threadtrace: http://pastebin.com/3EGis7Qz |
| # | 09:08:02 | jeff | _bott_: Unless I ran into a service restart or network timeout, I'm guessing that it may just be a bad record. Looking at the records just before and just after the end of what I *did* receive. |
| # | 09:08:27 | _bott_ | did you export as MARC21 or MARCXML? |
| # | 09:09:05 | jeff | MARC21 |
| # | 09:13:51 | dbs has joined #evergreen |
| # | 09:14:54 | berick | csharp: is your gateway configured to use the private domain in opensrf_core.xml by any chance? |
| # | 09:15:14 | jeff | heh. the end of the last record in the MARC21 looks like this after being parsed by yaz-marcdump: |
| # | 09:15:17 | jeff | 655 7 $a Young adult fiction. |
| # | 09:15:19 | jeff | 901 f $c tion. |
| # | 09:15:22 | csharp checks |
| # | 09:15:57 | csharp | berick: <domain>public.test-b0.test.gapines.org</domain> |
| # | 09:16:02 | csharp | so no, guess not |
| # | 09:17:02 | berick | is open-ils.pcrud listed in the <services> in the public domain in the <opensrf> section? |
| # | 09:17:04 | csharp | I just increased opensrf's loglevel to include debug messages and will try again |
| # | 09:17:10 | tlilleberg has joined #evergreen |
| # | 09:17:28 | _bott_ | jeff: does the client allow you to modify that record, or do you need me to touch it? |
| # | 09:17:39 | berick is wondering why the gateway is trying to talk to a service at pensrf@private.test-b1.test.gapines.org/open-ils.pcrud_drone... |
| # | 09:17:48 | csharp | berick: yes it is |
| # | 09:17:56 | jeff | haven't looked at the marcxml to determine if it's broken yet -- i'll let you know shortly. |
| # | 09:18:21 | csharp | berick: ah - a clue |
| # | 09:19:52 | berick | csharp: mind pasting the gateway log for the transaction.begin call? |
| # | 09:21:54 | csharp | berick: I will, but here is my (scrubbed) opensrf_core.xml file: http://pastebin.com/t3DHLe4m |
| # | 09:23:10 | yboston has joined #evergreen |
| # | 09:24:32 | csharp | berick: http://pastebin.com/6T7ed2YS |
| # | 09:25:23 | StephenGWills has joined #evergreen |
| # | 09:25:36 | berick | csharp: arg, sorry, i guess what I really want to see is the CONNECT call, which occurs just before the xact.begin |
| # | 09:32:17 | csharp | berick: this is the full gateway log for when I just tried to add a perm to a group: http://pastebin.com/5Lq3qvAL |
| # | 09:33:25 | Dyrcona | http://pastebin.com/AyaiHNAM |
| # | 09:33:43 | Dyrcona | I still can't get to anything at esilibrary.com domains. |
| # | 09:33:59 | berick | @isitdown esilibrary.com |
| # | 09:33:59 | pinesol_green | berick: Error: "isitdown" is not a valid command. |
| # | 09:33:59 | tspindler has quit IRC |
| # | 09:34:04 | berick | @help |
| # | 09:34:04 | pinesol_green | berick: (help [<plugin>] [<command>]) -- This command gives a useful description of what <command> does. <plugin> is only necessary if the command is in more than one plugin. |
| # | 09:34:09 | berick | @list |
| # | 09:34:09 | pinesol_green | berick: Admin, Channel, ChannelLogger, Config, Games, Herald, Karma, Later, Math, Misc, Note, Owner, Praise, Quote, RSS, Reply, Seen, Todo, and User |
| # | 09:34:41 | tsbere can visit esilibrary.com |
| # | 09:34:42 | Dyrcona | I got a similar traceroute last night at home. I have the same ISP, ultimately, as where I work, Verizon. |
| # | 09:34:43 | csharp | Dyrcona: it looks like it's getting lost somewhere at QTS (qualitytech.com) |
| # | 09:35:01 | Dyrcona | git.esilibrary.com fails for me, too. |
| # | 09:35:32 | tsbere can get to esilibrary.com, but not git.esilibrary.com |
| # | 09:35:41 | csharp | tsbere: same here |
| # | 09:35:54 | Dyrcona | I can get to the esilibrary.com web site, except the flash never loads because of no-script. |
| # | 09:36:48 | Dyrcona | berick: Think you'd better bug quality tech. They appear to be your hosting provider. |
| # | 09:37:29 | berick | pastebin_under_heavy_load-- |
| # | 09:37:48 | csharp blames himself *sob* |
| # | 09:37:59 | berick | Dyrcona: thanks. i'll inform those what do the networking |
| # | 09:39:17 | jeff | I can reach esilibrary.com, demo.evergreencatalog.com, etc. The only host I can't reach in this set is git/yeti. The host may simply be down. |
| # | 09:39:48 | jeff | The last hop before the destination for demo.evergreencatalog.com is 64.88.172.102, and that's the last returning hop on an attempt to traceroute to yeti. |
| # | 09:40:22 | berick | jeff: yeti is down |
| # | 09:41:01 | jeff | Dyrcona: were you having issues with any esilibrary.com hosts other than git/yeti? |
| # | 09:41:28 | Dyrcona | jeff: I haven't tried any other than the website. |
| # | 09:41:58 | jenny has joined #evergreen |
| # | 09:42:06 | Dyrcona | I didn't know yeti == git. |
| # | 09:42:15 | jeff | aha. :-) |
| # | 09:42:57 | berick | Dyrcona: if, by any chance, you were looking for the freebsd doc, it's mirrored at http://dev198.esilibrary.com/~berick/eg_freebsd.html |
| # | 09:43:16 | Dyrcona | berick++ # for supercow powers |
| # | 09:43:46 | Dyrcona | I also have git.esilibrary.com configured as a remote, so might be nice if that were back sometime. |
| # | 09:44:09 | jeff | git fetch --all --except-for-that-hairy-yeti-chap |
| # | 09:45:28 | Dyrcona | berick: I was thinking of wikify-ing the freebsd instructions. Maybe when we have something known to work. |
| # | 09:45:29 | berick | pretty sure we're pushing everything evergreen/opensrf directly to the community repos now, if you want to just remove the remote |
| # | 09:46:01 | Dyrcona | berick: will do. we keep a couple of repos private here, 'cause they have passwords and junk in the configurations. |
| # | 09:46:01 | berick | Dyrcona: btw, I fixed the vandelay problem and it's reflected in the current version of the doc. just had to install marc::charset from cpan |
| # | 09:46:47 | berick | the z39 problem turns out to be specifcially w/ biblios. LoC works fine. haven't researched beyond that |
| # | 09:47:26 | Dyrcona | berick: OK. gives me something to look into when I get a VM set up or when I get it installed on my machine at home, which I may bring back into the office. |
| # | 09:48:38 | Dyrcona has some other things to do right now. |
| # | 09:52:22 | jeff | _bott_: the last record in the batch from Nov 27 is malformed at the end, but requesting that record by itself today returns a clean MARC21. Odd. I think I'll try the export again tonight and see if/how it breaks. This is bre id 18106286 |
| # | 09:55:10 | berick | csharp: i'm going back to my earlier statement, which tsbere also suggested, that the pcrud drone process is dying. between the request and the xact.commit |
| # | 09:55:32 | berick | csharp: run the test again and when you're done, see if the pcrud process is still around |
| # | 09:57:27 | jeff | kinda' odd. there's an extra "fiction. " followed by a field sep <1E> char where the record's directory claims the 901 should start. |
| # | 09:58:18 | Dyrcona | jeff: Not so odd. I've seen worse formatted MARC than that. |
| # | 09:59:28 | jeff | edit_date on biblio.record_entry is 2008-08-02, so that probably shoots down the idea of "it was broken on Nov 27 and somebody fixed it between then and now." |
| # | 10:01:01 | jeff | Dyrcona: yeah, but I can't explain this malformation. That's the part that annoys. |
| # | 10:03:19 | Dyrcona | jeff: perhaps the MARC has some "nonprintable" character in it that is messing things up? |
| # | 10:06:28 | jeff | Dyrcona: I requested many bibs from the /exporter on Nov 27. The resulting MARC21 had far fewer records than I requested, and the final record in the file had this malformation. |
| # | 10:06:38 | jeff | Dyrcona: requesting just that record today shows no malformation. |
| # | 10:06:54 | jeff | Dyrcona: so I'll see what happens tonight when I request the batch again. |
| # | 10:07:48 | tspindler has joined #evergreen |
| # | 10:08:04 | jeff | Dyrcona: If there was a bad record that the /exporter tripped up on, or if there was an interruption in the transfer or some maintenance resulting in a late night restart of services/apache/etc, I would expect it to be truncated, but not "has some field data in the wrong place, then finishes" like this does. |
| # | 10:08:39 | csharp | berick: the pcrud process doesn't appear to be dying - I'm getting the same thing "remote-server-not-found" in the error message |
| # | 10:09:16 | Dyrcona | jeff: Well, it could be dying, truncating the output, and you're seeing garbage at the end of the last record that gets output. |
| # | 10:09:29 | csharp | from what you know is the "remote server" in this case the OSRFHTTPTranslator memcache server? |
| # | 10:09:34 | Dyrcona | jeff: You're getting binary MARC out, right? |
| # | 10:09:40 | berick | csharp: no, memcache is fine |
| # | 10:10:00 | csharp | ok - well - it's nice to cross that off the list ;-) |
| # | 10:10:24 | jeff | Then I also wonder, why do I have 75166 records, but only 72023 901 tags... and why do only 40066 of those have 901$c? |
| # | 10:10:32 | jeff | Dyrcona: binary MARC21, yes. |
| # | 10:12:10 | Dyrcona | jeff: I'd try modifying the source to write the MARC as it comes out in XML to a file and another file with the MARC after conversion. |
| # | 10:12:48 | berick | csharp: the problem is the translator is unable to send a jabber msg to the pcrud drone |
| # | 10:13:03 | berick | a drone it already sent several messages to successfully |
| # | 10:13:14 | csharp | okay - that makes sense |
| # | 10:13:22 | berick | the pcrud process dying is the only logical explanation for what's in the logs |
| # | 10:13:28 | tsbere | berick: He previously pasted a line that indicated the pcrud drone was auto-rollbacking and disconnecting due to lack of messages. |
| # | 10:13:38 | jeff | I think the "dying, truncating the output, and seeing garbage" is close, but it's odd that it's [lots of good records][good start of record][weird repeat of data][rest of record] |
| # | 10:13:41 | berick | tsbere: ah, yeah |
| # | 10:13:48 | tsbere | berick: So if the pcrud drone is dieing, it is because it is disconnecting from XMPP? |
| # | 10:13:50 | tsbere | hmmm |
| # | 10:14:00 | tsbere | csharp: Did you check your ejabberd config for max sessions? |
| # | 10:14:13 | csharp | tsbere: not until now ;-) |
| # | 10:14:17 | berick | or, it's just getting disconnected and not actually dying |
| # | 10:14:29 | csharp | it appears to not be dying |
| # | 10:14:33 | berick | right |
| # | 10:15:27 | csharp | tsbere: {access, max_user_sessions, [{10000, all}]}. on both bricks |
| # | 10:15:38 | tsbere | Hmmm |
| # | 10:15:38 | berick | csharp: max_stanza_size? |
| # | 10:16:32 | tsbere | csharp: A thought, if we want to go nuts: Register a third user (brick2 or something) on the public and private domains, and tell one of the bricks to use *that* user instead of opensrf? Then that *brick* gets 10,000 sessions to work with. |
| # | 10:16:44 | csharp | {max_stanza_size, 2000000} |
| # | 10:17:15 | Dyrcona | csharp: Add another zero to your max stanza size. Mine is 20,000,000 |
| # | 10:17:55 | Dyrcona | and sometimes 20 million is too small, so you have to stream results. |
| # | 10:18:46 | csharp is already going nuts |
| # | 10:18:56 | jeff wanders off to see where 901$c was previously added during export, and to see if things changed with the introduction of the maintain control numbers bits. |
| # | 10:19:00 | berick notes, fwiw, 2000000 is sufficient for the request csharp is making |
| # | 10:19:58 | csharp | yeah - we've never had a problem with the defaults (from install instructions) |
| # | 10:20:46 | Dyrcona | csharp: the README was recently changed to set that to 20000000 though, that's 7 zeroes not 6, IIRC. |
| # | 10:20:59 | csharp | the screwed up thing is that this was all working before last week... I was able to add permissions without any issues |
| # | 10:21:38 | csharp | when the GUI stopped responding, I chatted here, and berick guided me to the cache setting for the http translator |
| # | 10:21:59 | csharp | I found the line commented out, so I don't know how it was working before |
| # | 10:22:11 | plux has joined #evergreen |
| # | 10:22:19 | csharp | I just now that since I set the memcache server to my actual server, these 404s appeared |
| # | 10:22:36 | csharp | s/now/know/ |
| # | 10:23:14 | berick | csharp: did you add the second brick last week, by any chance? |
| # | 10:23:32 | csharp | berick: nope - they've been running in this configuration for about a month |
| # | 10:24:09 | csharp | and everything was great and happy until now :-( |
| # | 10:24:11 | csharp weeps |
| # | 10:30:30 | plux | looking for 2.2 alpha for some testing... is it on a separate git or just by account only? |
| # | 10:31:23 | csharp | plux: should be able to 'git checkout tags/rel_2_2_alpha1' |
| # | 10:31:46 | csharp | plux: may need to 'git pull' beforehand |
| # | 10:41:46 | plux | the main repo? |
| # | 10:42:08 | tsbere | the main evergreen repo, yea. |
| # | 10:42:28 | tsbere | Or you can download the tarball, or you can just check out master for 2.2 alpha2 preview ;) |
| # | 10:47:40 | akilsdonk has joined #evergreen |
| # | 10:51:48 | plux | that's great.... oversight.... thanks |
| # | 10:56:39 | dbs | plux: I'd recommend master for now, a number of bug fixes and changes since alpha1 |
| # | 10:57:59 | dbs would like to see 894052 (point-to-point version scripts) and 896405 (fixes for 2.1-2.2 update script) merged |
| # | 10:58:14 | plux | perfect.... I'll start with that |
| # | 11:02:35 | mrpeters-isl_ has joined #evergreen |
| # | 11:02:43 | mrpeters-isl_ | Any thoughts on [Wed Nov 30 11:01:17 2011] [error] Can't locate DateTime/Format/Mail.pm in @INC (@INC contains: /openils/lib/perl5 /etc/perl /usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl /usr/local/lib/perl/5.10.0 /usr/local/share/perl/5.10.0 . /etc/apache2) at /openils/lib/perl5/OpenILS/WWW/SuperCat/Feed.pm line 10.\nBE |
| # | 11:02:58 | mrpeters-isl_ | occurs after an upgrade from lenny > squeeze when attempting to start apache2 |
| # | 11:03:17 | akilsdonk has quit IRC |
| # | 11:03:56 | dbs | mrpeters-isl: upgrade to squeeze - did you rerun Makefile.install as well? |
| # | 11:04:00 | mrpeters-isl_ | giving "cpan DateTime::Format::Mail" a shot... |
| # | 11:04:19 | mrpeters-isl_ | dbs: no...was under the impression all we needed was a dist-upgrade |
| # | 11:04:33 | mrpeters-isl_ | but that makes sense...ill rerun it |
| # | 11:05:24 | dbs thinking that perl might have gone from 5.8 to 5.10 and thus no longer finds the old CPAN-installed modules? wild guess |
| # | 11:05:51 | mrpeters-isl_ | gmcharlt:: if you're lurking, do you want us to go ahead and use the 2.1 Makefile or the 2.0.4? |
| # | 11:06:10 | dbs | mmm. perl 5.10.0 on our lenny system, so maybe not that |
| # | 11:06:13 | mrpeters-isl_ | i assume i need to do the same for OpenSRF |
| # | 11:06:31 | dbs | yup |
| # | 11:06:38 | dbs | (or at least I would suggest that) |
| # | 11:08:06 | mrpeters-isl_ | ok. i'll just go with re-running it for debian-squeeze at the versions we're currently on |
| # | 11:09:09 | mrpeters-isl_ attempts to upgrade 20 machines in 4 days...yay! |
| # | 11:09:46 | tsbere attempts to juggle way too many things in his head, and thinks he may be failing |
| # | 11:11:15 | gmcharlt | mrpeters-isl: for the moment, try going with the 2.0 deps from the Makefile |
| # | 11:14:27 | mrpeters-isl_ | gmcharlt: yep -- good to go |
| # | 11:14:34 | mrpeters-isl_ | apache is happy now |
| # | 11:14:48 | mrpeters-isl_ | upgrade from xen 3.2 > 4.0 is a bit painful |
| # | 11:14:57 | Dyrcona | anyone have an example of using a CStoreEditor->search_some_object with a join? |
| # | 11:15:06 | mrpeters-isl_ | but we will crank through the rest now that we found the links |
| # | 11:15:10 | mrpeters-isl_ | errr kinks |
| # | 11:15:18 | Dyrcona | bonus points for search_biblio_record_entry |
| # | 11:17:14 | dbs | mrpeters-isl: don't link to your kinks, please |
| # | 11:18:15 | tsbere | http://egdev.mvlcstaff.org/Parts_and_Sub-Parts < Any thoughts? |
| # | 11:18:28 | dbs | Dyrcona: my $scaps = $editor->search_serial_caption_and_pattern([{"+siss" => {"id" => $issuance_id}}, { "join" => {"siss" => {}} }]); from O:A:Serial.pm ? |
| # | 11:18:46 | Dyrcona | dbs++ |
| # | 11:18:55 | dbs | ack++ |
| # | 11:22:01 | Dyrcona | ooh. this'll be fun to get working. I'm going to be joining bre, acn, acp, ascecm, asce, and mfr! |
| # | 11:22:19 | youdonotexist has joined #evergreen |
| # | 11:23:40 | tsbere | Gonna do any fleshing of extra pieces while you are at it? ;) |
| # | 11:23:58 | Dyrcona | No, I just want the bre objects to update their marc. |
| # | 11:24:31 | Dyrcona | gonna change the leaders of those that DO NOT have marc type r to have marc type r. |
| # | 11:25:03 | dbs | Dyrcona: huh. I would probably either go with json_query or simplify it by defining a view and adding that to fm_IDL - but I don't touch much of that sort of thing |
| # | 11:25:27 | dbs | Dyrcona: oh, this is for a one-off script? |
| # | 11:25:42 | dbs would just go with nice, clean SQL in that case :) |
| # | 11:25:45 | Dyrcona | dbs: yeah. I'm considering doing the json_query, since I know how to do that. |
| # | 11:26:12 | dbs has shared "nice, clean SQL" for clean-up purposes - what a joke |
| # | 11:26:12 | Dyrcona | I find its easier to manipulate the marc in Perl. |
| # | 11:26:39 | Dyrcona enjoys a challenge. |
| # | 11:26:46 | dbs | Define a plperl function :) |
| # | 11:27:10 | gmcharlt | dbs++ |
| # | 11:27:37 | Dyrcona | plperl, not for a one-off. :) |
| # | 11:28:10 | Dyrcona | or do you mean something to change the marc type of a record given the id and the new marc type? |
| # | 11:29:52 | Dyrcona keeps most of his one-offs around, because he invariably ends up doing something very similar with different parameters later. |
| # | 11:29:57 | jeff | oh wait, maintain_control_numbers does nothing related to the 901$c. i was mis-remembering. |
| # | 11:30:18 | jeff | evergreen.maintain_901 on the other hand... |
| # | 11:31:25 | dbs misses context for jeff's mis-remembering, but knows that malformed MARCXML really angers the MARC::Record-based triggers, in a bad way |
| # | 11:32:04 | tsbere | gigo, but where the go part is a crash? |
| # | 11:33:34 | jeff | yeah, and since the db handles 901 mangling, the exporter stopped doing it, and thus i have the situation i'm in now. :-) |
| # | 11:33:41 | jeff | okay, theory confirmed. |
| # | 11:34:25 | jeff | i think the short term fix will be to restore the 901 mangling in OpenILS::WWW::Exporter |
| # | 11:35:41 | jeff | (locally) |
| # | 11:36:20 | jeff | dbs: "in a bad way" resulting in a crash like tsbere guessed, or just "complete failure to perform the trigger's intended task"? |
| # | 11:37:11 | dbs | jeff: rollback of any transaction touching biblio.record_entry |
| # | 11:38:33 | dbs | thus the whackjob SQL updates that I've posted - because it sucks when you're trying to update a batch of records to, say, change a proxy address and your update of 100,000 records gets rolled back because one of the records has a tag like "0-9" |
| # | 11:38:46 | jeff | yeah. |
| # | 11:39:22 | jeff | okay, so next step is to look at some of these 901$c missing or incorrect records and see what fun we have. |
| # | 11:40:37 | jeff | dbs: as long as the updated record isn't broken marcxml, you're able to fix things -- no need to disable triggers during the fixing, right? |
| # | 11:40:57 | dbs | jeff: right |
| # | 11:41:27 | jeff | ind2="" is bad, right? |
| # | 11:41:30 | dbs | right |
| # | 11:41:45 | jeff | yeah, okay. now i have something to work with. :-) |
| # | 11:41:46 | jeff | dbs++ |
| # | 11:41:57 | dbs will pull together the sets of SQL that he has run on his testing server to address a bunch of issues we have run into... |
| # | 11:42:25 | jeff | update value.copynotes set title = 'COST' where upper(title) in ('"COST"','COST ',' COST','CCOST','COPY','COPY ','OST','COS','OCST','CSOT','COCST','COAT','COAR','COSY','COSTS','CST','CPST','CPOST','CIST','COPY NOTES'); |
| # | 11:44:07 | rogan has joined #evergreen |
| # | 11:48:09 | jeff | yeah, 78384 bre records where marc like '%ind1=""%' or marc like '%ind2=""%' |
| # | 11:51:59 | tsbere probably would have done that as where marc like '%ind_=""%' |
| # | 11:53:02 | jeff | good point. i initially ran my query with * instead of %, and wondered why i got nothing back :P |
| # | 11:54:23 | tsbere | alt: marc similar to '%ind(1|2)=""%' |
| # | 11:56:15 | dbs put spaces around the the start and end of ind and the quotes for good measure |
| # | 11:56:31 | jeff | indeed |
| # | 11:58:23 | dbs | some simple, dumb examples: http://pastebin.com/5eqCWGz2 |
| # | 11:59:16 | dbs | kind of an iterative process; you'll have empty tags, empty codes, invalid tags (non-alphanums, single char).... |
| # | 12:00:38 | ElliotFriend has joined #evergreen |
| # | 12:01:53 | ElliotFriend | Does Evergreen 2.1.1 still use cgi-bin/config.cgi to configure things like Consortium name, Library branches, etc? |
| # | 12:03:59 | jeff | I don't see anything in the upgrade scripts for 1.6 to 2.0 nor 2.0 to 2.1 that would trigger a maintain_901 on existing records. Would records lack a maintained 901 field until they were updated via some other process, or am I missing something that would take place during the upgrade? |
| # | 12:06:44 | tsbere | ElliotFriend: No. Admin->Server admin menus in the staff client, or direct DB queries for the brave ;) |
| # | 12:07:13 | dbs | jeff: same sort of problem that we ran into with authority records |
| # | 12:07:39 | ElliotFriend | tsbere: So simple!!! Thanks :) |
| # | 12:08:16 | dbs | ElliotFriend: does the documentation you're using still refer to the config.cgi stuff? |
| # | 12:09:26 | ElliotFriend | dbs: No. config.cgi was the only thing I could find in any eg documentation that discussed Oganization info. I was only looking in the administrative stuff, though. Could be somewhere else |
| # | 12:21:58 | tsbere comments on berick's address notification bug there |
| # | 12:22:58 | ElliotFriend | dbs: Looking back at the README, it does mention cgi a couple times. Once under "Creating the evergreen database", and a second time under "starting evergreen" |
| # | 12:24:21 | dbs | ElliotFriend: you're right. I know we've discussed exterminating those scripts before. Can't remember whether we just forgot to or if there actually is a reason to keep them around |
| # | 12:34:00 | tecoripa has joined #evergreen |
| # | 12:34:12 | AaronZ-PLS has quit IRC |
| # | 12:34:49 | Meliss has joined #evergreen |
| # | 12:35:14 | tecoripa | I have a question (or several) about exposing backend methods in javascript |
| # | 12:35:35 | tsbere will assume that one question will turn into 10 there |
| # | 12:35:57 | tecoripa | I want to have a mthod in stat_cat_editor.js that retrieves a default stat cat entry for an org_unit |
| # | 12:36:04 | tecoripa | a signature like this: |
| # | 12:36:19 | tecoripa | entry.default(org_unit, [entry]) |
| # | 12:36:37 | tecoripa | without the entry param, it retrieves the default entry for the org_unit |
| # | 12:36:46 | tecoripa | with the optional entry param, it will set it |
| # | 12:37:08 | tecoripa | this will be a virtual method: there's no default column in the entry tabel |
| # | 12:37:39 | tecoripa | I'm hazy on how methods are exposed to the hjavascript from the backend |
| # | 12:38:19 | tecoripa | I've seen how a set of standard CRUD methods is made available for objects that are directly tied to columns |
| # | 12:38:39 | tecoripa | but extra functiuons, not tied so closely to the object database model? |
| # | 12:39:05 | tecoripa | what would be most helpful for me is an example of another object that does the same kind of thing |
| # | 12:39:24 | tsbere | The editor tends to do writes via Open-ILS/src/perlmods/lib/OpenILS/Application/Circ/StatCat.pm based functions |
| # | 12:39:32 | tecoripa | i.e., expose a method that has no DB counterpartm, but rather, performs several functions on the backend |
| # | 12:40:06 | tecoripa | so the functions in StatCat.pm that are registered will magically be available in the javascript? |
| # | 12:41:07 | tsbere | Look at the top of stat_cat_editor.js. You will see a collection of variables starting with SC_ that define calls to backend functions. TYPE and/or PCRUD are swapped out for asset or actor where needed. |
| # | 12:41:24 | tecoripa | right, saw that... |
| # | 12:41:39 | tecoripa | I missed the SC_* variables, though |
| # | 12:41:59 | tecoripa | so that's the glue that will tie javascript methods to the perl StatCat.pm methods? |
| # | 12:42:11 | tsbere | Basically |
| # | 12:42:22 | tecoripa | great, that helps tremendously |
| # | 12:42:42 | tecoripa | thanks again, Thomas! |
| # | 12:46:02 | youdonotexist_ has joined #evergreen |
| # | 12:46:15 | tecoripa has left #evergreen |
| # | 12:47:25 | youdonotexist_ has quit IRC |
| # | 12:48:19 | youdonotexist has quit IRC |
| # | 12:49:21 | AaronZ-PLS has joined #evergreen |
| # | 12:53:55 | pmpcat has joined #evergreen |
| # | 12:54:30 | matt_carlson has joined #evergreen |
| # | 12:54:36 | Dyrcona has quit IRC |
| # | 12:55:00 | Dyrcona has joined #evergreen |
| # | 12:55:14 | Dyrcona lols. |
| # | 12:56:05 | plux has quit IRC |
| # | 12:56:40 | plux has joined #evergreen |
| # | 12:57:45 | plux has joined #evergreen |
| # | 12:58:55 | matt_carlson has quit IRC |
| # | 13:11:46 | plux_ has joined #evergreen |
| # | 13:13:35 | jeffdavis has quit IRC |
| # | 13:20:47 | tsbere pokes phasefx about https://bugs.launchpad.net/evergreen/+bug/884773 |
| # | 13:22:23 | mrpeters-isl_ has quit IRC |
| # | 13:23:19 | phasefx makes the pillsbury dough boy sound |
| # | 13:25:37 | plux has left #evergreen |
| # | 13:26:44 | phasefx | tsbere: top 4 commits? I'll definitely poke tomorrow, wearing a different hat now |
| # | 13:27:52 | tsbere | phasefx: Yea. |
| # | 13:30:52 | plux has joined #evergreen |
| # | 13:35:50 | plux has quit IRC |
| # | 13:35:51 | plux_ is now known as plux |
| # | 13:36:20 | plux1 has joined #evergreen |
| # | 13:39:03 | plux1 has joined #evergreen |
| # | 13:40:05 | plux1 has joined #evergreen |
| # | 13:55:25 | asimon_ has joined #evergreen |
| # | 13:58:54 | asimon_ | I've upgraded a working 2.0.9 system to 2.1.1. When I try to log in with a newly created staff user (with the STAFF_LOGIN permission set), I get a PERM_FAILURE log entry. |
| # | 13:59:07 | asimon_ | The admin user can log in without any problems. Ideas? |
| # | 13:59:23 | mtate has quit IRC |
| # | 13:59:29 | gmcharlt | asimon_: does the staff user have any working locations? |
| # | 13:59:31 | dbs | asimon_: staff member also has a work ou? |
| # | 13:59:49 | gmcharlt | dbs: outta my head, please! |
| # | 13:59:54 | gmcharlt | ;) |
| # | 13:59:58 | dbs | jinx! |
| # | 14:00:20 | rangi | vulcan mind meld |
| # | 14:00:36 | dbs | An error message that says "This user has not been assigned any working locations." would be a nice enhancement :) |
| # | 14:01:14 | mtate has joined #evergreen |
| # | 14:02:00 | youdonotexist has joined #evergreen |
| # | 14:03:36 | asimon_ | * Problem solved: The default group STAFF_LOGIN permission was not set at the Consortium level. Changing that fixed the problem. |
| # | 14:03:52 | gmcharlt | asimon++ |
| # | 14:06:52 | plux has quit IRC |
| # | 14:11:22 | dbs | -= THIS MESSAGE NOT LOGGED =- |
| # | 14:13:47 | Dyrcona | -= THIS MESSAGE NOT LOGGED =- |
| # | 14:15:35 | dbs | -= THIS MESSAGE NOT LOGGED =- |
| # | 14:15:47 | dbs | -= THIS MESSAGE NOT LOGGED =- |
| # | 14:15:51 | jeffdavis has joined #evergreen |
| # | 14:19:10 | tspindler has quit IRC |
| # | 14:20:08 | asimon_ has quit IRC |
| # | 14:20:42 | matt_carlson has joined #evergreen |
| # | 14:21:11 | Dyrcona | http://pastebin.com/9H2nYPKj |
| # | 14:21:51 | Dyrcona | wonder if anyone knows off the top of their head what might cause that when creating marc records from bre->marc? |
| # | 14:25:37 | tsbere | truncated fixed fields, I would assume |
| # | 14:33:38 | dbs pushes https://bugs.launchpad.net/evergreen/+bug/891171 - yay |
| # | 14:33:44 | Dyrcona | yeah. turns out I messed up the leader. |
| # | 14:33:52 | dbs | Now on to coffee, and thence on to librarianship |
| # | 14:33:52 | Dyrcona | all better now. |
| # | 14:38:38 | Dyrcona | I do get some weirdness when joining bre => mrd with a filter on mrd.item_type. |
| # | 14:38:50 | Dyrcona | but fixed that by specifying join columns. |
| # | 14:39:15 | Dyrcona | how's that for non sequitur? |
| # | 14:44:35 | dbs | @later tell berick updated http://evergreen-ils.org/dokuwiki/doku.php?id=dev:opac:template-toolkit a bit to reflect death of oils_web.xml / examples of hostname-based skinning - probably better ways to skin that cat (hah) but works++ |
| # | 14:44:35 | pinesol_green | dbs: The operation succeeded. |
| # | 14:45:34 | berick | @later tell dbs dbs++ |
| # | 14:45:34 | pinesol_green | berick: The operation succeeded. |
| # | 14:45:41 | berick | ;) |
| # | 14:54:07 | dbs | right on |
| # | 14:54:19 | matt_carlson has quit IRC |
| # | 14:55:09 | kmlussier has joined #evergreen |
| # | 14:56:15 | matt_carlson has joined #evergreen |
| # | 15:02:58 | Dyrcona | If anyone is looking at branches with new functionality for master, I find this one very useful: |
| # | 15:03:00 | Dyrcona | https://bugs.launchpad.net/evergreen/+bug/888572 |
| # | 15:19:21 | matt_carlson has quit IRC |
| # | 15:33:35 | rogan has quit IRC |
| # | 15:53:32 | plux1 has quit IRC |
| # | 15:55:33 | Meliss has quit IRC |
| # | 16:06:20 | ElliotFriend has quit IRC |
| # | 16:06:32 | ElliotFriend has joined #evergreen |
| # | 16:06:44 | ElliotFriend_ has joined #evergreen |
| # | 16:30:32 | collum has quit IRC |
| # | 16:30:36 | akilsdonk has joined #evergreen |
| # | 16:41:08 | _bott_ has quit IRC |
| # | 16:41:39 | _bott_ has joined #evergreen |
| # | 16:54:37 | ElliotFriend_ has quit IRC |
| # | 17:02:00 | youdonotexist has quit IRC |
| # | 17:02:06 | youdonotexist_ has joined #evergreen |
| # | 17:08:50 | tlilleberg has quit IRC |
| # | 17:17:54 | pmpcat has quit IRC |
| # | 17:18:50 | Dyrcona wrote OILS.pm and started adding things to CronScript.pm, only to discover oils_header.pl. |
| # | 17:19:34 | jeff | heh |
| # | 17:20:45 | dbs | Dyrcona: yeah, atz's intention for Cronscript.pm was to provide a home for the stuff that was rather grossly stuck in oils_header.pl (I think) |
| # | 17:21:09 | Dyrcona | dbs: Well, I'll pick up the torch. |
| # | 17:21:16 | jeff | Dyrcona++ |
| # | 17:21:19 | dbs | Dyrcona++ |
| # | 17:26:25 | jamesrf had the theme to chariots of fire pop into his head upon reading that |
| # | 17:26:27 | AaronZ-PLS has quit IRC |
| # | 17:29:13 | kmlussier has quit IRC |
| # | 17:29:56 | Dyrcona laughs and disappears slowly until the last to fade is a wide grin suspended in space. |
| # | 17:30:00 | Dyrcona has quit IRC |
| # | 17:31:17 | csharp | Dyrcona++ |
| # | 17:45:05 | jenny has left #evergreen |
| # | 17:49:21 | akilsdonk has quit IRC |
| # | 17:54:56 | matt_carlson has joined #evergreen |
| # | 18:03:10 | dbs has quit IRC |
| # | 18:03:42 | youdonotexist_ has quit IRC |
| # | 18:05:32 | youdonotexist has joined #evergreen |
| # | 18:29:16 | mdevilz has quit IRC |
| # | 18:37:28 | dbs has joined #evergreen |
| # | 18:37:28 | dbs has joined #evergreen |
| # | 18:40:16 | StephenGWills has left #evergreen |
| # | 18:40:19 | mrpeters-isl has quit IRC |
| # | 18:50:57 | matt_carlson has quit IRC |
| # | 18:57:21 | Dyrcona has joined #evergreen |
| # | 18:57:56 | yboston has quit IRC |
| # | 18:58:22 | Dyrcona | I can't find anything that ships with Evergreen that uses CronSript.pm, so I feel kind of safe in making a change to its behavior as regards the session method. |
| # | 18:59:03 | Dyrcona | Currently, it stores the session that was first created on the CronScript instance which prevents you from using session to create any new sessions. |
| # | 18:59:32 | Dyrcona | I want to change it so that the session is no longer stored, so you can use session for different services. |
| # | 18:59:45 | Dyrcona | Anyone have any objections? |
| # | 19:01:49 | dbs | Umm, there are definitely things using Cronscript |
| # | 19:02:37 | dbs | edi_fetcher, the Configure module (which underpins autogen.sh now), various tests |
| # | 19:02:53 | dbs | "ack Cronscript Open-ILS/src" |
| # | 19:03:01 | dbs | (maybe your camelcase threw you off ?) |
| # | 19:04:37 | Dyrcona | ah, maybe. |
| # | 19:07:20 | dbs | In any case - I'm +1 for making the move that you've suggested, but with careful testing :) |
| # | 19:08:58 | Dyrcona | dbs: so far I don't see anything that calls session more than once, but I'm still looking. |
| # | 19:09:25 | Dyrcona | most do Cronscript->new()->session() and use the session directly. |
| # | 19:09:38 | dbs | Dyrcona: yeah, I think your function was the only one I ran across, and that's why you worked around it right? |
| # | 19:09:52 | dbs | (err, yours wanted to but needed to work around it) |
| # | 19:10:37 | Dyrcona | dbs: Yeah, cause I missed the "set once" behavior of $self->{session} ||= OpenSRF::AppSession->create |
| # | 19:11:23 | Dyrcona | by eliminating, the $self->{session} ||= we can use the session method as often as we want. |
| # | 19:12:45 | dbs | Dyrcona: I know |
| # | 19:16:00 | Dyrcona | dbs: It looks safe to make the change. Nothing calls Cronscript->session() without an argument. |
| # | 19:16:53 | dbs wonders whether tsbere or gmcharlt know how to poke http://git.evergreen-ils.org/gitstats/Evergreen/ to get it to generate actual up-to-date stats |
| # | 19:17:13 | tsbere | I *can* poke it. Not 100% sure I know how. |
| # | 19:19:03 | tsbere | Looks simple enough |
| # | 19:19:04 | dbs | whoa - I had no idea North Bay Public Library migrated to Evergreen: http://www.esilibrary.com/esi/newsitem.php?id=2179 |
| # | 19:19:18 | dbs | gotta get the esilibrary news feed working again in planet! |
| # | 19:19:24 | gmcharlt | dbs++ |
| # | 19:19:36 | gmcharlt | tsbere: unless you're buried in it already, I can poke gitstats |
| # | 19:19:49 | tsbere | gmcharlt: I may be done with Evergreen's |
| # | 19:19:53 | tsbere was about to check if it looks updated |
| # | 19:20:07 | gmcharlt | tsbere: very good, carry on |
| # | 19:20:07 | dbs | The ESI newsfeed had been totally toasted, will see if it's fixed... |
| # | 19:20:33 | tsbere | Looks like I did evergreen correctly |
| # | 19:20:38 | tsbere hits OpenSRF while he is at it |
| # | 19:21:12 | dbs | tsbere++ |
| # | 19:21:23 | dbs sees no RSS or Atom feed in http://www.esilibrary.com/esi/newsitem.php?id=2179 source |
| # | 19:21:42 | youdonotexist has quit IRC |
| # | 19:22:40 | dbs pulls http://esilibrary.com/esi/news.rss from ohloh.net |
| # | 19:23:58 | tsbere | Hmmm |
| # | 19:24:11 | tsbere | is the gitstats not auto-updating, or were we just looking for "as of today" stats? |
| # | 19:24:49 | dbs | tsbere: it claimed to be auto-updating, but it wasn't actually showing any changed stats since mid-October |
| # | 19:25:03 | tsbere wonders why the cronjob wasn't running, then |
| # | 19:26:47 | dbs | (by "pulls" I mean "copies") |
| # | 19:27:22 | dbs | tsbere: what I see on my copy of gitstats/Evergreen was "Generated: 2011-11-30 01:10:28 (in 27 seconds)" |
| # | 19:27:55 | dbs | "Report Period: 2005-02-04 17:08:15 to 2011-11-23 15:14:32" |
| # | 19:28:23 | dbs | huh, now it says "Report Period: 2005-02-04 17:08:15 to 2011-11-16 09:48:11" |
| # | 19:29:02 | tsbere | dbs: AHA |
| # | 19:29:15 | tsbere | The end date on the report period is the last AUTHOR date. Not the last COMMIT date. |
| # | 19:29:29 | dbs | Okay, that makes sense |
| # | 19:29:40 | tsbere | So when you merge something from, say, mid-october, and that is the last commit... |
| # | 19:30:14 | dbs | but http://git.evergreen-ils.org/gitstats/Evergreen/authors.html was showing Author of Month going up to 2011-09, with nothing in 2011-10 or 2011-11 |
| # | 19:30:22 | tater-laptop has joined #evergreen |
| # | 19:30:36 | tsbere | Ok |
| # | 19:30:45 | dbs | now it goes to 11! |
| # | 19:31:00 | tsbere told gitstats to start writing the cronjob output to files (overwriting each day) so that errors can be looked for later |
| # | 19:33:17 | dbs | tsbere++ |
| # | 19:48:42 | tfaile has quit IRC |
| # | 20:39:13 | youdonotexist has joined #evergreen |
| # | 20:50:18 | Dyrcona push user/dyrcona/Cronscript-improvements to working. |
| # | 20:50:36 | Dyrcona will write up a launchpad bug tomorrow. |
| # | 21:15:00 | Dyrcona will write up a launchpad bug tomorrow. |
| # | 21:19:00 | jeff | Dyrcona++ |
| # | 21:42:00 | Dyrcona | yeah, well, we'll see how it works tomorrow. |
| # | 21:49:00 | jeff scribbles talk proposals on the back (well, front) of a napkin (well, PDF) |
| # | 21:50:00 | rangi | man you guys are slackers on saturdays |
| # | 21:50:00 | rangi | :-) |
| # | 21:50:00 | rangi | http://git.evergreen-ils.org/gitstats/Evergreen/activity.html#day_of_week |
| # | 21:52:00 | rangi | http://git.koha-community.org/stats/koha-master/activity.html#day_of_week <-- so are we |
| # | 21:56:00 | gmcharlt | rangi: Saturday is when we all do our design work |
| # | 21:56:00 | gmcharlt | right? ;) |
| # | 21:57:00 | gmcharlt | right? ;) |
| # | 21:58:00 | jeff | :-) |
| # | 21:59:00 | rangi | its all day scrumm meetings, with chickens and pigs and stuff |
| # | 22:07:00 | Dyrcona is going to sleep to dream up designs for new features. |
| # | 22:07:00 | Dyrcona is going to sleep to dream up designs for new features. |
| # | 22:08:00 | senator | my saturdays usually have chickens and pigs, but less development and more bbq pit |
| # | 22:16:00 | jeff | hrm. evergreen-ils.org appears down. |
| # | 22:18:00 | jeff | rather, web services on. |
| # | 22:42:00 | tsbere | jeff: Seems to be dead-dead. :( |
| # | 22:42:00 | tsbere | No ssh response either |
| # | 22:43:00 | jeff aims the csharp signal at the underside of a nearby cloud |
| # | 22:44:00 | tsbere was firing up traceroute as a "just in case something else is going on" test |
| # | 22:44:00 | tsbere | trace completes....but no SSH/HTTP. :( |
| # | 22:47:00 | dbs | http://planet.evergreen-ils.org/ trucks on! but it's hosted on a different machine |
April 10-13