| Time |
Nick |
Message |
| 05:55 |
|
mtate joined #evergreen |
| 05:55 |
|
pmurray joined #evergreen |
| 05:55 |
|
pmurray joined #evergreen |
| 05:55 |
|
chatley joined #evergreen |
| 05:55 |
|
eeevil joined #evergreen |
| 07:13 |
|
jboyer-isl joined #evergreen |
| 07:56 |
|
remingtron joined #evergreen |
| 08:09 |
|
remingtron_ joined #evergreen |
| 08:18 |
|
akilsdonk joined #evergreen |
| 08:30 |
|
mrpeters joined #evergreen |
| 08:31 |
|
akilsdonk joined #evergreen |
| 08:40 |
|
_bott_ joined #evergreen |
| 08:41 |
|
ericar joined #evergreen |
| 08:43 |
|
ericar left #evergreen |
| 08:49 |
|
kmlussier joined #evergreen |
| 08:56 |
|
tspindler joined #evergreen |
| 08:57 |
|
Dyrcona joined #evergreen |
| 09:35 |
|
artunit joined #evergreen |
| 09:53 |
|
jwoodard joined #evergreen |
| 09:54 |
|
dkyle left #evergreen |
| 10:09 |
kmlussier |
Good morning all! |
| 10:13 |
|
Wyuli joined #evergreen |
| 10:14 |
jeff |
good morning! |
| 10:49 |
|
akilsdonk joined #evergreen |
| 10:57 |
tspindler |
@weather |
| 10:57 |
pinesol_green |
tspindler: (weather <US zip code | US/Canada city, state | Foreign city, country>) -- Returns the approximate weather conditions for a given city. |
| 10:57 |
|
mjingle joined #evergreen |
| 10:57 |
tspindler |
@weather 01605 |
| 10:57 |
pinesol_green |
tspindler: The current temperature in Thornton Rd., Worcester, Massachusetts is 86.0°F (10:57 AM EDT on July 22, 2014). Conditions: Clear. Humidity: 20%. Dew Point: 41.0°F. Pressure: 30.15 in 1021 hPa (Falling). |
| 10:58 |
tspindler |
@sortinghat |
| 10:58 |
pinesol_green |
Hmm... tspindler... Let me see now... GRYFFINDOR! |
| 10:58 |
kmlussier |
@sortinghat |
| 10:58 |
pinesol_green |
Hmm... kmlussier... Let me see now... GRYFFINDOR! |
| 10:59 |
tspindler |
@librarian |
| 10:59 |
pinesol_green |
tspindler: Management:14, Cataloging:13, Acquisitions:14, Reference:8, Circulation:14, Systems:15, Research:12, Custodial:7 |
| 11:05 |
kmlussier |
@coffee tspindler |
| 11:05 |
* pinesol_green |
brews and pours a cup of Sumatra Lake Tawar, and sends it sliding down the bar to tspindler |
| 11:07 |
|
dkyle joined #evergreen |
| 11:08 |
|
mjingle joined #evergreen |
| 11:10 |
|
mjingle joined #evergreen |
| 11:12 |
|
akilsdonk_ joined #evergreen |
| 11:43 |
pinesol_green |
[evergreen|Dan Pearl] LP#827442 Z39.50 will split the total cap between locations when multiple locations selected - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a5d2ba3> |
| 11:45 |
Dyrcona |
dbwells and anyone else for that matter: Should the above be backported to 2.6 and/or 2.5? |
| 11:47 |
* bshum |
doesn't care to backport, but leaves that to dbwells to decide as current release maintainer for those versions. |
| 12:04 |
|
mtate joined #evergreen |
| 12:06 |
|
dbwells joined #evergreen |
| 12:09 |
|
dbwells_ joined #evergreen |
| 12:09 |
Dyrcona |
Oops. Guess dbwells wasn't here earlier. |
| 12:12 |
|
dbwells joined #evergreen |
| 12:18 |
bshum |
parts-- |
| 12:34 |
kmlussier |
parts++ |
| 12:34 |
|
bmills joined #evergreen |
| 12:37 |
|
_bott_ joined #evergreen |
| 13:05 |
|
akilsdonk joined #evergreen |
| 13:31 |
|
collum joined #evergreen |
| 14:27 |
|
mjingle joined #evergreen |
| 14:56 |
kmlussier |
OK, I'm back to the problem of getting a PO name to end in an EDI order. This is the JEDI template body of an order sent to Ingram yesterday. http://pastebin.com/6SLPH92p You can see the po name (15-016) in the body. |
| 14:57 |
kmlussier |
But this is the EDI message that was sent http://pastebin.com/uXJQynLu |
| 14:57 |
kmlussier |
The PO name isn't there. Any thoughts on why the PO name isn't being sent in the EDI message? |
| 14:59 |
|
Wyuli joined #evergreen |
| 15:00 |
berick |
kmlussier: next sug. is ensure you have the latest version of https://github.com/berick/openils-mapper |
| 15:00 |
berick |
well, rather, https://github.com/berick/openils-mapper/tree/GIR-segments-for-copy-data |
| 15:00 |
* kmlussier |
turns to Dyrcona to answer that question. :) |
| 15:01 |
Dyrcona |
We have whatever the install script for EDI installed. |
| 15:04 |
kmlussier |
berick: Is this something that should be added to the EDI installation documentation? Or, perhaps, should be part of the standard install script? |
| 15:05 |
berick |
kmlussier: https://bugs.launchpad.net/evergreen/+bug/1297967 |
| 15:05 |
pinesol_green |
Launchpad bug 1297967 in Evergreen "document openils-mapper code for enriched EDI" (affected: 1, heat: 6) [Undecided,New] |
| 15:05 |
berick |
what we *need* to go is get rid of all this ruby, etc. crap |
| 15:06 |
Dyrcona |
Yes, we do. |
| 15:06 |
berick |
bu in the meantime, changes to the external code should be documented as part of the upgrade, uyes |
| 15:06 |
berick |
s/crap/difficult to maintain moving parts/ |
| 15:07 |
Dyrcona |
I've never had a good experience with something done in ruby. |
| 15:07 |
Dyrcona |
I've always had to install some other version than what comes with my distro because of incompatibilities with some gem or another. |
| 15:08 |
kmlussier |
berick: Thanks. Another thing to add to my documentation to-do list. :) |
| 15:08 |
berick |
Dyrcona: there's that, too |
| 15:10 |
berick |
kmlussier: version #'s may vary, but this is a quick way to see if your ruby stuff supports PO name.. |
| 15:10 |
berick |
grep po_name /usr/lib/ruby/gems/1.8/gems/openils-mapper-0.9.9/lib/openils/mapper.rb |
| 15:10 |
berick |
if you get output, you're probably fine |
| 15:18 |
Dyrcona |
Documenting that would be good, getting that done via the install.sh for edi would be better. |
| 15:18 |
Dyrcona |
After installing this, do I have restart webrick.rb? |
| 15:18 |
berick |
Dyrcona: yes |
| 15:19 |
Dyrcona |
berick: Thanks! I thought so. |
| 16:05 |
|
ahelten joined #evergreen |
| 16:12 |
|
ahelten joined #evergreen |
| 16:17 |
|
jwoodard joined #evergreen |
| 16:22 |
|
_bott_ joined #evergreen |
| 16:36 |
|
tspindler left #evergreen |
| 16:44 |
|
dbwells_ joined #evergreen |
| 16:49 |
ahelten |
Hello, I'm attempting to upgrade from 2.2.1 to 2.6.2 but getting errors in the database upgrade, the first one being in the 2.3-2.4.0-upgrade-db.sql script |
| 16:49 |
ahelten |
psql:2.3-2.4.0-upgrade-db.sql:96: ERROR: operator family "gist_tsvector_ops" does not exist for access method "gist" |
| 16:49 |
ahelten |
Any ideas? |
| 16:53 |
phasefx |
ahelten: what version of postgres are you using? |
| 16:53 |
ahelten |
9.1.1 |
| 16:54 |
ahelten |
sorry, 9.1.13 |
| 16:58 |
ahelten |
In looking back at my previous upgrade, 1.6.0.4 to 2.2.1, I had to upgrade to Postgres 9.1 and I see now that I had some errors on the original database import: |
| 16:58 |
ahelten |
function gin_extract_tsquery(pg_catalog.tsquery, internal, smallint) does not exist |
| 16:59 |
ahelten |
And 3 or 4 other errors like that (missing functions) |
| 16:59 |
phasefx |
looks like once before csharp had not quite the same error, but in the same vicinity: http://evergreen-ils.org/irc_logs/evergreen/2013-05/%23evergreen.22-Wed-2013.log |
| 16:59 |
phasefx |
http://evergreen-ils.org/irc_logs/evergreen/2013-05/%23evergreen.24-Fri-2013.log |
| 17:07 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:12 |
pastebot |
"ahelten" at 64.57.241.14 pasted "Errors during import into PG 9.1 database of 1.6.0.4 export" (38 lines) at http://paste.evergreen-ils.org/72 |
| 17:14 |
ahelten |
phasefx: I think csharp's problem was different and unfortunately those irc logs don't even show how he solved the problem. The more I look at this, the more I think it goes back to the upgrade to Pg 9.1 |
| 17:14 |
ahelten |
Here is the error from the Pg 9.1 import (at least I'm pretty sure that it's from the import): http://paste.evergreen-ils.org/72 |
| 17:16 |
ahelten |
BTW, I don't work with databases much so this all new and somewhat greek to me |
| 17:20 |
dbwells |
ahelten: Is your 2.2 install functional, or is 1.6.0.4 your live version? |
| 17:20 |
ahelten |
2.2 functions fine and has for 2 years. Granted, we are a small school library so we don't use a lot of the features |
| 17:21 |
ahelten |
So, yes, 2.2 is our live version |
| 17:23 |
dbwells |
:q |
| 17:24 |
dbwells |
oops :) |
| 17:29 |
ahelten |
Hmmm, this post says something about the functions (search that email for 'gin_extract_tsquery'): https://www.mail-archive.com/open-ils-dev@list.georgialibraries.org/msg04792.html |
| 17:29 |
ahelten |
He says those functions have different signatures now but that "Anything that was built from the old versions is now built from the new ones, so they're not a problem." |
| 17:30 |
ahelten |
Not sure what that means and not sure why it would be an error if it was able to resolve the function (should have been info or warn) |
| 17:34 |
|
hbrennan joined #evergreen |
| 17:40 |
bshum |
Wow, that's an old message. Throwback to the 8.3 to 8.4 upgrade fun. |
| 17:41 |
bshum |
Which presumably would have been passed already if you're running a 2.2 system on PG 9.1 |
| 17:41 |
bshum |
I'd wonder if those initial import issues were due to the method used to export / import into the new database. |
| 17:42 |
dbwells |
ahelten: It's late in the day, so this might be suspect advice, but I'd try to just comment out line 96 from that upgrade file and see what happens. It was supposed to be a safety measure, but it might be making assumptions about your DB history / setup which just aren't true. |
| 17:42 |
ahelten |
dbwells: I'll give it a try |
| 17:43 |
bshum |
ahelten: You're running your upgrades on a test server I hope. |
| 17:43 |
bshum |
Using a copy of your real database |
| 17:43 |
ahelten |
Yes |
| 17:44 |
dbwells |
There is something unexpected about your transition from the tsearch2 extension to the inbuilt stuff, but I can't exactly put my finger on where your DB is at. |
| 17:47 |
ahelten |
Error moved to line 98: psql:2.3-2.4.0-upgrade-db.sql:98: ERROR: extension "tsearch2" does not exist |
| 17:47 |
ahelten |
I'll try commenting out that one |
| 17:47 |
dbwells |
ahelten: Yes, I was kinda expecting that to be the case |
| 17:50 |
ahelten |
OK, disabling both 96 and 98 gets me farther. I now have a Perl error which appears to be related to the dependency 'make install' installing everything in /root/perl5 instead of a system path. I can fix that but any idea how that happened? |
| 17:51 |
dbwells |
ahelten: So, for the record, it sounds like you inadvertantly switched to native full-text search in version 2.2 even though it wasn't officially supported until 2.4. Interesting to know that native full-text worked for you in 2.2 :) |
| 17:52 |
bshum |
dbwells: ahelten: I wonder if it's search_path related strangeness from moving from whatever version of PG was being used before 9.1 and importing the 1.6 DB into it, and then upgrading. There's stuff way back in the 1.6.1-2.0 that aren't fully schema qualified and related to tsearch2, etc. and probably were broken way back. |
| 17:53 |
bshum |
Hard to tell this far down the upgrade dance and without looking at the actual database contents. |
| 17:53 |
ahelten |
dwells: yes definitely inadvertent but definitely was working |
| 17:53 |
ahelten |
bshum: I found one forum post that mentioned search_path with respect to missing PG functions during imports |
| 17:54 |
bshum |
~search_path |
| 17:54 |
pinesol_green |
After restoring a database, make sure to reset the search_path accordingly with something like: alter database unpredicable_haxxors_go_away set search_path = evergreen, public, pg_catalog; |
| 17:54 |
dbwells |
ahelten: for your new problem, I'm not sure what you mean. What is "everything" in this case? |
| 17:54 |
bshum |
ahelten: Yeah search_path has been more of an issue with more recent postgresql database restores from Evergreen databases, so it might be important. Though like dbwells says it seems that tsearch2 was just MIA in your system |
| 17:55 |
bshum |
Or it sounds like it |
| 17:55 |
ahelten |
Well, "everything" might be an exageration but it appears to be stuff installed by CPAN ends up in /root/perl5 |
| 17:55 |
ahelten |
bshum: should we be using tsearch2? Sounds like it |
| 17:56 |
bshum |
What OS is this? |
| 17:56 |
ahelten |
dbwells: Rose/URI.pm in this instance |
| 17:56 |
ahelten |
bshum: Ubuntu 12.04 |
| 17:57 |
ahelten |
full version: Ubuntu 12.04.4 LTS |
| 17:57 |
bshum |
ahelten: Well, most of what you're seeing in the 2.3-2.4 upgrade script is a process to get rid of tsearch2 as an added extension, because we changed it. |
| 17:57 |
bshum |
Err, it was no longer necessary |
| 17:57 |
ahelten |
bshum: ok |
| 17:58 |
bshum |
So you "need it" only because the script expected you to have had it from prior setup |
| 17:58 |
bshum |
And that's weird sounding, for a Ubuntu system. I would have expected perl stuff to have gone into some /usr/local/share/perl/.... directory. |
| 17:59 |
ahelten |
bshum: yep, I certainly didn't do anything intentional to put Perl installs somewhere else -- but maybe answered something wrong during original cpan setup |
| 18:02 |
ahelten |
Well, 2.3-2.4 seems to be happy at least it looks like expected errors from running the 2.3-2.4 script multiple times (i.e. key already exists stuff) |
| 18:09 |
pastebot |
"ahelten" at 64.57.241.14 pasted "2.3-2.4-supplemental.sh script failures" (45 lines) at http://paste.evergreen-ils.org/73 |
| 18:10 |
ahelten |
ok, didn't make it much farther, the 2.3-2.4-supplemental.sh script is failing: http://paste.evergreen-ils.org/73 |
| 18:10 |
ahelten |
This looks like it might be search_path related? |
| 18:10 |
ahelten |
So maybe I should deal with that now |
| 18:10 |
bshum |
No, if schema "metabib" can't be found that sounds like something not-good happened during your PG restore. |
| 18:11 |
bshum |
Since that schema ought to exist |
| 18:11 |
bshum |
Alot of schemas should exist... |
| 18:11 |
ahelten |
bshum: well, it does appear to exist in my evergreen db |
| 18:11 |
|
vlewis joined #evergreen |
| 18:12 |
ahelten |
For example, (using webmin because I'm db illiterate), this returns results: select * from "metabib"."identifier_field_entry" limit 25 offset 0 |
| 18:12 |
bshum |
ahelten: I'm guessing that the supplemental script is connecting with the wrong database then. |
| 18:15 |
ahelten |
bshum: looks like I should do something like this (similar to what pinesol_green suggested): SET search_path TO evergreen, public; |
| 18:17 |
ahelten |
Hmmm, so current search_path is: "$user",public |
| 18:18 |
ahelten |
Where user in this case is postgres instead of evergreen (I have no 'evergreen' system user) |
| 18:18 |
bshum |
You have a very interestingly put-together Evergreen system :) |
| 18:20 |
ahelten |
Yeah, it would probably make you cry. I'm a part-time volunteer IT guy for the local school so they get what they pay for (I'm a programmer by nature, not an IT guy) |
| 18:21 |
dbwells |
ahelten: I'm with bshum, your supplemental script isn't connecting to the the right DB. |
| 18:23 |
ahelten |
dbwells: how do I fix this? Edit the script or can this be done via search_path? I tried this but it didn't work (just retained previous value): SET search_path TO '$user', evergreen, public; |
| 18:24 |
dbwells |
No, search path won't help you here. I'm not sure what determines a users "default" DB, but you could just add the '-d dbname' flag to each line in the script. |
| 18:24 |
ahelten |
ok |
| 18:24 |
dbwells |
e.g. psql -d evergreen -c ... (if your database is named 'evergreen') |
| 18:25 |
ahelten |
yes it is named "evergreen", yeehaw something is standard!! |
| 18:26 |
dbwells |
If you get that running, it "will take a while", and I think that's no lie. |
| 18:27 |
dbwells |
I'm heading out in any case. Hope things go smoother from here for you. |
| 18:27 |
ahelten |
dbwells: most of the "take a while" threats are not true on our little database but it is working away now, looks like the -d worked |
| 18:27 |
bshum |
dbwells++ |
| 18:28 |
ahelten |
dbwells: thanks for the help, you got me past a couple problems anyway |
| 18:57 |
|
jmccarty joined #evergreen |
| 19:51 |
ahelten |
bshum, I have more testing to do but so far it looks like my upgrade to 2.6.2 was successful. Thanks again for the help |
| 19:52 |
bshum |
ahelton: Good luck! Hope things continue to work out |
| 20:10 |
|
wjr_ joined #evergreen |
| 21:51 |
|
mtcarlson joined #evergreen |
