Evergreen ILS Website

Search in #evergreen

Channels | #evergreen index




Results

Result pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143

Results for 2019-03-21

05:02 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
07:01 agoben joined #evergreen
07:15 rjackson_isl joined #evergreen
07:34 bdljohn joined #evergreen
08:40 bos20k joined #evergreen
08:53 mmorgan joined #evergreen
08:54 Dyrcona So, I think my issues with the fine generator and open-ils.storage are memory issues.
08:57 Dyrcona Because, I started running the fine generator on a test VM yesterday and today, I see that is has used swap, and there's a decent amount of RAM in the O/S cache: 4GB.
08:57 Dyrcona I'm working on getting the rss sizes of the drones, the listener is not presently all that big.
08:59 aabbee joined #evergreen
09:07 Dyrcona Interesting... All of the storage processes, including the listener have had 15,000+ minor page faults while running. That's no big deal, right, because that's accessing stuff that's in RAM already.
09:44 nfBurton joined #evergreen
09:55 tlittle joined #evergreen
10:01 tlittle joined #evergreen
10:05 Dyrcona So, our storage drones seem to use around 260MB of RAM apiece and I'm cycling through them rather quickly, at least on this test machine.
10:06 Dyrcona Perhaps, I should up the connection count settings on the machine that runs the fine generator?
10:22 jeff I wouldn't focus on the swap usage too much, especially that amount. If vm.swappiness is at the default of 60, swap usage isn't something that indicates "we're running out of physical memory".
10:25 Dyrcona jeff: I know that it normally doesn't. It can, though if your swap usage gets really high and you have a large number of swap ins and swap outs....When swap usage is 100%, you've got real problems. :)
10:26 Dyrcona I also think that bumping the connection count for storage on the utility server will help, as I'll cycle through drones less quickly that way.
10:27 jeff Sure, just trying to talk you down from chasing "why did my system use 1.6 megabytes of swap" :-)
10:27 Dyrcona Yeah, and it dropped to 160K rather soon after.
10:28 Dyrcona The fine generator has been running for the past 1.5 hours on my test vm, and it is still doing something as I'm tailing syslog.
10:29 Dyrcona The test db is also busy with other things.
10:29 Dyrcona when this stops. I'll up the connection count by a factor of 10.
10:34 collum joined #evergreen
10:36 Dyrcona Looks like drones are being recycled at a rate of about 1 every 3 minutes.
10:47 Dyrcona Seems to be going through cstore drones at a similar clip, too. That must be some of the storage calls using cstore.
10:48 Dyrcona Think I'll up the max requests on cstore for the next test.
11:22 phasefx @later tell sandbergja re: LP1721109, I noticed a syntax error in line 430 of cat/item/app.js, with  var all_items = itemSvc.copies.map((item) => {return item.id});
11:22 pinesol phasefx: The operation succeeded.
11:32 jeff certificate expired on https://yeti.esilibrary.com
11:36 sandbergja joined #evergreen
11:37 Dyrcona Lp 1721109
11:37 pinesol Launchpad bug 1721109 in Evergreen 3.2 "Web client: Editing item information from the item status screen does not automatically update item status display" [Medium,Fix committed] https://launchpad.net/bugs/1721109
11:37 phasefx also, I only saw the syntax error with npm, haven't tested it in a real browser.  Could be a version issue on my end given that the functionality tested out
11:38 phasefx npm and rhino
11:38 berick that would be interesting if browsers supported arrow functions
11:38 berick not impossible
11:39 Dyrcona rhino? Really?
11:45 Dyrcona https://developer.mozilla.org/en-US/do​cs/Web/JavaScript/Reference/Functions/​Arrow_functions#Browser_compatibility
11:45 berick Dyrcona: neat
11:45 khuckins joined #evergreen
11:45 phasefx fwiw, the live tester behaves the same (reports a syntax error) but doesn't flag a warning/error with the QA tests
11:46 Dyrcona phasefx: You're getting the syntax from npm run test ?
11:46 phasefx Dyrcona: yeap
11:47 phasefx http://testing.evergreen-il​s.org/~live/cronoutput.txt
11:47 * Dyrcona usually skips that.
11:48 berick probably best to de-arrow-ify for now
11:48 sandbergja_ joined #evergreen
11:49 Dyrcona So, PhantomJS doesn't like it.
11:49 phasefx Dyrcona: I tried to make the installer match the instructions on the website as closely as possible; we call for npm run test there
11:49 Dyrcona phasefx: Yeah, it definitely makes sense to run the test on the QA testing server. :)
11:49 phasefx :D
11:50 Dyrcona I usually skip it on my own installations because it usually passes and I'm lazy. :)
11:57 jeff so that's unlikely to happen anytime soon.
11:58 sandbergja JBoyer: hahaha, that's what I thought. :-)
11:58 JBoyer Is it still used by node, or only the version of node that builds the AngularJS parts of the client?
11:59 berick JBoyer: it's used for headless unit tests
11:59 berick node doesn't use it
11:59 JBoyer Ah, that's where I was getting confused.
11:59 JBoyer berick++
12:02 jeff_ joined #evergreen

Results for 2019-03-20

