| Time |
Nick |
Message |
| 01:36 |
|
beanjammin joined #evergreen |
| 05:26 |
|
beanjammin joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:59 |
|
agoben joined #evergreen |
| 07:12 |
|
rjackson_isl joined #evergreen |
| 07:37 |
JBoyer |
jeffdavis++ |
| 07:37 |
JBoyer |
berick++ |
| 07:37 |
JBoyer |
I was running into that nginix issue at home and was losing my mind. |
| 07:41 |
|
bdljohn joined #evergreen |
| 07:41 |
|
collum joined #evergreen |
| 07:52 |
|
jvwoolf joined #evergreen |
| 08:13 |
|
jvwoolf joined #evergreen |
| 08:35 |
|
jvwoolf joined #evergreen |
| 08:38 |
|
jvwoolf1 joined #evergreen |
| 08:43 |
|
remingtron joined #evergreen |
| 08:46 |
|
mmorgan joined #evergreen |
| 09:07 |
|
bos20k joined #evergreen |
| 09:07 |
bshum |
@later tell kmlussier https://i18n.evergreener.net -- master (as of this morning) demo server with i18n enabled - I'll leave it in place for the week for testing |
| 09:07 |
pinesol_green |
bshum: The operation succeeded. |
| 09:19 |
|
dickreckard joined #evergreen |
| 09:19 |
dickreckard |
uhm the documentation to upgrade to 3.1 links to some old documentation on how to update to 2.12 |
| 09:19 |
dickreckard |
http://docs.evergreen-ils.org/3.1/_upgrading_the_evergreen_server.html |
| 09:19 |
|
lsach joined #evergreen |
| 09:24 |
|
rlefaive joined #evergreen |
| 09:24 |
|
kmlussier joined #evergreen |
| 09:25 |
|
terran joined #evergreen |
| 09:32 |
dbwells |
dickreckard: Yes, we currently have an issue with how our build process and docs are coordinated. The correctly numbered instructions are in the tag branch, but those docs are built from the main branch. Don't worry, they are in this case the same other than the numbering. |
| 09:33 |
dbwells |
dickreckard: I'm going to go update the main branch to at least say some version of 3.1, but it will drift again until we nail down a better process. |
| 09:33 |
kmlussier |
bshum++ |
| 09:35 |
|
yboston joined #evergreen |
| 10:10 |
|
Christineb joined #evergreen |
| 10:24 |
remingtron |
bshum++ #for terminal demos https://evergreener.net/demos.html |
| 10:24 |
bshum |
remingtron: I should update those, but they were fun |
| 10:24 |
|
jihpringle joined #evergreen |
| 10:24 |
bshum |
remingtron: The fun part is how asciinema lets you copy/paste lines directly off the video too |
| 10:25 |
bshum |
If I was a better typist, I would type out everything as I went along next time |
| 10:25 |
remingtron |
yes, that's a great feature |
| 10:26 |
berick |
those are pretty great... |
| 10:42 |
pastebot |
"rjackson_isl" at 64.57.241.14 pasted "Failed Marc Batch Import from Web Client" (23 lines) at http://paste.evergreen-ils.org/5295 |
| 10:43 |
rjackson_isl |
Appreciate any available eyes as one site is having problems using Marc Batch Import records on web client but it works on legacy staff client |
| 11:24 |
dbs |
rjackson_isl: I've been using the batch import in the web client on 2.12 with no issues, if that's any help |
| 11:24 |
dbs |
rjackson_isl: is only one of your sites having this issue? |
| 11:25 |
rjackson_isl |
dbs: right - just on esite |
| 11:25 |
rjackson_isl |
one |
| 11:25 |
rjackson_isl |
the file imports fine from legacy staff client for them though |
| 11:25 |
rjackson_isl |
and creates the massive bogus filename from web client somehow |
| 11:28 |
dbs |
huh. browser extension? firewall filtering? Dunno :( |
| 11:29 |
rjackson_isl |
yeah - I think JBoyer indicated they route traffic thru a local school so probably related :( |
| 11:39 |
|
mmorgan joined #evergreen |
| 11:46 |
|
beanjammin joined #evergreen |
| 12:00 |
|
idjit joined #evergreen |
| 12:01 |
|
rlefaive_ joined #evergreen |
| 12:15 |
|
rlefaive joined #evergreen |
| 12:20 |
|
rlefaive joined #evergreen |
| 12:20 |
Stompro |
sandbergja++ , wow, lots of bug updates. |
| 12:35 |
|
jwoodard joined #evergreen |
| 12:37 |
|
yboston joined #evergreen |
| 12:38 |
|
abowling joined #evergreen |
| 13:03 |
jeffdavis |
We're still seeing some websockets processes stuck at 100% CPU. 4163499191d and 50a6bcad0b6d are applied on the affected server (unless I missed a problem during install). |
| 13:03 |
pinesol_green |
jeffdavis: [opensrf|Bill Erickson] LP#1744158 Websocket proc exits on ejabberd disconnect - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=4163499> |
| 13:03 |
pinesol_green |
jeffdavis: [opensrf|Bill Erickson] LP#1746577 Websocket responder exits on jabber disconnect - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=50a6bca> |
| 13:08 |
|
rlefaive joined #evergreen |
| 13:09 |
|
collum_ joined #evergreen |
| 13:19 |
|
eady joined #evergreen |
| 13:24 |
csharp |
berick: testing bug 1727557... the file appears to download fine but when I enter a patron barcode from the blocklist, firefox dies - I haven't tried in Chrome yet |
| 13:24 |
pinesol_green |
Launchpad bug 1727557 in Evergreen "Web Client: Download Block List causes unresponsive page with large file" [High,Confirmed] https://launchpad.net/bugs/1727557 - Assigned to Dawn Dale (ddale) |
| 13:25 |
* csharp |
tries Chrome |
| 13:30 |
csharp |
same behavior in Chrome |
| 13:30 |
berick |
csharp: hmm, ok |
| 13:30 |
csharp |
1631512 lines in our download |
| 13:30 |
csharp |
we can reduce that by changing the criteria for "blocked" |
| 13:31 |
csharp |
the good news is that the file downloads, though! :-) |
| 13:31 |
berick |
csharp: if you look at the db in the dev tools, it looks sane? |
| 13:34 |
csharp |
ugh - opening the dev tools makes each browser crash too :-( |
| 13:35 |
jeff |
cute. |
| 13:35 |
csharp |
yeah - trying to navigate the DB tree in FF makes it die |
| 13:37 |
csharp |
ok - Chrome is at least letting me look |
| 13:37 |
csharp |
yes, I see valid data in the offline blocks table |
| 13:38 |
berick |
does the browser differentiate between the different block types? |
| 13:39 |
berick |
i notice lots of dupes in my test file |
| 13:39 |
berick |
dupe barcodes, that is |
| 13:39 |
csharp |
finally got FF to stay open - seeing valid data there too now |
| 13:40 |
csharp |
the browser shows L, D, etc. under "reason" |
| 13:40 |
csharp |
let me look for dupes |
| 13:40 |
berick |
csharp: cut -d' ' -f1 /openils/var/web/standalone/list.txt | sort | uniq -c | wc -l |
| 13:41 |
csharp |
berick: thanks! was about to try to noodle that out |
| 13:41 |
berick |
well, that's number of unique barcodes |
| 13:42 |
csharp |
whoa: 1475225 |
| 13:42 |
csharp |
can that be right? |
| 13:42 |
berick |
hm, can't get the 'Checkout' button to activate in offline regardless of what patron barcode i enter. |
| 13:43 |
berick |
csharp: yeah, i mean, about 15% of mine are dupes. |
| 13:48 |
csharp |
when I add a grep to filter out counts of "1", I get 151627 (about 10%) which sounds more likely |
| 13:52 |
berick |
ok, if I force-activate the Checkout button, I can confirm blocked patrons are treated as such (as expected). |
| 13:52 |
csharp |
good |
| 13:52 |
dbs |
jeffdavis: yeah I'm worried about our little single app server being able to handle everyone using web staff client when we upgrade |
| 13:53 |
berick |
csharp: maybe experiment with a smaller file just to see if it works? chop it down to ~500k. |
| 13:53 |
csharp |
dbs: load definitely increased for us at first, but after some opensrf tuning (upping pcrud and cstore from wimpy defaults) things were smoother |
| 13:54 |
csharp |
berick: will do |
| 13:54 |
berick |
csharp: at this point, you might be better off with a not-blocked list :) |
| 13:54 |
csharp |
srsly |
| 14:02 |
kmlussier |
@eightball Will I have any time to squash bugs this week? |
| 14:02 |
pinesol_green |
kmlussier: In your dreams. |
| 14:02 |
terran |
Ha! |
| 14:03 |
kmlussier |
eightball has failed me. |
| 14:04 |
JBoyer |
@eightball Will you disappoint the humans? |
| 14:04 |
pinesol_green |
JBoyer: Unlikely. |
| 14:05 |
JBoyer |
Sorry kmlussier, that sounds pretty ironclad. ;) |
| 14:07 |
kmlussier |
JBoyer: I'm still shooting for Friday afternoon. Maybe pinesol_green knows of some workplace crisis that will deter me. |
| 14:09 |
csharp |
kmlussier: this is a bad week for me too - also, I usually don't get much direct squashing done because I'm helping terran and others get patches installed on test servers (which I'm happy to do) |
| 14:09 |
berick |
@who will blast [band] to get kmlussier pumped for bug squashing! |
| 14:09 |
pinesol_green |
yboston will blast All The Jeffs to get kmlussier pumped for bug squashing. |
| 14:09 |
berick |
all the other Jeffs with their pumped up kicks... |
| 14:10 |
csharp |
@band add How Many Librarians |
| 14:10 |
pinesol_green |
csharp: Band 'How Many Librarians' added to list |
| 14:10 |
|
kmlussier joined #evergreen |
| 14:11 |
kmlussier |
My IRC client got so excited about hearing All the Jeffs play that it crashed on me. |
| 14:11 |
berick |
that's how you really get work done |
| 14:13 |
csharp |
@who loaded the offline blocklist into their IRC client? |
| 14:13 |
pinesol_green |
ejk loaded the offline blocklist into their IRC client. |
| 14:15 |
ejk |
irccloud++ |
| 14:21 |
dbs |
Always hate when a dump/restore results in seemingly random functions getting dropped (e.g. metabib.compile_composite_attr but not metabib.compile_composite_attr_cache_init) |
| 14:28 |
jeff |
dbs: "dropped"? |
| 14:29 |
jeff |
dbs: silently dropped, or error on creation? |
| 14:29 |
dbs |
jeff: ok, not restored |
| 14:29 |
dbs |
pg_restore does not generate random DROP statements :) |
| 14:30 |
jeff |
well, hopefully not. :-) |
| 14:30 |
jeff |
but were there errors at restore time regarding creation of the functions? |
| 14:30 |
|
jihpringle joined #evergreen |
| 14:31 |
jeff |
my first suspicion is search path fragility. |
| 14:33 |
dbs |
jeff: yes, I thought that was pretty much guaranteed with stock dump/restore |
| 14:55 |
jeff |
dbs: sorry, not sure I follow which of my messages you were replying to. in any event, I'm interested in more details if you're willing to share! |
| 15:05 |
|
mmorgan1 joined #evergreen |
| 15:08 |
dbs |
jeff: metabib.compile_composite_attr() failed because type evergreen.query_int didn't exist (that type is actually created by intarray module in public schema) |
| 15:08 |
dbs |
Not sure if it was a search_path issue or if the module wasn't installed in the right order for some reason, it's there now |
| 15:09 |
jeffdavis |
dbs: could be an issue with the dump/restore process used, I can take a closer look but probably not today |
| 15:10 |
dbs |
And then a number of issues due to unaccent(TEXT) not being able to be found, probably because it was in the "public" schema rather than the "evergreen" schema, suggesting that the search_path hadn't been set |
| 15:10 |
dbs |
but yeah, I'm not the one running the dump/restores so hard for me to diagnose further |
| 15:12 |
dbs |
I know it's a common enough issue, though, that it would be valuable to document as part of http://docs.evergreen-ils.org/reorg/3.1/command_line_admin/_database_backups.html perhaps |
| 15:12 |
dbs |
(maybe "if you see these types of errors on restore, it means you forgot to do X")? |
| 15:16 |
jeff |
Hrm. Any idea what version of Evergreen? |
| 15:17 |
jeff |
And yeah, frustrating not being the one doing the dump/restore, especially when someone's pestering you for more info about the dump/restore. ;-) |
| 15:18 |
dbs |
jeff: 2.12, although our db dates back to the ~1.6 days |
| 15:22 |
dbs |
mrca_vlist_idx failed because operator class "evergreen.gin__int_ops" does not exist for access method "gin" - heh |
| 15:22 |
* dbs |
recently picked up some nice gin from our local https://crosscutdistillery.ca/ |
| 15:23 |
dbs |
dump method was: pg_dump --cluster <dbcluster> -U <dbuser> -i -Fd -Z 9 -f <dumpfile> --serializable-deferrable <dbname> |
| 15:35 |
jeff |
Yeah. Maybe in a previous chain of events CREATE EXTENSION intarray; was called without an explicit schema, and the default object creation schema thanks to search_path was "evergreen"... then when it came time to CREATE FUNCTIOn metabib.compile_composite_attr, the search path no longer contained "evergreen" and someone modified the function definition to reference evergreen.query_int... |
| 15:37 |
jeff |
(haven't tested, and not sure that I can test that theory) |
| 15:37 |
jeff |
I'll take a stab at writing up some of the challenges and known issues and maybe some recommendation for devs and admins. |
| 15:38 |
jeff |
Seems worthwhile. |
| 15:39 |
|
mmorgan joined #evergreen |
| 15:39 |
dbs |
That would be awesome |
| 15:45 |
jeff |
I've also been thinking again about how best to audit existing databases for issues including things like "oops, we ended up with two versions of this function in different schemas" |
| 15:46 |
jeff |
...maybe in a few days. :P |
| 15:47 |
* dbs |
heads home |
| 15:56 |
pinesol_green |
[evergreen|Galen Charlton] LP#1497322: add Perl live_t regression and unit tests for patron searching - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=28f155f> |
| 15:56 |
pinesol_green |
[evergreen|Jason Boyer] LP14973322: Search for Users by Profile - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ce419b5> |
| 15:56 |
pinesol_green |
[evergreen|Galen Charlton] LP#14973322: (follow-up) allow profile-only patron searches - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1e1e83a> |
| 16:53 |
jeffdavis |
Is it reasonable to think that bug 1765444 might be the proximate cause of open-ils.cat NOT CONNECTED errors? |
| 16:53 |
pinesol_green |
Launchpad bug 1765444 in Evergreen "webstaff MARC editor can spam requests for fixed field metadata" [Medium,New] https://launchpad.net/bugs/1765444 |
| 17:06 |
|
mmorgan left #evergreen |
| 17:29 |
|
abowling1 joined #evergreen |
| 18:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 20:26 |
|
jvwoolf joined #evergreen |
| 20:28 |
|
jvwoolf1 joined #evergreen |
| 21:01 |
pinesol_green |
[evergreen|Jane Sandberg] Docs: updating 3.0.8 release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1b8bbc3> |
| 21:01 |
pinesol_green |
[evergreen|Jane Sandberg] Docs: updating 3.1.2 release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=aa6020b> |
| 21:15 |
|
jvwoolf1 left #evergreen |
| 22:29 |
|
abowling joined #evergreen |
