| Time |
Nick |
Message |
| 05:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:47 |
|
JBoyer joined #evergreen |
| 06:48 |
|
agoben joined #evergreen |
| 07:11 |
|
rjackson_isl joined #evergreen |
| 08:29 |
|
mdriscoll joined #evergreen |
| 08:40 |
|
mmorgan joined #evergreen |
| 08:55 |
|
littlet joined #evergreen |
| 08:59 |
|
Dyrcona joined #evergreen |
| 08:59 |
|
jeffdavis joined #evergreen |
| 08:59 |
|
ejk joined #evergreen |
| 09:01 |
|
troy__ joined #evergreen |
| 09:27 |
|
stephengwills left #evergreen |
| 09:34 |
|
yboston joined #evergreen |
| 09:45 |
|
collum joined #evergreen |
| 09:47 |
Dyrcona |
So, fun with multiple PostgreSQL versions commences with the first automated attempt to restore a production dump to the 9.5 database. |
| 09:49 |
Dyrcona |
Just for the sanity of anyone else who may try running multple Pg versions like this in the future, be sure to use the version of pg_dump and pg_restore for your specific source and target databases. You can find versioned binaries under /usr/lib/postgresql/$version/bin |
| 09:50 |
Dyrcona |
Also, I'm not sure that pg_restore likes going backwards in version much, i.e. restoring a Pg 10 dump to a 9.5 database might not work. |
| 09:51 |
Dyrcona |
I *think* my restore succeeded but I got a lot of error messages about pg_restore: [archiver (db)] could not execute query: ERROR: unrecognized configuration parameter "idle_in_transaction_session_timeout", so I thought I'd figure it out and make them go away. |
| 09:59 |
|
mmorgan1 joined #evergreen |
| 10:03 |
csharp |
Dyrcona++ |
| 10:06 |
JBoyer |
Dyrcona++ # testing. |
| 10:06 |
Dyrcona |
BTW, using the wrong version of pg_dump will apparently also trigger similar messages. |
| 10:06 |
JBoyer |
And I'm certain pg_restore doesn't like to go backward, especially if you use the custom dump format. (that may cause it to refuse outright, even.) |
| 10:08 |
Dyrcona |
Yeah, I'm fairly certain about that, too, but didn't want to make any false statements. :) |
| 10:09 |
Dyrcona |
I need to pound on the Pg 10 and Pg 11 database some more. I'll have to set up VMs to run them through the various paces. |
| 10:10 |
Dyrcona |
It's nice having a decent amount of RAM and 6TB of drive space. :) |
| 10:13 |
Dyrcona |
And, not related to Pg, but related to Evergreen: One of our member library directors wrote an article about Evergreen in the April issue of Computers In Libraries: http://www.infotoday.com/cilmag/apr19/index.shtml. It is apparently not available online. |
| 10:15 |
|
sandbergja joined #evergreen |
| 10:27 |
|
mmorgan joined #evergreen |
| 10:30 |
* JBoyer |
learned today that Computers In Libraries is in the state of Indiana's INSPIRE database service... |
| 10:32 |
Dyrcona |
:) |
| 10:39 |
|
gsams joined #evergreen |
| 10:44 |
|
Christineb joined #evergreen |
| 10:46 |
berick |
Dyrcona: FYI I merged your changes into bug 1731021 |
| 10:46 |
pinesol |
Launchpad bug 1731021 in Evergreen "Enhance SIP support for fine item detail" [Wishlist,Confirmed] https://launchpad.net/bugs/1731021 |
| 10:47 |
|
khaun joined #evergreen |
| 10:47 |
Dyrcona |
berick: Cool. I'll take a look. I'm actually working on a spreadsheet of Dpearl's branches for us to discuss later today. That branch/bug is at the top of the list. :) |
| 10:48 |
|
khuckins joined #evergreen |
| 10:49 |
|
sandbergja joined #evergreen |
| 10:51 |
berick |
cool |
| 10:52 |
berick |
i rewrote his branch to address a couple of issues, jfyi |
| 11:03 |
Dyrcona |
OK. |
| 11:04 |
Dyrcona |
I know the top commit was bad. I had seen that before you commented on it. I think I'd asked it to be fixed, but not sure anymore. :( |
| 11:05 |
berick |
yeah, some commit cleanup was needed |
| 11:10 |
csharp |
@band add Broken Pipe |
| 11:10 |
pinesol |
csharp: Band 'Broken Pipe' added to list |
| 11:11 |
Dyrcona |
csharp: Where'd you find the broken pipe? |
| 11:12 |
* Dyrcona |
is curious. |
| 11:21 |
csharp |
Dyrcona: pretty much an endless stream of "Apache2::RequestIO::print: (32) Broken pipe at /usr/lib/x86_64-linux-gnu/perl5/5.22/Template.pm line 180" in our logs |
| 11:22 |
Dyrcona |
Uh huh. I think I've seen that, too. |
| 11:26 |
Dyrcona |
Yeahp.... |
| 11:27 |
Dyrcona |
Over 2,000 so far today. |
| 11:32 |
|
JasonEDN joined #evergreen |
| 11:35 |
* berick |
force-pushed one more patch to the 3m sip fines branch |
| 11:40 |
Dyrcona |
:) |
| 11:42 |
Dyrcona |
I picked it up already. I did a fetch --all just a few minutes ago. berick++ |
| 11:47 |
|
bpeters joined #evergreen |
| 11:59 |
miker |
csharp / Dyrcona: re the error log, I believe that's when a user stops their browser from loading a page (close tab, stop button, link to another page, etc). there are branches for both opensrf and evergreen to help with that that I don't /think/ have been merged yet |
| 12:05 |
|
bpeters joined #evergreen |
| 12:11 |
|
bpeters joined #evergreen |
| 12:12 |
|
yboston joined #evergreen |
| 12:13 |
|
sandbergja joined #evergreen |
| 12:38 |
|
jihpringle joined #evergreen |
| 13:04 |
jeffdavis |
I'm getting 404s on /eg2 URLs and I can't figure out why. /eg2/en-US/index.html works (I get a "Welcome to Webby!" page), as does clicking the link on that page to /eg2/en-US/staff/splash (I get the splash page), but otherwise it always fails -- I even get a 404 if I go to /eg2/en-US/staff/splash directly rather than via index.html |
| 13:30 |
jeff |
jeffdavis: ensure that you do not have a file or directory on the filesystem at that path? in the past, that has actually led to a redirect loop, not a 404, but... worth checking, if only to rule out? |
| 13:32 |
jeffdavis |
Thanks, I'll take a look. |
| 13:34 |
|
yboston joined #evergreen |
| 13:36 |
jeff |
otherwise, double check your eg2 Rewrite* directives are similar to those in Open-ILS/examples/apache_24/eg_vhost.conf.in and then... now, on second thought I'm thinking that /eg2 might exist on disk under normal circumstances, so the recycled advice from /eg might not be helpful. |
| 13:37 |
sandbergja |
jeffdavis: sometimes the console will be kind enough to display an error from the Angular router; any luck there? |
| 13:37 |
jeffdavis |
nothing I could see |
| 13:38 |
|
sandbergja_ joined #evergreen |
| 13:38 |
jeffdavis |
I'm attempting a reinstall |
| 13:54 |
berick |
the apache rewrites and FallbackResource are critical |
| 14:30 |
|
khuckins joined #evergreen |
| 15:36 |
|
yboston joined #evergreen |
| 15:37 |
jeffdavis |
Well, it's working now. Not sure what I did differently from previous reinstall attempts, but I'll assume the problem was human error. Thanks for the suggestions. |
| 15:41 |
mmorgan |
Regarding settings, I understand how workstation setting types can be copied or moved to org unit setting types. If a setting type exists as both workstation and org unit, the workstation setting would take precedence over the org unit setting. |
| 15:41 |
mmorgan |
Assuming I have that right, how do the user settings fit in? Does a user setting take precedence over a workstation setting? Is it possible to have the same setting type as workstation and user? |
| 15:42 |
Dyrcona |
mmorgan: I'm not aware of any overlap between user settings and workstation settings. |
| 15:42 |
jeff |
jeffdavis++ thanks for following up :-) |
| 15:43 |
berick |
mmorgan: workstation and user settings are mutually exclusive. a given setting type can only be one of them. |
| 15:43 |
berick |
but either can also be a workstation setting |
| 15:43 |
berick |
arg, i meant either can also be an org setting |
| 15:44 |
jeff |
phew. |
| 15:44 |
* mmorgan |
thought so :) |
| 15:45 |
mmorgan |
So given the same setting type as a user setting type and an org unit setting type, I assume the user setting takes precedence. |
| 15:45 |
berick |
mmorgan: yes |
| 15:45 |
mmorgan |
Ok, I think I have it :) |
| 15:47 |
berick |
you can also go org-setting only, which essentially causes values to reset every time the page is loaded. |
| 15:49 |
mmorgan |
To do that you'd remove that particular setting from the workstation setting types, right? |
| 15:51 |
mmorgan |
Has anyone experimented making copy templates org unit settings instead of user? |
| 15:52 |
berick |
mmorgan: right, you would have to remove the analogous workstatoin setting |
| 15:52 |
berick |
mmorgan: one limitation with org settings is there's no way in the interface to manage the values |
| 15:52 |
berick |
that's pending work |
| 15:53 |
berick |
but you can do so in the database, for example, which is simple enough for (say) grid settings |
| 15:53 |
mmorgan |
Ok, gotcha. |
| 15:53 |
berick |
well, any setting really, as long as you have the value saved as a workstation setting... |
| 15:53 |
berick |
you would just copy the value to the org unit setting |
| 15:53 |
berick |
before deleting the workstation setting type |
| 16:20 |
|
khuckins joined #evergreen |
| 16:53 |
|
mdriscoll left #evergreen |
| 17:01 |
|
sandbergja_ joined #evergreen |
| 17:05 |
|
mmorgan left #evergreen |
| 17:30 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:35 |
|
BlanBish joined #evergreen |
| 20:22 |
|
sandbergja joined #evergreen |
| 21:17 |
|
jamesrf joined #evergreen |
| 22:37 |
|
sandbergja joined #evergreen |
| 22:55 |
|
sandbergja joined #evergreen |
| 23:46 |
|
sandbergja joined #evergreen |