01:21 sandbergja_ joined #evergreen
05:01 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
06:48 agoben joined #evergreen
07:11 rjackson_isl joined #evergreen
07:36 bdljohn joined #evergreen
15:32 berick dbwells++
15:32 berick thanks
15:40 phasefx Stompro: Dyrcona: the call number pull list fix (lp1749502), for me, if you do Print Full List twice in a row, it renders the affix id's and not the labels
15:41 csharp ok, so the next step, I think, is to implement cross-domain registration in a test environment.  Does anyone out there have docs or examples I could use for this?  I have a high-level understanding of what needs to happen, but I'm not sure how to actually do it
15:42 * csharp steps away for a bit but will be back soon
15:49 sandbergja_ joined #evergreen
15:50 berick csharp: take w/ grain of salt cuz I'm not using it, but IIRC you just have to add public and private <router> entries in opensrf_core.xml per each host
15:50 berick that's assuming the bricks can already route to each other and jabber is using non-localhost domains (e.g. private.brick01, public.brick01, etc.)
15:52 Dyrcona phasefx: I see that one some rows but not others. I'm getting -1 on some prefixes.
15:52 Dyrcona Also, doing it a third time, everything looks OK.
15:53 Stompro phasefx, Interesting, I'll test that out.
15:55 phasefx I imagine most folks will only invoke it once per page load, but my chaos powers are compulsive
15:55 Dyrcona Doesn't seem to be much rhyme nor reason when it happens and if it it is prefix, suffix, or both.
15:55 Dyrcona Well, if you do it again and again you get different results each time, at least I seem to.
16:09 phasefx Stompro: sure, it's back up, but with an extra commit beyond master
16:09 phasefx in the pull list grid UI, no less :) but shouldn't affect the bug
16:10 Dyrcona Stompro: I saw the same thing as phasefx. I could open it, look at it, close, then open it again.
16:12 Stompro phasefx, yep, I see it too on your test system.  Hmm, I'll check to see what I missed when creating the commit.
16:15 Dyrcona I'm only seeing it with affixes of -1. phasefx did you see it with others?
16:15 phasefx Dyrcona: yes, the REF one from concerto
16:16 Dyrcona OK. Could be that the list I was looking at had no actual affixes.
16:16 Dyrcona I was using production data with a small library.
16:16 phasefx I created a pull list in concerto by hitting up 3 bibs with copy level holds, and specifically modifying the item for the 2nd hold to have a prefix and suffix
16:17 Dyrcona Good way to test it. I just logged in and brought up the pull list. :)
16:17 phasefx I also played with location affixes too, because I forgot those were just for label printing
16:19 * phasefx is poking at lp1779316 and wanted to see what changes were made recently
16:19 Dyrcona I wonder if fleshing the affixes would be better than going back and retrieving them? We seem to do a lot of pcrud lookups in the web staff client for that sort of thing.
16:57 sandbergja__ joined #evergreen
17:00 sandbergja__ Hey all -- I've got Evergreen running on localhost, using docker.  But Firefox doesn't like weird ports like 7682 under a self-signed certificate. Does anybody know if there's a way I can adjust about:config so that Firefox isn't so picky about that?
17:00 sandbergja__ FWIW, I can use Chromium just fine.
17:02 pinesol News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~li​ve/test.42.html#2019-03-20T16:59:00,937625555-0400 -0>
17:03 sandbergja__ I tried setting network.security.ports.banned.override to 7682, but that didn't help :-(
17:05 mmorgan left #evergreen
17:13 berick sandbergja__: try navigating to https://HOST:7682/osrf-websocket-translator

Results for 2019-03-19

00:02 sandbergja joined #evergreen
05:01 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
07:15 rjackson_isl joined #evergreen
07:31 agoben joined #evergreen
07:41 bdljohn joined #evergreen
11:26 Dyrcona Ok. I take that back. Of the two that are active, one has a custom granularity that works out to daily, the other doesn't.
11:27 Dyrcona Ours are working, but we're on 3.0.13.
11:28 pastebot "Bmagic" at 64.57.241.14 pasted "Trigger logs" (7 lines) at http://paste.evergreen-ils.org/10507
11:28 Dyrcona They seem to be working on our 3.2 test machine.
11:29 Dyrcona To answer your question, no. If that's the main trigger that marks items lost it goes by checkout.due.
11:30 Dyrcona The notices and extra triggers that play off something going lost should have lost.auto.
11:30 Bmagic yep, that's what I've got
16:45 nfBurton joined #evergreen
16:45 csharp okay - websocketd is back in place - no significant difference between now and before with apache2-websockets
16:45 csharp also looks like restarting services staves off the issue for a while
16:46 nfBurton Quick Q: Running an update on my test server and keep getting " duplicate key value violates unique constraint "upgrade_log_pkey"". Is there something wrong with my DB or the upgrade script?
16:46 nfBurton The DB upgrades are not my friend today
16:47 csharp nfBurton: sounds like you're trying to apply an upgrade you already have?
16:47 nfBurton I'm not though...
16:52 nfBurton I've been commenting those out since they aren't Combo Breakers
16:53 csharp it only happens if you apply upgrade scripts outside normal "version" upgrades
16:53 csharp which I think all of us do from time to time
16:54 nfBurton Yeah. This is just my test which I thought was in line with my production site but may have pushed some updates along at some point
16:55 nfBurton Is there a generally accepted reinjest script for the whole catalog as well? While I am here
16:55 nfBurton I should run that too
16:56 csharp nfBurton: Open-ILS/src/support-scripts/pingest.pl is nice if you have a large database
17:01 csharp hmm
17:01 nfBurton Yeah
17:01 nfBurton I have set up 3 new collections and they all do the same thing
17:01 pinesol News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~li​ve/test.42.html#2019-03-19T16:57:59,497208919-0400 -0>
17:01 nfBurton I feel like a CRON job must clean them up if it randomly happens
17:03 csharp might need to look directly at the metabib data for the records where it's not changing
17:04 csharp that's getting into territory I'm less familiar with day-to-day, but have had to troubleshoot before

Results for 2019-03-18

00:46 sandbergja joined #evergreen
04:37 jamesrf joined #evergreen
05:01 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
07:00 JBoyer joined #evergreen
07:02 agoben joined #evergreen
07:10 rjackson_isl joined #evergreen
09:59 Dyrcona berick: I think csharp was referring to the fact that apache2-websocket processes would go ballistic from time to time, not that it made a difference in drone usage.
09:59 Dyrcona At least, that's what I meant about websocketd making a difference.
10:04 csharp berick: so the idle timeout with websocketd is set in the nginx config, right? (as opposed to the apache config for apache2-websockets where we left the nginx timeouts higher)
10:04 berick csharp: correct
10:05 berick as a test, maybe knock it down to 1 minute
10:05 miker csharp: opensrf is already able to distribute load. you can create a single xmpp domain, as Dyrcona suggests, or just tell the services about all the existing domains (which requires they have non-localhost addresses and unique names)
10:05 csharp berick: thanks
10:05 * Dyrcona uses non-localhost addresses anyway, but doesn't do cross-brick communication, yet.
15:40 miker gmcharlt: will look, sec
15:44 berick forgot all about that stuff
15:45 berick gmcharlt: i trust your research there.
15:48 miker gmcharlt: hrm. it looks to me like we still eval it into place if no added content provider is defined in opensrf.xml, no? I haven't looked past the named commit yet
15:49 miker gmcharlt: we don't in master... ok, it does look dead to me, indeed
15:51 miker looks like we can drop a test! :)
15:52 miker Open-ILS/src/perlmods/t/06-O​penILS-Application-Search.t specifically
15:52 miker or, one in there
15:53 bdljohn joined #evergreen
16:25 csharp ...and we're back to drone saturation
16:25 csharp might have to revert to apache2-websockets
16:58 csharp sounds more like the album name than the band name though
17:00 bshum jeff++ berick++ csharp++ # I miss production issues (not really)
17:00 csharp it's a mixed bag - the soul-crushing lows are often followed by dizzying highs
17:01 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
17:01 * bshum now wants pumpkin pie
17:01 bshum It's too early for this.
17:02 * bshum wanders off, but will read the rest of this adventure story later
17:41 csharp this feels like something that could be fixed with tuning configs though
17:42 csharp at this very moment, everything is pretty balanced across (after restarting opensrf to reactivate backlog queuing)
17:42 csharp also just generally calmer
17:43 berick yeah, probably over the hump
17:44 berick well, keep us posted, especially if you decide to revert websocketd to test.
17:44 csharp thanks!
17:44 berick guessing tests now won't prove much
17:45 csharp agreed
19:33 Dyrcona joined #evergreen
20:26 gryffonophenomen joined #evergreen

