| # | Time | Nick | Message |
|---|
| # | 00:39:07 | tildeequals has joined #evergreen |
| # | 09:56:39 | tildeequals has quit IRC |
| # | 09:56:55 | tildeequals has joined #evergreen |
| # | 11:04:28 | atz has joined #evergreen |
| # | 11:06:46 | atz_ has quit IRC |
| # | 11:54:16 | agJohn | atz: RE validation of the XML; the error indicates something that would be invalid in XML. The characteristics of the MARC data is not at issue. Fortunately, that error only showed up in a test environment. The news from the live environment is not good either, unfortunately. |
| # | 11:55:09 | agJohn | Anyone running 1.6.1.4? Getting an error that the username already exists when updating borrower info (such as a birth date or phone number). |
| # | 11:55:27 | atz | agJohn: that's probably because they already exist (but are marked deleted) |
| # | 11:55:43 | atz | er, nm.... misread |
| # | 11:55:49 | agJohn | If they're marked as deleted, they wouldn't show up in the patron search, would they? |
| # | 11:59:08 | atz | right, misread |
| # | 12:05:51 | agJohn | Anyone using 1.6.1.4? |
| # | 13:06:32 | agJohn | In 1.6.1.4 updating an existing user is apparently calling Actor.pm's sub _add_patron; surely this can't be what it should be doing? (That's where the check occurs for an existing user w/ that usrname; shouldn't even be in this code, should it?) |
| # | 13:13:23 | agJohn | The $patron->isnew flag is apparently not set properly upon entering sub update_patron, so the check to see if the patron should be added (on line 337) is sending the code down the wrong path. Not sure how the isnew flag is getting set, but it's not working properly on this 1.6.0.4-upgraded-to-1.6.1.4 install. So, if anyone can tell me if this works correctly for them, I'd be very interested... |
| # | 13:13:25 | agJohn | ...in comparing notes. |
| # | 13:21:31 | bshum has joined #evergreen |
| # | 13:22:07 | bshum | agJohn: I just tested our user editor (we're running 1.6.1.3 (with some hand patches)) and did not notice the issue as you're describing. The editor updates as expected. |
| # | 13:22:45 | bshum | agJohn: I can check the DB directly to see this flag issue |
| # | 13:23:30 | agJohn | I assume that $patron->isnew is something that's set within the code (there's no such field on the database). |
| # | 13:23:43 | agJohn | I appreciate your checking, bshum. |
| # | 13:24:29 | bshum | agJohn: Hmm |
| # | 13:25:24 | bshum | Just checking, but which patron editor are you using? The new single screen one or the original 7 split screen? |
| # | 13:26:14 | bshum | We're still using the original one |
| # | 13:26:28 | agJohn | Original 7 split-screen one; did not know there was a new one. |
| # | 13:26:47 | bshum | It's there, but not active by default. |
| # | 13:27:00 | bshum | You'll notice it more with 2.0 systems, since that became the default in 2.0+ |
| # | 13:27:08 | agJohn | (I can't keep up with all the changes...) |
| # | 13:32:16 | bshum | agJohn: So this happens with any user you try to edit? |
| # | 13:32:47 | agJohn | Yup; any user. |
| # | 13:32:48 | agJohn | The top-level call, according to osrfsys.log is to open-ils.actor.patron.update (which is the registered api_name for Actor.pm's sub update_patron. But there appears to be an embedded call in the JSON string passed to it: |
| # | 13:32:50 | agJohn | [05fb246ea5f4fa8499e097c1130aae23, Fieldmapper::actor::user=ARRAY(0x3084bc0)] |
| # | 13:32:51 | agJohn | Presumably the 32-digit hex value is the auth key so it appears the problem must be in the Fieldmapper::actor::user function (although I'm rather puzzled by the hex value in the ARRAY--that value does not seem to correspond to the actor.usr.id (which is sort of what I would have expected). |
| # | 13:37:26 | agJohn has quit IRC |
| # | 13:39:55 | artunit_ has joined #evergreen |
| # | 13:39:57 | eby_ has joined #evergreen |
| # | 13:39:58 | mjg_1 has joined #evergreen |
| # | 13:39:59 | sylvar_ has joined #evergreen |
| # | 13:39:59 | mtate_ has joined #evergreen |
| # | 13:40:00 | tsbere has quit IRC |
| # | 13:40:01 | lisppaste has quit IRC |
| # | 13:40:02 | brendan2 has quit IRC |
| # | 13:40:02 | eby has quit IRC |
| # | 13:40:02 | sylvar has quit IRC |
| # | 13:40:03 | gmcharlt has quit IRC |
| # | 13:40:03 | berick has quit IRC |
| # | 13:40:04 | artunit has quit IRC |
| # | 13:40:05 | artunit_ is now known as artunit |
| # | 13:40:06 | eeevil | agJohn: I bet you didn't update one of the fm_IDL.xml files. there's one /openils/var/web/reports (used by clients, exposed through apach) and one in /openils/conf. the former is I18N-ized in the packaged release. did you install from a packaged release? also, did you upgrade over a packaged release, or was your previous install from svn? |
| # | 13:40:07 | berick_ has joined #evergreen |
| # | 13:40:07 | dbwells has quit IRC |
| # | 13:40:07 | mtate has quit IRC |
| # | 13:40:08 | gmcharlt` has joined #evergreen |
| # | 13:40:08 | eeevil | Fieldmapper::actor::user=ARRAY(0x3084bc0) is how blessed objects that are not scalars are represented when they are printed directly. logging parameters is naive, it simply interpolates params into the log string, it does not try to disassemble them. |
| # | 13:40:26 | dbwells has joined #evergreen |
| # | 13:40:27 | CmptrWz has joined #evergreen |
| # | 13:40:27 | agJohn has joined #evergreen |
| # | 13:41:15 | eeevil | repeating due to netsplit ... : |
| # | 13:43:15 | agJohn | Actor.pm's sub update_patron's logic wrt the isnew flag is the same in 1.6.0.6 & 1.6.1.4; so I assume the problem is occurring before it gets to that point. |
| # | 13:43:24 | eeevil | agJohn: I bet you didn't update one of the fm_IDL.xml files. there's one /openils/var/web/reports (used by clients, exposed through apach) and one in /openils/conf. the former is I18N-ized in the packaged release. did you install from a packaged release? also, did you upgrade over a packaged release, or was your previous install from svn? |
| # | 13:43:25 | eeevil | Fieldmapper::actor::user=ARRAY(0x3084bc0) is how blessed objects that are not scalars are represented when they are printed directly. logging parameters is naive, it simply interpolates params into the log string, it does not try to disassemble them. |
| # | 13:43:47 | eeevil | no |
| # | 13:44:05 | eeevil | well, yes. the fm_IDL.xml files are out of sync |
| # | 13:44:13 | eeevil | and that's before the logic is called, I suppose |
| # | 13:46:11 | eeevil | isnew is created magically after the last named field. fields were (IIRC) added to the au class (Fieldmapper::actor::user in perl) between 1.6.0 and 1.6.1, so one side or the other is interpreting a new bit of data as the old isnew position |
| # | 13:46:19 | agJohn | I used a packaged release upgrading from a prior packaged release. |
| # | 13:46:50 | eeevil | check the fields of the au class in both of those. do they differ on your box? |
| # | 13:47:13 | agJohn | So, I would have thought that the fm_IDL.xml file would have been overwritten. Checking now. |
| # | 13:47:49 | eeevil | and, of course, you ran autogen post-upgrade-server-restart and pre-staff-client-start, yes? |
| # | 13:48:11 | phasefx__ has joined #evergreen |
| # | 13:48:33 | eeevil | that would have the same effect, because the JS generated by autogen from a 1.6.0 release will not fit a 1.6.1 release |
| # | 13:48:55 | agJohn | eevil: I think you hit the nail on the head; I do not think I remembered to run autogen.sh; that's likely the culprit. Thanks much! |
| # | 13:50:23 | phasefx_ has quit IRC |
| # | 13:51:09 | agJohn | That was it, all right. agJohn--; eeevil++ |
| # | 13:51:28 | agJohn | At least it's easy to fix.... |
| # | 13:51:38 | eeevil | indeed |
| # | 13:53:32 | eeevil | hrm.. the new, slimmed down upgrade instructions leave that out. I'll pull that in from the older, more verbose instructions |
| # | 13:56:47 | bshum has quit IRC |
| # | 13:59:07 | atz_ has joined #evergreen |
| # | 14:00:45 | mtate has joined #evergreen |
| # | 14:05:07 | mtate_ has quit IRC |
| # | 14:05:07 | atz has quit IRC |
| # | 14:06:45 | brendan2 has joined #evergreen |
| # | 14:13:36 | agJohn | eeevil: You might also add some notes about checking on batch processes (such as the fine generator, ClarkKent, &c); did remember to deal with most of these, but a note wouldn't hurt. |
| # | 14:32:30 | mtate_ has joined #evergreen |
| # | 14:36:40 | gmcharlt` has quit IRC |
| # | 14:36:40 | brendan2 has quit IRC |
| # | 14:36:43 | berick_ has quit IRC |
| # | 14:36:47 | berick has joined #evergreen |
| # | 14:36:56 | sylvar_ has quit IRC |
| # | 14:37:00 | sylvar has joined #evergreen |
| # | 14:37:19 | mtate has quit IRC |
| # | 14:37:21 | gmcharlt has joined #evergreen |
| # | 14:50:27 | BryanK has joined #evergreen |
| # | 15:48:27 | jhaig has joined #evergreen |
| # | 15:51:07 | jhaig | I'm trying to install 2.0 beta 3 with evergreen on one machine and postgres on a separate machine. When running eg_db_config.pl (on the evergreen machine) it is getting so far and then failing with "creation of Perl function "translate_isbn1013" failed: Can't locate Business/ISBN.pm in @INC" (followed by lots more errors). It is possible that I have not correctly worked out what commands need to be executed on each machi |
| # | 15:53:15 | atz_ | sudo cpan Business::ISBN |
| # | 15:54:22 | jhaig | Should that have been installed at a previous step? |
| # | 15:55:05 | jhaig | "Business::ISBN is up to date" (on the evergreen machine) |
| # | 15:56:06 | jhaig | it is installing now on the postgres machine |
| # | 15:56:45 | jhaig | Should it be included in the list of CPAN modules to install at step III on http://www.open-ils.org/dokuwiki/doku.php?id=server:2.0:install ? |
| # | 16:03:17 | jhaig | This may be a silly question, but do I need to go through the whole install on the postgres machine, even though I am not going to be running evergreen on it? I have found another cpan module that isn't installed (XML::LibXSLT), which in turn requires other packages that are not installed (something to do with xslt) |
| # | 16:46:10 | atz_ | jhaig: it's trying to create a psql function, which has to exist on the database server |
| # | 16:46:26 | atz_ | the psql function runs perl which has the Business::ISBN dependency |
| # | 16:46:32 | atz_ | make senes? |
| # | 16:46:33 | atz_ | *sense |
| # | 16:51:56 | jhaig | Makes some sense. I'm not too familiar with Postgres and I'm feeling my way a bit. I've only just discovered that the default configuration on Debian makes it awkward to connect (psql: FATAL: Ident authentication failed for user "evergreen"? What on earth is that supposed to mean? You didn't even ask me for a password!) |
| # | 16:52:07 | jhaig | (Sorry, a little bit of frustration coming in there) |
| # | 16:53:01 | atz_ | that's on the command line? |
| # | 16:53:17 | atz_ | try w/ a -P option (signalling password prompt desired) |
| # | 16:59:15 | jhaig | psql doesn't seem to have a switch to signal a password prompt - -P is for 'assignment'. Actually, I think I have found a solution - I have to go and edit a configuration file to allow me to connect to the database without creating a new 'evergreen' user just for this purpose. According to a blog post I've found (http://www.depesz.com/index.php/2007/10/04/ident/) this is a non-standard configuration that Debian decided |
| # | 17:02:26 | atz_ | ah, sorry, for psql it's apparently -W (to force password prompt) |
| # | 17:02:39 | atz_ | mysqlism muddies the waters |
| # | 17:03:34 | atz_ | psql -W -U evergreen evergreen # something like that |
| # | 17:03:39 | jhaig | I still get the "Ident authentication failed" - I just get asked for a password first. |
| # | 17:07:30 | atz_ | might have to repeat the admin authorization steps for whatever machine your are on |
| # | 17:07:41 | jhaig | Now I'm in, I connect to the evergreen database (\c evergreen) and try to list the tables (\d) but I get "No relations found." As far as I can tell, this means there are no tables. |
| # | 17:08:01 | atz_ | the EG install instructions only say to authorize localhost, you would need to authorize add'l host or IP |
| # | 17:08:39 | atz_ | \dn |
| # | 17:08:45 | atz_ | for namespace |
| # | 17:08:48 | jhaig | For the moment, I've given in a little and installed the database on the same machine. |
| # | 17:08:59 | atz_ | k |
| # | 17:09:36 | jhaig | Thanks. I haven't seen \dn anywhere. Everywhere I've seen so far says \d is used to list tables. |
| # | 17:10:05 | atz_ | we use full schema.table namespacing |
| # | 17:12:46 | atz_ | so you could do \d actor.[tab-complete] |
| # | 17:15:32 | atz_ | otherwise need to repeat the db installation steps, as i'm sure you already figured |
| # | 17:32:02 | jhaig | Thanks again for the help (and patience). |
| # | 17:32:05 | jhaig has quit IRC |
| # | 18:05:20 | youdonotexist has joined #evergreen |
| # | 19:28:37 | agJohn has quit IRC |
| # | 19:43:13 | senator_ has joined #evergreen |
| # | 19:44:07 | senator has quit IRC |
| # | 19:44:55 | tildeequals has quit IRC |
| # | 19:54:51 | youdonotexist has quit IRC |
| # | 22:55:22 | youdonotexist has joined #evergreen |
April 10-13