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

Results for 2017-02-10

05:01 pinesol_green News from qatests: Test Failure <http://testing.evergreen-ils.org/~live>
05:50 bshum joined #evergreen
07:08 pinesol_green [evergreen|Kathy Lussier] LP#1654534: Prevent loop that occurs when staff us 'place another hold' link - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=cc481b0>
07:11 rjackson_isl joined #evergreen
07:16 agoben joined #evergreen
07:27 kmlussier joined #evergreen
07:40 Callender joined #evergreen
07:42 bshum @later tell gmcharlt Was talking to kmlussier and wanted to inquire about doing a POT sync and PO sync for master to get new strings into play and also updated files for Arabic for testing. As buildmaster 2.12, checking with you as well, but I don't see any harm in doing more i18n sync-ups. Opinion?
07:42 pinesol_green bshum: The operation succeeded.
07:47 bshum That may or may not affect any decision or changes necessary for 2.11 support for Spanish actually.  Before the next POT, if we do any PO sync we can probably still safely backport them before any string updates in templates for master take effect.
07:47 bshum If we want to, it's our last chance to do any PO sync from LP translations before we do a POT sync for new template strings drift.
09:58 berick csharp: what are you trying to do?
09:59 Dyrcona berick: He's trying to build hatch.
10:00 mmorgan1 joined #evergreen
10:00 berick well, more to point, csharp if you're just testing Windows for now, you don't have to compile.  the libs are included in the insatller I posted on the ticket.  if you want to build and/or run on linux, then carry on :)
10:01 berick also the -Xdiags:verbose can be removed if it's causing problems.  it's just for debugging.  it's never cause probs for me, though, in either flavor of jdk
10:02 Dyrcona berick: Am I right that hatch requires JavaFX for printing?
10:02 berick csharp: oh, and you should be able to compile without X, but not run it
10:02 berick Dyrcona: yes, openjfx is required on linux
10:19 JBoyer Yeah.
10:19 kmlussier copy_counts.tt2 shows up in the record detail page, right?
10:20 kmlussier No, you said search results. Let me check there.
10:20 csharp we usually keep our test server at the previous version for a few weeks post upgrade exactly for "it did X before the upgrade" issues
10:22 kmlussier On 2.10, it is included Lost (and I assume missing) in the Y of x of Y accounts when logged into the staff client.
10:22 JBoyer csharp, that's not a bad idea (provided thing are caught in time... we're a a month and a half out now.)
10:22 JBoyer Ah.
12:23 kmlussier If you hadn't found those already.
12:24 mmorgan kmlussier is reading my mind :)
12:24 mmorgan kmlussier++
12:24 * kmlussier runs out to buy lunch for the three family members who spent the morning shoveling snow while I tested code inside a warm house.
12:25 sandbergja Hey everyone!  I have a student here who will be helping out with the DIG hackaway next week.  Who's the best person to get her an account on the wiki?
12:26 jihpringle joined #evergreen
12:29 sandbergja Is anybody still checking the docs@evergreen-ils.org email account?

Results for 2017-02-09

01:54 Callender_ joined #evergreen
05:01 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
06:06 genpaku joined #evergreen
07:11 rjackson_isl joined #evergreen
07:30 agoben joined #evergreen
09:07 rhamby @weather 30046
09:07 pinesol_green rhamby: Lawrenceville, GA :: Partly Cloudy :: 43F/6C | Wind Chill: 34F/1C | Thursday: Mostly sunny and windy. High 49F. Winds NW at 20 to 30 mph. Thursday Night: Clear skies. Low 28F. Winds NW at 10 to 15 mph. | Updated: 12m ago
09:08 rhamby kmlussier: not today and probably not tomorrow but next week I'm going to force myself to deal with some outreach stuff.  how is next week looking for me bothering you?
09:17 kmlussier rhamby: Well, it is feature freeze at the end of next week, so I'll be doing a lot of testing. But I should be around.
09:18 rhamby kmlussier: I don't know how much I'll need to bug you but I'll probably at least want to bounce a few ideas off you
09:19 maryj joined #evergreen
09:21 kmlussier Dyrcona: So I should hold off on bug 1005040 until the issue you mentioned in comment 11 is addressed?
10:41 pinesol_green [opensrf|Galen Charlton] LP#1652122: fix infinite recursion in opensrf.system.method.all - <http://git.evergreen-ils.org/?p​=OpenSRF.git;a=commit;h=bd5fc63>
10:42 Dyrcona And, I'll pickup that one, too. :)
10:48 Dyrcona miker: Yep. Looks like that one fixes that.
10:48 miker cool, thanks for testing. have time to sign off, etc?
10:50 Dyrcona Yeah, I was just looking at the code before signing off. Should I just push it to master?
10:56 miker let me make sure of that...
10:57 miker yes, I think so for now
11:49 brahmina joined #evergreen
12:03 sandbergja joined #evergreen
12:06 bmills joined #evergreen
12:09 * csharp builds a Windows 10 workstation to start testing hatch
12:18 berick csharp++ # i'm around if hit any snags.  since so few have tread there, i'm guessing you will.
12:19 * berick is reminded of a docs change he meant to make after kmlussier's testing last week..
12:19 berick oh right the permission granting
12:22 * berick pushed the doc update
12:23 csharp berick: thanks
12:23 jihpringle joined #evergreen
12:29 kmlussier berick: I'll check that out as soon as I get back to testing hatch. Thanks!
12:30 berick kmlussier: cool, i believe your past that step, btw, so my doc change probably won't have any effect your testing.
12:30 berick unless you start over
12:30 kmlussier berick: I was thinking of starting over.
12:31 * berick nods
12:42 jihpringle joined #evergreen
15:56 berick Dyrcona: indeed, and the Actions drop-down above the grid
15:57 Dyrcona Oh. Missed the Actions drop down, 'cause I think it is all the way to the left in XUL, but I might be wrong.
16:02 Dyrcona So, I have half of a fix. More work required.
16:04 pinesol_green Showing latest 5 of 17 commits to Evergreen...
16:04 pinesol_green [evergreen|Mike Rylander] LP1281280: Allow test script to run without a full installation - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=9a03ed4>
16:04 pinesol_green [evergreen|Mike Rylander] LP#1005040: Styling cleanup for filter display - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=f12cc28>
16:04 pinesol_green [evergreen|Kathy Lussier] LP#1005040: Release notes entry for advanced search limiter improvements - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=32d9fd0>
16:04 pinesol_green [evergreen|Mike Rylander] Adjust comment about apostrophes in opensearch code.  This is a marker for future work. - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=38ca8cc>
16:04 pinesol_green [evergreen|Kathy Lussier] LP#1005040: Stamping upgrade script for realign search layers - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=c9afb45>
16:16 Dyrcona Right click is now acting weird on me. It's taking me to Item Status as if I'd left clicked.
16:16 Dyrcona The menu pops up and then I end up at Item Status.
16:17 * Dyrcona blames low RAM and/or Firefox.
16:56 bmills joined #evergreen
16:58 kmlussier Ok, so if I'm on the Harry Potter record, it will provide a link to any editions that match particular formats. When it lists the 'book' format, it's based on the icon_format definition.
16:59 kmlussier But when you click the link, it's limiting to search_format='book', which is defined entirely differently from the icon format, so you get a different number of results than you expected.
17:01 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
17:01 kmlussier We know both need to be based on the same record attribute so that the counts match up correctly, but we were just looking for direction on which one should be used.
17:02 kmlussier I think Bmagic saw a benefit to re-using the code that was being used for icon formats, but then that means we would be filtering by icon_format when clicking the link. This works, but some might find it strange to limit based on icon format.
17:04 Dyrcona icon_format makes sense because it often corresponds to what people think of as item types.
17:05 JBoyer I didn't think icon_format had Filter set to True, but it does so I suppose that should work out fine.
17:10 kmlussier Yes, I did some testing with icon_format and had no trouble filtering the results that way.
17:10 * miker reads up
17:12 mmorgan left #evergreen
17:15 miker is it too much to have a new YAOUS that defines how a site wants to divide up their MR types?