Results for 2019-03-17

01:07 sandbergja joined #evergreen
05:01 pinesol News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~li​ve/test.42.html#2019-03-17T04:57:23,484151305-0400 -0>
09:47 sandbergja joined #evergreen
11:30 sandbergja joined #evergreen
15:52 sandbergja joined #evergreen
17:01 pinesol News from qatests: Failed Create Evergreen Database <http://testing.evergreen-ils.org/~li​ve/test.41.html#2019-03-17T16:54:50,976448567-0400 -0>
17:01 pinesol News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~li​ve/test.42.html#2019-03-17T16:54:51,004602185-0400 -2>
17:01 pinesol News from qatests: Failed Running pgTAP live tests <http://testing.evergreen-ils.org/~li​ve/test.47.html#2019-03-17T16:54:51,032760892-0400 -4>
19:19 sandbergja joined #evergreen
20:27 sandbergja joined #evergreen
21:31 sandbergja joined #evergreen

Results for 2019-03-16

05:01 pinesol News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~li​ve/test.42.html#2019-03-16T04:57:38,930319641-0400 -0>
11:15 sandbergja joined #evergreen
17:01 pinesol News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~li​ve/test.42.html#2019-03-16T16:59:35,802275636-0400 -0>
18:04 sandbergja joined #evergreen

Results for 2019-03-15

05:01 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
05:17 RBecker joined #evergreen
06:59 agoben joined #evergreen
07:14 rjackson_isl joined #evergreen
13:05 Dyrcona Bmagic 00:00:06, 00:00:08, and one is 5 minutes.
13:05 Dyrcona RMiller_ I'm working on a complete insert SQL for you.
13:06 RMiller_ Thank you! I'm starting to figure out SQL stuff a little, but I don't want to make a bigger mess
13:08 pastebot "Dyrcona" at 64.57.241.14 pasted "RMiller_ Should work. I have not tested it." (9 lines) at http://paste.evergreen-ils.org/10296
13:08 mmorgan Dyrcona++
13:12 RMiller_ That fixed it! Check in is working now!
13:12 RMiller_ Thank you so much!
13:12 Dyrcona You're welcome.
13:29 * Dyrcona is going to reboot the laptop.
13:38 Dyrcona joined #evergreen
14:24 Stompro Dyrcona, about splitting the code up.  Does each commit need to be fully independent of each other for a situation like this, or can they build off of each other, seperate commits in the same branch that should be tested together?
14:26 Dyrcona Stompro: Either way, could also all be in one commit. It depends on the tickets, etc.
14:26 Dyrcona I prefer to split things up into logical chunks and prefer not to have branches that cover multiple Lp bugs, but I sometimes do the latter.
14:27 * Dyrcona is not a huge fan of omnibus branches or bugs, but deals with 'em when they happen.
14:29 Dyrcona More specifically, I was offering to help if you had a single commit, say, that you wanted to split into multiple commits.
14:44 stephengwills joined #evergreen
14:52 yboston joined #evergreen
17:01 pinesol News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~li​ve/test.42.html#2019-03-15T16:58:14,560346605-0400 -0>
17:05 mmorgan left #evergreen
17:44 mcgriff joined #evergreen
18:42 stephengwills joined #evergreen

Results for 2019-03-14

00:23 sandbergja joined #evergreen
05:00 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
06:32 JBoyer_alt joined #evergreen
06:37 bos20k joined #evergreen
06:55 agoben joined #evergreen
09:49 sandbergja joined #evergreen
10:03 pinesol [evergreen|Bill Erickson] LP1739293 Record merge horizontal; optional holdings - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=29882b4>
10:03 pinesol [evergreen|Bill Erickson] LP1739293 Record merge fits container - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=d2ad575>
10:03 Bmagic csharp: Do you have a machine seperate from the production cluster that you can test on? Things started becoming more clear once I did that
10:03 pinesol [evergreen|Bill Erickson] LP1739293 Record merged edit-in-place avoid wrap - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=df8973b>
10:13 Dyrcona joined #evergreen
10:40 csharp Bmagic: were you able to resolve your issue?
10:40 Bmagic my issue was resolved by uncommenting the remote IP business in eg_vhost.conf
10:40 csharp (yes, I do have a couple of production-ish test clusters)
10:40 csharp ok cool
10:41 Bmagic Not the same as your issue though
10:41 Bmagic (We've not tried the org unit editor on our new production environment though, we may have the same issue)
10:42 Bmagic berick++ # remote IP
12:58 sandbergja RMiller: no problem!  FWIW, this can be super helpful for questions like that: http://docs.evergreen-ils.org/3.2_schema/
13:00 Dyrcona I'd do something more complicated for the org_units.
13:02 RMiller My org units are really really simple at the moment, so I think this does the trick for now, unless there's something else I should know?
13:05 Dyrcona Yeah, I was just testing the SQL before sharing it. The work firewall doesn't always play nice.
13:05 pastebot "Dyrcona" at 64.57.241.14 pasted "Rmiller: Getting org_units that can have users" (5 lines) at http://paste.evergreen-ils.org/10236
13:06 RMiller Oh, gotcha. I can see how that would be handy.
13:10 sandbergja Dyrcona++
16:53 gsams Bmagic: I'd be all for that.
16:54 Bmagic seems like a simple solution
16:54 Bmagic replacing \n with <br />
17:01 pinesol News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~li​ve/test.42.html#2019-03-14T17:00:39,182624603-0400 -0>
17:08 bdljohn left #evergreen
17:10 Dyrcona For every problem, there is a solution that is simple, obvious and wrong. :)
17:17 AMM_ joined #evergreen

Results for 2019-03-13

03:21 jamesrf joined #evergreen
05:00 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
07:02 agoben joined #evergreen
07:17 rjackson_isl joined #evergreen
07:36 bdljohn joined #evergreen
13:47 JBoyer it is
13:49 csharp JBoyer++ # thanks!
14:02 yboston joined #evergreen
14:21 pinesol [evergreen|Jason Stephenson] LP 1819796: Fix method call on undefined value in generate_fines - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=090f864>
14:28 littlet_ joined #evergreen
14:32 littlet_ left #evergreen
15:09 yboston joined #evergreen
16:03 bdljohn1 joined #evergreen
16:03 sandbergja joined #evergreen
16:39 bdljohn joined #evergreen
17:00 pinesol News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~li​ve/test.42.html#2019-03-13T16:59:08,748157845-0400 -0>
17:08 mmorgan left #evergreen
20:29 sandbergja joined #evergreen

Results for 2019-03-12

02:05 yar_ joined #evergreen
03:57 beanjammin joined #evergreen
05:00 pinesol News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~li​ve/test.42.html#2019-03-12T04:58:59,712036408-0400 -0>
05:07 jamesrf joined #evergreen
05:13 yar joined #evergreen
07:00 agoben joined #evergreen
15:46 sandbergja jeff: I sure will!
15:46 sandbergja :-)
16:07 mmorgan left #evergreen
16:18 Stompro I was just testing out an add on to item status that would allow pasting in a string of barcodes in CSV format... and I accidentally tried pasting in a string with 400K barcodes in CSV format.  "This seems to be taking a while. hmm".
16:20 Stompro Trying it out with 200 barcodes worked much better.
16:38 beanjammin joined #evergreen
17:00 sandbergja joined #evergreen
17:00 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
18:12 sandbergja joined #evergreen
18:22 Dyrcona So, I'm pretty sure that no one is around, but I just had an issue with the fine generator again, this time on a new VM setup just to run it and some other jobs that use storage.
18:23 Dyrcona It is scheduled to run every hour on the hour.

Results for 2019-03-11

01:47 beanjammin joined #evergreen
02:44 beanjammin joined #evergreen
03:06 jamesrf joined #evergreen
05:30 pinesol News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~li​ve/test.42.html#2019-03-11T05:00:57,112741866-0400 -0>
06:49 JBoyer joined #evergreen
07:00 agoben joined #evergreen
07:15 rjackson_isl joined #evergreen
15:46 jamesrf joined #evergreen
16:52 Christineb joined #evergreen
17:10 mmorgan left #evergreen
17:30 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
21:37 sandbergja joined #evergreen
21:58 sandbergja joined #evergreen
22:29 beanjammin joined #evergreen

Results for 2019-03-10

05:01 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
07:32 troy__ joined #evergreen
10:58 darkdrgn2k3 are there any server specs for running evergreen.
10:58 darkdrgn2k3 looking to deploy at a small library only about 8,000 books
13:39 darkdrgn2k3 joined #evergreen
13:56 beanjammin joined #evergreen
16:43 rhamby darkdrgn2k3: Evergreen works well for large and small libraries, I don't think it would be overkill but it's also not the only option.  If you want to look at mutiple good ILS options Koha is a good open source one as well.
17:00 pinesol News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~li​ve/test.42.html#2019-03-10T16:59:34,207685443-0400 -0>
19:37 jamesrf joined #evergreen
20:43 Christineb joined #evergreen
20:46 beanjammin joined #evergreen

Results for 2019-03-09

05:01 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
08:15 jamesrf joined #evergreen
11:00 gsams_ joined #evergreen
11:21 darkybinlio joined #evergreen
11:21 darkybinlio hi the install intrusions seem to be 404?
11:40 jeff usually there are install instructions in the tar archive once you extract it.
11:40 jeff that daid, what link is 404 and what document linked to that url?
12:25 bshum Uh
12:26 bshum downloads is gone, so is docs, etc.
12:28 bshum Basically all links are pointing to nonexistent directories
12:38 * bshum typed up an email for the team
12:38 bshum Time to test if we have backups...
13:23 darkdrgn2k joined #evergreen
13:23 darkdrgn2k joined #evergreen
13:23 darkdrgn2k joined #evergreen
16:48 csharp thankfully we have a good backup strategy and restoring was possible/easyu
16:48 csharp easy
16:48 rhamby eh, it happens, thanks for the restore
17:01 pinesol News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~li​ve/test.42.html#2019-03-09T16:58:50,722593620-0500 -0>
18:05 beanjammin joined #evergreen
18:36 jeff csharp++
23:19 darkdrgn2k3 joined #evergreen

Results for 2019-03-08

