Evergreen ILS Website

IRC log for #evergreen, 2019-05-13

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

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

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat