| # | Time | Nick | Message |
|---|
| # | 00:10:23 | dbs has quit IRC |
| # | 00:32:52 | enhancin has joined #evergreen |
| # | 01:28:36 | enhancin has quit IRC |
| # | 05:30:55 | bshum has quit IRC |
| # | 05:31:34 | bshum has joined #evergreen |
| # | 05:37:36 | dkyle has quit IRC |
| # | 05:37:38 | bradl has quit IRC |
| # | 05:37:39 | mtate has quit IRC |
| # | 05:37:39 | sylvar has quit IRC |
| # | 05:37:40 | hughbris has quit IRC |
| # | 05:38:59 | dkyle has joined #evergreen |
| # | 05:38:59 | bradl has joined #evergreen |
| # | 05:38:59 | mtate has joined #evergreen |
| # | 05:38:59 | sylvar has joined #evergreen |
| # | 05:38:59 | hughbris has joined #evergreen |
| # | 06:13:34 | tsbere has quit IRC |
| # | 06:14:10 | tsbere has joined #evergreen |
| # | 07:48:08 | collum has joined #evergreen |
| # | 07:53:01 | kmlussier has joined #evergreen |
| # | 08:13:26 | kmlussier_ has joined #evergreen |
| # | 08:13:43 | kmlussier has quit IRC |
| # | 08:13:53 | kmlussier_ is now known as kmlussier |
| # | 08:26:30 | csharp sighs |
| # | 08:27:05 | csharp | now contacting Linked In to make sure open-ils-dev email list does not receive further emails... |
| # | 08:27:17 | tsbere | I attempted to do that. Got an error. |
| # | 08:27:31 | csharp will contact Ephraim directly as well |
| # | 08:27:51 | tsbere | Might want to hit open-ils-general while you are at it, though. |
| # | 08:27:59 | csharp | tsbere: I'm filling out a "Contact Us" web form |
| # | 08:31:51 | tsbere prepares for a week or two of daily "We are giving you preferred access to this domain that is going to expire from us sitting on it for five years soon because you have a similar domain....if you are willing to pay 50x the price you should be willing to!" emails |
| # | 08:32:37 | jeff | tsbere: hmm? |
| # | 08:33:37 | tsbere | Our domain registrar email address got one this morning. They will send another every day for the next week or two, each coming from a different address and referring to different websites to take advantage of the offer. |
| # | 08:34:04 | jeff | lovely. enjoy! |
| # | 08:34:17 | tsbere | "You have the .org version of this site! We want to sell you the .com at 1000% or more markup!" |
| # | 08:42:45 | csharp | seems like Mailman should've flagged the LinkedIn email and held it for approval... |
| # | 08:42:53 | csharp looks at the settings |
| # | 08:44:11 | jeff | mailman does only basic checks of From: and possibly Sender: -- since the linkedin email had Ephraim's return address, and Ephraim is permitted to post, the linkedin email was sent to the list. |
| # | 08:44:32 | csharp | jeff: good to know |
| # | 08:44:39 | jeff | I wouldn't worry too much about it, or spend too much time reacting to it. Better things to do, and all that. :-) |
| # | 08:44:54 | tsbere | add a filter for "X-LinkedIn-Class". If that header shows up, hold the message? |
| # | 08:45:01 | csharp | jeff: yeah - definitely - just wanted to nip it in the bud ;-) |
| # | 08:46:45 | dbs has joined #evergreen |
| # | 09:01:10 | Dyrcona has joined #evergreen |
| # | 09:02:39 | Meliss has joined #evergreen |
| # | 09:03:48 | shopkins has joined #evergreen |
| # | 09:06:55 | yboston has joined #evergreen |
| # | 09:12:02 | shopkins | Hi. I'm having a problem logging into the staff client. Logging in via srfsh works fine - looks like the same issue as enhancin has been posting about. Everything worked on 9-6 then we loaded a large number of patron records, hold and transactions, now nothing |
| # | 09:12:30 | shopkins | we are in a brick environment and I have completely rebooted all servers involved with no luck. Any suggestions? |
| # | 09:13:20 | bshum has quit IRC |
| # | 09:13:20 | bshum has joined #evergreen |
| # | 09:14:46 | dbwells | shopkins, do you also have problems logging in via srfsh when using the public router, as enhancin does? |
| # | 09:17:44 | shopkins | dbwells: yes I get a bootstrapping error |
| # | 09:18:26 | dbwells | shopkins, can you paste that somewhere? |
| # | 09:18:57 | shopkins | dbwells: I did end up getting a "SUCCESS" message after a second try |
| # | 09:20:30 | dbwells | shopkins, well, that seems positive. I am guessing your problem is different than enhancin then, which is good, because nobody has cracked that one. |
| # | 09:21:04 | dbwells | shopkins, what error do you get when logging in via the client? |
| # | 09:22:59 | shopkins | dbwells: Copied "Network or server failure. Please check your Internet connection to 134.241.192.80 and choose Retry Network. If you need to enter Offline Mode, choose Ignore Errors in this and subsequent dialogs. If you believe this error is due to a bug in Evergreen and not network problems, please contact your help desk or friendly Evergreen administrators, and give them this information: method=open-ils.actor.org_unit_settin |
| # | 09:24:02 | dbwells | shopkins: your error got cut off at "method=open-ils.actor.org_unit_settin..." |
| # | 09:27:34 | tsbere looked at the IP address and almost thought shopkins was talking to a MVLC server, before he finished reading the IP address |
| # | 09:29:41 | shopkins | dbwells:http://paste.lisp.org/display/124637 |
| # | 09:30:07 | jenny has joined #evergreen |
| # | 09:36:15 | dbwells | shopkins: it seems possible that you have an invalid (i.e. not JSON) org_unit setting. Try this query: select id,evergreen.is_json(value) from actor.org_unit_setting; |
| # | 09:36:25 | dbwells | do any say 'f'? |
| # | 09:37:10 | tsbere | select * from actor.org_unit_setting where not evergreen.is_json(value) |
| # | 09:37:25 | dbwells | or that :) |
| # | 09:38:35 | tsbere finds that the ou, name, and value are all useful to figure out what broke |
| # | 09:39:28 | shopkins | dbwells: several say false |
| # | 09:40:27 | dbwells | shopkins: okay, if you try tsbere's query you can easily see what is wrong, hopefully. |
| # | 09:42:49 | shopkins | dbwells: I tried tsbere query and get 12 rows returned. Not sure exactly what I am looking for or at |
| # | 09:44:08 | dbwells | shopkins: the 'value' column will have something in it which is not valid JSON. If you have trouble figuring it out, it is likely safe to delete the offending setting rows, then re-create the settings properly in the UI (once you can log in). |
| # | 09:49:14 | shopkins | dbwells: ok I will delete and let you know what happens |
| # | 09:50:52 | dbs | dbwells++ |
| # | 09:50:54 | dbs | tsbere++ |
| # | 09:54:49 | dbs had no awareness of the evergreen.is_json() function or that non-JSON would break things horribly |
| # | 09:55:16 | phasefx has a pullrequest branch adding that as a check constraint |
| # | 09:55:48 | phasefx | I don't think you can break things through the UI |
| # | 09:56:03 | phasefx | could be wrong though :) |
| # | 09:56:24 | berick | right, the UI will json-ify everything coming in |
| # | 09:56:48 | berick | dbs: about to merge working/user/dbs/tpac-css-buttons (then mtg), then master merge, booyah |
| # | 09:57:06 | dbs | wow: our JSPAC home page makes 83 requests for 406K of data, the TPAC home page makes 16 requests for 39K of data |
| # | 09:57:20 | dbs | berick++ |
| # | 09:57:31 | berick | dbs++ killin' the images |
| # | 09:57:34 | dbs will pick up phasefx's pullrequest, sounds like an excellent one |
| # | 10:00:04 | dbs | shopkins: fwiw, I bet many of your non-JSON issues were something like (((SET value = 'foo'))) instead of (((SET value = '"foo"'))) -- note double-quotes required around string values |
| # | 10:00:08 | jeff | tpac hacking should be done against collab/berick/template-toolkit-opac-master-merge and best against a fresh install from that branch, or can the tpac bits work against say, 2.1-rcX? |
| # | 10:00:17 | berick | for future reference, a pre-image-cleanup branch is living at esi/template-toolkit-opac-master-image-buttons, since I might need it for my own nefarious purposes |
| # | 10:00:24 | shopkins | dbswells: Ok I deleted those lines and can log in now. As far as breaking things through the UI, we imported these settings from a training machine to our production machine so the import could have gone wrong |
| # | 10:00:49 | shopkins | dbs: thanks for the info and the fix. Will check on the double quotes |
| # | 10:00:50 | dbs | berick: cool, preserving history is good |
| # | 10:02:11 | berick | jeff: best done w/ fresh install. it moves a lot of stuff around, so 2.1 is pretty much out of the question |
| # | 10:02:12 | dbs hopes that someone with greater Web/CSS skills than his own will tackle the more daunting task of moving to a non-fixed-width layout |
| # | 10:02:33 | jeff | berick: thanks |
| # | 10:03:59 | tsbere | Wait, tpac is fixed width right now? |
| # | 10:04:03 | tsbere might have to tackle that |
| # | 10:04:11 | dbs | heh - search results page for a search that results in a single hit is 18 requests on TPac vs. 120 requests on our JSPAC (which is more than default skin, but still) |
| # | 10:04:27 | dbs | tsbere: yeah, 974px IIRC |
| # | 10:04:32 | jeff | hrm. before i try to chase this down, has anyone else noticed the following in an Evergreen Makefile.install output? /bin/bash: line 0: [: too many arguments |
| # | 10:04:56 | dbs | jeff: two pg_config files? What version of the Makefile.install? |
| # | 10:05:09 | jeff | rel_2_1 branch |
| # | 10:05:29 | dbs | and completely up to date? |
| # | 10:05:40 | jeff | as of last night |
| # | 10:05:48 | jeff | checking to see what i might be behind on now |
| # | 10:06:02 | dbs | and what distro? |
| # | 10:06:13 | jeff | sorry, forgot to mention. debian-squeeze |
| # | 10:07:09 | jeff | fully up to date. oh, maybe the "is old postgres installed" checks, you're thinking? |
| # | 10:07:23 | dbs | yep, the checks that I committed yesterday |
| # | 10:07:52 | dbs | http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=45f2b618fd0485e585b6744a51b9e9719fe1f038 and http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4194c87743f278b7041e938531adacd3caaf50e6 |
| # | 10:08:39 | dbs | jeff: freshly installed debian-squeeze image? |
| # | 10:08:52 | jeff | not fresh, but close. |
| # | 10:08:53 | dbs wonders if the checks fail in the absence of any packages |
| # | 10:09:09 | dbs | e.g. if libpq5 is not installed at all, kabooms? |
| # | 10:09:21 | jeff | libpq-dev libpq5 were present and were upgraded by Makefile.install |
| # | 10:09:41 | dbs | huh. More context, such as a paste, would be useful then |
| # | 10:09:51 | dbs | so that we have a clue about what is blowing up where. |
| # | 10:10:18 | dbs was testing on debian-squeeze and did not see said blowups |
| # | 10:10:56 | jeff | everything seemed to work well, i just noticed the error in the output. looking deeper. |
| # | 10:13:00 | jeff | $ aptitude versions libpq-dev | grep ^i | sed 's/^i[ \t]*//' | cut -d. -f1 |
| # | 10:13:00 | jeff | A 9 |
| # | 10:13:10 | jeff | that's the extra argument, i think. |
| # | 10:13:23 | jeff | full line before sed is: |
| # | 10:13:24 | jeff | i A 9.0.4-1~bpo60+1 squeeze-backports 100 |
| # | 10:14:14 | jeff | of course, that's after it was upgraded by Makefile.install -- presumably before it was something starting with i A 8.4.8-0squeeze2 |
| # | 10:15:21 | jeff | dbs: is that helpful? |
| # | 10:15:54 | dbs | jeff: I would say so. |
| # | 10:17:10 | dbs needs to rebuild vbox drivers before retesting |
| # | 10:17:55 | dbs | Of course, if you want to supply a fix that would be even better |
| # | 10:20:45 | jeff | two or three characters, but i'm game to supply the change and have you test :) |
| # | 10:20:46 | tsbere | Is there a minimal number of things that need to be restarted if I edit a SELECT query in fm_IDL.xml (instead of restarting everything)? |
| # | 10:22:31 | berick | tsbere: I believe restarting services listed in the controller= attribute are all that are needed. in most cases, restart_c |
| # | 10:23:12 | tsbere | Hmmm. cstore, pcrud, reporter-store. That all covered by restart_c? |
| # | 10:23:20 | berick | yep |
| # | 10:27:06 | tsbere | There an easy way to ask the backend "what is the query for this IDL entry?" via, say, srfsh? |
| # | 10:29:11 | berick | hm, not that I recall |
| # | 10:29:47 | agJohn | Anyone encountered a problem like this (apparently the exception originates in the Perl DateTime module)? |
| # | 10:29:49 | agJohn | open-ils.storage [ERR :16186:action.pm:919:] Error processing overdue circulation [1104732]: |
| # | 10:29:50 | agJohn | Invalid local time for date in time zone: America/Chicago |
| # | 10:29:51 | agJohn | (Running EV 1.6.1.8 on Ubuntu 10.04 w/ DateTime info as per paste) |
| # | 10:31:08 | agJohn | Except that the paste apparently didn't work.... |
| # | 10:31:22 | tsbere | http://paste.lisp.org/display/124640 That paste? |
| # | 10:32:05 | agJohn | Yeah, that'd be it (how come it didn't pop up in the display here?). |
| # | 10:34:23 | tsbere | The bot isn't in the channel |
| # | 10:34:35 | jeff | long story... paste.lisp.org is broken when posting to channel sometimes. you can get the list of pastes for #evergreen here, and pick yours and send the link here manually: http://paste.lisp.org/list/evergreen |
| # | 10:34:39 | tsbere | So the server gives a white screen o death instead of having sane "the bot isn't there, ignore it then" code |
| # | 10:36:12 | agJohn | Ah so. OK. So, to the error. The only exact reference I've found to this kind of problem is this: http://www.44342.com/perl-f863-t13674-p1.htm (5 years old and no replies in the forum). |
| # | 10:38:01 | agJohn | The dates in the circ in question are not even close to a date related to, say, a transition to daylight time. So, this is all very puzzling. |
| # | 10:40:43 | agJohn | Referring to the cpan m info, is this saying there's a 0.70 version and the installed version is 0.52? Is that as it should be? |
| # | 10:49:44 | senator | agJohn: i'm not sure about cpan m, but if you're trying to determine what version of the perl module DateTime you have installed, this is the way to do it from a shell: perl -mDateTime -e 'print $DateTime::VERSION,"\n";' |
| # | 10:52:22 | agJohn | Yup; that also gives 0.52. So, the question becomes, is there a reason for using the 0.52 version with EV or is that just what happened to land on the server (in /usr/lib/perl5) when it was originally set up and I can go ahead and upgrade and perhaps solve this problem? |
| # | 10:53:49 | mrpeters-isl | heck FWIW we're on 0.42 |
| # | 10:53:53 | senator | no particular version of DateTime is targeted by evergreen as far as i know. i've seen older and newer versions than that work fine. |
| # | 10:54:12 | agJohn | Given the relative silence about the problem itself, I guess I'll try it on a test environment and see if a newer version happens to resolve it. |
| # | 10:54:20 | mrpeters-isl | 0.66 in some other places |
| # | 10:54:40 | agJohn | Thanks for the info on the version number, mrpeters-isl & senator. |
| # | 10:54:51 | mrpeters-isl | no probelm |
| # | 10:55:15 | sal_ has joined #evergreen |
| # | 10:59:20 | dbs | agJohn: i was on a call. did you paste the actual data from the offending circ in question? |
| # | 11:00:01 | dbs | and/or the date that the server thinks it currently is? |
| # | 11:00:02 | agJohn | Nope, but I'll add it as an annotation. |
| # | 11:01:35 | dbs | also, if distro updates for time zones have been applied (I'd expect/hope DateTime to rely on the OS for its info, but could be wrong) |
| # | 11:05:52 | bshum | Does anyone know who this sammywilson wiki user is and why they're editing old pages to put links to stuff? Spammer? |
| # | 11:07:34 | gmcharlt | bshum: based on http://www.evergreen-ils.org/dokuwiki/doku.php?id=advocacy:newsletter&do=diff, spammer |
| # | 11:08:02 | moodaepo | Wouldn't someone have to have approved the account? |
| # | 11:08:39 | phasefx | not if there's a hole in dokuwiki |
| # | 11:08:53 | moodaepo | phasefx++ |
| # | 11:09:06 | moodaepo goes to check on that...and will delete the user |
| # | 11:10:04 | agJohn | dbs: I've added the circ data to the paste: http://paste.lisp.org/display/124640 |
| # | 11:10:05 | agJohn | Also worth noting that the DB in question was just moved from one server to another (and it used to be physically housed in the Eastern timezone; it appears that the DB was set to just use the local timezone on the server). |
| # | 11:10:58 | phasefx | moodaepo: I reverted that page |
| # | 11:12:28 | kmlussier has quit IRC |
| # | 11:12:47 | dbs | agJohn: huh. I would try changing the due date of "2010-09-23 23:59:59" to "2010-09-23 12:59:59" just to see what happens for that one circ |
| # | 11:13:10 | dbs | but I have no experience with migrating databases from one timezone to another |
| # | 11:14:18 | agJohn | This is not an isolated problem; hundreds of errors of this type thrown by the batch processes for dealing with overdues and standing penalties. |
| # | 11:15:19 | kmlussier has joined #evergreen |
| # | 11:15:33 | agJohn | So, it's not going to be easy to see what happens with one particular circ, but I'll give that (or something similar) a shot. |
| # | 11:16:13 | agJohn | The timezone info on the server is surely current enough for US timezones--it was just set up last month.... |
| # | 11:16:34 | agJohn | I thnk I'll try updating the DateTime module just for the heck of it. |
| # | 11:16:55 | agJohn | It sure seems like it must be a bug in DateTime, ultimately. |
| # | 11:18:31 | mrpeters-isl | agJohn: I'm not seeing an error in your paste. Perhaps I'm overlooking it? |
| # | 11:18:56 | agJohn | Sorry, the error (stupidly) was in the main chat text. |
| # | 11:19:14 | agJohn | (Was ONLY in the main chat text; I'll add it to the paste.) |
| # | 11:19:23 | mrpeters-isl | ahh now i see |
| # | 11:19:55 | mrpeters-isl | wasn't going back far enough |
| # | 11:20:41 | mrpeters-isl | ok, so just a hunch, but i wonder if the database is appending "-5" to that |
| # | 11:21:01 | mrpeters-isl | and its saying wait, central time zone can't be 2010-09-09 16:02:03.876097000-5 |
| # | 11:21:33 | berick | tsbere: am I reading this rigth? [http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/sql/Pg/110.hold_matrix.sql#l146] if circ.holds.usr_not_requestor is set, user and requestor profile groups are swapped? |
| # | 11:22:48 | berick | and if so, why do we want the user profile set to the requestor profile? |
| # | 11:23:40 | agJohn | mrpeters-isl: meaning it's trying to subtract 5 hours (or 6) but the effect is all wrong because of the textual representation? |
| # | 11:24:49 | mrpeters-isl | yeah, im thinking its trying to apply the wrong offset |
| # | 11:24:54 | mrpeters-isl | have a look at postgresql.conf |
| # | 11:24:56 | mrpeters-isl | #timezone = unknown # actually, defaults to TZ environment |
| # | 11:25:07 | mrpeters-isl | maybe we can look at your timezone settings in there, if any |
| # | 11:25:56 | mrpeters-isl | but im thinking since it's the system time which is America/Chicago you might be trying to insert a timestamp with timezone that doesn't match a possible offset for America/Chicago |
| # | 11:27:13 | mrpeters-isl | since chicago is in DST, and your date is within the DST time period i bet it's expecting UTC -6 |
| # | 11:27:46 | vagojan has joined #evergreen |
| # | 11:27:54 | mrpeters-isl | i bet if that date were sometime after November or whenever we switch now (who ever remembers!) it'd accept the -5 that it's probably using from when it was in the Eastern timezone |
| # | 11:28:43 | agJohn | You may be onto something. But I'm not sure why the date/time in question would evaluate to invalid, rather than just being off by one hour (in the case you describe). |
| # | 11:29:27 | mrpeters-isl | i'm just thinking if you were trying to insert something other than -5 or -6 it would fail because any other offset isn't valid for that TZ |
| # | 11:30:10 | vagojan has left #evergreen |
| # | 11:30:12 | agJohn | Ah, understoood. So you're thinking it's essentially a configuration problem of some kind. |
| # | 11:30:14 | agJohn | I'll sure check the postgresql.conf. The entry in the DB's pg_catalog.pg_settings has timezone = local (use the system date/time). |
| # | 11:30:55 | mrpeters-isl | yeah, kind of just taking a blind stab at it but maybe something to try playing with |
| # | 11:31:23 | agJohn | Much appreciated. I hadn't come up with anything coherent to blindly stab at! |
| # | 11:31:35 | mrpeters-isl | maybe adjust one of your inserted circs to include -5 and see what happens |
| # | 11:32:02 | mrpeters-isl | http://stackoverflow.com/questions/1789862/scheduling-scripts-at-a-different-timezone |
| # | 11:34:56 | mrpeters-isl | agJohn: http://pastie.org/2526956 (from TimeZone.pm) |
| # | 11:35:20 | mrpeters-isl | this has gotta be the problem |
| # | 11:38:23 | mrpeters-isl | agJohn: also see "If you specify an ambiguous time, then the latest UTC time is always used, in effect always choosing standard time. In this case, you can simply subtract an hour to the object in order to move to saving time" on http://search.cpan.org/~drolsky/DateTime-0.70/lib/DateTime.pm |
| # | 11:38:59 | agJohn | Yes, but, the problem should only occur in the Spring on the night when transitioning to CDT. For instance, the UTC value that corresponds to CST 2:30 am does not exist in the timezone--there is no 2:30 am (it jumps from 2:00 am to 3:00 am). |
| # | 11:41:47 | agJohn | That's not to say it couldn't be a bug that leads to incorrectly deciding that this is the case when it is not. |
| # | 11:43:05 | dbs has quit IRC |
| # | 11:44:11 | agJohn | That is, if the time were ambiguous by an hour, it wouldn't matter. But, my guess is that you are correct and that the time being 23:59:59 (with the date) is invalid because it's effectively changing the date. In which case, dbs's solution of moving the time to close to noon rather than midnight should fix it. |
| # | 11:50:46 | agJohn | E.g. 2010-09-09 24:02:03 |
| # | 11:51:45 | agJohn | is an invalid time. But I think it's more likely that the 23:59:59 time is the problem and it might end up being 24:59:59. |
| # | 11:51:50 | akilsdonk has joined #evergreen |
| # | 11:52:57 | Dyrcona | Time: such a simple concept, yet not. |
| # | 11:54:03 | Dyrcona | "It's a bunch of wibbly-wobbly, timey-wimey stuff." |
| # | 11:54:15 | tsbere | berick: That is to preserve existing behaviour(ish) on upgraded systems from before usr was checked at all |
| # | 11:56:42 | tsbere | berick: See http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/sql/Pg/110.hold_matrix.sql;hb=refs/heads/rel_2_0#l77 |
| # | 11:59:22 | dbs has joined #evergreen |
| # | 12:02:38 | kmlussier has quit IRC |
| # | 12:02:59 | kmlussier has joined #evergreen |
| # | 12:03:10 | moodaepo | phasefx: Helps prevent spammers if I hadn't forgotten to disable open registration...DO'H |
| # | 12:03:29 | phasefx | oy |
| # | 12:04:27 | moodaepo | I haven't allowed/created any new users so if you could take a quick look through users.auth.php and make sure they are legit it would be great, none of the users popped out when I looked just now. |
| # | 12:05:25 | berick | tsbere: i guess I'm unclear on why, now that usr is checked, we want recipient.profile to bet set to requestor.profile. i would have assumed that circ.holds.usr_not_requestor only affected what the code uses as the requestor profile. IOW, http://paste.lisp.org/display/124641 |
| # | 12:05:36 | eeevil | so ... meeting? |
| # | 12:05:39 | berick | s/bet set/be set/ |
| # | 12:06:45 | tsbere | berick: That paste isn't even valid, I don't think. Mine, as the comment says, swaps the two, rather than duplicating user into requestor. |
| # | 12:07:08 | berick | tsbere: right, i'm saying duplicating is what we want |
| # | 12:07:18 | berick | the sql may not be valid, i don't know |
| # | 12:07:19 | tsbere | twas a decision based on "before my code usr wasn't used, at all" |
| # | 12:08:46 | tsbere | The code as is lets you still do things based on user and requestor groups, but if you have that setting enabled swaps them. Which may be confusing, but still allows for things to function after upgrades. |
| # | 12:08:47 | berick | again, if I'm reading this right, in the 2_0 code, the only value that's changed is current_requestor_group (i.e. requestor_object.profile). In the latest code, both requestor_object.profile and user_object.profile are changed |
| # | 12:09:33 | tsbere | and in the 2_0 code the usr_grp field in the table is ignored, 100%. |
| # | 12:10:12 | tsbere | eeevil: Meeting sounds good. |
| # | 12:10:33 | berick | ok, i think there's some confusion about what circ.holds.usr_not_requestor is supposed to do, and it could very well be on my part. /me tables for now |
| # | 12:21:11 | berick | *tap* *tap* |
| # | 12:26:03 | bshum | Well, there was supposed to be a meeting. Anybody care to lead or note take? (I can roll through the agenda too) |
| # | 12:26:08 | bshum | http://evergreen-ils.org/dokuwiki/doku.php?id=dev:meetings:2011-09-13 |
| # | 12:26:24 | bshum | Though I just noticed it's marked meeting leader: tsbere |
| # | 12:26:27 | bshum | :) |
| # | 12:27:02 | tsbere led a previous meeting but made no promises for future ones |
| # | 12:27:18 | bshum | Might just be a carryover from the previous meeting. |
| # | 12:29:02 | bshum | Anywho, should we have the meeting or delay (since it's already past time and pretty quiet) |
| # | 12:29:20 | bshum | There's 3 action items listed, we could run through them quickly enough too |
| # | 12:29:27 | bshum | If everyone is here. |
| # | 12:29:41 | berick is here |
| # | 12:30:56 | akilsdonk has quit IRC |
| # | 12:31:42 | akilsdonk has joined #evergreen |
| # | 12:32:05 | phasefx is here |
| # | 12:33:36 | csharp shows up because decisions are made by those who show up |
| # | 12:33:49 | bshum | Heh |
| # | 12:34:07 | bshum | Well, the action items are about 2.1 status and tt-opac release notes. |
| # | 12:34:09 | phasefx moves that we rename Evergreen to Turpentine |
| # | 12:34:23 | bradl seconds |
| # | 12:34:35 | moodaepo motion carries |
| # | 12:34:45 | csharp changes the website and logo |
| # | 12:34:56 | akilsdonk has quit IRC |
| # | 12:35:23 | akilsdonk has joined #evergreen |
| # | 12:35:24 | moodaepo | bshum: Is the release notes berick & dbs then? |
| # | 12:35:35 | bshum | moodaepo: That's right. |
| # | 12:36:36 | bshum | Given how quiet it is, I guess we're skipping this meeting officially. Unofficially I suppose we can talk about 2.1 and such too. Since I'm always interested to know when we get 2.1.0 cut :) |
| # | 12:36:48 | moodaepo | +1 |
| # | 12:37:31 | denials | bah, dbs was here but connection timed out |
| # | 12:37:34 | berick | tpac release notes http://evergreen-ils.org/dokuwiki/doku.php?id=dev:opac:template-toolkit:release_notes |
| # | 12:37:45 | denials | berick++ |
| # | 12:37:45 | dbs has quit IRC |
| # | 12:37:53 | moodaepo | I guess meeting is back on...bshum |
| # | 12:38:16 | moodaepo | berick++ |
| # | 12:38:58 | denials | FWIW, Conifer is hoping to migrate to 2.2-ish in December, primarily for TPac |
| # | 12:39:18 | moodaepo | conifer++ |
| # | 12:39:29 | csharp | TPac lives! |
| # | 12:39:44 | denials | moodaepo: have you done any testing of the absolute latest TPac? Particularly interested in your keen web design eye |
| # | 12:40:11 | moodaepo | denials: I moved the test server from hardy to lucid so got slowed down since yesterday |
| # | 12:40:47 | moodaepo | But hope to have an update in channel by the end of today |
| # | 12:41:17 | denials | sweet: the more eyes, the shallower I am |
| # | 12:41:28 | senator | merge! merge! merge! feature branches off feature branches are getting too hard to keep up with |
| # | 12:41:33 | dbs has joined #evergreen |
| # | 12:41:40 | berick | if there is no frantic waving of arms, I'm going to merge tpac to master after the meeting |
| # | 12:42:09 | dbs waves arms in excitement, not to be confused with franticness |
| # | 12:42:14 | tlilleberg has joined #evergreen |
| # | 12:42:22 | eeevil calls meeting to a close, so merging can commence |
| # | 12:42:22 | gmcharlt is frantically waving his arms doing the +1 cheer |
| # | 12:42:35 | jeff | +1 \o/ |
| # | 12:42:58 | moodaepo | +1 |
| # | 12:43:20 | berick | excellent |
| # | 12:44:38 | mmorgan has joined #evergreen |
| # | 12:45:22 | akilsdonk has quit IRC |
| # | 12:46:34 | moodaepo | eeevil: About cutting 2.1 thoughts? |
| # | 12:47:16 | eeevil | I want to do it right now |
| # | 12:47:21 | dbs | the "2.1 blockers" discussion had some candidates at the start but kind of devolved a bit |
| # | 12:47:26 | eeevil | but I've been waved off |
| # | 12:47:56 | gmcharlt will have some patches for the EDI blockers this week |
| # | 12:48:21 | moodaepo | gmcharlt++ |
| # | 12:48:22 | dbs | jamesrf mentioned https://bugs.launchpad.net/evergreen/+bug/800477 and https://bugs.launchpad.net/evergreen/+bug/800478 |
| # | 12:48:23 | eeevil | some fixes have been ... I hesitate to say "demanded", but ... but, has anyone "strongly requesting" these fixes happen before 2.1.0 looked into them? |
| # | 12:49:00 | dbs did some groundwork exploration of some of the EDI madness |
| # | 12:49:14 | jeff | https://bugs.launchpad.net/evergreen/+bug/843961 should probably be considered a blocker for those in replicated setups. |
| # | 12:49:53 | gmcharlt | jeff: that one is also in an ESI queue for this week |
| # | 12:50:02 | eeevil | there's an apparent problem with the marc editor, and its current inability to pick a record type (or show the record type dropdown) that I would add to the blockers list ... and will try to work on right away |
| # | 12:50:27 | jeff | gmcharlt++ |
| # | 12:50:40 | dbs | gmcharlt++ |
| # | 12:51:19 | gmcharlt | jeff: speaking of libraries using replication ... if you can do a once over to scare up any more, that would be great |
| # | 12:51:25 | dbs | Is the "Funds transfer always transfers entire fund, not specified amount" bug (https://bugs.launchpad.net/evergreen/+bug/800478) on anybody's list? |
| # | 12:51:44 | gmcharlt | glitches, that is, not libraries using replication -- pretty I know who most of them are :) |
| # | 12:51:54 | eeevil | dbs: that may have been addressed actually, I'll check |
| # | 12:52:58 | jeff | gmcharlt: if we find any, i'll be sure to pass them along. offhand, the "Refresh" button in holdings maintenance could probably benefit from being authoritative, but 1) not as large an issue as the bug I linked, and 2) might even be the same api call -- i haven't checked. |
| # | 12:53:29 | dbs | eeevil: cool; the other bug jamesrf reported (amounts are off when you have both encumbered and spent funds) is of interest too :) https://bugs.launchpad.net/evergreen/+bug/800477 |
| # | 12:55:08 | berick will take a crack at 800478 and 800477 |
| # | 12:56:48 | dbs | berick++ |
| # | 12:59:08 | berick grabs 0621 |
| # | 13:02:08 | dbs | jeff: fwiw, it's possible that debian improved their backports such that postgresql 8 + 9 could co-exist; they managed to do that in the past with 7 + 8 |
| # | 13:02:46 | dbs | jeff (or anybody else) - it would be great if that could be confirmed and all of the detection/removal hackery ripped out |
| # | 13:03:29 | jeff | so, install squeeze -- install old libpq stuff, try to install 9 from backports without removing things? |
| # | 13:04:25 | dbs | jeff: install squeeze + OpenSRF Makefile.install + 9 from backports (without Evergreen Makefile.install) for the most accurate test, I think |
| # | 13:04:57 | dbs | IIRC, libpq gets pulled in by OpenSRF Makefile.install in the first place |
| # | 13:05:11 | berick | jeff: http://svn.open-ils.org/trac/ILS-Contrib/browser/ESI-Examples/trunk/tools/eg_dev_squeeze_installer |
| # | 13:05:43 | berick | it's a good reference, if you don't want the whole shebang |
| # | 13:06:20 | berick | it installs pg via backports before anything else, which seems to work ok |
| # | 13:07:38 | berick lulz |
| # | 13:07:38 | berick | # On branch master |
| # | 13:07:38 | berick | # Your branch is ahead of 'origin/master' by 821 commits. |
| # | 13:07:47 | dbs | awesome |
| # | 13:09:18 | eeevil | 821 delicious, templaty commits |
| # | 13:10:09 | agJohn | Is there someplace in EV that gets the timezone other than just from the OS? |
| # | 13:10:33 | eeevil | agJohn: the database can have its own TZ |
| # | 13:10:38 | akilsdonk has joined #evergreen |
| # | 13:10:53 | eeevil | ALTER DATABASE SET TIMEZONE TO 'America/New_York'; etc |
| # | 13:10:55 | agJohn | That part I understand; I'm just trying to verify that they're not out of sync. |
| # | 13:11:40 | agJohn | (That is, the DB thinks it's in Central timezone and EV is picking it up from somewhere else.) |
| # | 13:12:02 | eeevil | right, the db is other than the OS ... beyond that, no (unless you modify the env of the user starting evergreen processes) |
| # | 13:13:06 | eeevil | Updating 83e5388..b77e56f WHEEEE |
| # | 13:14:23 | agJohn | So does EV get the TZ from the DB or the OS? (If you can change it via the env of the user starting the EV processes)? |
| # | 13:14:42 | dbs | berick: did you guys do any performance / stress-testing that compares oldPAC to newPAC? That would make a great blog post |
| # | 13:14:43 | eeevil | agJohn: the db gets it from the db, the perl and c get it from the os |
| # | 13:15:05 | agJohn | Thanks. |
| # | 13:18:06 | berick | dbs: we did load testing to look for memory leaks and make sure we could get good overall throughput, but it's difficult to compare UI apples to oranges (programaticaly) since rendering is handled so differently between the two. |
| # | 13:19:00 | berick | if you run a web spider against tpac, you are getting pretty close to real page-delivery performance numbers, but jspac is a whole other beast |
| # | 13:19:16 | dbs | berick: ah, that makes sense. You would need to do something like automate a browser and have it tell you when all jspac requests are complete for a given page |
| # | 13:19:29 | dbs | E_OUT_OF_BOUNDS for our purposes :) |
| # | 13:20:05 | berick | right, though we have collected API calls made on a given page for jspac and pouned on those, but yeah, still not the same |
| # | 13:20:12 | berick | *pounded |
| # | 13:24:13 | csharp | wow - that git commit message was 4MB large and required administrative approval ;-) |
| # | 13:26:07 | Dyrcona | ttopac-master-merge was merged. :) |
| # | 13:33:31 | akilsdonk has quit IRC |
| # | 13:39:39 | edoceo has quit IRC |
| # | 13:53:07 | edoceo has joined #evergreen |
| # | 13:53:09 | csharp | I'm doing a practice 1.6.1.8 - 2.0.9 upgrade on a snapshot of the PINES production DB... |
| # | 13:53:51 | tspindler has joined #evergreen |
| # | 13:53:57 | csharp | when I run the 1.6-2.0 upgrade script, I get: ERROR: could not access file "$libdir/slony1_funcs": No such file or directory |
| # | 13:54:22 | csharp | so, does that mean that slony-I is required for upgrading servers? |
| # | 13:54:42 | csharp | it's not in the pre-reqs for a standalone DB server, so I didn't have it installed |
| # | 13:54:43 | eeevil | csharp: you didn't remove some slony triggers from your restored db |
| # | 13:55:18 | csharp | eeevil: ah - thought I had gotten them by removing the replication table I dropped |
| # | 13:55:39 | eeevil | table? no, lots more than one table |
| # | 13:55:42 | gmcharlt | csharp: try a drop schema _replication cascade; |
| # | 13:56:57 | csharp | ok - thanks for that eeevil and gmcharlt |
| # | 13:57:11 | csharp | this is one reason I'm doing this - to learn ;-) |
| # | 13:58:55 | Dyrcona | always better to practice a few times before doing it for real. |
| # | 13:59:54 | gmcharlt | Dyrcona: no sense of adventure ... ;) |
| # | 13:59:59 | csharp | Dyrcona: yeah - this is my "break - rebuild - repeat" box |
| # | 14:00:24 | csharp has always been intimidated by postgres |
| # | 14:01:27 | csharp | I'll say in the same breath though, that the more I learn, the more straightforward it all seems |
| # | 14:01:49 | edoceo has quit IRC |
| # | 14:03:27 | bshum | Yay for upgrades, wish I were upgrading already |
| # | 14:04:16 | csharp | bshum: you can come visit when we upgrade to 2.0 and relive the memories }:-) |
| # | 14:05:55 | bshum | csharp: I would be depressed thinking about the cache issues with our 2.0 upgrade. 2.1+ ftw! |
| # | 14:06:15 | csharp | aw frak - I forgot about that! |
| # | 14:06:31 | csharp had tried to wash the memories away with booze and pills |
| # | 14:07:09 | bshum | I keep adding things to my list of reasons I'm so eager to upgrade out of 2.0. |
| # | 14:07:41 | bshum | Perhaps PINES should consider skipping over it ;) |
| # | 14:08:07 | dbs | csharp: jeff and _bott_ went from 1.6 -> 2.1 |
| # | 14:08:42 | csharp | dbs: might be worth considering... |
| # | 14:08:43 | jeff | that statement gives me far too much credit. _bott_ and dkyle did the upgrade. :-) |
| # | 14:10:30 | phasefx | moodaepo: btw, I browsed through this and didn't see any more spammy links: dokuwiki/data/pages# grep -R 'http://' * | cut -f2- -d: | perl -ne 'while (/(http:.+?)[\s\]]/g) { print "$1\n"; }' | sort | uniq | less |
| # | 14:10:51 | phasefx | but there's a lot there |
| # | 14:12:43 | dbs just went through the soul-destroying task of cleaning deferred mail (spam) out of the security list |
| # | 14:13:35 | csharp | uh oh - postgres problems: http://pastebin.com/PHi3in5P |
| # | 14:15:08 | jamesrf | did anyone notice that xulrunner 1.9.2 disappeared off of releases.mozilla.org? |
| # | 14:15:51 | sal_ | jamesrf: Its renumbered replacement works... |
| # | 14:16:10 | jamesrf | what's the renumbered replacement? |
| # | 14:16:36 | sal_ | 3.6.20 |
| # | 14:16:44 | jamesrf | ok thanks i'll give that a whirl |
| # | 14:17:00 | sal_ | (I ran into this in August--see logs from 8/17-18) |
| # | 14:17:59 | csharp would like to see the EG community host those kinds of dependencies within our own universe - CPAN stuff too |
| # | 14:19:50 | collum has quit IRC |
| # | 14:21:14 | sal_ | csharp: does that include Postgres 9.0 (gdr) |
| # | 14:22:14 | csharp | sal_: it's just an idea (I sure people would point out downsides), but I would think we could host any specific versions of software EG requires |
| # | 14:22:37 | dbs | we already do, for things like libdbi |
| # | 14:22:58 | csharp | if the packaging project continues and has committed maintainers, they could be in .deb/.rpm format |
| # | 14:23:08 | sal_ | * only brings it up because she seems to have been the first (vocal) one burned by both postgres and xulrunner version changes... :-) |
| # | 14:23:25 | csharp | you're not the first! |
| # | 14:23:27 | csharp | :-) |
| # | 14:23:31 | gmcharlt would prefer that we do the bare minimum of maintaining packages for other projects, however |
| # | 14:23:38 | sal_ | * just the loudest ;-) |
| # | 14:23:48 | gmcharlt | i.e., do it if we have no other choice |
| # | 14:23:55 | edoceo has joined #evergreen |
| # | 14:24:30 | csharp | well, Mozilla's a great example - they have pulled older xulrunner versions down before |
| # | 14:24:49 | phasefx | long term I'm in favor of jumping ship there |
| # | 14:25:02 | csharp | phasefx: you know I agree with you there ;-) |
| # | 14:25:48 | csharp | but the CPAN stuff too - somebody's typo somewhere else can blow up an Evergreen install |
| # | 14:25:49 | phasefx | we could lock down on whatever the last of the 1.9.2/3.6 happens to be.. warn folks not to put remote sites in their portal pages (bad idea even now) |
| # | 14:25:56 | bshum | Well, there's precedent with keeping older xulrunners around if I remember the steps for 1.4 SC building included pulling a copy from the phasefx directory. |
| # | 14:26:40 | phasefx was actually really excited about not having to do that and finally being able to follow the latest xulrunners (moving away from 1.8), right up until remote xul went away |
| # | 14:26:43 | Dyrcona | csharp: That's the joy of CPAN. It doesn't just affect Evergreen. |
| # | 14:27:14 | jeff | dbs: inspired by your earlier performance musings, and something i've both been wanting to do for a long time and suddenly have a good reason to spend time on... here are some quick and dirty load-search-results tests using selenium and python: http://paste.lisp.org/display/124644 |
| # | 14:27:17 | dbs | someone made a CPAN bundle for Evergreen ages ago :) |
| # | 14:27:18 | csharp | Dyrcona: agreed - I'm just saying we could keep a repo of known working versions and let CPAN be CPAN |
| # | 14:28:07 | gmcharlt | csharp: until our working versions become non-working versions because of (say) a security update to a CPAN module that doesn't get propagated |
| # | 14:28:13 | csharp | that volatility also means that fully replicating the EG 2.0.9 I build today might be very difficult later |
| # | 14:28:57 | gmcharlt | I'm not unsympathetic -- but it can be a surprisingly large amount of extra work that trusting to the broader Perl ecosystem can help deal with |
| # | 14:29:00 | dbs | jeff: cool! now you just need to run a ton of those against jspac vs. tpac and come up with some amazing comparisons! |
| # | 14:29:11 | csharp | gmcharlt: (not volunteering here - just musing) that could be a volunteer role in the project - to periodically check for updates and rationales behind them |
| # | 14:29:22 | dbs hopes that the amazing comparison isn't "tpac is surprisingly slower" :) |
| # | 14:29:40 | phasefx puts csharp in charge of the Evergreen Linux Distribution :) |
| # | 14:29:46 | Dyrcona | sixpac and twopac? |
| # | 14:30:09 | dbs | csharp: I was thinking of something similar - putting together a list of "Ancient Things Upon Which Evergreene Dependeth" and associated bugs for people interested in tackling |
| # | 14:30:09 | jeff | toward that end, is there a current install somewhere that exposes both the opac and tt-opac? |
| # | 14:30:13 | csharp | phasefx: I can dig out the email I sent to Open-ILS-General in 2008 saying I'd love to see a debian installer hack |
| # | 14:30:59 | Dyrcona | jeff: my dev machine does, but its closed to most of the world. |
| # | 14:31:23 | dbs | e.g. Class::DBI 0.9.7 / 3.0.1, Dojo 1.3, XULRunner the remote XUL edition - many of which will prevent Debian/Fedora/other official packaging |
| # | 14:31:29 | dbs | fire alarm |
| # | 14:31:30 | Dyrcona | it also hasn't been updated since yesterday morning. |
| # | 14:31:35 | jeff | dbs: have fun! |
| # | 14:32:07 | berick looks for the fire alarm in his basement |
| # | 14:32:21 | Dyrcona | we're about due for a fire drill ourselves.... |
| # | 14:32:26 | csharp | if more of my time could be spent on that kind of thing I would definitely do something around packaging/maintaining |
| # | 14:32:39 | csharp wishes he had a clone sometimes |
| # | 14:32:50 | csharp | cp csharp csharp-clone |
| # | 14:33:04 | Dyrcona | definitely an advantage in keeping a clone of Dojo, since Eg requires some additional patches. |
| # | 14:33:35 | Dyrcona | CSharp clone = Object.clone(csharp); |
| # | 14:33:49 | edoceo has quit IRC |
| # | 14:33:54 | csharp | heh |
| # | 14:33:55 | gmcharlt | Dyrcona: more of an argument to upgrade to current Dojo; ditto for Class::DBI -> something more recent |
| # | 14:35:48 | jamesrf | phasefx: was wondering if you saw this: https://github.com/jvillalobos/Remote-XUL-Manager |
| # | 14:35:55 | csharp | well, if the idea catches fire, GPLS can provide hardware (or another VM) - FYI to all |
| # | 14:36:27 | phasefx | jamesrf: I had not |
| # | 14:37:09 | edoceo has joined #evergreen |
| # | 14:37:58 | bjwebb has joined #evergreen |
| # | 14:38:05 | tsbere | If there is a whitelist, we should be able to manipulate it. |
| # | 14:38:13 | phasefx | jamesrf: I think remote xul is going to be even more of a non-first-class citizien going forward; stuff was already broken in prior versions |
| # | 14:39:07 | edoceo has quit IRC |
| # | 14:39:10 | Dyrcona | does the whitelist also exist in XulRunner? |
| # | 14:39:12 | phasefx | but.. sure would be nice to stick it out until it becomes painful again |
| # | 14:39:21 | edoceo has joined #evergreen |
| # | 14:39:30 | Dyrcona finds XulRunner to be painful anyway. |
| # | 14:39:33 | edoceo has quit IRC |
| # | 14:40:31 | edoceo has joined #evergreen |
| # | 14:40:51 | tsbere | phasefx: I can look into that at some point in the near(ish) future |
| # | 14:41:02 | edoceo has joined #evergreen |
| # | 14:41:23 | phasefx | tsbere++ sounds good to me. jamesrf++ |
| # | 14:41:24 | jamesrf | yeah it's really probably a question of buying some time, i have no idea how much work removing the remote xul would be |
| # | 14:41:36 | tsbere looks at a hold targeting issue first, though |
| # | 14:43:08 | phasefx | we can move bits and pieces to local xul incrementally.. I tried something wholesale/automated, and it scared me. Alternately, we can embrace the dojo and replace things with it incrementally, and eventually drop xulrunner. More fun, more pain, would be throw it all away and start over with some new hot technology stack :) |
| # | 14:43:29 | phasefx | like tcl/tk |
| # | 14:43:48 | jeff | apache rivets! |
| # | 14:44:10 | phasefx _has_ been playing with ncurses |
| # | 14:44:16 | tsbere | From a printing POV I think we still need an actual client |
| # | 14:44:29 | Dyrcona | lpr ? |
| # | 14:44:31 | jeff | i'm favoring a helper app for printing. |
| # | 14:44:42 | phasefx | if we do web-ased, we could still.. yeah, plugin, extension, helper app |
| # | 14:44:46 | phasefx | web-ased :) |
| # | 14:45:05 | Dyrcona | missing an 's' |
| # | 14:45:12 | phasefx | missing a letter, but which one .. yeah :D |
| # | 14:45:43 | Dyrcona | could have a competition to see who can produce the coolest client. |
| # | 14:46:45 | Dyrcona | I know some people who would like to see it all in the browser, as tsbere pointed out though, printing there is a pain. |
| # | 14:49:01 | jeff | i can see the marc editor being potentially problematic as well, but a not-web cataloging client and web everything-else seems attainable. |
| # | 14:50:09 | jeff | browser offline storage capabilities may have matured enough to make offline-mode circ possible as well. i've been doing a bit of thinking/playing. perhaps time for a blog/list post. |
| # | 14:50:35 | dbs | MOAR COAD |
| # | 14:51:13 | phasefx | really need more interest from folks with resources |
| # | 14:51:21 | jeff | dbs: i just fed you a working branch -- you're hungry again? ;-) |
| # | 14:51:24 | jeff ducks |
| # | 14:51:47 | dbs | MOAR COAD MOAR COAD |
| # | 14:53:30 | Dyrcona | phasefx: we will soon have slightly more resources. |
| # | 14:53:53 | phasefx | yay |
| # | 14:56:12 | tsbere | For the record, it is currently possible to get a frozen hold to capture. :( |
| # | 14:56:32 | _bott_ has quit IRC |
| # | 14:56:44 | jeff | tsbere: i've seen scattered examples of that. have you found a code path? |
| # | 14:57:17 | _bott_ has joined #evergreen |
| # | 14:57:23 | tsbere | jeff: Yep. I can reproduce it! |
| # | 14:57:29 | tsbere | I can also PATCH it. :D |
| # | 14:58:09 | tsbere | http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/tsbere/hold_frozen_no_targeting |
| # | 15:00:33 | jeff | tsbere++ |
| # | 15:00:51 | tsbere goes to open a launchpad bug |
| # | 15:02:37 | phasefx | man, they want to drop enablePrivilege as well |
| # | 15:03:32 | tsbere | I suspect https://bugs.launchpad.net/evergreen/+bug/849312 should go into 2.1. Maybe 2.0? |
| # | 15:03:37 | jeff | so, if cataloging was xulrunner, and autoupdates handled pushing xul (thus, no remote xul), what does the elimination of enablePrivilege break? |
| # | 15:05:09 | phasefx | for an all local app, I can't think of anything |
| # | 15:06:29 | tsbere | I think circ would need to be xulrunner too, for receipt printing purposes. |
| # | 15:06:50 | dbs | jeff: was the reason for echoing LIBPQ & the next layer of indenting primarily debuggin? Considering replacing with: if [[ -n "$LIBPQ" && "$LIBPQ" -eq "8" ]] |
| # | 15:07:10 | tsbere | Because I don't want to think about the horror of "make sure you are using the right browser with the right extension loaded" at circ desks |
| # | 15:07:27 | phasefx | folks print receipts with web-based selfcheck |
| # | 15:08:01 | phasefx | I'd hope they don't remove the print silently pref, even though we may have to start setting it by hand (or extension) |
| # | 15:08:02 | tsbere | And that is wonderful until you hit "holds may print to a different printer than other circ-related receipts" |
| # | 15:08:22 | tsbere | And the inability for browser-based to pick printers for security reasons |
| # | 15:10:18 | collum has joined #evergreen |
| # | 15:10:32 | phasefx | yeah, printing from web browsers suck |
| # | 15:10:58 | bshum | Speaking of printing receipts off the web-based selfcheck... |
| # | 15:10:58 | phasefx | but it may be "good enough" |
| # | 15:11:03 | phasefx | or not |
| # | 15:11:51 | bshum | Is it possible to change the template definition (or find some other way) to make it print as though it were on a receipt printer roll instead of normal sized paper? |
| # | 15:11:51 | Dyrcona | printing in general is a joke on computers. |
| # | 15:12:17 | tsbere | bshum: Printer settings in the browser? |
| # | 15:12:24 | Dyrcona | I do believe printing began when some guys at IBM were bored and said, "What happens if we hook one of these up to a Selectric?" |
| # | 15:12:40 | tsbere finds he has to select "Roll Paper" on all the epson drivers when a non-receipt printer was selected before |
| # | 15:13:12 | bshum | tsbere: Right, I changed the options there and I can do one of two things, have it print at scale (meaning tiny, tiny fonts resized to fit the page onto the roll paper) or full size, leaving the edges of the receipt going off the edges. |
| # | 15:13:28 | bshum | Since the template was designed with full sized paper in mind. |
| # | 15:13:38 | bshum | And the lines don't seem to wrap |
| # | 15:13:55 | tsbere | Dunno. When I select roll paper everything starts wrapping. |
| # | 15:13:57 | bshum | Just curious, didn't mean to derail the brainstorming of clients :( |
| # | 15:14:22 | Dyrcona | bshum: You are selecting roll paper in the Windows printer driver, right? |
| # | 15:14:45 | bshum | Dyrcona: Well, it's not a windows machine it's a Ubuntu workstation, but yes, I believe that was selected. |
| # | 15:15:11 | Dyrcona | Ah....Good luck with that! :) |
| # | 15:15:37 | bshum | That's kind of what I thought :) |
| # | 15:16:12 | Dyrcona | I don't print receipts from Ubuntu, much, 'cept when I use our little thin client. (Not sure if it is Ubuntu.) |
| # | 15:16:54 | bshum | It was easier to setup the selfcheck workstation at the time using Ubuntu, though now I'm filled with regrets as always. |
| # | 15:17:20 | jeff | dbs: sorry, the echo snuck in. twas debugging. |
| # | 15:17:48 | tsbere | bshum: Still haven't had issues on ubuntu with roll paper. But haven't done much beyond transit slips there. |
| # | 15:17:50 | jeff | dbs: i attempted to use -n tests and was unsuccessful for unknown reasons. |
| # | 15:18:22 | dbs | jeff: hmm. seemed to work here; I'll deinstall all postgresql stuff and try it again |
| # | 15:18:28 | bshum | tsbere: Right, we were playing with those fancy self-check receipts that are generated using A/T on-demand, I think. The contents of those pages hated the roll paper. |
| # | 15:18:58 | jeff | dbs: i'll re-test here. i'm also installing squeeze to test "is this even needed" |
| # | 15:19:08 | dbs | sweet |
| # | 15:20:05 | dbs was doing light research on the occasional failure of self checkouts to desensitize materials and has concluded that we should just turn our gates off |
| # | 15:20:14 | phasefx | http://www.amplesdk.com/examples/markup/xul/views/ (I know we've seen this before) |
| # | 15:20:45 | Dyrcona is doing heavy research on the failure of SIP2 self-checks to occasionally pay fines. |
| # | 15:23:46 | phasefx | we really make too much use of stuff like xulG though.. that code is tied to mozilla, and a xul-like won't help |
| # | 15:24:08 | tsbere | You know, the client needs so much work to make it work after the current xulrunner major version we are using I am not sure it is worth figuring out some stuff right now. <_< |
| # | 15:24:33 | tsbere can't test xul whitelist stuff without some other overhauling, for example |
| # | 15:24:55 | dbs | jeff: hmm, looks like backports now happily upgrades libpq* to 9.0 |
| # | 15:25:19 | dbs | but... what? libapache2-mpm-prefork and libapache2-mod-perl2 get removed? |
| # | 15:27:06 | dbs | prolly should have done safe-upgrade first, might be confusing state of locally installed packages |
| # | 15:27:16 | dbs changes nick to dbstreamofconsciousness |
| # | 15:28:40 | dbs recommends we solve the web client printing problem the obvious way: Google Cloud Print |
| # | 15:29:06 | dbs | That should make the paranoid / legally not allowed to use such services really freak out |
| # | 15:30:20 | Dyrcona freaks out. |
| # | 15:30:25 | Dyrcona | :) |
| # | 15:30:35 | Dyrcona | or printeron. |
| # | 15:31:56 | phasefx | point a polaroid at the screen |
| # | 15:32:16 | tsbere | That mean we need to supply wooden tables? |
| # | 15:34:00 | sal_ has quit IRC |
| # | 15:35:35 | sal_ has joined #evergreen |
| # | 15:40:41 | tsbere still can't get later versions of xulrunner to *start*, with or without evergreen stuff in them |
| # | 15:40:46 | dbs | as far as I can tell, debian lenny no longer freaks out about libpq5 8 vs. 9; it will upgrade libpq 8 to 9, and not remove postgresql 8.4 server in the process |
| # | 15:41:20 | dbs | So that leaves just ubuntu-lucid, which I do not have a VM to test with; then maybe we can make this whole mess go away. |
| # | 15:41:36 | sal_ | dbs: will maverick work? |
| # | 15:41:47 | sal_ | I have plenty of VMs :-) |
| # | 15:42:11 | dbs | sal_: we only recommend LTS releases so really kind of have to test Lucid |
| # | 15:42:28 | bshum | dbs: What are we testing with Lucid? I have PG 8 installed on a few. |
| # | 15:43:24 | dbs | bshum: seeing whether backports will happily run install_pgsql_client_debs_90 without all of the existing libpq5 detection / removal hackery |
| # | 15:43:48 | Dyrcona | dbs: we used psql 9 on lucid. in dev and production. |
| # | 15:43:51 | bshum | Ah, so, grab a copy from master or some other branch that we're testing on. |
| # | 15:44:20 | dbs | Dyrcona: that's not the question |
| # | 15:44:30 | Dyrcona | you're talking about for upgrades. |
| # | 15:44:36 | Dyrcona | never mind. |
| # | 15:44:43 | dbs | bshum: just running "aptitude postgresql-client-9.0" on an updated Lucid with backports should give a good feel |
| # | 15:44:54 | dbs | err, aptitude install postgresql-client-9.0 |
| # | 15:45:21 | dbs | course that'll be 9.1 one of these days :) |
| # | 15:45:33 | bshum | Heh |
| # | 15:46:13 | jeff | dbs: i pushed a (mostly pointless, now) update to that working branch removing the echo statement and simplifying the logic. if debian no longer requires the removal of those packages, great! do we have any point where we recommend the user enable backports in sources.list or equivalent? |
| # | 15:46:31 | dbs | In the fine README |
| # | 15:46:32 | tsbere | phasefx: Given the issues I keep having with later versions of xulrunner (aka, can't even get the profile manager to show) I recommend we stick with the older variant. |
| # | 15:46:46 | bshum | dbs: It didn't like that, saying that libpq-dev package is broken. |
| # | 15:46:55 | Dyrcona | Qt/WebKit here we come! :p |
| # | 15:47:24 | jeff | dbs: got it :-) |
| # | 15:47:35 | eeevil | marc editor fiximicated ... wheee! |
| # | 15:47:38 | dbs | bshum: hmm, maybe you could try out jeff's version of Makefile.install? |
| # | 15:47:44 | jeff | eeevil++ |
| # | 15:47:51 | dbs | eeevil++ # two lines of glory! |
| # | 15:48:29 | dbs | lines != amount of head scratching |
| # | 15:48:43 | phasefx | tsbere: let's make sure we keep a copy somewhere handy |
| # | 15:49:09 | dbs | bshum: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/jeff/lp801624_fix_bash_test if you have the chance |
| # | 15:49:10 | tsbere | phasefx: As mentioned, the re-numbered variant is probably fine. They don't look to be pulling it anytime soon. |
| # | 15:49:13 | shopkins has quit IRC |
| # | 15:49:24 | dbs | let's torrent it |
| # | 15:49:39 | phasefx | let the staff client distribute itself |
| # | 15:49:56 | kmlussier has quit IRC |
| # | 15:50:26 | eeevil | dbs: yeah ... not sure how it ever worked, TBH ... but it did |
| # | 15:53:17 | tsbere | phasefx: Basically, "bumping" the version to 3.6.22 works fine. But going to anything after the 3.6 run is causing me headaches. |
| # | 15:53:56 | tsbere | We don't even have to change application.ini |
| # | 15:54:29 | phasefx | tsbere: you were just trying for the whitelist thing, right? |
| # | 15:55:13 | tsbere | I have tried several times for various reasons, and have a local branch with various changes I have gone through to try and make sure things might work. |
| # | 15:55:13 | dbs | give my PyQt or give me death |
| # | 15:55:15 | bshum | dbs: Tested the makefile.install and tried "install_pgsql_client_debs_90" and it installed postgresql-client-9.0 and upgraded my libpq-dev and libpq5 (to 9.1.0 versions) |
| # | 15:55:43 | dbs | bshum: okay - and it didn't blow away your postgresql 8.4 server? |
| # | 15:55:53 | bshum | dbs: It does not appear to be gone. |
| # | 15:56:02 | tsbere | phasefx: End result, I have yet to attempt to code the whitelist thing, but I have a pile of local changes that may make other things support xulrunner 6+ that we would have issues with otherwise.........but I can't test them because I can't get the later versions to *start* properly, let alone run the code. |
| # | 15:56:20 | bshum | dbs: Or wait |
| # | 15:56:25 | bshum | dbs: I can't connect to it. |
| # | 15:56:57 | eeevil | bshum: might have been moved to another port |
| # | 15:57:09 | bshum | eeevil: Good point, checking on that now... |
| # | 15:57:09 | tsbere | Try 5433 |
| # | 15:57:11 | tsbere | ;) |
| # | 15:57:15 | phasefx | tsbere: being stuck on 1.9/3.6 is where I expected us :( did you try the extension route with Firefox? |
| # | 15:57:31 | dbs | weird. normally debian would put a new server at a new port |
| # | 15:57:42 | tsbere | phasefx: I am considering a patch to rip all the extension stuff *out* at this point. <_< Never worked well enough for me. |
| # | 15:57:45 | dbs | bshum was just upgrading the client |
| # | 15:58:17 | bshum | Wacky.... I thought this server had 8.4 installed on it and I see data files for it, but it's like it's not here... |
| # | 15:58:32 | bshum | Bad test |
| # | 15:58:35 | phasefx | tsbere: I could agree with that; we really don't want to push folks to stick with Firefox 3.6 :) |
| # | 16:00:30 | Meliss has quit IRC |
| # | 16:05:56 | tspindler has quit IRC |
| # | 16:07:29 | sal_ | Minor and unrelated question...is my change to SIP/Patron.pm:charge_ok to report denial of privileges in the SIP patron status field a bug fix (for a bug I should report) or a patch? |
| # | 16:07:57 | sal_ | (And was that a runon sentence?) |
| # | 16:09:05 | Dyrcona | sal_: I don't think I know enough about the context of the question to be able to answer. |
| # | 16:09:56 | akilsdonk has joined #evergreen |
| # | 16:10:07 | Dyrcona | My suggestion would be create a launchpad bug and attach code. |
| # | 16:10:15 | jeff | sal_: open a bug in launchpad with the details and either include your patch or a link to a working branch/etc. |
| # | 16:10:25 | jeff | what Dyrcona said :) |
| # | 16:11:02 | Dyrcona | I think we should have a developer/community meeting devoted to discussing the future of the client. |
| # | 16:11:10 | sal_ | thanks. I shall. |
| # | 16:11:51 | bjwebb has quit IRC |
| # | 16:12:30 | bshum | dbs: Alright, tested again with another lucid server that actually had PG 8.4 installed and running on it. |
| # | 16:12:30 | akilsdonk has quit IRC |
| # | 16:12:38 | dbs awaits anxiously |
| # | 16:12:42 | bshum | Things connected just fine, and the database is still there. |
| # | 16:12:53 | dbs | AWESOME |
| # | 16:13:22 | dbs will rip out the current hackery and credit jeff and bshum for helping discover that much pain is gone |
| # | 16:13:29 | akilsdonk has joined #evergreen |
| # | 16:13:53 | bshum | Wait, just to check on one last thing |
| # | 16:14:02 | bshum | How do you verify that you're using the right psql version? |
| # | 16:14:05 | dbs waits |
| # | 16:14:20 | dbs | psql --version |
| # | 16:14:35 | bshum | Hmm, that came back with 8.4.8 |
| # | 16:14:42 | collum has quit IRC |
| # | 16:14:45 | dbs | and "show server_version" once you're connected |
| # | 16:14:45 | Dyrcona | That matters less than the libs and server version, though. |
| # | 16:14:58 | bshum | Though postgresql-client-9.0 definitely installed along with upgraded versions of libpq-dev and libpq5 |
| # | 16:15:20 | Dyrcona | the 8.4 client works well with 9.0+ servers. it just doesn't have any new features of the 9.0+ clients. |
| # | 16:15:21 | dbs | well, given that bshum installed postgresql-client-9.0 it is a bit surprising :) |
| # | 16:15:27 | bshum | I guess the DB itself not being blown away is good though. |
| # | 16:15:35 | dbs | that's the primary concern |
| # | 16:15:36 | Dyrcona | dbs: that happened to me until i uninstalled the 8.4 client. |
| # | 16:15:45 | dbs | probably /etc/alternatives or the like |
| # | 16:15:48 | bshum | Let me try uninstalling the pg 8.4 client then |
| # | 16:15:50 | Dyrcona | yes |
| # | 16:15:53 | jeff | okay, i'm getting breakage here. |
| # | 16:15:57 | jeff | installed debian squeeze. |
| # | 16:16:16 | jeff | installed opensrf 2.0.1 pre-reqs with debian-squeeze target in Makefile.install |
| # | 16:16:39 | jeff | add squeeze-backports line in sources.list, apt-get update, then: |
| # | 16:16:47 | bshum | Oh, oops, definitely not doing that. It wants to kill the 8.4 server along with the client when I do that. |
| # | 16:17:06 | Dyrcona | bshum: what are you running? |
| # | 16:17:12 | Dyrcona | the command I mean. |
| # | 16:17:38 | bshum | Ah, maybe that's what I'm doing wrong... apt-get remove postgresql-client-8.4 |
| # | 16:18:06 | bshum | postgresql-8.4 depends on the 8.4 client it seems. |
| # | 16:18:38 | Dyrcona | postgresql-8.4 is a metapackage, not the server itself. |
| # | 16:18:41 | jeff | running aptitude -t squeeze-backports -yq install libpq5 libpq-dev postgresql-client-9.0, i get an unmet dependencies error from aptitude- postgresql-client-9.0: Depends: libpq5 (>= 9.0~) but 8.4.8-0squeeze2 is installed. |
| # | 16:18:42 | tsbere | phasefx: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/tsbere/no_ff_extension |
| # | 16:18:46 | bshum | Dyrcona: Ahh, I see. |
| # | 16:18:49 | Dyrcona | it's a shortcut to install everything. |
| # | 16:18:49 | jeff | so, we seem to still have the original issue requiring the workaround. |
| # | 16:19:04 | jeff | not sure why it worked once for me last night |
| # | 16:19:09 | dbs wonders if we're on different mirrors |
| # | 16:19:34 | jeff | or i did something unusual last night that i promptly forgot |
| # | 16:19:46 | dbs | jeff: slowoutofdate.debian.org is not reliable, fwiw |
| # | 16:20:05 | jeff | so, here's an alternate workaround: |
| # | 16:20:48 | jeff | drop the -9.0 from postgresql-client package name. then it upgrades just fine... but when squeeze-backports gets 9.1, we may have issues :-) |
| # | 16:21:33 | jeff | i'll bet i did that last night at some point. |
| # | 16:21:53 | bshum | Eww, doing that on Lucid definitely gets me the 9.1 client. |
| # | 16:22:43 | jeff | .bash_history confirms, i manually installed postgresql-client from backports before running the Evergreen pre-reqs. |
| # | 16:22:44 | dbs | 9.1 isn't an issue, thanks to tsbere |
| # | 16:22:48 | bshum | pitti's ppa has the 9.1 stuff in it, so I have to be more explicit about which versions I want to have. |
| # | 16:23:24 | dbs | given that 9.1 was released yesterday-ish, I'm sure it's safe |
| # | 16:23:42 | dbs | Famous Last Words(TM) |
| # | 16:24:13 | bshum | Heh, dbs++ |
| # | 16:24:24 | bshum | And tsbere++ too, 9.1 support |
| # | 16:24:27 | jeff | so, the issue requiring the workaround is still an issue. we have an updated workaround (dbs + my changes), or we can install postgresql-client instead of postgresql-client-9.0 -- i can't weigh the pros/cons right now, just enumerate two possible options. :-) |
| # | 16:25:05 | dbs | given that postgresql 9.0 support is going to be pulled from the backports / ppa in a few months, apparently? |
| # | 16:25:14 | dbs would lean towards 9.1 |
| # | 16:25:25 | dbs | but /me is not upgrading to 2.1 anytime soon |
| # | 16:26:53 | akilsdonk has quit IRC |
| # | 16:26:55 | bshum | As long as we know PG 9.1 is the intended target for an EG 2.1, then that seems fine to me. Good to know which direction to plan in. |
| # | 16:27:09 | bshum | For the sites already on PG 9.0 well... hmm. We have to upgrade eventually right? |
| # | 16:27:19 | akilsdonk has joined #evergreen |
| # | 16:27:39 | bshum | Direction to plan in / for newbies to install with. |
| # | 16:28:05 | dbs | well, there we're in your boat; on 9.0 with 2.0. so you can take some comfort :) |
| # | 16:28:37 | bshum | dbs: Actually, our production is still 8.4 with 2.0. I can go anywhere I want! :D |
| # | 16:29:41 | bshum | Has the 9.1 support been backported to 2.1 already? |
| # | 16:29:51 | bshum | I might try to install it later tonight to see how it plays. |
| # | 16:31:20 | bshum | Ah yes, there it is. |
| # | 16:33:54 | jamesrf | did i catch it right that 2.1 is now going to require 9.1? |
| # | 16:34:14 | tsbere | Require? Probably not. Support? Probably. |
| # | 16:34:56 | sal_ | Rumor has it that 9.0 is going away altogether (having never actually been included in any official distributions, it may never be.) |
| # | 16:35:06 | dbs | jamesrf: we're considering making a default Makefile.install install the 9.1 client |
| # | 16:35:21 | dbs | but the server would still be under your control |
| # | 16:35:45 | jamesrf | hm yeah we're just sort of starting to look at upgrading our 8.4 server to 9.0 in anticipation of 2.1 but maybe 9.1 would be better? |
| # | 16:35:45 | dbs holds up his Fedora 15 and shakes it in sal_'s face |
| # | 16:36:37 | jeff wishes for a launchpad "bugs i've recently commented on" |
| # | 16:36:50 | dbs thinks this would make a fine topic for the "2.1 blockers" thread: "PostgreSQL 9.0 seems to be hard to install on Debian Squeeze / Ubuntu Lucid and 9.1 seems to be the direction backports are going in" |
| # | 16:37:24 | jeff | advanced search has it. launchpad++ |
| # | 16:37:25 | dbs | not quite a blocker, but we need to have a consensus on what we want to try to support as a standard |
| # | 16:37:28 | sal_ | dbs: was quoting Martin Pitt, before the big stink :-) |
| # | 16:37:40 | dbs | ah |
| # | 16:38:14 | jamesrf | hmm yeah it would be nice to get through a major eg version without having to upgrade postgres again or at least to know what to expect |
| # | 16:39:42 | Dyrcona | trouble is we're an open source project in an open source ecosystem with "customers" who are used to a siloed experience. |
| # | 16:41:23 | jeff | yeah, forget that "postgresql-client" fixes it -- it installed / stayed with 8.4. |
| # | 16:42:50 | dbs has no idea what state things are in now |
| # | 16:42:52 | dbs goes home |
| # | 16:42:55 | dbs has quit IRC |
| # | 16:44:13 | jeff | still wondering what in the world i did last night that it worked :P |
| # | 16:45:14 | moodaepo thinks 8.x to 9.0 will be the same as 8.x to 9.0 and 9.0 to 9.1 shouldn't be a pain |
| # | 16:46:38 | jamesrf | anyone tested eg 2.0 + pg 9.1? |
| # | 16:47:55 | moodaepo | jamesrf: That is my next test...once I finish setting up our demo tt_opac server |
| # | 16:48:40 | jeff re-tests |
| # | 16:50:21 | elene has joined #evergreen |
| # | 16:53:00 | elene has left #evergreen |
| # | 16:53:34 | elene has joined #evergreen |
| # | 16:54:24 | elene | hi everyone :) |
| # | 16:54:43 | jeff | greetings, elene! |
| # | 16:55:24 | elene | could someone please help me cope with one issue about record's OPAC visibility |
| # | 16:56:50 | jeff | ask away! |
| # | 16:56:58 | jeff | (no need to ask to ask) |
| # | 16:57:21 | elene | thanks :) I have this strange problem on 1.6.0.1: when I create a record from staff client and attach a copy |
| # | 16:57:35 | elene | everything seems to work, but the record does not show up on OPAC |
| # | 16:57:59 | jeff | By default some copy statuses are not opac visible. If the copy's status is In Progress, it won't show in public searches. |
| # | 16:58:05 | elene | and later even from Staff Client, I can only retrieve the record by its ID, not by searching by keywords |
| # | 16:58:25 | elene | thanks. I set copy status as 'available' |
| # | 16:58:42 | elene | and the record is not even visible from staff client |
| # | 16:58:51 | elene | unless I search for it by its record ID |
| # | 16:58:55 | jeff | er, "In Process" is what I meant. no big difference there. :-) |
| # | 16:59:42 | elene | i see |
| # | 17:01:56 | jeff | It sounds like the record itself might not be properly indexed/ingested. |
| # | 17:02:14 | elene | i see. could you please remind me the reingest command? |
| # | 17:02:33 | jeff | editing the marc record and re-saving it may just do the trick. |
| # | 17:03:20 | tlilleberg has quit IRC |
| # | 17:04:19 | elene | I see. I just tried it, but strangely, I can no longer retrieve the record, even by its record ID. it seems to be gone :( |
| # | 17:05:49 | elene | is there such thing as 'reingest' in 1.6.0.1? or a 'repair database' script / command |
| # | 17:08:11 | moodaepo | elene: I think jeff's sugestion about editing marc record and saving works only in 2.0 and above, 1.6.0.1 seems so long ago I forget how it was done. |
| # | 17:08:54 | elene | I see. Thanks, moodaepo. Would you happen to have any other suggestions? |
| # | 17:09:03 | moodaepo | elene: I think there is a script one sec |
| # | 17:10:04 | bshum | If you can't even retrieve it by record ID that seems unusual. |
| # | 17:10:20 | bshum | Even if it were a deleted bib, it would come up by its id. |
| # | 17:14:19 | mmorgan has left #evergreen |
| # | 17:21:03 | moodaepo | elene: The script I remembered is used when we are loading records on the server using scripts not via the client so it won't be of much use to you. In any case it's mentioned here http://open-ils.org/dokuwiki/doku.php?id=evergreen-admin:importing:bibrecords moe specifically look under "Example: Importing the Project Gutenberg records" for usage example. |
| # | 17:22:20 | elene | moodaepo: Thank you. I recently imported holdings using staging table, so I may have missed the command that does 'reingest' |
| # | 17:28:22 | Dyrcona has quit IRC |
| # | 17:59:22 | jenny has left #evergreen |
| # | 18:06:55 | elene has quit IRC |
| # | 18:26:14 | sal_ has quit IRC |
| # | 18:43:43 | yboston has quit IRC |
| # | 18:51:02 | elene has joined #evergreen |
| # | 18:55:02 | elene has quit IRC |
| # | 18:56:50 | elene has joined #evergreen |
| # | 19:03:13 | akilsdonk has quit IRC |
| # | 19:05:17 | elene | hi again. i have the same problem on 1.6.0.1: I create record from staff client, i attach copies. set status to 'availabe' but the record does not show up on OPAC. Also, it is not searchable from staff client, unless I retrieve it by record ID |
| # | 19:05:53 | elene | I have tried editing and re-saving the record from stall client, but no luck |
| # | 19:06:48 | elene | I checked record_entry, call number and copy tables and the record is there |
| # | 19:07:00 | elene | along with holdings info |
| # | 19:07:50 | shadowspar is now known as latefordinner |
| # | 19:09:45 | latefordinner is now known as shadowspar |
| # | 19:15:11 | jeff | okay, on the "that didn't fix it" -- i was using -t debian-backports -- not -t squeeze-backports :-) |
| # | 19:15:22 | jeff | i'll update the bug once i've confirmed. |
| # | 19:29:14 | moodaepo | elene: I don't suppose the web catalog is available publicly? |
| # | 19:29:43 | elene | moodaepo: yes, it's library.ac.ge |
| # | 19:31:44 | elene has quit IRC |
| # | 19:34:07 | elene has joined #evergreen |
| # | 19:36:31 | elene | . |
| # | 19:43:07 | elene | the title of the test record is 'kiev test 2' |
| # | 19:48:28 | bjwebb has joined #evergreen |
| # | 19:52:49 | elene | Could my manually adding the holding info have somehow damaged the ingest function? |
| # | 19:53:58 | elene | I did not do very clean import of holdings info. All I did was manually adding info in asset - call_numbers table and then relevant data in asset - copy table. |
| # | 19:54:47 | elene | Staging table somehow did not work, so as I used manual way, I may have missed some other required tables to update |
| # | 19:55:07 | jeff | it is possible that you have asset.call_number or asset.copy entries that do not have proper circ_lib / owning_lib or other info. have you tried adding volumes and copies from a staff client? |
| # | 19:56:05 | elene | yes, and they add without problems, though the record is still not findable and not visible unless retrieved by id |
| # | 19:56:53 | elene | last entry befor ebatch import in asset.call_number was "22571", so I started adding new call numbers from "52424" |
| # | 19:57:27 | elene | so now I have a gap in asset.call_number like this: "22569", "22570", "22571", "52424", "52425", "52426" |
| # | 19:57:50 | elene | Could that have created any issues? |
| # | 20:00:51 | tsbere wonders if triggers are disabled |
| # | 20:17:11 | akilsdonk has joined #evergreen |
| # | 20:23:40 | akilsdonk has quit IRC |
| # | 20:41:21 | bjwebb has quit IRC |
| # | 20:48:59 | dbs_n1 has joined #evergreen |
| # | 20:49:41 | dbs_n1 | elene: you need to run the metarecord mapping sql |
| # | 20:50:52 | dbs_n1 | tsbere: elene is on 1.6.0.1 when ingest was mostly outside the database |
| # | 20:51:08 | tsbere | dbs_n1: Good to know. |
| # | 20:51:18 | tsbere has minimal clue how most things work in 1.6.anything |
| # | 20:53:43 | dbs_n1 | http://evergreen-ils.org/dokuwiki/doku.php?id=scratchpad:random_magic_spells#how_to_generate_metarecords_for_a_newly_loaded_bib_batch |
| # | 20:54:22 | dbs_n1 | tsbere: it was perl to spidermonkey and back to perl |
| # | 20:54:34 | dbs_n1 | good fun |
| # | 20:55:31 | tsbere | Heh |
| # | 20:56:36 | tsbere | dbs_n1: Any thoughts on "circ.transit.suppress_hold" and "circ.transit.suppress_non_hold" as OU setting names for suppressing hold and non-hold transits? |
| # | 20:57:30 | dbs_n1 | is non-hold really all? |
| # | 20:59:16 | tsbere | I aimed for "if you want to stop all transits you need to set both" |
| # | 20:59:16 | dbs_n1 has quit IRC |
| # | 21:55:43 | jeff | hrm. i still thought that saving a record would generate the metabib... dbs++ for the forgotten link to generate them all, though :-) |
| # | 22:02:59 | tsbere | Anyone have thoughts? http://git.mvlcstaff.org/?p=tsbere/ILS.git;a=commit;h=4d861d7673d78eb8cc441698be8b4b0954c909aa |
| # | 22:14:59 | jeff | i reached the fourth paragraph until i understood what the intended use case was... :-) |
| # | 22:15:49 | jeff | the same-setting-id bit is clever, and eliminates potential complexity from "don't transit to this array of OUs" kind of approaches. |
| # | 22:15:56 | tsbere | yea |
| # | 22:16:16 | tsbere thought that was the easiest way to handle it |
| # | 22:16:56 | jeff | i wonder if it's "too clever", but that's what good documentation and clear settings descriptions are for, right? |
| # | 22:17:38 | tsbere | I think it is easier than trying to keep both ends of a "don't transit to these ous" setting in sync |
| # | 22:17:52 | jeff | phasefx and i talked of such library-within-a-library setups once, but went with copy stat cats instead, not least of which due to transits. |
| # | 22:18:58 | tsbere | This has the benefit of "you can suppress reshelving transits but still keep multiple hold shelves going" or "you can send things to the right part of the library but share a common hold shelf" |
| # | 22:19:52 | jeff | yeah. next up would be a "present these children as one library in the public opac" feature, i suppose. :-) |
| # | 22:20:28 | jeff | what led you to want to use multiple OUs for a library? |
| # | 22:20:39 | jeff | departmental splitting of holds pull list / etc? |
| # | 22:20:55 | tsbere | We have one library with a children's department as a branch. |
| # | 22:20:56 | jeff | we've considered shelving location hierarchy for that sort of thing. |
| # | 22:21:00 | tsbere | Beyond that, though, this isn't for us |
| # | 22:21:12 | tsbere wrote this in response to an internal RFP |
| # | 22:21:35 | tsbere | One of the other MassLNC libraries is looking to have departments under the branch or something like that |
| # | 22:21:37 | jeff | what are the reasons leading up to that department being a branch / reasons for it remaining a distinct org unit? |
| # | 22:21:45 | tsbere | or MassLNC consortia or whatever ;) |
| # | 22:22:03 | tsbere | I *think* they want to be able to have departmental circ rules and such |
| # | 22:22:07 | tsbere | not sure. |
| # | 22:22:17 | jeff | hrm |
| # | 22:22:25 | jeff | curious, that's all. |
| # | 22:23:01 | jeff | i've had reasonable success with "why are you asking me for this -- there may be a better way" today. :-) |
| # | 22:23:22 | tsbere | I don't attend enough meetings to have asked that. |
| # | 22:23:23 | tsbere | ;) |
| # | 22:24:45 | tsbere | Hmm |
| # | 22:24:57 | tsbere | I seem to recall, now that I think about it, something about search scoping too. |
| # | 22:25:02 | tsbere | As for the "why" |
| # | 22:26:58 | jeff | something that shelving location hierarchy could do also, difference being it doesn't exist yet, and your transit supression/elimination org unit settings do. |
| # | 22:27:57 | jeff | also, shelving location hierarchy could require creating of more shelving locations than currently are needed in a system, and circ_lib/owning_lib just needs an org unit to point at. |
| # | 22:29:01 | tsbere | I don't know the full set of reasons they want it. I just know they want a feature to make transits not happen. And hey, I wrote such a feature. |
| # | 22:29:11 | jeff nods |
| # | 22:29:19 | tsbere | And one (single, solitary) library in our group might find it useful too |
| # | 22:57:57 | enhancin has joined #evergreen |
| # | 23:00:34 | enhancin | I'm having an issue with the public account and ejabberd. I get errors in the srfsh.log that ejabberd as nothing to send a message to |
| # | 23:48:18 | enhancin has quit IRC |
April 10-13