00:39 sandbergja joined #evergreen
02:09 yar joined #evergreen
05:00 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
06:55 Dyrcona joined #evergreen
06:59 agoben joined #evergreen
07:05 jamesrf joined #evergreen
11:53 berick miker: I feel like a dummy.  Anyway, I like how your branch adds smarts to FormatService (plus grid additions), so it can be used in grid and non-grid contexts and I like how mine adds the logic to pcrud so it's not limited to admin pages.  I'd like to merge the two if that works for you.
11:53 berick s/the logic/the link-fleshing logic/
11:54 terran berick++ for commits!
11:55 miker berick: +1. one thought, instead of using virtual=true, should we use reltype={has_a|might_have} instead? (though we may have to be careful of map=$something)
11:56 miker so that we can do might_have, that is
11:56 miker or... are those not virtual... gah, going to go confirm
11:57 miker might_have is virtual, so we'd need to test reltype for that
11:58 miker (we could make map=$something cases work, of course, by jumping through the remote link)
12:00 miker FTR, there are only 2 instances of might_have with a map
12:00 miker they're on bre: metarecord and language
12:00 berick miker: so instead of this:  filter(f => f.datatype === 'link' && !f.virtual)
12:00 berick something like:   filter(f => f.datatype === 'link' && (f.rel_type === 'has_a' || f.rel_type === 'might_have'))
12:01 miker right, that's my thought. though I'm not sure if we surface the map attr in idl2JS
12:03 miker we ... don't seem to: {name:"metarecord",label:"Metarecord",virtu​al:true,type:"link",key:"source","class":"m​mrsm",reltype:"might_have",datatype:"link"}
12:04 miker berick: but ... we don't show non-virt fields in grids via * in any case, do we?
12:04 berick miker: that's true, it filters those out when auto-generating fields
12:05 miker however, I'd still advocate for testing reltype='has_a' rather than virtual='false'
12:06 miker because if we do expand to showing might-have's (or even doing something smarter with has_many's, like counts or something) then it's more obvious.
12:06 miker IOW
12:07 miker filter up front via virtual now, and work on the result based on the more direct description (reltype). that feels like a better separation of concerns to me
12:07 berick +1
12:08 miker awesome, thanks berick!
12:08 miker berick++
13:39 pinesol [evergreen|Chris Sharp] LP#1709698 - stamping upgrade script - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=c20bfea>
13:48 Dyrcona Calling 1157
14:02 terran joined #evergreen
14:03 pinesol [evergreen|Bill Erickson] LP#712490 Vandelay merge-based field replacement - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=23293c7>
14:03 pinesol [evergreen|Bill Erickson] LP#712490 Vandelay replace/merge PGTAP tests - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=99b75e0>
14:03 pinesol [evergreen|Jason Stephenson] Lp 712490: Stamping UPgrade Script - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=f098f38>
14:16 terran abneiman++ for hitting 100 tag/bug updates!
14:17 csharp calling 1158
14:17 abneiman :-D I knew I was close but thanks for the shoutout!
16:37 abneiman yeah, I'm looking at the oldest ones still marked "new"
16:44 jamesrf joined #evergreen
17:01 jvwoolf1 left #evergreen
17:01 pinesol News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~li​ve/test.42.html#2019-03-08T16:58:14,635466859-0500 -0>
17:06 mmorgan left #evergreen
17:12 terran Wrapping up my day, but on Monday I will update the  Bug Squashing Week chart with everything that comes in through midnight :D   (Like, you'll all be working on this on a Friday night)
17:50 yboston joined #evergreen

Results for 2019-03-07

02:33 beanjammin joined #evergreen
05:00 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
07:06 agoben joined #evergreen
07:07 rjackson_isl joined #evergreen
07:35 bos20k joined #evergreen
09:35 sandbergja joined #evergreen
09:46 yboston joined #evergreen
10:13 Christineb joined #evergreen
10:19 pinesol [evergreen|Jane Sandberg] Docs: Fixing broken link - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=7f7919e>
10:20 beanjammin joined #evergreen
10:42 jvwoolf joined #evergreen
10:43 terran mmorgan++ for finding the link to my patch when I forgot to include it :D
11:48 Bmagic vs
11:48 Bmagic https://missourievergreen.org/eg/opac/results?qu​ery=dog&amp;qtype=keyword&amp;fi%3Asearch_format​=&amp;locg=1&amp;detail_record_view=1&amp;sort=
11:49 Bmagic 26 seconds for gapines, 14 seconds on missourievergreen
11:51 Bmagic It's not quite apples to apples of course, due to the db's not having the exact same data. The test machine with the exact same data is here http://104.155.152.239/eg/opac/home
11:53 csharp Bmagic: maybe a comparison of queries and explain data would help?
11:53 Bmagic yeah, good point
11:54 Bmagic I've been here before, and the two versions of evergreen are fundamentally different in the search strategy. No conclusion
12:48 Bmagic ty
12:48 csharp if it weren't for the move from QTS -> ITS, we would have already moved to Ubuntu 18.04/PG 10
12:49 csharp probably do that over Labor Day
12:50 Dyrcona Someone (me?) should start testing with Pg 11. We only started looking at Pg 10 when 11 was released. :)
12:55 jvwoolf joined #evergreen
13:06 Bmagic fresh reboot, same cats query 190 seconds!
13:06 Bmagic collapsable join was at 10
13:18 Bmagic yeah, but that was the point of rebooting
13:18 Bmagic restarting postgres wasn't enough
13:18 Bmagic what's the command to warm up the cache after reboot?
13:19 jeffdavis You don't want your test query in cache, but you want indexes etc to be cached so that performance is normal (or else test on two different cold-cache servers I guess)
13:21 jeffdavis doing some other searches or typical queries and/or vacuuming metabib index tables might help, I'm not actually sure what's best beyond letting the server get used a bit
13:23 jeffdavis you could ask in #postgres for advice on benchmarking and cache issues
13:25 Bmagic yeah, it's hard to get a good test after changing those config points
13:25 Bmagic to know whether or not the change made a difference
13:26 sandbergja_ joined #evergreen
13:35 Dyrcona Bmagic: Find your database's oid: select oid from pg_database where datname = 'evergreen'; -- Assuming your database is named evergreen and you run that query in the postgres database.
14:30 littlet_ joined #evergreen
14:31 terran Okay, thanks
14:32 terran I've been removing some of the unofficial tags if there is a better existing term already in place
14:32 abneiman another one I've been wondering about but haven't looked into -- test-writing-day-1
14:32 abneiman https://bugs.launchpad.net/evergreen​/+bugs?field.tag=test-writing-day-1
14:34 abneiman All file by Liam Whalen, 3 years ago, seemingly about things that need tests written.  We typically use needstest to flag new code that needs a unit/pgtap tests, so I'm not sure that applies here, but it seems like a bit of a one-off
14:35 abneiman oh, mmorgan does have one with that tag too, my mistake.  mmorgan please chime in if you have thoughts on this.
14:38 terran I'm unsure about that one as well
14:39 mmorgan abneiman: Looks like Liam added the tag to bug 1331174, I have no strong feelings about that tag.
14:39 terran Was it flagging things that needed end user test instructions added?
14:39 pinesol Launchpad bug 1331174 in Evergreen "Long Overdue processing needs org unit settings separate from Lost Processing" [Wishlist,Confirmed] https://launchpad.net/bugs/1331174
14:39 abneiman http://libmail.georgialibraries.org/piperm​ail/open-ils-dev/2015-November/009998.html
14:41 abneiman and here https://wiki.evergreen-ils.org/d​oku.php?id=dev:test_writing_day
16:22 yboston joined #evergreen
16:32 * csharp plans to work on committing more tomorrow too
16:56 afterl left #evergreen
17:01 pinesol News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~li​ve/test.42.html#2019-03-07T16:59:16,091764708-0500 -0>
17:07 mmorgan left #evergreen
17:13 jamesrf joined #evergreen
17:14 jvwoolf left #evergreen