Results for 2017-02-08

04:40 ldw_ joined #evergreen
04:40 phasefx__ joined #evergreen
04:40 jeffdavi1 joined #evergreen
05:00 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
07:01 tspindler joined #evergreen
07:12 rjackson_isl joined #evergreen
07:16 kmlussier joined #evergreen
12:28 berick csharp: excellent
12:29 csharp berick++
12:29 csharp this was totally worth your time :-)
12:30 berick csharp++ # testing machine
12:30 csharp pines++ # the ultimate test case
12:30 berick seriously
12:30 berick the reference install of evergreen
12:39 Dyrcona csharp++ berick++
15:39 Dyrcona Well, last time I cleared cache it was on a drone server because it was acting "weird" compared to the others, so I thought I'd see what happened after I cleared it.
15:39 Dyrcona It went right on being weird.
15:45 Dyrcona Meh. I have like 3.7GB "available." The VM is configured for 4GB, but it really won't use more than 1-2GB once it is actually running.
16:10 Dyrcona Oh well. Doesn't look like I'll get to test that branch today.
16:16 brahmina joined #evergreen
17:00 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
17:04 mmorgan left #evergreen
17:10 Bmagic csharp: kmlussier: bug 1508208 is pretty much the same as 1416438 or at least (most likely) has the same root issue
17:10 pinesol_green Launchpad bug 1508208 in Evergreen "Checkin age based hold protected item may not fill fillable holds" [Undecided,New] https://launchpad.net/bugs/1508208
17:31 pinesol_green Launchpad bug 1416438 in Evergreen "slow hold placement on titles with many copies" [Undecided,Confirmed] https://launchpad.net/bugs/1416438
17:32 Bmagic sweet!
17:50 csharp well, I can definitely say that the example bib I cited in that ticket taking 15+ seconds took < 1 second with the new targeter + latest patches
17:51 berick and to be fair, that specific hold may not have taken 15 seconds with the current targeter.  so apples/oranges
17:51 berick unless csharp tested that too
17:55 * csharp didn't
17:56 csharp I can say though, that since day one on new hardware (faster processors) and the new hold targeter, we've gotten many positive comments from staff about improved hold placement speed in general
17:57 csharp I'll do some investigation of old vs. new (though "old" was on older slower HW)

Results for 2017-02-07