Results for 2019-03-06

00:17 bshum joined #evergreen
00:51 abowling left #evergreen
01:10 abowling joined #evergreen
05:00 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
05:41 jamesrf joined #evergreen
06:40 stephengwills joined #evergreen
07:30 bdljohn joined #evergreen
09:19 aabbee joined #evergreen
09:44 jvwoolf joined #evergreen
09:45 yboston joined #evergreen
09:57 Bmagic I'm having trouble building 3.1.9 at the npm run test step. Getting phantomJS errors about IDL2js.js not found. node version 4.2.6~dfsg-1ubuntu4.1 and npm versoin 3.5.2-0ubuntu4
10:00 sandbergja joined #evergreen
10:02 Bmagic whoops, might be permissions issue
10:09 Dyrcona Bmagic: You might also want to use a more recent version of Node.js.
16:47 berick miker: yeah, you'd think.  took a sec to figure out why it wasn't seeing the class
17:05 jvwoolf left #evergreen
17:11 mmorgan left #evergreen
17:31 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
17:43 berick miker: yay it's working https://git.evergreen-ils.org/?p=work​ing/Evergreen.git;a=shortlog;h=refs/h​eads/user/berick/admin-grid-fm-flesh
17:44 berick autmented the grid, added some warnings/checks for faulty data, minor thinko/lint repairs
17:44 berick *augmented
17:44 berick easy test case are ACQ exchange rates
17:51 sandbergja_ joined #evergreen
18:32 makohund joined #evergreen
18:55 makohund My bizarre Vandelay problem that I've been yammering about for a few days... I finally figured it out.

Results for 2019-03-05

00:12 sandbergja joined #evergreen
04:13 beanjammin joined #evergreen
05:00 pinesol News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~li​ve/test.42.html#2019-03-05T04:58:06,059464870-0500 -0>
07:03 agoben joined #evergreen
07:12 rjackson_isl joined #evergreen
07:29 book` joined #evergreen
10:12 terran littlet++ for getting over 100 Bug Squashing Week updates on the chart already!
10:17 mmorgan littlet++
10:31 tlittle :)
10:44 terran There are 7 new patches ready for testing if anyone wants to take a stab at them: https://docs.google.com/spreadsheets/d/1x_sZcEaP62​J42KcB03AUn1I1MSZQpPI5mF9r0Zrmhgo/edit?usp=sharing
11:19 csharp where does the new ng stuff get installed?
11:20 csharp if I want to rebuild on a live server, where do I do that?
11:20 khuckins joined #evergreen
14:14 sandbergja for an added dash of mystery
14:15 csharp argh - still seeing it
14:15 csharp yeah, I'm in FF
14:15 dbwells csharp: yes, I only tested in Chrome, and it also worked for me there.
14:16 csharp same behavior in Chrome for me
14:16 berick and I'm not seeing it in FF
14:16 berick csharp: just to confirm, the page doesn't render or it's an error in the console?
16:48 terran berick: thanks, I'll open a bug report
16:58 terran berick: never mind, there's already a bug report and gmcharlt already has a fix and rhamby has already signed off :)  gmcharlt++ rhamby++
16:58 terran https://bugs.launchpad.net/evergreen/+bug/1812389
16:58 pinesol Launchpad bug 1812389 in Evergreen "Group Penalty Threshold link does not work" [Medium,Confirmed]
17:00 pinesol News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~li​ve/test.42.html#2019-03-05T16:58:45,793808627-0500 -0>
17:05 berick terran: clearly you have magical powers
17:05 terran I can control space and time. Everybody knows that.
17:09 mmorgan left #evergreen
17:38 rhamby abneiman++ for getting rid of cruft, the more invalid/won'tfix bug we mark out the better we can identify ones we actually need to work on
17:41 littlet abneiman++ for tag updating and updating the official tag list! I also love the controlled vocab :D
17:48 gsams Bmagic: We are running 3.1 in production.
17:50 makohund I've gone through every single line in osrfsys.log for my last test import (roughly 1000 lines), and haven't found anything wrong there. Yet.
17:52 gsams abneiman++ #Didn't even know I was still on a list for notification on some of these!
17:56 Bmagic gasms++
17:56 Bmagic gsams++ #even
18:04 Bmagic that's very very close now
18:05 Bmagic my patch works but the real answer is upgrading to the absolute latest version of java fx
18:07 Bmagic berick figured that out berick++
18:07 gsams berick++
18:08 gsams Well, if you need someone to test/signoff I will happily jump at it, it'd resolve the biggest issue we currently have.
18:08 berick need to get a little more broad resposne to my proposal of packaing jre in the installer
18:08 berick once we're thumbs-up there, we can update the Hatch installer
18:08 gsams Awesome

Results for 2019-03-04

03:10 beanjammin joined #evergreen
03:42 jamesrf joined #evergreen
05:00 pinesol News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~li​ve/test.42.html#2019-03-04T04:57:50,470383187-0500 -0>
07:05 JBoyer joined #evergreen
07:13 agoben joined #evergreen
07:14 rjackson_isl joined #evergreen
10:36 terran StomproJosh++ extra karma anyhoo
10:38 jeff launchpad--
10:39 jeff terran: are you working on bug 1777677? you're currently assigned.
10:39 pinesol Launchpad bug 1777677 in Evergreen "Test notification method" [Wishlist,New] https://launchpad.net/bugs/1777677 - Assigned to Terran McCanna (tmccanna)
10:39 Dyrcona StomproJosh++
10:41 terran_ joined #evergreen
10:41 terran_ @jeff - nope, sorry, forgot to take my name off
12:02 Dyrcona littlet: Just ask and if anyone can answer, they will.
12:03 * Dyrcona uses iptable to combat "Bobby Tables." :)
12:03 * Dyrcona can't type. :(
12:04 littlet Thanks :)  So, I'm trying to play around with the new Angular stuff, and just to change something simple, like a label or something to see the change show on my test server. But nothing I do changes anything--even if I change a label to say 'Cancel Reasons TESTING', it doesn't change.
12:04 littlet I've cleared cache and cookies, and Googled, and I don't know if I'm just not Googling well...
12:05 Dyrcona littlet: Did you just copy the file into place or edit in place, or did you the ng build --prod step, and then do make install?
12:06 littlet I just edited in place
12:09 Dyrcona I think you should edit it in the source code, then do the ng build --prod and make install steps.
13:27 mmorgan One less bug needing squashing!
13:27 Bmagic Now that I'm on a roll: Record bucket searching by ISBN doesn't seem to use the same methods as an OPAC search. Specifically the 10/13 normalizer is not taken into account. Is that a bug?
13:34 jihpringle Bmagic: my vote would be searching for the ISBN should work the same throughout the OPAC/staff client
13:35 Bmagic yeah, agreed. Not sure what the underlying record bucket search uses, but based upon some test examples, it's not using the same methods as OPAC search
13:36 * mmorgan would agree also, but wonders how it worked in the xul client
13:40 mmorgan Bmagic: xul client record bucket search on isbn also does not employ the isbn 10/13 normalizer. So it was always broken :-(
13:40 jihpringle I suspect buckets weren't the same as the OPAC in the xul client which might make this more of a new feature (change of existing behaviour) than a bug
14:25 Dyrcona jeff: Are you working on bug 1519879?
14:25 pinesol Launchpad bug 1519879 in Evergreen "SIP Precedence Warning, possible logic issue" [Undecided,Confirmed] https://launchpad.net/bugs/1519879 - Assigned to Jeff Godin (jgodin)
14:26 jeff I wasn't, but I can be. Dusting off memories...
14:27 Dyrcona The fix is exactly as mentioned in the description, use && instead of and. I've verified it with a test script.
14:28 Dyrcona As long as circ is not blocked, it always returns true the was it is written.
14:28 Dyrcona So, I can post a branch if you don't have the time.
14:29 jeff go ahead, if you beat me to the branch i can signoff/merge. i think there was something more subtle (and the reason i grabbed and was going to comment on it), but as you can see, there's no comment.
16:45 makohund though I'm not sure I ever tried it back on jessie on this machine either, so it may have been broken all along
16:53 Bmagic joined #evergreen
16:56 mnsri_away joined #evergreen
17:00 pinesol News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~li​ve/test.42.html#2019-03-04T16:58:41,171347372-0500 -0>
17:03 mmorgan left #evergreen
17:39 makohund I'm not outta the woods yet... inspecting my import queue, none of the descriptive fields show anything at all (Title, Author, ISBN, etc).  Even though the fields are there if I view MARC.  (Or look at it in vandelay.queued_record, or vandelay.queued_bib_record.)  And if I import the same file again, expecting matches to be found... nope.
17:40 makohund I import the same test file on our production system... no such problems.  Fields are fleshed out, second import matches on all records, etc.
19:12 dickreckard joined #evergreen
19:30 beanjammin joined #evergreen
19:34 jvwoolf joined #evergreen
19:39 jvwoolf left #evergreen
19:53 makohund I've just confirmed that my import problem predates my buster upgrade test... I jumped back to a vm snapshot on old evergreen version on jessie... importing was fine.  Jumped forward to stretch, and no import, until changing it from /tmp to somewhere else.  Now records import, but no matching and no data in the fields on the inspect queue screen.  Hmm.
20:33 beanjammin joined #evergreen
21:28 sandbergja joined #evergreen
22:07 sandbergja joined #evergreen

Results for 2019-03-03

05:01 pinesol News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~li​ve/test.42.html#2019-03-03T04:58:12,106550747-0500 -0>
10:36 sandbergja joined #evergreen
11:52 berick joined #evergreen
13:37 jamesrf joined #evergreen
16:55 beanjammin joined #evergreen
17:01 pinesol News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~li​ve/test.42.html#2019-03-03T16:58:02,908818147-0500 -0>
20:10 beanjammin joined #evergreen
21:46 beanjammin joined #evergreen
23:22 beanjammin joined #evergreen

Results for 2019-03-02

04:01 jamesrf joined #evergreen
04:47 jamesrf joined #evergreen
05:01 pinesol News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~li​ve/test.42.html#2019-03-02T04:58:10,193035437-0500 -0>
10:22 sandbergja joined #evergreen
17:01 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
19:59 beanjammin joined #evergreen
22:43 jamesrf joined #evergreen

Results for 2019-03-01

01:11 sandbergja joined #evergreen
02:39 beanjammin joined #evergreen
05:01 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
06:29 Dyrcona joined #evergreen
07:13 rjackson_isl joined #evergreen
07:16 JBoyer dbwells++
16:18 Dyrcona Yeah, not sure if that works, but I think it does.
16:41 jvwoolf left #evergreen
16:47 yboston joined #evergreen
17:00 pinesol [evergreen|Bill Erickson] LP1806087 Ang catalog pending tabs offer manual redirect - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=c2c4916>
17:00 pinesol [evergreen|Bill Erickson] LP1806087 Synchronize browse code for staff cat / tpac - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=d1e58bb>
17:01 pinesol News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~li​ve/test.42.html#2019-03-01T16:59:25,736751945-0500 -0>
17:02 mmorgan left #evergreen
17:06 sandbergja_ joined #evergreen
17:15 sandbergja For anybody who wants to shake up their bug squashing week, here's a simple python script that will give you a link to a random Evergreen bug every time you run it: https://github.com/sandbergja/random_evergreen_bug

Results for 2019-02-28

00:10 jamesrf joined #evergreen
01:10 StomproJ joined #evergreen
05:01 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
06:55 StomproJosh joined #evergreen
07:04 agoben joined #evergreen
07:11 rjackson_isl joined #evergreen
17:00 berick mmorgan: I'll open a bug
17:00 mmorgan berick++
17:00 jeff mmorgan++ berick++
17:01 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
17:02 yboston joined #evergreen
17:04 mmorgan left #evergreen
17:21 khuckins joined #evergreen
17:58 pinesol [evergreen|Dan Wells] Stop asciidoc from squawking about missing list number - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=81d5551>
18:05 dbwells For any eager to help, the first beta of 3.3 is available in the "previews" area of the site (not the normal downloads area yet): https://evergreen-ils.org/downloads/pr​eviews/Evergreen-ILS-3.3-beta1.tar.gz
18:06 dbwells We'll do a test install locally tomorrow, but it would be nice if someone else could do the same, and even better, run the upgrade script on a real 3.2.4 DB.
18:07 dbwells The upgrade script is actually rather short this release, which overall is a good thing.
18:18 berick dbwells++
18:27 sandbergja_ joined #evergreen
18:40 sandbergja_ joined #evergreen

Results for 2019-02-27

01:09 jamesrf joined #evergreen
05:02 pinesol News from qatests: Failed Installing some build essentials <http://testing.evergreen-ils.org/~l​ive/test.4.html#2019-02-27T04:55:21,162334599-0500 -0>
05:02 pinesol News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~li​ve/test.42.html#2019-02-27T04:55:21,191140280-0500 -2>
05:02 pinesol News from qatests: Failed Running pgTAP live tests <http://testing.evergreen-ils.org/~li​ve/test.47.html#2019-02-27T04:55:21,220190182-0500 -4>
06:39 stephengwills joined #evergreen
07:09 agoben joined #evergreen
07:13 rjackson_isl joined #evergreen
15:44 Dyrcona If it doesn't do this already, it should detect the language of the browser and switch automatically.
15:46 Bmagic "That's like, your opinion man"  -The Dude
15:47 Dyrcona It's an informed opinion.
15:48 jihpringle Bmagic: I've seen the same thing on the 3.2 server we set up to test French on, it doesn't like to switch back to English
15:50 Bmagic oh good, glad it's not just me
15:51 jihpringle it's on my list to test further and report to launchpad
15:59 bshum jihpringle: Bmagic: Yeah the switcher is touchy for sure.  I've found it's easier to use TPAC to change my language cookie setting, and then use that with my staff client
16:00 bshum And also, because of how the i18n PO files are broken up, sometimes you get colliding values where the TPAC translated string doesn't match the staff client version of something
16:00 bshum "name" is a bad example"
16:39 JTaylor_ or if, that is.
16:59 JTaylor_ Guess not :-)    Will try again sometime.
16:59 JTaylor_ left #evergreen
17:02 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
21:43 sandbergja joined #evergreen

Results for 2019-02-26

04:30 phasefx joined #evergreen
04:30 maryj joined #evergreen
04:35 dbs_ joined #evergreen
05:01 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
06:14 Dyrcona joined #evergreen
06:15 Dyrcona So, our fine generator got stuck twice last night. Nothing in the logs, literally, after 9 seconds from its start time.
06:16 Dyrcona Well, nothing from the fine generator or the storage service.
15:28 jeff Ah. *nod*
15:28 jeff Less flat.
15:28 csharp we've chased our tail more than once trying to add carriers for some of these off-brand cellular companies (and some more well-known ones)
15:29 jeff More "not without official documentation from the carrier in question" and perhaps even "a patron willin to test" :-)
15:29 jeff Which in some cases reduces/simplifies to "No."
15:30 csharp I guess that's the other nuance that de-flattens my "no" - the patron is welcome to request that information of the carrier :-)
15:31 jeff I'm pretty sure I've made my strong feelings about this known, but in case anyone's interested in trying the "eliminate the email to text gateways" approach, I'd be interested in helping / collaborating. :-)
15:31 jeff I think that Stompro is on that short list.
16:25 csharp jeff: I don't remember right this moment, but I'm pretty sure we group them so it's not an insane number of texts per patron
16:31 yboston joined #evergreen
16:40 makohund joined #evergreen
16:47 makohund A while back I mentioned wanting to try out evergreen on debian buster.  (Was upgrading our test server from jessie to stretch, and kept going.)  And I'm happy to report that it is done, and working just fine. :)
16:48 bshum Buster?  Lol, awesome
16:48 Dyrcona makohund: Do you have a git branch to update the prerequisite installers?
16:49 Bmagic makohund++
16:52 makohund Biggest prob was ejabberd... change to default internal hostname.  Eventually just reinstalled & configured it from scratch.
16:53 khuckins joined #evergreen
16:59 makohund Found the message about it... the release note for 17.08-1... https://github.com/jabber-at/ej​abberd/blob/master/debian/NEWS
17:02 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
17:05 sandbergja_ joined #evergreen
17:05 makohund Instead of the ejabberd config notes for stretch, follow the ones for ubuntu bionic.  Except can't just uncomment mod_legacy_auth, have to add it.
17:08 mmorgan left #evergreen
17:26 Bmagic oh!
17:26 Bmagic the "default" printer bug?
17:26 berick Bmagic: i wanted to see if we could avoid the big fork in the code
17:27 makohund sandbergja_: I'm finally done monkeying around with the test server
17:27 berick Bmagic: https://bugs.openjdk.java.net/browse/JDK-8088918
17:27 Bmagic berick: so the work around using JEditorPane isn't needed?
17:28 berick the fix was a side effect of this bug, a toss-away comment basically that got some love
17:30 berick Bmagic: that was part of my concern, thinking it might be brittle over time
17:30 * berick will document findings
17:30 Bmagic berick++
17:31 berick I have a tine return address label here now that just says "test"
17:31 berick s/tine/tiny/
17:31 Bmagic oh man! The feeling of seeing that printer spit anything out for the first time is euphoric
17:32 Bmagic RE: brittle over time - I did write in my comments "well, crap"
17:32 Bmagic :)

Results for 2019-02-25

16:04 pinesol Dyrcona: The stars typed Google into Google; broke the Internet.
16:08 bdljohn1 left #evergreen
16:10 Gandalfo joined #evergreen
16:56 berick in case anyone else is seeing oddness, I think the latest version of chrome refuses to load sharedworkers via https if it doesn't like the certificate (self-signed certs)
16:57 berick so, test VM's and such w/o a valid cert
16:59 berick end result is browser client pages intermittently fail to fully render
17:00 * berick configures chrome to trust the cert as a test
17:02 pinesol News from qatests: Failed Installing some build essentials <http://testing.evergreen-ils.org/~l​ive/test.4.html#2019-02-25T16:58:32,440142273-0500 -0>
17:02 pinesol News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~li​ve/test.42.html#2019-02-25T16:58:32,469827548-0500 -2>
17:02 pinesol News from qatests: Failed Running pgTAP live tests <http://testing.evergreen-ils.org/~li​ve/test.47.html#2019-02-25T16:58:32,499617430-0500 -4>

Result pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143