00:34 pinesol_green [evergreen|Kyle Huckins] LP#1534787 Patron Message Center port - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=a6f1a4f>
03:08 abowling joined #evergreen
05:02 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
07:03 bshum jetlag--
07:03 bshum breakfast++
07:17 rjackson_isl joined #evergreen
09:51 * pinesol_green brews and pours a cup of Ethiopia Yirgacheffe Koke, and sends it sliding down the bar to Bmagic
09:52 * Bmagic sits up at attention
09:52 Bmagic Ethiopia knows what they are doing
09:53 Dyrcona Hmm.. I just setup opensrf on a test VM. Services are up and running, but when I ran srfsh, I got this "Unable to bootstrap client for requests"
09:56 Dyrcona log says it can't authenticate with jabber...
09:57 * csharp suspects the ejabberd nightmare he experienced a couple of weeks ago
09:57 Dyrcona Nope. Simpler than that.
09:57 Dyrcona I was put the password in for the router user when I wanted the opensrf user's password, in .srfsh.xml.
09:57 csharp ah
09:58 Dyrcona And I got 4 for the opensrf.math test, so that works. :)
09:59 Dyrcona Next, I get to transpose our Apache 2.2 config to Apache 2.4.
10:02 * Dyrcona is preparing to upgrade to Debian 8.
10:02 berick csharp: thanks!  taking a look
10:49 dbs JBoyer++
10:49 Dyrcona dbs++
10:50 Dyrcona JBoyer++
10:50 Dyrcona I usually use localhost on my test VMs.
10:50 Dyrcona I used the FQDN of the local machine in production.
10:51 Dyrcona So, think I'll switch to localhost.
10:53 Dyrcona Fun thing: I have 3 config branches: 2.10, 2.11, and master, so that's a couple of git checkout; git cherry-pick to keep them all in sync.
13:22 Dyrcona And, a search worked. This is promising. :)
13:22 mllewellyn joined #evergreen
13:29 Dyrcona All right, I don't know why logger complained like that.
13:30 Dyrcona Maybe I need the full path? I'll try that after I test a z39.50 search.
13:34 pgardella joined #evergreen
13:35 Dyrcona Well, I guess the little machine is struggling. It timed out after 30 seconds.
13:39 Dyrcona This doesn't look right: "searches":{"author":{"term":"coe​lho"},"keyword":{"term":"eg."}}, Looks like part of the index name ends up as a search tem.
13:39 Dyrcona s/tem/term/
13:41 Dyrcona That comes from this Z search: find @attr 1=1003 coelho
13:41 pgardella Good afternoon, everyone! I'm trying to restore a backup of the evergreen database onto another server for testing, and have run into some errors I've not hit before. Namely, functions not existing:
13:41 pastebot "pgardella" at 64.57.241.14 pasted "missing functions" (8 lines) at http://paste.evergreen-ils.org/45
13:42 pgardella this was with a -Fc backup of our live DB
13:43 pgardella Anyone seen this before?
14:27 JBoyer I get the same message pgardella was talking about when it tries to restore the indexes. Since the func isn't found the indexes don't exist when the restore complets.
14:27 Dyrcona Is the unaccent extension in the db create script? I think so, but it might have been missed.
14:28 JBoyer I've been using a complete dump restore (with -C) for ages, that's breaking. The only time I've ever bothered with pre-creating the db is when I want to restore with a different name.
14:31 pgardella Latest tests done: With using the examples restores that dyrcona and charp gave me, I get the missing uaccent error and the missing functions. Using the pre-create the DB, I just get those missing functions.  (I'm on 2.10.5, by the way.)
14:31 Dyrcona What Pg version?
14:32 pgardella I'm going to 9.3 right now, from a 9.1 db
14:32 Dyrcona OK. My restores are going to 9.5 from 9.2.
15:43 Dyrcona And, it does appear to affect search results.
15:44 JBoyer If it didn't that'd practically be a yes to "Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?"
15:45 dbs Flash--
15:46 csharp dbs: srsly - apparently Google is kinda testing a flash-free version of play music, but it's not consistently/widely available
15:47 csharp https://bugzilla.redhat.co​m/show_bug.cgi?id=1405287 - and then I'll shut up :-)
15:47 dbs csharp: I think you have to go Chrome if you're doing anything with Flash these days (and yeah I hatesessss the long-standing Flash dependency Google Music has)
15:48 dbs At least Evergreen doesn't have a Flash dependency.
15:48 csharp the key word is "YET"
16:41 Dyrcona I love how some parts of the system are using localtime and others are using UTC.
16:41 Dyrcona I'm going to add some more info on a bug comment.
16:59 Dyrcona So, some more digging and it looks like specifying a version=1.2 to SRU is the real issue.
17:00 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
17:08 mmorgan1 left #evergreen
17:11 Dyrcona Well, that's it for today.
17:30 mllewellyn left #evergreen
17:34 jvwoolf left #evergreen
18:05 csharp berick: early testing of your last fixes shows this error: ERROR:  cannot pass more than 100 arguments to a function#
18:06 csharp I can get the full output to you shortly
18:11 csharp berick: http://pastebin.com/brVt8xrj
18:12 berick doh!
18:12 berick ok
18:12 berick i can fix that, just use an array.

Results for 2017-02-06

05:01 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
06:15 NawJo joined #evergreen
07:19 rjackson_isl joined #evergreen
07:23 book` joined #evergreen
07:35 bshum We'll be putting comments on there and adding links to stuff
07:35 NawJo Yes!
07:36 JBoyer joined #evergreen
07:39 bshum NawJo: Okay, emailed you a reply with some instructions about the DCO.
07:39 bshum I'll play with the git changes later today, but look forward to testing everything out
07:40 NawJo thank you a lot! I just received the mail :)
07:41 bshum NawJo++
08:29 NawJo @bshum I've just emailed git admins. requesting the permission to commit to the Evergreen repository :)
13:55 Dyrcona Rather, git rebase says no changes....
13:55 Dyrcona Anyway, git rebase --skip fixes it if you ever run into that.
14:15 jeffdavis bug 1662297
14:15 pinesol_green Launchpad bug 1662297 in Evergreen "Install directory hardcoded in web client build and tests" [Undecided,New] https://launchpad.net/bugs/1662297
14:17 jeffdavis ^ not sure how critical this is, but it looks like web client won't build out of the box unless you have installed in /openils ?
14:18 jeffdavis It built for me with "Done, without errors." at the end, but there were warnings related to the above issue and the web client doesn't actually work
14:23 gmcharlt kmlussier: because of the reingest, I'm not inclined to backport it
16:20 jvwoolf joined #evergreen
16:36 mmorgan joined #evergreen
16:44 rlefaive joined #evergreen
17:02 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
17:06 mmorgan left #evergreen
18:27 abneiman_ joined #evergreen
18:46 ejk joined #evergreen
19:08 ats-jc joined #evergreen
19:45 rlefaive joined #evergreen
20:52 jvwoolf joined #evergreen
22:45 pinesol_green [evergreen|Kyle Huckins] LP#1537217 Precat Checkout Circ Modifier - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=79fafc2>

Results for 2017-02-05

05:01 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
08:04 bshum joined #evergreen
11:47 pinesol_green [evergreen|Clare Sobotka] Docs: Updating to reflect Web staff client - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=dadadc1>
12:30 kenstir joined #evergreen
15:59 rlefaive joined #evergreen
17:01 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
18:07 jonadab joined #evergreen

Results for 2017-02-04

05:01 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
11:50 csharp @later tell berick there are several errors per hour like those in this full threadtrace: http://pastebin.com/CcaMp6tH caused by "too many copies per bib" (I think)
11:50 pinesol_green csharp: The operation succeeded.
11:51 csharp key lines:
13:29 bmills joined #evergreen
13:49 bmills joined #evergreen
13:50 kenstir joined #evergreen
17:01 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
17:51 jboyer joined #evergreen
18:24 genpaku joined #evergreen

Results for 2017-02-03

01:54 ATS-JC joined #evergreen
02:04 gsams_ joined #evergreen
04:09 abowling joined #evergreen
05:00 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
07:29 rjackson_isl joined #evergreen
07:33 agoben joined #evergreen
07:53 kmlussier joined #evergreen
09:46 csharp kmlussier: I just removed myself - thanks for the poke
09:47 kmlussier csharp: OK, I think I'm going to apply a 2.12 milestone to that one. See if we can get it in for the upcoming release.
09:47 * csharp would love to see that feature implemented (though Canceled Transit may remove the urgency for it)
09:49 * mmorgan would like to see that go in, too, and may try to carve out some time to test it.
09:53 csharp mmorgan: I intentionally separated out the "Abort -> Cancel" changes into the second commit so they can be tested separately (since they're really not the same issue), just adding context for testing (if you get around tuit)
09:55 dteston joined #evergreen
09:57 mmorgan csharp: Gotcha. We love the new status, but would also like to be able to identify the source and destination of the canceled transits when necessary.
10:09 * berick adds a note to 1347774
10:16 ATS-JC joined #evergreen
10:20 bshum As a general musing... if we were trying to take action on https://bugs.launchpad.net/evergreen/+bug/697926 to change the locale name for ar-AR to ar-JO....
10:20 pinesol_green Launchpad bug 697926 in Evergreen "change ar-AR to ar-JO for more accurate locale" [Low,Confirmed] - Assigned to Ben Shum (bshum)
10:20 bshum I was thinking that we should just be able to rename all the directory and files in git and then sync it back.
10:20 bshum I don't think there's any way to really test it though, given the limitations of how things sync with Launchpad translations.
10:20 bshum Anyone object if we just proceed and do cleanup if it goes wrongly?  :)
10:21 bshum (I was thinking to ask the translators to pause their work before the sync so that we make sure to capture all the new strings prior to moving things around)
10:24 kmlussier bshum: Would all translators need to pause their work or just the person working on the arabic files?
10:25 bshum kmlussier: I want to say only arabic since that's the one we want to move
10:26 bshum But this is new to me so I'm not sure :)
14:19 berick the user no longer has to accept the permissions at run time
14:19 * jeff defers to berick again
14:19 berick it happens when the app is installed
14:19 kmlussier berick: Oh, good. I'll carry on with testing then.
14:19 jeff i don't like that Hatch gets such permissions, but that might be for another time.
14:19 berick note to self: fix docs
14:20 berick jeff: agreed, but at this point, if it works for someone besides me, i'm throwing a party
14:20 Dyrcona jeff: Everything wants the keys to the kingdom these days.
14:20 berick kmlussier: consider me on call for your testing :)
14:20 kmlussier Ooh! A party?
14:20 berick well, it is friday
14:21 berick @bartender hatch-testers
14:21 * pinesol_green fills a pint glass with Magic Hat Hocus Pocus, and sends it sliding down the bar to hatch-testers (http://beeradvocate.com/beer/profile/96/292)
14:35 kmlussier Not sure I should be testing anything after drinking something called Hocus Pocus.
14:36 JBoyer *Biipity-Boppity-Broken!*
14:46 Dyrcona :)
14:52 sandbergja The DIG meeting will start in about 8 minutes
15:16 kmlussier But I can give anyone access who needs it too.
15:16 kmlussier We aren't stingy with WP credentials. :)
15:16 rhamby yep, both are accurate as well as kmlussier
15:16 Christineb it is also possible for me to add collaborators on the list so others can add videos - testing required
15:16 kmlussier Sorry, meant to say I can give access *to anyone* who needs it.
15:17 Christineb if anyone is interested in being a collaborator let me know and I will email you the invite so we can test it out
15:17 remingtron rhamby: kmlussier: thanks for confirming
15:17 sandbergja Anyone up for getting WP credentials and/or adding this link?
15:18 Christineb I can add it
16:30 kmlussier joined #evergreen
16:31 berick windows doesn't like you either
16:31 kmlussier berick: Sorry, that disconnect was not a response to your question.
16:31 berick kmlussier: ok, try this please:  open a console, then cd C:\\Program Files (x86)\Hatch
16:31 berick you may have use quotes on the directory names, tab-complete should help
16:32 berick once your there do:  hatch.bat test
16:34 berick well, probably it's just C:\Program...
16:34 berick not c:\\
16:36 * berick launches a windows vm
16:37 kmlussier berick: Sorry, distractions. Unfortunately, I'm going to have to look at this Monday morning.
16:37 berick kmlussier: ok, no worries, I'll be around
16:37 kmlussier berick: Thanks! And have a nice weekend!
16:37 berick kmlussier++
16:38 berick you too
16:38 berick csharp: any more hold targeter issues?
17:01 pinesol_green News from qatests: Test Failure <http://testing.evergreen-ils.org/~live>
17:04 jeff open-ils.cstore 2017-02-03 16:35:23 [ERR :11276:oils_sql.c:2522:] open-ils.cstore ERROR inserting config::copy_status object using query [INSERT INTO config.copy_status (holdable,id,name,opac_visible,copy_act​ive,restrict_copy_delete,is_available) VALUES (DEFAULT,1,DEFAULT,DEFAULT,​DEFAULT,DEFAULT,DEFAULT);]: 0 ERROR:  null value in column "name" violates not-null constraint
17:05 * jeff compares last success to see which of the 12 are the 3 expected errors.
17:06 jeff ah, yup. ignore my paste. that's expected.

Results for 2017-02-02

01:14 abneiman joined #evergreen
05:00 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
07:16 rjackson_isl joined #evergreen
08:01 collum joined #evergreen
08:46 mmorgan joined #evergreen
10:53 jeff i think people also have stronger opinions on the per-hold booleans vs the per-hold notification targets. in our environment, we've done away with both.
10:54 jeff your notification settings at the time that the hold goes available are how you are notified for that hold.
10:54 jeff (with one or two theoretical corner cases that i've on my list to hunt down)
10:55 * berick tests the tpac, sees that it forces patrons to use the email on the account and provides no way to change the email value
10:56 berick that kind of renders the whole feature useless, doesn' it?
10:56 jeff berick: because there is no per-hold email string, just a bool for yes/no.
10:56 jeff but unlike email, there are per-hold phone_notify and sms_notify (and sms_carrier) settings.
10:57 jeff which function as both bool and target, iirc.
12:26 jvwoolf joined #evergreen
12:32 bmills joined #evergreen
12:38 mmorgan joined #evergreen
12:46 * mmorgan catches up
12:52 mmorgan jeffdavis: Hard to say if the fix for 1086458 made the problem go away entirely. Many variables changed - OSs, workstation hardware, etc. Have not done another concise test since, but my current unscientific impression is that there are still some 'memory leak' issues related to patron searches.
12:54 jeffdavis mmorgan: understood, thank you
12:59 miker csharp: re the desire for "stacked" validators and such from the other day, the module loading logic is built such that if you can toss a perl module anywhere that perl can find it for "use", you can create your own validators (and reactors, etc).  So if you created a module called, say, PINES::AT::Validators and in there you had subs (like "sub sms_validate {...}' that pulled in and used stock validators in the order you wanted, and did other
12:59 miker validations as well, you could configure A/T to use them.  Just add a validator module (via staff client config) for, say, PINES::AT::Validators::sms_validate and make use of it
13:37 miker ah, ok ... NOTHING TO SEE HERE!
13:37 JBoyer :)
13:40 miker csharp: huh... well, ws should be the id of the workstation, obv, not a string ... recent changes to the staff client? or missing/local changes to the idl?
13:40 JBoyer csharp, I suppose it's too much to hope that you're testing some toolbar changes on that install?
13:41 csharp I rebuilt the staff client just in case it was my older local one
13:41 csharp if someone can easily confirm that it's happening or not, that would help :-)
13:41 csharp JBoyer: nope :-/
16:50 berick in circ, self->retarget is a list
16:50 * berick patches
16:57 khuckins_ joined #evergreen
17:00 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
17:06 berick csharp: _bott_: http://git.evergreen-ils.org/?p=worki​ng/Evergreen.git;a=commitdiff;h=320cc​9fe56d38c79da2da064a68fec746ae3385e
17:06 berick pushed to same branch
17:07 mmorgan left #evergreen

Results for 2017-02-01

02:42 gsams joined #evergreen
05:00 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
07:06 agoben joined #evergreen
07:15 rjackson_isl joined #evergreen
07:45 krvmga joined #evergreen
15:21 kmlussier joined #evergreen
15:36 Bmagic I'm lost in Circulate.pm - Does a paid deposit get refunded upon checkin? It should right? I just dont see it in the code
15:45 khuckins joined #evergreen
15:47 mmorgan Bmagic: In a quick unscientific test, I did not see the paid deposit refunded on checkin.
15:48 Bmagic mmorgan: yeah, that is what I am doing too. There is a permission I discovered: ITEM_RENTAL_FEE_REQUIRED.override that doesnt exist (yet)
15:49 Bmagic I wonder if that somehow is needed to do the refund?
15:51 mmorgan Hmm. I see ITEM_DEPOSIT_REQUIRED in the client override window at checkout.
16:17 * jeff plays with window functions across auditor tables
16:17 Bmagic mmorgan++
16:17 Bmagic jeff++
17:00 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
17:04 mmorgan left #evergreen
17:33 jvwoolf left #evergreen
17:54 csharp Bmagic: PINES uses that feature - I can research and/or pass on any questions

Results for 2017-01-31

00:28 dcook joined #evergreen
00:33 dcook__ joined #evergreen
05:00 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
06:46 genpaku joined #evergreen
07:14 rjackson_isl joined #evergreen
07:17 dteston joined #evergreen
11:24 pinesol_green csharp: Thank you csharp! But our princess is in another castle!
11:24 csharp @bartender berick
11:24 * pinesol_green fills a pint glass with Samuel Adams Black Lager, and sends it sliding down the bar to berick (http://beeradvocate.com/beer/profile/35/21300)
11:25 berick csharp: but did you test it yet? :)
11:25 csharp doing so now
11:25 csharp :-)
11:25 Dyrcona I don't think you have to test that. It will fix the problem. ;)
11:26 Dyrcona I was ready to commit it after just eyeballing it. :)
11:27 * Dyrcona wonders what's for lunch.
11:30 csharp no errors - now going to wait a little while for more events to accumulate and run a bigger batch at once
12:32 miker csharp: is there an LP bug to attach this to?
12:33 miker nm, found it
14:55 mmorgan1 joined #evergreen
15:38 csharp miker: oops - I left out the "next;" in my git branch - it was added to my local file :-/
15:41 csharp miker: I'll test your branch in a bit and let you know how it goes
15:45 agoben joined #evergreen
15:55 khuckins_ joined #evergreen
15:59 csharp miker: so putting aside the functionality of the patch(es), you're saying that it's "wrong" to group on a field that is nullable (in this case, sms_notify on action.hold_request)?  I see that all other notices group on usr, but I'm assuming we group on sms_notify since that's a per-hold setting...
16:00 csharp that is to say, if there's a better way to do this in the first place, I'm game :-)
16:01 jeff can you articulate why you were grouping by sms_notify and not usr? how do the stock phone / pbx A/T event defs group?
16:02 berick i'm fairly certain it is because sms_notify is per-hold and not per-user
16:02 berick (a topic I know jeff loves)
16:38 stephengwills in my case it appears as if the xact_finish date == the date the item was checked in.  the bills are all unpaid.  not even partial payments on them
16:51 mmorgan joined #evergreen
16:56 khuckins__ joined #evergreen
17:00 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
17:02 mmorgan left #evergreen
17:15 jeffdavis Are folks around these parts experiencing memory leak issues with the staff client?
17:17 jeffdavis there are some reports of this kind of thing in bug 1110817 (and in bug 1086458 which was "fixed" circa 2.5) but I'm not sure of prevalence of that kind of issue

Results for 2017-01-30

05:00 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
07:20 rjackson_isl joined #evergreen
07:23 JBoyer joined #evergreen
08:40 mmorgan joined #evergreen
12:27 jihpringle joined #evergreen
12:33 miker _bott_: I just marked your bug as private and security related ... as it happens, it's a duplicate of one I entered last week that has patches already :)
12:33 _bott_ patches would be very welcomed!
12:35 miker I've attached you to the other bug.  I'm going to mark yours as dup and put patches (instead of branch names in a repo you can't get to...) there so you can test 'em
12:36 genpaku joined #evergreen
12:37 jihpringle joined #evergreen
12:41 jvwoolf joined #evergreen
14:17 dteston berick: So existing salts are pulled from actor.passwd, but new salts are created from that function once per user?
14:21 berick dteston: existing MD5 hashed passwords [ just MD5('password123') ] are pulled from actor.passwd.  all passwords, migrated and new, get new salts from actor.create_salt()
14:22 berick dteston: see also actor.migrate_passwd() db func
14:22 _bott_ miker: patches in and brief testing yields positive results
14:27 dteston berick: post-migration though, the only salt that's used to authenticate my password will be on actor.passwd, right?
14:28 berick dteston: yes
14:29 berick it's the only salt, but passwords going forward also do the 2 rounds of md5 hashing
15:25 gsams joined #evergreen
15:27 dteston joined #evergreen
16:04 mmorgan joined #evergreen
17:00 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
17:10 jvwoolf left #evergreen
17:10 mmorgan left #evergreen
17:23 Stompro mmorgan++ Thanks for the response to my list question!

Results for 2017-01-29

05:00 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
09:50 genpaku joined #evergreen
14:49 Dyrcona joined #evergreen
15:57 kenstir joined #evergreen
16:44 Dyrcona yeah, I looked at syslog-ng's documentation and I'm not sure you can do this with syslog-ng, either. :)
16:44 Dyrcona Anyway, I'm blocking sites that try non-existent accounts or accounts that do not receive email immediately.
16:45 Dyrcona If you try a legit account, you get blocked after so many failures in  a certain time period, hence the dbm file.
16:46 Dyrcona I tested it by deliberately messing up my password.
16:46 Dyrcona I've been getting attacked every couple of weeks from Romania, Belize, and Ukraine mostly.
16:53 kenstir It's annoying, but as soon as you bring up a server on a public IP it gets probed.
16:56 Dyrcona Yeah.
16:56 Dyrcona And my script works, 'cause I managed to fail enough times to get blocked in my firewall. :)
16:58 Dyrcona I guess my first attempt at configuring it didn't have the program name filter correct, and my second attempt had the wrong level.
16:59 Dyrcona I wonder if it works if I move it to the bottom of the file?
17:00 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
17:00 Dyrcona Yes, apparently, so that wasn't my problem before.
17:00 Dyrcona Anyway, enough about that.
22:07 dbs @later tell kenstir https://example.org/opac/extras/superc​at/retrieve/marcxml-full/record/907278 to get the MARCXML + holdings + URIs for record 907278, per https://wiki.evergreen-ils.org/doku.p​hp?id=backend-devel:supercat:examples

Results for 2017-01-28

05:00 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
08:57 rlefaive joined #evergreen
12:27 bmills joined #evergreen
13:00 bmills1 joined #evergreen
17:00 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
17:05 csharp following up from the conversation here: http://irc.evergreen-ils.org/​evergreen/2017-01-26#i_285899, adding the code I added in bug 1660059 fixed the problem
17:05 pinesol_green Launchpad bug 1660059 in Evergreen "Action trigger mechanism not handling null/undef values for grouping field" [Undecided,New] https://launchpad.net/bugs/1660059
17:06 csharp my working theory is that the error messages returned by the attempt to run the A/T process added up to the humongous 52MB message that killed off the drone

Results for 2017-01-27

05:00 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
06:20 kmlussier joined #evergreen
06:20 * kmlussier yawns
07:07 rjackson_isl joined #evergreen
10:01 _adb yea.. hold is captured, but before 'hold shelf delay status' time has passed
10:02 tsbere aka, it is in the "on hold shelf" status with a shelf time, but within that delay period?
10:03 jeff _adb: i thought that that was a known and fixed issue a while back. maybe there's still an open bug and it's not been merged. looking.
10:03 _adb i think so? the hold shows up in the staff client as "reserved/pending", but i'm not sure what the item status is during this time. i'd have to test.
10:04 remingtron joined #evergreen
10:04 jeff bug 1195428
10:04 pinesol_green Launchpad bug 1195428 in Evergreen "TPAC reports hold "ready for pickup" before hold_shelf_status_delay expires" [Medium,Confirmed] https://launchpad.net/bugs/1195428
10:09 berick jeff: bonus, it's not prompting for any permissions.  it almost seems too good to be true, though.
10:10 jeff that does seem a bit too good to be true... hrm.
10:10 _adb how long is the timeout before notifications sent and hold is marked as ready for pickup if it's captured as transit?
10:10 jeff berick: have you tested with a fresh copy of chrome and potentially a fresh google account to confirm that there's nothing going on like "oh, you granted some permissions to this a while ago"?
10:11 tsbere _adb: You still need to check it in again to end the transit, so "until staff take action, plus whatever is configured then"
10:11 jeff _adb: depends on a few variables, including how often you run the action trigger script with the granularity in question, and the delay configured in the A/T definition...
10:11 _adb ah, ok, thank you
10:14 Dyrcona joined #evergreen
10:15 bos20k joined #evergreen
10:15 jvwoolf joined #evergreen
10:16 berick jeff: i'm going to clean up my test code, get it into the working repo, then try it on a few other machines today.  i'll update the bug.  other eyes would be awesome, though
10:16 berick jeff: for now, the fact that you didn't say "that's insane" is what I was looking for ;)
10:17 jeff it got a raised eyebrow and a "that doesn't sound like it should work", but I'm not planning to make any further assertions without testing. :-)
10:25 mmorgan1 joined #evergreen
10:32 Christineb joined #evergreen
10:39 Callender joined #evergreen
10:51 mdriscoll joined #evergreen
10:54 berick jeff: oh, i missed your earlier comment.. when viewing the details of the extension, it does say "Read and change all your data on the websites you visit"  -- however, it already said that.
10:55 berick first test passed, installing under a different "person" in chrome.  trying on a different machine now..
11:07 sandbergja joined #evergreen
11:08 dbwells joined #evergreen
11:14 khuckins joined #evergreen
11:17 remingtron joined #evergreen
11:17 berick jeff: fyi, installed on another machine (mac) where i've never installed it before, on a different chrome "person" (not logged into google) and all is well.  this is after trimming the manifest even more.  http://git.evergreen-ils.org/?p=working/Hatch.gi​t;a=blob;f=extension/app/manifest.json;hb=collab​/berick/lp1646166-native-messaging-2.12-omnibus
11:17 * berick updates lp
11:19 jeff berick: does the extension still show "Read and change all your data on the websites you visit"?
11:19 jeff and it didn't display that permission as being granted when the extension was installed?
11:20 berick jeff: it does display that message when viewing the extension details.  it doesn't inform me of that during install, presumably because I'm installing in developer mode.
11:59 brahmina joined #evergreen
12:01 bmills1 joined #evergreen
12:03 jihpringle joined #evergreen
12:18 kmlussier berick++ jeff++ # Continued hatch work and testing.
12:19 jeff i'm just listening today. :-)
12:20 JBoyer berick++
12:21 JBoyer It sounds like hatch is coming along nicely. I've finally got a notebook running Linux so I'll be able to take part in more testing and so on. (Not putting Java on any machines I actually like, so it's been a no-go at home until now, and work doesn't like it either. :/ )
12:22 jeff berick++ indeed
12:32 Bmagic Is there a way to ask SIP weather a patron can circulate without trying to circulate an item?
12:33 Bmagic It looks like we are getting 'Y' in the 3rd position on the 64 responses. AKA "64  Y           " - which means block right? The problem is, that 'Y' seems to shows up no matter what penalties or no penalties
12:41 JBoyer I can't tell that it's actually looking at penalties that block CIRC, only that there are some penalties. barring the patron (the checkbox on the Edit screen) or letting them expire are the only sure-fire ways to set that to Y
12:42 Bmagic thanks for the help, I will keep digging
12:42 Bmagic $u->standing_penalties and @{$u->standing_penalties}
12:43 Bmagic If the result of that test is true, then circ is blocked, which results in the first position 'Y' ?
12:44 jeff might want to start with "why do you think the patron should be blocked?"
12:44 JBoyer Yes, but I can't tell what that's actually testing. first, that there are standing penalties, but I'm not sure what @{$u->standing_penalties} is actually testing.
12:44 Bmagic if the penalty they have blocks CIRC
12:45 Bmagic if you look at the code for renew_ok - $renew_block_penalty = 't' if $_->standing_penalty->block_list =~ /RENEW/;
12:45 Bmagic probably need something similar in charge_ok ?
12:50 Dyrcona That check is check that we have something, and that they arrayref has 1 or more memberes.
12:50 Dyrcona @{[]} is 0 or false in scalar context
12:50 pinesol_green Dyrcona: Error: "" is not a valid command.
12:52 Bmagic the test is then "penalties exist and there are more than 0" ?
12:55 Dyrcona Bmagic: Yeah.
12:55 Bmagic I'm thinking there needs to be a penalty block check for charge_ok and hold_ok just like renew_ok, do you think?
12:55 Dyrcona It's done that way to avoid warnings about undefined values.
13:23 Bmagic I suppose I will create a new bug unless you can think of one that is already there ( I really don't want to make a duplicate)
13:25 jeff either start with a "this might be the same thing" as a comment on that bug, or a new ticket with "this might be a duplicate" and either a new bug can be created or the new bug can be marked as a duplicate if so.
13:25 Bmagic I would like to mention that our system is not setting that first position 'Y' when they have penalties. Therefore, I can conclude that "$u->standing_penalties and @{$u->standing_penalties}" doesn't seem to be returning correctly
13:25 jeff i would err on the side of getting a clear explanation of what you found and how you think it should be different into launchpad over worrying about comment vs new bug too much. :-)
13:26 jeff (i say this because i've let that prevent me from getting info into launchpad before)
13:27 jeff also helpful is some background on what the actual practical effect of the current behavior is, as not everyone has the same SIP clients to test with, or uses SIP in the same way.
13:36 Dyrcona In my experience, a number of SIP vendors treat a Y in any field as blocked for everything.
13:36 Dyrcona It's rare to find one that actually checks the specific field.
13:38 Dyrcona As for Bmagic's comment about it returning correctly, I'd have to look at the code in question, but when dealing with arraryrefs, that's a common way to check if it has members.
16:23 rlefaive joined #evergreen
16:52 khuckins_ joined #evergreen
17:00 jvwoolf left #evergreen
17:00 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
17:10 mmorgan left #evergreen
17:12 pinesol_green [evergreen|Bill Erickson] LP#1655399 webstaff: User perm editor grantable fix - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=a2e9d7a>
17:30 khuckins__ joined #evergreen
17:44 kmlussier joined #evergreen
17:45 pinesol_green [evergreen|Kyle Huckins] LP#1621947: webstaff address alert functionality - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=5a3e0dd>
17:59 pinesol_green [evergreen|Kyle Huckins] LP#1657466 - Edit Due Date Doesn't Submit - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=117d164>
18:03 * kmlussier just set 2.11.2 and 2.10.9 as milestones and then thought, wait, didn't we just release those?
18:26 * kmlussier would love to see checkboxes on this page - https://launchpad.net/evergreen/2.11/2.11.2 - with an actions menu to perform batch updates on the bugs.
19:05 rlefaive joined #evergreen

Results for 2017-01-26

03:48 jonadab joined #evergreen
05:00 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
07:10 rjackson_isl joined #evergreen
07:17 agoben joined #evergreen
08:06 rlefaive joined #evergreen
14:46 berick lot of people out there using PG 9.5?
14:48 Dyrcona berick: Considering upgrading to 9.5 from 9.2 next month.
14:49 berick Dyrcona: good to know.  trying to figure out where to upgrade to..  also on 9.2 here.
14:49 csharp berick: I'm planning to start testing in PINES for 2.12/Labor Day upgrade
14:49 berick csharp: *nod*
14:49 Dyrcona berick: I believe NOBLE just upgraded to 9.4.
14:49 csharp I'm using 9.5 on a standalone EG server for the governor's mansion and I haven't seen problems, but it's a tiny dataset
14:49 csharp and no transaction load
14:50 csharp 9.4 rox
14:50 berick i have it on my test vm's.  been fine, but yeah, no load
14:51 Bmagic berick: we are on 9.5 atop 16.04
14:52 berick Bmagic: cool, no issues?
14:52 csharp just pay attention to the posix/THP issue that I hit last year: http://libmail.georgialibraries.org/pipermai​l/open-ils-general/2016-February/012736.html (plus miker's caveats in that thread)
14:52 csharp heh
14:53 Bmagic transparent huge pages are turned off for us as well
14:54 Bmagic otherwise, we haven't done any of the other things mentioned on that thread from csharp
14:54 miker basic testing of 9.6 shows it should work fine, too, fwiw.  parallel seq scans!  tsearch phrases!  faster on big boxen!
14:55 Bmagic parallel seq scans sounds nice!
14:58 csharp JBoyer: miker: http://pastebin.com/qfL43KAS
14:58 * csharp transits himself from office to home - will check back from there
14:59 kmlussier miker or others: Is bug 1485374 something that can be merged rather soonish? It has a signoff from Dyrcona, but when I asked about it at the hack-a-way, my recollection was that it wasn't ready to go in yet.
14:59 pinesol_green Launchpad bug 1485374 in Evergreen "Use client TZ in the database when supplied to the server" [Wishlist,Confirmed] https://launchpad.net/bugs/1485374
15:05 mmorgan1 joined #evergreen
15:06 miker kmlussier: it looks good to me, and will cause testing :)
15:07 miker merging will cause testing, I mean
15:07 JBoyer This isn't necessarily a discussion I'm eager to have now, but has there ever been any discussion of only ever storing UTC in the db and only applying a TZ on the client?
15:14 maryj joined #evergreen
15:22 * csharp returns
15:41 Dyrcona Well, looks like we don't have wunder any more.
16:18 JBoyer joined #evergreen
16:55 mmorgan joined #evergreen
17:00 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
17:08 mmorgan left #evergreen
21:11 pinesol_green [evergreen|Jane Sandberg] Docs: authority_control_field script --days-back feature - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=3b36b46>
23:56 abowling1 joined #evergreen

Results for 2017-01-25

01:23 Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged: http://irc.evergreen-ils.org/evergreen | Large pastes at http://paste.evergreen-ils.org
03:50 abowling joined #evergreen
04:34 jonadab joined #evergreen
05:00 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
07:14 rjackson_isl joined #evergreen
07:16 agoben joined #evergreen
07:56 lualaba joined #evergreen
10:09 berick mmorgan: ohh, right, i was not considering all-day closing
10:14 kmlussier gmcharlt / miker / dbwells: Are we still planning for a point release today?
10:15 miker kmlussier: checking, but I think a couple of patches are yet to be merged ... and, I've got a fix for a vandelay-via-acq issue on opensrf master (which I think you said you had problems with) when activating a PO
10:17 kmlussier miker: Any specific patches you want me to look at? The issue I had was related to the bundling / chunking thing, I think.
10:17 * kmlussier can look at that one.
10:22 jvwoolf joined #evergreen
10:23 kmlussier Has anyone running the web client noticed a lot of log bloat? I've found that the two MassLNC VMs that are running the web client run out of space very quickly. I never have any problem on the VMs that are webby free.
10:26 kmlussier I reduced the log level to 2 last week, but it's still a problem. I suppose I can reduce the log level even further, but that won't be an option for production servers.
10:31 kmlussier Ah, I see. The earlier bundling / chunking fix only addressed the pull list issue. miker: are you planning to add the vandelay fix to the same branch as the pull list fix? If so, I'll hold off on testing.
10:31 csharp hmm - I'm curious about the types of messages that are causing that
10:31 JBoyer kmlussier, can you post some samples somewhere so we can try to see what kinds of messages you're getting and if they can be fixed/toned down?
10:31 miker kmlussier: I can, if that's easier for you
10:32 kmlussier JBoyer: Sure, but I just cleared them out this morning. I'll post something later when they've had some time to grow.
10:33 JBoyer kmlussier++
10:33 miker kmlussier: well, it's less work for me to not create a new bug, so I'll add to the same branch :)
10:34 kmlussier Works for me
10:39 kmlussier Is anyone actively testing the latest branch at bug 1657237?
10:39 pinesol_green Launchpad bug 1657237 in Evergreen "Trigger function maintaining hold-target mapping not well constrained" [Critical,Confirmed] https://launchpad.net/bugs/1657237
10:41 miker kmlussier: I know of several sites that are actively using it in production ... so, yes?
10:41 kmlussier miker: I was thinking of somebody who could add a signoff to it. :)
10:50 bos20k joined #evergreen
11:02 miker kmlussier: branch at http://git.evergreen-ils.org/?p=working/​Evergreen.git;a=shortlog;h=refs/heads/us​er/miker/lp1657885-alt-pull-list-print updated (this does fix PO activation for some broken cases)
11:02 miker updating the LP ticket now
11:02 kmlussier OK, thanks. I'll test it now.
11:03 JBoyer miker, merge away! It fixed up the migration and dev servers that I had heretofore ignored with no problems.
11:04 miker JBoyer: thanks!
11:11 khuckins joined #evergreen
11:33 pinesol_green [evergreen|Mike Rylander] LP#1657237: Rewrite the hold target cache - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=cbe4cae>
11:50 bmills joined #evergreen
12:13 sandbergja joined #evergreen
12:22 kmlussier miker: I noticed when testing Vandelay imports on OpenSRF 2.4, I'm not getting the usual updates on progress. Looking at your comments in the commit, I'm guessing that's expected?
12:22 miker kmlussier: it is ... does the import succeed?
12:24 miker kmlussier: I'll see if I can think of a good way to retain the behavior for 2.4
12:24 kmlussier miker: Yes, it does. But for a larger one, the progress bar never went away when the import was complete. When importing a smaller set of records, that wasn't a problem.
12:25 miker kmlussier: gotcha. I'll see what I can do. do updates show up with opensrf master? (or are you not testing that yet?)
12:25 kmlussier miker: Yes, they do in opensrf master. And they also work in opensrf master, so that's a big improvment. :)
12:26 miker :)
12:37 miker kmlussier: the branch is updated ... that should bring back the update stuff for 2.4
16:56 pinesol_green Launchpad bug 1392396 in Evergreen "Wishlist: Action Trigger for new user creation" [Wishlist,Fix released] https://launchpad.net/bugs/1392396
16:59 berick hah, there is already an 'au.create' even fire in the patron update API
16:59 berick *event
17:00 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
17:08 mmorgan left #evergreen
17:23 gmcharlt I've uploaded 2.10.9 and updated the downloads page
17:23 gmcharlt I'll check in later this evening for 2.11.2 and to do the release announcement

Results for 2017-01-24

05:02 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
06:47 tspindler joined #evergreen
06:57 agoben joined #evergreen
07:13 rjackson_isl joined #evergreen
09:58 * JBoyer feels for Dyrcona. Many are the LPs in my head, but faster are the workarounds and more work waits. :(
10:22 Christineb joined #evergreen
10:28 Dyrcona Great....The two servers where I've tried yaz-client get connection refused, but someone is connecting because the number of simple2zooms > 1.
10:28 Dyrcona I just wanted to test the configuration, but I don't remember from where I tested it successfully last time.
10:29 Dyrcona Maybe the training server?
10:52 jvwoolf joined #evergreen
11:23 abowling joined #evergreen
14:53 jeff i see some queries involving auditor.asset_copy_history in your future.
14:56 collum joined #evergreen
14:59 Dyrcona Hmm... Can I tell psql to fill a variable from a file, one line at a time? Something tells me, "No."
15:00 berick recently vacuum-full'ed auditor.asset_copy_history on a test server after removing old entries...  table size went from 127G to 11G.  woot.
15:00 berick in less than 20 minutes, no less
15:02 mmorgan1 joined #evergreen
15:03 csharp @love vacuum full
15:03 pinesol_green csharp: The operation succeeded.  csharp loves vacuum full.
16:54 Dyrcona It apparently has no concept of keep alive packets.
16:55 phasefx Stompro: it's the staff client doing that; the web staff client isn't so zealous.  Look at patron/search_form.js, line 372
16:57 phasefx Stompro: you could comment that out on the server-side and be okay, I think
17:02 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
17:08 mmorgan left #evergreen
17:12 Stompro Thanks, I'm trying to figure out why this is done.  it would be one thing if names starting/ending with numbers couldn't be registered...
17:19 Stompro Pre commit f7db7f578e6f numbers were allowed, then it was changed to allow unicode characters but to exclude digits.  I wonder if that was on purpose or not?

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