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 144 145 146 147 148

Results for 2016-09-14

10:10 dbs JBoyer: We've run for 7 years on a single app server, the simplicity has been nice
10:11 * Dyrcona has fun with Internets. Could drop again without notice.
10:14 JBoyer dbs, there is something to be said for simplicity.
10:16 kmlussier I keep coming across bug 1013786 whenever I'm getting ready for Bug Squashing Day. I think we need to decide whether we want to push the code that's there, which already has two signoffs, or if we want to wait until the password strength test is moved to a self-contained routine, in which case we should remove the pullrequest tag.
10:17 pinesol_green Launchpad bug 1013786 in Evergreen "tpac: Check for password strength at login" [Medium,Confirmed] https://launchpad.net/bugs/1013786
10:17 kmlussier Any thoughts?
10:17 * kmlussier guesses that nobody is actively working on it at the moment.
15:28 Dyrcona Hmm... It isn't always quick to branchify configs that are generated from .in files if you're not starting from git but from the modified output of the .in files.
15:34 mmorgan1 joined #evergreen
15:37 Dyrcona Because of things like this: 3 out of 10 hunks FAILED -- saving rejects to file eg_vhost.conf.in.rej
15:45 Bmagic miker: I am still testing this branch ( just resuming now )
16:04 Dyrcona One thing I've discovered in this process is that it helps to check out the rel_* branch for the release that your production server is on and do the comparisons/updates in that branch.
16:06 Dyrcona Then cherry-pick the resulting commits to a copy of master and/or any later rel_* branches.
16:10 berick_ joined #evergreen

Results for 2016-09-13

16:41 miker the difference that my second commit makes is that it allows you to say "ignore the client's CP field, use this value from the config file"
16:42 miker well, it will if you do /not/ set client_location_code="true" for your institution(s)
16:42 miker which gives you the ability to migrate clients over time
16:43 Bmagic that should work, I will have to setup a test
16:43 miker by moving their account entries from one institution to another, with differing settings
16:44 miker please do! I'd like this to get into sipserver before 2.11 goes GA if possible, so sipserver master can be configured (at least) to not break any existing releases
16:45 jeff i may propose an alternate branch if i can get my thoughts together.
17:03 Dyrcona Yes. I would tend to agree with server wins.
17:04 miker anyway, I pushed one more commit that changes the institution policy setting "client_location_code" so that, unless that is set to "true", you get the old behavior (plus the ability to set the value in the config file)
17:04 Bmagic if a username/password is presented on the xml and from the client, who wins?
17:04 miker Bmagic: so, if you feel like testing, please try the tip of http://git.evergreen-ils.org/?p=workin​g/SIPServer.git;a=shortlog;h=refs/head​s/user/miker/lp1579144_login_location
17:07 miker Bmagic: for an <account> you mean? the xml is considered authoritative. if they don't match (or the login fails at the ILS) then login fails... so, I guess the ILS is most authoritative, but between XML and client, XML wins. is that what you mean?
17:07 Bmagic yeah, another joke
17:07 Bmagic the xml has the username/password/workstation supplied and the sip client has the same. who wins on each one.....
17:09 * Dyrcona calls it a day.
17:28 miker git blame --annui ??
17:29 * miker really runs away
17:30 Bmagic lol
17:53 Bmagic miker: I just tested the SIP server code - something is amiss (probably me)
17:53 Bmagic LOGIN ERROR: 'Undefined subroutine &Sip::MsgType::to_bool called at Sip/MsgType.pm line 859.
18:37 _adb left #evergreen
19:17 miker Bmagic: no, it's me. I'll look at that as soon as I can and let you know. probably in the morning

Results for 2016-09-09

14:53 bshum Yes, I believe that setting can stand in place for whatever is defined in the script that dbs/jeff pointed you to.  So that if it was configured, it would use that setting.  But you'd still need to run said reshelving script on a regular enough basis to make use of the proper interval.
14:53 bshum Unset, it's still default to 24hours wait time
14:54 ssieb oh, ok
14:55 StomproJosh Yep, just tested it out, the web self check will queue up a payment every time the pay fines button is pressed, and submit them all serially after the submit payment button is pressed.
15:05 mmorgan StomproJosh: We have never allowed payment in selfcheck. We hid the link to pay early on.
15:06 StomproJosh mmorgan, why?
15:06 Dyrcona Because it is broken? :)

Results for 2016-09-08

09:20 jeff can your apache hosts connect to memcached successfully?
09:20 dbs jeff: yeah, I realize that -- so many moving parts to tweak
09:21 jeff any cache-related errors in the logs?
09:21 dbs tested the apache memcache translator setting of 127.0.0.1:11211 via telnet and that works, no errors reported in the logs
09:21 jeff there are things that are fetched from config, from the db, and from memcached... also the template toolkit cache...
09:21 dbs yep
09:22 * dbs will get back onto debug_timing, whoever thought of adding that was a GENIUS
09:39 dbs It seems that the apache processes need to be initialized, subsequent requests don't show those kinds of slowdowns (157ms and 83.5ms for initial connection & ssl), so that's an outlier
09:40 Dyrcona dbs: yes, I've seen that Apache is really slow just after start up. Load also tends to stay high for a couple of minutes, then settles down.
09:40 dbs hah, there aren't many events in the stock /eg/opac/advanced page it seems, just New page and initial load (At 0.1836: Initial load)
09:40 csharp same here - just saw that on my test box
09:40 dbs btw, Dyrcona, thank you for http://blog.mvlcstaff.org/2013/​05/what-has-been-going-on.html
09:43 jeff worst case i can get is 2.30s Load time (per chrome devtools) on a fresh apache start, even with cstore intentionally hobbled to 1 worker.
09:43 jeff on a fresh apache start.
10:22 dbs we do have about 20 virtualhosts configured for both 443 and 80, so undoubtedly lots of parsing overhead
10:23 JBoyer Could be, this machine hosts nothing else and it's generally hit by outside users.
10:24 JBoyer NOT generally hit by users, that is.
10:24 Dyrcona So, you're testing against one of 20 virtual hosts on the same hardware? Could be the hardware is slightly overtaxed.
10:26 dbs Dyrcona: yep
10:26 dbs although load seems fine
10:26 dbs at 0.75 for the last fifteen minutes, on an "8 core" VM
10:30 JBoyer dbs, referring to your speed comment above, I'm seeing ~200Kb/s for our homepage on the same gigabit network. TCP startup speeds I'm guessing? With pages that "small" the speed may never be able to top out. ( I also see 2000Kb/s when testing localhost on it's public IP)
10:30 dbs total of 14 cstore timeout errors reported over the past 24 hours (determined by grep "perl:error" /var/log/syslog | grep cstore)
10:33 jeff also laptop-on-wifi here. local system gets me 111.196 ms mean over 100 requests (11.120 seconds total); webby gets 740.887 ms mean over 100 requests (74.089 seconds total)
10:34 jeff that seems to be more than just rtt hurting me there. second guess is ssl tuning, but in both cases ab selected TLSv1.2,ECDHE-RSA-AES256-SHA384,2048,256
16:16 Dyrcona I want to start clark kent on the training server and it has a copy of production.
16:17 Dyrcona I set recur to false on all of the reports.
16:17 Dyrcona Is that all I need to do to prevent any surprise reports firing off?
16:17 Dyrcona We want to test some reports manually.
16:19 jeff also check for any reports scheduled to run which have not run.
16:19 * jeff refreshes memory on what columns he means
16:20 Dyrcona jeff: I was just going to aks.

Results for 2016-09-07

16:33 dbs "Powered by a Professional Organization of Heritage Preservation Institutions"
16:33 jeff the other, "deprecated" link is of course 404 (with a different powered by ad)
16:35 jeff broken link, broken link, document management system with spam from 2010...
16:42 bshum For fun, I just noticed that we haven't updated the version statement in the README that goes "Evergreen 2.8 has been tested on ...." (insert various Linux flavors).  I'm thinking either to toss out some commits to fix that in all the rel_2_x branches and give master the coming 2.11 (so that future branching and updates get a better number) or that we remove the version entirely.  Thoughts?
16:43 bshum I think it could work too with just plain "Evergreen has been tested on ..." various OS
16:47 dbs yeah, looks like it escaped the version numbers to bump part of https://wiki.evergreen-ils.org/doku.ph​p?id=dev:release_process:evergreen:2.8
16:47 * dbs looks at the short-lived https://wiki.evergreen-ils.org/doku.p​hp?id=dev:evergreen:release_checklist
16:48 dbs but I agree with dropping the version entirely there

Results for 2016-09-06

15:05 dbs there's code in auth.c and auth_internal.c for setting wsid, I hope our use of auth_proxy + LDAP isn't triggering a weird path where wsid doesn't get set.
15:09 Dyrcona dbs: Did you just upgrade to 2.10?
15:09 maryj joined #evergreen
15:09 dbs Dyrcona: yep
15:10 dbs oddly enough, just tried my master-from-about-a-month-ago test server and it propagated the wsid just fine
15:10 Dyrcona Well, I would suspect the auth changes and something unforeseen with using LDAP.
15:10 Dyrcona Any particular dot release?
15:10 Dyrcona Like, 2.10.6?

Results for 2016-09-05

17:23 dbs oh, i see, we were still using libyaz4 from ubuntu, thus the libgnutls.so.26 segfacults when libyaz5 is linked against libgnutls.so.28
17:36 * dbs falls back and punts, removing libnet-z3950-simple2zoom-perl libnet-z3950-zoom-perl libyaz4 libyaz4-dev from the system and building Net::Z3950::Simple2ZOOM from scratch
17:38 dbs which built Net::Z3950::ZOOM from source as a dependency. And now our z39.50 server doesn't fall over. YAYYYYYYY
21:38 pinesol_green [evergreen|Dan Scott] SIP manual testing formatting cleanup - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=e1a555e>
22:06 dbs Downside of that approach is that it seems to throw our Z39.50 import functionality for a loop, so imported records appear fine in the editor and then get corrupted or fail to import at all when you try to save them.
22:06 dbs *sigh*
23:44 dbs Best approach might be to run with the ubuntu packages on the evergreen server (for working z39.50 import of utf8 records with accents), and just install the yaz5 / simple2zoom bits on a separate vm to serve as the z39.50 server

Results for 2016-09-02

10:36 jeff i'm not quite sure how i managed to get this many for a single file without noticing.
10:37 Dyrcona My laptop doesn't crash much, but it's like playing Russian roulette after resume from suspend/sleep if it is going to act normal or exhibit one of two or three bugs.
10:38 * Dyrcona goes back to figuring out why some students didn't load yesterday...
10:40 Stompro Dyrcona, I just got done purging based on our migration date, lots of test load data, and batch global edits in there.
10:41 berick Stompro: we break our auditor data into 3 time categories and keep at most a certain number of entries from each grouping.  (We're only cleaning the copy auditor right now, more to follow).  the code i'm about to deploy: http://git.evergreen-ils.org/?p=worki​ng/Evergreen.git;a=commitdiff;h=f4585​7003181c8b0083c4d66e07d003d4478f29a
10:41 Stompro berick++ , thank you.
10:43 * berick notes some of the comments in there mention specific values for variables which are, in fact, variable
15:44 Stompro But for things like the various receipts and reports, that shouldn't be a problem.
15:45 * Dyrcona gets a lot of deprecations warnings on npm install.
15:48 Dyrcona bshum berick: grunt all just worked. Did you two do anything to fix that issue or has npm fixed it?
15:49 jeff are you talking about the test failure fixed in commit 6bc0bc2?
15:49 pinesol_green jeff: [evergreen|Jeff Godin] LP#1618136 Fix webstaff IDL2js.js test failures - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=6bc0bc2>
15:49 jeff (that was unrelated to npm, so i'm not sure if that's what you mean)
15:50 Dyrcona jeff: I think that is it. My memory ain't what it used to be.
15:50 Dyrcona jeff++ bshum++ dbwells++
16:08 * Dyrcona answers his own question: Yes.
16:08 Bmagic wifi--
16:09 kmlussier Why is it not 5 p.m. yet?
16:11 miker Dyrcona: the point testing of that branch is not to change the server tz -- that should be whatever it should be -- but to change the /client/ tz and confirm that times are 1) recorded in the client tz 2) show up in the client tz. that is, a client in central time should see times in central, even if they were written in eastern and the server is in eastern. and that those times should be the /real point in time/ not the same string. does that make
16:11 miker sense?
16:12 Dyrcona miker: Yes. I could just change my server to UTC and get a similar effect, no?
16:12 miker eg, if someone checks out an item at 1pm EST, a client in CST will see the circ happened at noon CST
16:12 miker um, no
16:15 kmlussier berick: Brazil! Hopefully, they have no Schlitz there.
16:15 miker perhpas
16:15 Dyrcona Well, if I do some transactions in EDT and change my timezone to CST to view them later, that should work.
16:16 miker I guess my point is, the real world test of the branch is about "do times displayed in the client and opac use the client TZ?"
16:16 miker Dyrcona: right
16:16 jeff miker: agreed!
16:16 miker jeff: but, in the real world, one wouldn't be changing the server's system TZ
16:17 jeff miker: it doesn't matter which one has changed, just that they are different.
16:17 miker so, while that might aproximate the effect, I wouldn't trust it, necessarily. too many things (like database settings) could (in a real world setup) get in the way
16:18 miker anyway, testing++
16:18 miker Dyrcona++
16:18 miker jeff++
16:18 * miker steps away from all keyboards for a bit
16:32 Dyrcona Heh. Doesn't work if you start services before configuring the database in opensrf.xml....
16:43 Dyrcona Hmm.. /eg/staf/ leads to a login, but /eg/opach/home leads to an internal server error.
16:43 * tsbere would expect both of those to be 404s, honestly ;)
16:48 tsbere Dyrcona: I have gotten errors like that when the IDL didn't initialize properly. Did apache come up too soon or something?
16:49 Dyrcona Yeah, my next thought after cstore not running was the idl. I ran autogen, and started apache. I'll restart apache and see if that helps.
16:50 Dyrcona tsbere++ # A restart helped.
16:50 Dyrcona Well, now that it seems to be working. I'll shut it down and do the testing tomorrow.
16:54 Dyrcona Well, have a nice weekend, everybody!
17:23 jvwoolf left #evergreen
17:32 Bmagic I'm trying to login to my new test server via SIP. I am getting an error about workstation not found. Anybody have something off the top of their head before I dive in?
17:34 berick Bmagic: it's ringing a bell w/ a recent bug...
17:34 berick Bmagic: bug #1259196
17:34 pinesol_green Launchpad bug 1259196 in Evergreen "SIP support workstation option at login" [Wishlist,Fix committed] https://launchpad.net/bugs/1259196
17:35 Bmagic oh good!
17:35 Bmagic berick++
17:36 Bmagic I am running master on this test machine though
17:37 gmcharlt joined #evergreen
17:38 Bmagic my login message contains the CP for the insitution, now it's workstation?
17:40 Bmagic oh boy, this is going to break some stuff in the wild for sure

Results for 2016-09-01

15:19 berick uh, done
15:39 jonadab joined #evergreen
17:19 bmills joined #evergreen
19:17 jeffdavis bmills: for your test database, how important is it to have realistic transaction data (e.g. a subset of real circulations)?
19:19 jeffdavis I have a set of scripts that pulls some data (bibs/holdings, config) from our production environment and uses it to generate a small-ish test dataset with fake patron records, but it doesn't currently include circs, holds, bills, triggered events, etc.
19:21 bmills jeffdavis: oh nice! transaction data would be great from action.circulation, but record/item level info would be more important
19:23 jeffdavis Ok, I'll see if I can strip out the Sitka-specific stuff and share that with you.
19:23 bmills jeffdavis: thanks!

Results for 2016-08-31

10:18 jeff berick++ miker++
10:41 kmlussier StomproJ: I was reading your question from last week regarding Reshelving status. We have a site that did not have the option to run the Reshelving script more frequently than every 24 hours (too large). They ultimately went with a label change to "Recently Returned" that seemed to make people happy.
11:03 Dyrcona1 joined #evergreen
11:13 jeff hrm. need to spin up a pre-2.10 instance to test something.
11:18 * csharp dreams up library-themed horror movie: THE UNRETURNED
11:19 berick csharp++
11:20 dbwells csharp++ # I needed that laugh :)
13:27 jeff it is inconsistent with the current xul client's checkin option from a patron's Items Out
13:27 Griff`Ron joined #evergreen
13:27 jeff but it really only matters when you're dealing with an unusual situation, like a patron with an open circulation on a deleted copy.
13:28 tsbere Which is important
13:28 tsbere But not a normal test case
13:28 jeff checking in a deleted copy by barcode will either fail (because the barcode is not found), or will checkin the wrong copy (because another item with that same barcode has since been created).
13:28 mmorgan jeff: right. We've had confusion about that in the past.
13:28 jeff in my case, the latter happened.
15:26 * berick hopes more than 4 people are coming to the hackaway
15:26 Dyrcona csharp: Are you done working on Lp 1360347
15:26 pinesol_green Launchpad bug 1360347 in Evergreen "Wishlist - New LSE setting for Acquisitions" [Wishlist,In progress] https://launchpad.net/bugs/1360347 - Assigned to Chris Sharp (chrissharp123)
15:26 Dyrcona The status is in progress, but the code changes look good to me and we'd like to test it.
15:30 jeffdavis I've got a pcrud drone that's been running for over 40 minutes, chewing up a lot of CPU. Is there any way to find out what it's up to while it's running? I get the impression that the request (whatever it is) won't be logged until it's complete.
15:31 * JBoyer hopes there are at least 18 others coming, or there'll be bills to pay. :/
15:31 jeff jeffdavis: have you tried attaching to it with something like "strace -p PID_HERE" to see if it's just spinning?
16:10 jonadab "What's the worst that could happen?"  "You mean besides starting a global thermonuclear war?"
16:10 * dbs upgrades the upgrade plugin
16:11 dbs I'll be good and wait until I can backup the wiki directory first before I upgrade the wiki.
16:15 csharp Dyrcona: I'm done until I can actually test it, yes.  Our Acq person is out for a while, so I'm waiting for her to return before experimenting
16:15 csharp Dyrcona: please test if you have the means to do so
16:16 csharp dbwells: I kept seeing "banjo" in there too :-P
16:17 * csharp prolly won't bother bringing the ol' ukulele this round
16:19 Dyrcona csharp: Thanks. I'll see if I can do anything to test it in the meantime, too.
16:19 csharp Dyrcona++
16:19 * Dyrcona tosses another iron in the fire. ;)
16:26 StomproJ Ooops, just merged all the Readers digest large print into reader digest... to the auditor tables.  Where is the undo button in psql.
16:37 gsams_ joined #evergreen
16:39 gsams_ joined #evergreen
16:42 StomproJ Hmm, it doesn't look like asset.merge_record_assets deletes empty volumes, which works out well for me, but I wonder if that is intended.
16:43 csharp StomproJ: I'll test it, but it will take a long time to apply on our test system, so it won't be quick :-)
16:43 StomproJ csharp++ thanks.
16:43 csharp we have a buncha muncha cruncha bibs
16:54 bmills joined #evergreen

Results for 2016-08-30

14:09 jeff The situation where I was experiencing it was within our mobile app, so I'm not sure (without digging) if it was in that abstraction layer or an issue within the tpac itself.
14:11 tsbere jeff: Part of the headache there is you get a failure reason set for *every copy*. Which set of reasons do you pass to the end user?
14:11 tsbere I made it so that if age protection was the *only* reason on *any* copy then that information would be passed back up. But anything else is likely to get lost.
14:12 gvi I'm at the point of testing the staff client.  I've entered so many user names in the last few hours I don't know which one to use.
14:13 tsbere gvi: You probably specified the username/password at the eg_db_config step.
14:13 gvi OK thanks.
14:14 gvi That was it.
17:06 Dyrcona I can probably come up with a SQL to fix the circulations in the mean time.
17:07 Dyrcona I'll take a stab at a fix in the coming days.
17:07 mmorgan left #evergreen
17:20 phasefx incidentally, it looks like live_t/purge-user-activity.pg is failing now
17:21 phasefx and on the perl side, live_t/18-lp1592891_sip_standing_penalties.t
17:21 phasefx actually, wrong test on that last one
17:21 phasefx live_t/19-lp1306666-abort-transit-copy-status.t
17:40 Dyrcona phasefx: If that last one is failing, I'm not sure why. I'd have to play with it some more.
17:42 * Dyrcona sees about building a xenial vm from an ISO. It has been failing with vmbuilder since sudo was updated yesterday.
17:45 * Dyrcona give vmbuilder one last shot.
17:48 phasefx for that abort test, it's expecting Reshelving, and getting Canceled Transit.  I haven't looked more closely than that.  Maybe the behavior is correct and the test needs updating
17:50 Dyrcona Ah, OK. I hadn't noticed that csharp's branch had gone in.
17:50 Dyrcona I thought the tests were to be rewritten before that happened.
17:51 Dyrcona I'll see if I can get around to fixing the tests by this weekend, but I can't promise much.
17:56 Dyrcona And, yeah, vmbuilder is still choking on sudo.
18:13 Dyrcona virt-manager is being a pain. I wish I could remember the options that I used for virt-install that last time.
18:20 gmcharlt joined #evergreen

Results for 2016-08-29

11:36 * Dyrcona should have remembered.
11:38 jeff it appears to be the SQL strings.
11:40 * Dyrcona didn't get that far. ;)
11:52 jeff Open-ILS/web/js/ui/default​/staff/test/data/idl2js.pl outputs an IDL2js.js for testing which is not valid javascript.
11:52 jeff doesn't seem to be a problem for the OpenILS::WWW::IDL2js handler, though... thus, /IDL2js doesn't seem to break (or generate invalid output)
12:01 jeff possibly because something in that chain already strips out newlines -- maybe the locale bits in the subrequest that /IDL2js uses
12:04 jihpringle joined #evergreen
12:17 eeevil jeff: yeah, I updated the handler to strip newlines (and sql comments, required by the newline stripping).  I wasn't actually aware of the test script
12:18 jeff just got to that part.
12:20 jeff I believe those two things are the only current (stock) users of fm_IDL2js.xsl
12:30 jeff bshum: did you open a bug yet?
13:04 jeff my launchpad hasn't noticed yet.
13:04 jeff there we go
13:04 jeff bug 1618136 has my proposed fix
13:04 pinesol_green Launchpad bug 1618136 in Evergreen "webstaff build/test failures related to IDL2js" [Undecided,In progress] https://launchpad.net/bugs/1618136 - Assigned to Jeff Godin (jgodin)
13:05 * jeff unassigns self
13:05 jeff i opted for "preprocess in the same way" as opposed to "try to do those transforms in XSL so that fm_IDL2js.xsl does what the filename claims" :-)
13:06 bshum Haha
13:31 jeff that sounds... annoyingly similar to your kernel update -> different ethernet driver -> different device name woes from earlier in scrollback.
13:32 tsbere jeff: Doesn't it? Differences including that it isn't a server I normally maintain, I wasn't installing the updates, and the network was *configured*, it just decided to change firewall modes on it.
13:33 tsbere jeff: Oh, and the person who was installing updates is supposed to be on vacation and emailed me to go deal with the problem.
13:37 bshum Tested the patch jeff and it does let me get to the next steps and have a working web client
13:46 eeevil jeff: I'd be 100% in favor of having the xslt do the processing -- I'm too tuit poor to dig back into xslt string mangling now, though.  as evidenced by my "fix" for getting any IDL views to work at all ;)
15:25 abowling left #evergreen
15:38 Dyrcona jeff: Do you think the branch on bug 1618136 is ready to go? bshum tried it and I can try it and possibly push it to master tonight.
15:38 pinesol_green Launchpad bug 1618136 in Evergreen "webstaff build/test failures related to IDL2js" [Undecided,In progress] https://launchpad.net/bugs/1618136
15:44 jeff Dyrcona: IMO it's ready to go, yes. at some future point we might return and enhance fm_IDL2js.xsl to no longer require pre-processing, but the branch as it stands fixes the test failure.
15:44 Dyrcona OK. I can agree with that, but fixing it for now is good enough for now. :)
15:45 Dyrcona I'll give it a whirl this afternoon/tonight unless someone else beats me to pushing it.
15:46 Dyrcona I still need to really look at the timezone branch, too. Other things come up, y'know? :(
15:46 jeff I think it follows with the original spirit of the idl2js.pl support script: transform the IDL to js in a way similar to how OpenILS::WWW::IDL2js does, but do it without requiring that we already have a running system.
15:47 jeff My branch just updates idl2js.pl to keep up with some new things that OpenILS::WWW::IDL2js does.
15:47 jvwoolf joined #evergreen
15:48 Dyrcona Yeah. I eyeballed the diff already. It looks good. I asked bshum to sign off since he tested already.
15:48 Dyrcona I don't think 3 signoffs would hurt. :)
15:49 eeevil jeff++
15:50 eeevil Dyrcona++
16:59 TARA joined #evergreen
17:13 mmorgan left #evergreen
17:26 jihpringle joined #evergreen
17:32 pinesol_green [evergreen|Jeff Godin] LP#1618136 Fix webstaff IDL2js.js test failures - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=6bc0bc2>
17:36 jvwoolf left #evergreen
17:37 dbwells grabbing 1000
17:42 pinesol_green [evergreen|Ben Shum] LP#1618183: Add Spanish to config.i18n_locale - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=dddb70d>
18:18 Dyrcona Ah, man. My drive home takes too long. ;)
18:18 Dyrcona dbwells++
18:20 Dyrcona Well, I don't think it was just using the wifi at work that prevented my ssh to the vms, 'cause it isn't working now, either.
18:25 dbwells Dyrcona: If you want something to do, a hot, fresh tarball could use some testing: https://evergreen-ils.org/downloa​ds/Evergreen-ILS-2.11.beta.tar.gz
18:26 * dbwells heads home
18:27 Dyrcona OK. I'm trying to figure out why my vm networking is broken.
18:27 bshum dbwells: One potential reason not to backport the Spanish thing is cause it's an INSERT and if someone upgrades to 2.10.next with it, then try to upgrade to 2.11.0, they'll likely bomb their upgrade due to a rollback when it tries to INSERT the same entry a second time later on
18:28 bshum Either that or we try to safely add it in a separate part of the 2.11 upgrade script
18:31 bshum I'll defer to gmcharlt on backport opinions; I'm fine with just focusing on the future with 2.11
18:34 berick joined #evergreen
18:34 Dyrcona So, apparently, I built the xenial vm but didn't fix the networking after.
18:34 Dyrcona bshum: Did you test the new tarball on xenial?
18:35 bshum Dyrcona: Not yet, I just got home too :)
18:35 Dyrcona Well, I'll test trusty if you test xenial. ;)
18:35 bshum Haha, deal :)
18:35 bshum I'll spin up a new VM install in my virtualbox
18:35 bshum I got 25 minutes till dinner anyways :D
18:36 bshum I can grab the tarball and finish the rest of the Evergreen install setup
18:37 bshum I stopped at prereq installing earlier
18:37 bshum So, perfect.
18:37 Dyrcona Yeah, I was going to install on trusty where I tested the 2.9.7 tarball, but s'pose I could build a fresh one.
18:38 Dyrcona I should build a vm just with opensrf and save a snapshot.
18:39 bshum Heh, perhaps
18:39 bshum I was just thinking the same thing actually
19:13 Dyrcona Well, it woks for me. I tried the OPAC and the browser staff client.
19:14 bshum Dyrcona++
19:14 Dyrcona Aw, shucks...T'weren't nothin'.... ;)
19:15 Dyrcona bshum++ # For finding the test issue.
19:15 Dyrcona jgodin++
19:15 Dyrcona jeff++
19:15 bshum csharp++ # he got me looking for it in the first place

Results for 2016-08-28

12:02 bshum Might be a npm problem or something.  I'm having trouble grabbing the dependencies
12:02 bshum Node issues do occasionally happen :\
12:14 * bshum might try again later
12:29 csharp bshum: I got version mismatch warnings during the run of the -developer Makefile.install option, then grunt all died on a PhantomJS test
12:29 csharp I didn't preserve it, but I'll redo it on a fresh xenial box before reporting a bug
12:30 * csharp is still doing battle with ejabberd/apparmor
12:31 csharp I think I'm going to have to start over - I've been experimenting with aa commands without documenting as I go :-/
12:34 jonadab joined #evergreen
14:58 bshum csharp: warnings aren't always bad. There are lots of deprecate warnings on some of the pinned versions. I'd be most nervous on the failure for grunt all
14:58 bshum My box wouldn't pull the npm deps down so I assume some node difficulty. I'll try again later when i get back to a computer.
14:59 bshum I saw the apparmor denied warning in syslog after setting up opensrf
14:59 bshum Didn't seem to affect the math test, but I did see the same message for ejabberd
15:00 * bshum tries to pay attention to the broadway show now
15:54 tsbere_ joined #evergreen
16:02 wjr joined #evergreen
18:28 csharp joined #evergreen

Results for 2016-08-26

09:46 mrpeters but, i assume websockets still need to be set up manually as a part of opensrf
09:46 Dyrcona Well, I don't know what your debs building process does.
09:46 Dyrcona Yes, I believe it does.
09:46 Dyrcona I usually build OpenSRF from git when testing tarballs.
09:47 Dyrcona It's typically already installed on my vm, anyway.
09:47 Callender joined #evergreen
09:47 mrpeters the debs were just packages of the latest version of the bower/grunt modules from npm

Results for 2016-08-25

11:07 * gmcharlt also notes bug 1616882
11:07 pinesol_green Launchpad bug 1616882 in Evergreen 2.9 "string missing in translation file" [Low,Confirmed] https://launchpad.net/bugs/1616882
11:09 Dyrcona I saw that one last night. I'll defer to others if it should be pushed today.
11:10 Dyrcona I have not yet started on builing and testing a tarball. I'll need to update the release notes, etc.
11:11 Dyrcona Right now, I'm preparing a vm to do the testing.
11:12 gmcharlt I'll be doing my release-cutting in mid-afternoon
11:15 Dyrcona I'll wait until then, too.
11:16 Dyrcona Might as well get the translation fix in, even if it won't make a difference to 2.9...
12:14 miker jeff: the naive user of multiplex does everything in one process. we just do connection brokering in the main process, and everything heavy in forked workers. benefit is that quiescent sessions don't waist resources (and most sessions are quiescent, even for folks with sorters and such)
12:18 miker Dyrcona (and everyone else looking at i18n stuff, thanks!): i18n commits get a pass from me, esp. in early beta -- IMO it's more important for us (with relatively low translation rates) to make new strings available for translation by GA than to have a perfectly locked translation target as of beta cut-off. I'm open to opinions, though, if folks think that will cause more harm than possible good
12:20 bshum +1 to that approach, we only do template syncs during the period between beta and release, so any fixes for strings is better now than six months or more from now.
12:23 jeff miker: aha! thanks for the explanation. i was pretty sure based on gut/experience that the warning didn't apply in this case, but I was having a hard time explaining it to myself. :-)
12:25 jeff also, i'm pretty sure that the new workstation support breaks when the auth session expires, and that we can probably stuff the workstation in the ils state hash to preserve it in those cases.
12:26 jeff ("breaks" as in "silently logs back in without a workstation")
12:27 jeff i'll test / branch
12:31 JBoyer jeff, do we not just require the client to log in again on an auth timeout?
12:34 jeff JBoyer: not a sip client, at least not in the case of Multiplex
12:35 JBoyer Well then I suppose that case was overlooked. :/
12:56 Christineb joined #evergreen
12:58 jeff yeah, i'm in there. what do you think -- re-open and comment on original bug for the feature, or new bug?
12:58 JBoyer As for storing the location in state, I believe it's already in $self->{login}, it's just that verify_session doesn't use it.
12:58 jeff JBoyer: also, i was testing behavior when a location code doesn't correspond with a workstation.
12:58 jeff JBoyer: did you already test or have thoughts on that?
13:00 collum joined #evergreen
13:01 JBoyer I know it fails in a similar fashion to other issues, such as an expired / missing Eg account, etc. I wasn't too worried about it at the time, but I don't see a problem with retrying sans workstation. The alternative is you just insert whatever workstations you need into your db if your clients force you to use a hard coded location. (seems unlikely)
13:03 Dyrcona Hmm.. I just did a fresh install of osrf_rel_2_4_1 from git on my Ubuntu 14.04 vm and osrf_control --start-all appears to hang.
13:28 jeff JBoyer: yeah, anything's possible in circ script days, but from what I can see neither stock nor our old MIEG circ scripts ever threw (that particular event) on checkout, just renew.
13:29 csharp berick: howdy - do you have a favorite Linux-installable or web-based EDI reader?
13:29 jeff JBoyer: the ability to use an org unit setting to block/permit renewal when "needed for a hold" was new in 2010.
13:29 berick csharp: I use Open-ILS/src/support-scripts​/test-scripts/edi_reader.pl
13:30 jeff it gets a little murky, but COPY_NEEDED_FOR_HOLD may have even been thrown at one point instead of "copy is on holds shelf". :-)
13:30 csharp berick: heh - I didn't know about that - thanks
13:30 berick csharp: spits out JSON that's fairly human-readable
14:08 gmcharlt Dyrcona: I've reviewed 1496556 and intend to backport it to rel_2_10 as part of today's release; are you in a position to also including that in the 2.9 release?
14:09 gmcharlt if so, I'll push it to both rel_2_10 and rel_2_9
14:09 Dyrcona Sure! Thanks!
14:10 * Dyrcona is still working on getting a working vm to test the tarball.
14:10 * Dyrcona hasn't made a tarbal, yet.
14:11 gmcharlt OK
14:13 pgardella left #evergreen
17:22 jeff this has raised two other issues which do not require me to stump the client vendor:
17:23 jeff 1) why is my SIPServer instance sometimes dropping its syslog ident, and 2) why is this SIP server returning N for acs renewal policy when it seems to be set to yet, and doesn't seem to have changed.
17:23 Dyrcona gmcharlt++
17:28 jeff oh wow. it's...
17:30 * jeff tests
17:34 jeff yup. my SIP server flips from a Y to an N for the acs renewal policy after the initial worker is reaped.
17:35 jeff and once that flips from Y to N, the on-screen renewal interface on this client changes from sending renew[29] to sending checkout[11]
17:39 Dyrcona jeff: The first part sounds like a bug. The second part sounds normal for an approximately reasonable definition of "normal."
17:40 * Dyrcona is about to find out if he installed everything on his laptop needed to make a tarball.
17:40 miker jeff: being no SIP2 expert, I would expect EG to treat a checkout to the same patron as a renew automatically in SIP context (via some API flag or name). but it sounds like my expectation is false...
17:43 * Dyrcona would not be surprised either way. :)
17:44 Dyrcona And apparently, yes, I did install the packager prereqs already.
17:44 jeff miker: a SIP2 checkout[11] message sent to evergreen will renew the item, as long as various conditions are met.
17:47 Callender_ joined #evergreen
17:47 jeff the SC needs to have sent renew_ok = Y, the Evergreen SIP implementation needs to think that the patron who has an open circ on the item is the same as the patron in the SIP checkout request, the institution config needs to have renewals set to true, etc.
17:48 jeff i don't much care if the sip client uses renew or checkout to do a renewal, it was just that in testing some fixes to the same-patron detection and "needed for hold" messages i was hitting one code path and other times not.
17:49 jeff thus, the shovel and large pile of dirt.
17:50 miker :)
17:50 miker but, a bug is found. so that's something.
17:50 jeff yes!
19:51 Dyrcona You should be able to move them with sudo.
19:51 gmcharlt gotcha
20:37 bmills joined #evergreen
20:52 pinesol_green Showing latest 5 of 7 commits to Evergreen...
20:52 pinesol_green [evergreen|Kathy Lussier] Docs: Adding 2.9.6 Release Notes - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=7f609d0>
20:52 pinesol_green [evergreen|Jason Stephenson] Docs: Adding 2.9.7 Release Notes - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=0f717f5>
20:52 pinesol_green [evergreen|Jason Stephenson] Docs: Add Additional 2.9.7 Acknowledgments for Testing/Signoff - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=66dfd05>
20:52 pinesol_green [evergreen|Galen Charlton] forward-port 2.9.6-2.9.7 schema upgrade script - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=dc0d286>
20:52 pinesol_green [evergreen|Galen Charlton] forward-port 2.10.5-2.10.6 schema update script - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=936fbc2>
20:57 Dyrcona gmcharlt++
20:59 gmcharlt https://evergreen-ils.org/everg​reen-2-9-7-and-2-10-6-released/
21:14 bmills joined #evergreen

Results for 2016-08-24

08:08 rlefaive joined #evergreen
08:13 JBoyer The rest were lost in the great desktop reimage of '16. Now they're mostly bugs I have a branch for myself.
08:15 JBoyer bug 1593834 is fairly low impact and will end the scourge of Android email clients assuming our mail is sent from the beginning of unix time.
08:15 pinesol_green Launchpad bug 1593834 in Evergreen "Date header not set in default A/T email templates" [Low,New] https://launchpad.net/bugs/1593834
08:15 pinesol_green [evergreen|Jason Stephenson] LP 1306666: Abort Transit Only Change Copy Status if In Transit - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=cfe5110>
08:15 pinesol_green [evergreen|Jason Stephenson] LP 1306666: Add Perl tests for new behavior. - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=5f1362f>
08:15 pinesol_green [evergreen|Mike Rylander] LP#1306666: Rename test file - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=d3e3f3b>
08:15 JBoyer (I was hesitant to set the milestone to anything but 2.next because I thought the RMs were doing that.)
08:16 rlefaive joined #evergreen
08:24 kmlussier joined #evergreen
08:27 miker JBoyer: I'd call that a bug fix, fwiw, but, I'm 'bout to merge it to master and 2.10
08:27 kmlussier I would like to advocate for bug 1612274 if somebody wants to look at it.
08:27 pinesol_green Launchpad bug 1612274 in Evergreen "Improvements to My Account Holds Screens" [Wishlist,Confirmed] https://launchpad.net/bugs/1612274
08:31 kmlussier I also wondered what the likelihood is of bug 1596595 getting in. I'm not in a position to test it myself since I would want to use a test system with production data, but we have a lot of interest in seeing faster holds targeting.
08:31 pinesol_green Launchpad bug 1596595 in Evergreen "Hold targeter features and refactoring" [Wishlist,New] https://launchpad.net/bugs/1596595
08:31 pinesol_green [evergreen|Jason Boyer] LP1593834: Add Date Header to A/T Email Examples - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=780f40a>
08:33 JBoyer miker, I suppose it's a seed data bug fix, the real benefit for existing installations is the brief documentation (if they don't follow LP).
09:19 Dyrcona I didn't look to see if we explicitly enable it, or the package is doing it, now.
09:19 kmlussier miker: Yes, I have time now.
09:19 miker kmlussier: cool. I'll push those bug fixes, then. thanks!
09:21 * Dyrcona will do his best to test the tz branch today, but time is not on his side.
09:21 pinesol_green [evergreen|Kathy Lussier] LP#1614807: Fix Circ History table header display on small screens - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=4c16071>
09:21 pinesol_green [evergreen|Kathy Lussier] LP#1614807: Holds history should look like other My Account screens - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=4e1ab37>
09:21 pinesol_green [evergreen|Kathy Lussier] LP#1614807: Fix spacing issues in responsive design for My Account screens - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=f414ddd>
10:28 pinesol_green [evergreen|Kathy Lussier] LP#1612274: Release notes for improved holds interfaces - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=36f3313>
10:29 miker dbwells: re bug 1315552, is http://git.evergreen-ils.org/?p=working/Everg​reen.git;a=shortlog;h=refs/heads/user/dbwells​/lp1315552_fix_duplicates_in_ranked_volumes the correct branch still?
10:29 pinesol_green Launchpad bug 1315552 in Evergreen "Duplicate initial search results where copy circ lib/call number owning lib are different" [Medium,Confirmed] https://launchpad.net/bugs/1315552
10:34 berick just updated to master.., upgrade/0990.data.copy-count-badge.sql not happy.  could be my janky test db..
10:34 berick ERROR:  null value in column "id" violates not-null constraint
10:34 berick DETAIL:  Failing row contains (null, Copy Count, null, rating.copy_count, f, f, t).
10:39 berick maybe id should be a SERIAL?
10:39 berick in rating.popularity_parameter
10:40 * berick has not been following that branch closely
10:49 kmlussier Oof. I guess I didn't test the upgrade script on that one.
10:49 miker berick: I'll fix it. it needs to be a pinned ID
10:50 * berick nods
10:51 miker pushed
10:51 miker berick: thanks for testing!
10:54 pinesol_green [evergreen|Mike Rylander] Correct upgrade script - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=58fc8f0>
11:06 akilsdonk joined #evergreen
11:07 Stompro Does anyone know off the top of their heads if meta holds not showing up in catalog hold counts is expected behavior?  I tried to find a bug report on that, to see if anyone had suggested changes in that area, but didn't find anything.  Is that configurable?
12:02 pinesol_green [evergreen|Mike Rylander] Stamping upgrade script for ranked-volumes update - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=51759b2>
12:04 rlefaive joined #evergreen
12:10 miker berick: I've signed off your commits to the is_available branch ... want to look at the branch one last time, or are you happy with it?
12:10 berick miker: i'm happy with it.  did a few more tests this a.m.
12:11 berick gracias
12:12 miker kk
12:12 berick miker: did you see the comment on bug #1588948 I added just before you posted your code?
12:12 miker grabbing 0992
12:12 pinesol_green Launchpad bug 1588948 in Evergreen "Authority update propagation should update bib record editor and edit_date" [Undecided,New] https://launchpad.net/bugs/1588948
12:14 miker berick: update_headings_tgr is a BEFORE trigger, and aaa_auth_ingest_or_delete is an AFTER, so they run in the right order already
12:14 berick miker: oh!  nevermind then
12:14 berick thanks
12:15 berick i'll test that branch
12:15 miker (I had the same thought, so doublechecked when looking for the best place to insert the check)
12:15 jihpringle joined #evergreen
12:22 pinesol_green Showing latest 5 of 7 commits to Evergreen...
12:36 miker ok, thanks.  I'm calling it a feature for backporting purposes, then :)
12:38 miker grabbing 0993
12:42 csharp miker: if my branch for bug 1612752 gets accepted, it would theoretically be possible to "unwrap" the status on canceled transit checkin too, right?
12:42 pinesol_green Launchpad bug 1612752 in Evergreen "Feature Request: Cancel Transits, Don't Delete Them" [Wishlist,Confirmed] https://launchpad.net/bugs/1612752 - Assigned to Chris Sharp (chrissharp123)
12:42 pinesol_green [evergreen|Bill Erickson] LP#1570909 User activity transient default - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=b1f4d59>
12:42 pinesol_green [evergreen|Bill Erickson] LP#1570909 User activity purge function - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=ea8b2ae>
12:42 pinesol_green [evergreen|Bill Erickson] LP#1570909 User activity purge pgtap test - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=fc5b3ec>
12:42 pinesol_green [evergreen|Bill Erickson] LP#1570909 User activity purge release notes - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=cfad22b>
12:42 pinesol_green [evergreen|Mike Rylander] Stamping upgrade script for transient usr_activity - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=95ea3d5>
12:43 miker csharp: not sure I follow.  If an item got into Canceled Transit, and then transited (was scanned somewhere) the transit home would carry the Canceled Transit status and the copy would end up with that until a user did something about that ... is that what you mean?
12:44 miker (that's the case regardless of whether we restrict the situations we make use of Canceled Transit, though)
12:45 miker ah, you mean "the data still exists because it's on a closed transit"
12:59 csharp I was trying to keep the features separate in case one didn't get accepted, the other still had a chance
12:59 bmills joined #evergreen
13:00 miker I'm concerned that we'd be trading confusion for (effectively, to the user) lost data, unless we have something that pulls the old status from the canceled transit and uses that for any /new/ transit. which, I think, would fix the issue for remote aborts that re-transit.
13:00 pinesol_green Showing latest 5 of 6 commits to Evergreen...
13:00 pinesol_green [evergreen|Bill Erickson] LP#1588948 Authority propagation PGTAP test - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=7605ed8>
13:00 pinesol_green [evergreen|Bill Erickson] LP#1588948 Release notes (auth prop. bib edit[or|_date]) - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=8e95974>
13:00 pinesol_green [evergreen|Bill Erickson] LP#1588948 Auth propagate bib meta on change only - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=d61a652>
13:00 pinesol_green [evergreen|Mike Rylander] LP#1588948: Only attempt a bib update if the heading changes - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=84bed71>
13:00 pinesol_green [evergreen|Mike Rylander] Stamping upgrade script for authority edit changes and propagation improvement - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=1215938>
13:07 serflog joined #evergreen
13:07 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
13:08 jyorio joined #evergreen
13:09 tarac_ joined #evergreen
13:34 berick kmlussier: thanks for testing bug #1497335.  investingating now...
13:34 pinesol_green Launchpad bug 1497335 in Evergreen "Display aged circulations for copies (was: "virtually aged circulations")" [Wishlist,New] https://launchpad.net/bugs/1497335
13:35 * berick will also rebase
13:36 kmlussier berick: Thanks!
13:36 kmlussier Unfortunately, I can't test it in the web client at the moment.
13:37 csharp miker: I'm looking to change my canceled transit status branch (bug 1613374) so that it checks the stored copy status... how much time do I have before you call the beta done? :-)
13:37 pinesol_green Launchpad bug 1613374 in Evergreen "Feature Request: "Canceled Transit" Item Status" [Wishlist,Confirmed] https://launchpad.net/bugs/1613374 - Assigned to Chris Sharp (chrissharp123)
13:39 miker csharp: commit by EOB today, or whenever level3 decides to stop having problems, whichever comes later ;)
14:53 Stompro sandbergja, You are welcome.  Let me know if you have any problems with it.  You need the asset.call_number.id and the new label name as arguments.
14:55 csharp miker: ah... that's better
14:55 miker grabbing 0995
14:56 csharp okay, I've pushed a commit on top of my fix for bug 1613374 and I want to test it with mmorgan's testing method before calling it done, but I'm letting others know in case they want to look/test after me
14:56 pinesol_green Launchpad bug 1613374 in Evergreen "Feature Request: "Canceled Transit" Item Status" [Wishlist,Confirmed] https://launchpad.net/bugs/1613374 - Assigned to Chris Sharp (chrissharp123)
14:57 pinesol_green [evergreen|Mike Rylander] Moving function creation to later in the schema def, where its deps exist. - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=9fc0603>
14:57 pinesol_green [evergreen|Kathy Lussier] LP#1614290: Add badge_score_generator to example crontab - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=fd725a7>
15:21 mmorgan1 joined #evergreen
15:31 pinesol_green [evergreen|Ben Shum] LP#1603708: Remove support for Ubuntu 12.04 Precise - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=be0ed35>
15:58 kmlussier joined #evergreen
16:04 * kmlussier needs to leave and won't be able to test https://bugs.launchpad.net/evergreen/+bug/1497335/ again if berick is able to incorporate the changes he made in his last comment. If anyone else has tuits to look at it, feel free!
16:04 pinesol_green Launchpad bug 1497335 in Evergreen "Display aged circulations for copies (was: "virtually aged circulations")" [Wishlist,New]
16:06 csharp miker: bug 1613374 looks good to me after some poking
16:06 pinesol_green Launchpad bug 1613374 in Evergreen "Feature Request: "Canceled Transit" Item Status" [Wishlist,Confirmed] https://launchpad.net/bugs/1613374 - Assigned to Chris Sharp (chrissharp123)
18:35 pinesol_green [evergreen|Bill Erickson] LP#1497335 Aged circ display release notes - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=5769707>
18:35 pinesol_green [evergreen|Bill Erickson] LP#1497335 Show Last Few Circs patron retrieve options - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=3f2d3a0>
18:35 pinesol_green [evergreen|Mike Rylander] Stamping upgrade scripts for aged circs display branch - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=15ad6d4>
18:42 miker and ... that's it, folks.  I think I've merged anything that was ready to be merged and was a feature.  the remainder are bug fixes, or are in some way not complete or well tested enough (given their relative invasiveness).  Now, on to bug fix merging (not today)!
18:42 * miker calls beta locked for features
18:44 Dyrcona joined #evergreen
19:05 gsams joined #evergreen
19:06 Dyrcona miker: If you're still around, what do you think of bug 1583608?

Results for 2016-08-23

09:47 csharp heh
09:55 berick kmlussier: no backsies
09:55 kmlussier berick: Ha ha. I guess I should get working then!
10:39 * mmorgan always seems to find more bugs when testing bugs.
10:39 bshum Testing bugs or testing bug fixes?   :P
10:40 Dyrcona Both! :)
10:40 mmorgan :)
10:43 maryj joined #evergreen
12:03 mrpeters joined #evergreen
12:05 rlefaive joined #evergreen
12:06 jihpringle joined #evergreen
12:17 csharp mmorgan: I think it's good for now - I was just about to look into creating a perl test for the branch - I'll prolly need help :-)
12:23 csharp Dyrcona: I think I remember you mentioning that you might genericize your live_t for bug 1306666 for general transit testing - looking at it now, I tend to agree
12:23 pinesol_green Launchpad bug 1306666 in Evergreen 2.9 "When Aborting a Transit, items should not automatically get a status change." [Low,Confirmed] https://launchpad.net/bugs/1306666
12:23 Dyrcona csharp: Part of the reason it is so long is that this feature had no tests.
12:24 csharp right, I can see that
12:24 Dyrcona It needs to be in live_t because it requires concerto for copies, patrons, etc.
12:24 bshum 100.00% spanish translation; 0 strings remaining.  Sweet!  (at least till we do the next POT sync up from all the stuff that went into master)
12:24 Dyrcona I got hung up getting the copy to transit again after the hold transit was aborted by the receiving library.
12:25 csharp anahi++
12:26 Dyrcona I think my vm is presently rigged for the timezone branches, so I'll need to reinstall the code for that branch to continue working on it.
12:26 Dyrcona Anyway, csharp, if you want help with Perl tests, let me know.
12:27 jeff Dyrcona: did you determine what your TZ issues were the other day?
12:27 csharp Dyrcona++ # thanks
12:28 mmorgan csharp: Thanks. It's looking good to me so far.
12:30 Dyrcona I think I'll build a fresh vm and install everything again.
12:30 Dyrcona But that's for later. I have to go, now.
12:46 bmills joined #evergreen
12:59 jeff Dyrcona: when you get back... in your testing were you seeing holds being created hours in the past / future, or were you just seeing action.hold_request.request_time displayed with the server TZ of +00?
12:59 jeff Dyrcona: because the latter should be fine...
13:07 jeff Dyrcona: holds might not be the best thing to test with.
13:07 jeff but that does open the question of "how should this be tested". :-)
13:08 jeff I don't think that anything in 1485374 adds support to xul or web staff clients to pass timezone to the server.
13:12 jeff oh, actually... webstaff is probably covered by the changes in 1485371, the opensrf companion to that bug.
13:12 csharp oooh - perl tests go deep
13:13 * csharp stares in awe at https://metacpan.org/pod/Test::More
13:15 csharp Dyrcona: since your test is almost exactly what I need, any objections about me using it outright and modifying where necessary?
13:15 csharp seems like we would benefit from having some solid boilerplate files for this kind of thing
13:16 csharp or a set of custom functions (e.g., create a workstation at a branch/some branches)
13:18 csharp ah - OpenILS/Utils/TestUtils.pm has that stated purpose at the top of the file :-)
14:31 ericar_ joined #evergreen
14:54 tspindler joined #evergreen
14:56 tspindler Dyrcona: running apt-install and apt-update worked and ./configure --prefix=/openils --sysconfdir=/openils/conf executed
16:00 Dyrcona :)
16:02 Dyrcona One draw back of the way that I build vms for Xenial is that I have to login with virt-viewer or the other console to reconfigure the network interface.
16:03 Dyrcona All right, I'll start over on the timezone branch with everything clean.
16:14 jeff Dyrcona: did you see my earlier comments about that, and asking what exactly was looking incorrect in your test?
16:15 Dyrcona Yes, did you see my answers?
16:15 Dyrcona The server on a vm is UTC. The client, my laptop, is EDT.
16:15 * jeff scrolls up for answers
16:16 Dyrcona I thought when I placed a hold from the OPAC, it would get the EDT timezone, but the database shows UTC.
16:16 Dyrcona So, maybe I misunderstand the intent, or I had something wrong.
16:16 Dyrcona That's why I'm going with a clean install on a clean VM, to make sure there's no crud interfering.
16:16 jeff 09:59:09 < jeff> Dyrcona: when you get back... in your testing were you seeing holds being created hours in the past / future, or were you just seeing action.hold_request.request_time displayed with the server TZ of +00?
16:17 Dyrcona I missed that one. :)
16:17 jeff heh.
16:17 Dyrcona The timestamp on the hold was good, just UTC, not EDT.
16:17 Dyrcona Meaning, it was four hours in the future.
16:17 Dyrcona Right.
16:18 Dyrcona I'll reread the bug more carefully and check the code.
16:18 jeff 10:07:07 < jeff> Dyrcona: holds might not be the best thing to test with.
16:18 jeff 10:07:27 < jeff> but that does open the question of "how should this be tested". :-)
16:18 Dyrcona I'm going to install opensrf master and collab/miker/lp1485374-always-use-client-tz-rebase
16:18 Dyrcona Yep.
16:19 Dyrcona I'll take a deeper look this time.
16:26 jeff Dyrcona: the important part is that they be the correct value... which i'm pretty sure will be the case for a hold request with and without the timestamp support.
16:26 jeff i've been looking at it, but don't want to be the only one looking at it. :-)
16:27 Dyrcona So, I should try something like changing a due date where there are reports of times being wrong?
16:27 jeff so, my comment about holds might not be the best thing to test with.
16:27 * jeff nods
16:27 Dyrcona Right.
16:27 jeff pretty sure that will be a better before/after test.
16:27 Dyrcona Thanks. I'll do that, also.
16:28 jeff there are other things that will be interesting (nothing new), like dob.
16:28 Dyrcona Guess I'll build a xul client and the browser staff client.
16:28 jeff i don't know if the xul client will get benefit of timezones.
16:28 Dyrcona Well then, I'll skip it.
16:28 Dyrcona I haven't been building xul clients for the vms on my laptop.
16:29 jeff web staff client gets it by nature of opensrf.js having support added in the OpenSRF bug (code in master), but I don't think (haven't looked/tested) that benefits the XUL client.
16:29 jeff some embedded interfaces might get it.
16:29 Dyrcona It probably doesn't.
16:29 Dyrcona Maybe a dojo interface or two, yeah.
16:34 Dyrcona Hmm. It might be interesting to get opensrf.js working with node... Then you could write command code for Evergreen in JavaScript.

Results for 2016-08-22

09:09 csharp ah
09:09 bos20k joined #evergreen
09:10 * tsbere is also working on "bulk cleanup" commands, such as standardizing states to their uppercase abbreviations. Or at least the most common ones in our DB.
09:10 * csharp finally buckles down to test Dyrcona's and miker's fix to bug 1306666 since it's probably a dependency for his fix to bug 1613374
09:10 pinesol_green Launchpad bug 1306666 in Evergreen 2.9 "When Aborting a Transit, items should not automatically get a status change." [Low,Confirmed] https://launchpad.net/bugs/1306666
09:10 pinesol_green Launchpad bug 1613374 in Evergreen "Feature Request: "Canceled Transit" Item Status" [Wishlist,Confirmed] https://launchpad.net/bugs/1613374 - Assigned to Chris Sharp (chrissharp123)
09:13 * tsbere isn't sure if he should include misspellings of states in his corrections <_<

Results for 2016-08-20

12:51 gsams joined #evergreen
12:51 Dyrcona Not until after I changed the capture time on the hold, which puzzles me.
12:54 Dyrcona I'll do some more experimentation later. I'd like to see the real differences in what's going on for myself.
12:54 miker the change that let it work was the hold getting retargeted
12:55 miker after the copy became available or equivalent
12:59 miker if the problem to solve is "don't break circs" then the first "if" test in my branch is enough. if the problem is "staff are confused" the the status dance is needed. but the status dance kills immediate recapture via op-capture because the hold gets retargeted after the copy becomes untargetable
13:01 miker if we add the canceled-transit status, per csharp, and allow it to be holdable, op-capture will work as before
13:01 miker on top of my branch, I mean
13:03 miker I think we'll really want berick's is_available branch, too, and make the new status true for that flag
13:03 miker otherwise we'll get warnings at the eventual hold dest
13:03 Dyrcona Hmm. What you're saying makes sense, but I'm not sure that it completely supports what I think I saw. :)
13:04 Dyrcona I'll do some looking later.
13:04 miker k
13:45 Dyrcona Missing comma on line 667 of oils_auth.c.
13:46 miker huh. must have missed that in a conflict on rebase. soory :)
13:47 Dyrcona NP.
14:28 Dyrcona Hmm. I'm not really certain how to test that branch. I tried placing holds from the OPAC, but the times are in UTC.
14:29 Dyrcona I tried a SetENV TZ America/New_York in the Apache config for the /opac location and restarted, but that didn't seem to do anything either.
14:48 bmills joined #evergreen
15:10 csharp_ I was just going to finally comment out the PINES reporting views by default in fm_IDL.xml, but I can see that other non-PINES tables have been added to the PINES section

Results for 2016-08-18

10:27 Dyrcona Oh, wait. Failures started before that test. ;)
10:29 Dyrcona OK. Failures start at subtests of test 13, which is more or less where I might expect it.
10:29 * Dyrcona makes a collab branch based on miker's changes.
10:30 Dyrcona Test 14, rather.
10:30 * Dyrcona can't read today, apparently.
10:47 Christineb joined #evergreen
10:52 * miker tests new tz branch...
10:59 * Dyrcona "numbers" the tests in the test script.
11:05 rlefaive_ joined #evergreen
11:06 Dyrcona I think I'm going to remove the lp number from the test file, because csharp will need to alter the tests for the new copy status branch.
11:07 Dyrcona Eh, maybe I'll leave it for now and we can sort it out later.
11:07 JBoyer "rm it all and let the fs sort it out."
11:10 miker Dyrcona: updated TZ branch for evergreen located at http://git.evergreen-ils.org/?p=working/Eve​rgreen.git;a=shortlog;h=refs/heads/collab/m​iker/lp1485374-always-use-client-tz-rebase
11:10 Dyrcona miker++ # I'll take a look after working on these tests.
11:25 csharp @quote add < JBoyer> "rm it all and let the fs sort it out."
11:25 pinesol_green csharp: The operation succeeded.  Quote #158 added.
11:35 bmills joined #evergreen
11:58 Dyrcona It has been checked in twice at the home library and doesn't fill the hold again after either one.
11:59 berick should name the canceled transit copy status "stranded" or "stuck at O'Hare"
11:59 mmorgan Even after you changed it to available?
11:59 Dyrcona I haven't tried that yet. I have to reload concerto after each failed test run.
12:00 Dyrcona I'm first going to verify the copy status in the tests after each step.
12:03 kmlussier joined #evergreen
12:04 brahmina joined #evergreen
12:12 bmills joined #evergreen
12:17 miker in case anyone was talking in my direction
12:18 miker yeah, quassel core is acting up a lot recently...
12:23 bshum Poor quasselcore :(
12:23 Dyrcona I was just speaking in general how holds appear to be trapping differently for me in concerto today and it's more or less the same branch when the tests all passed before.
12:23 Dyrcona I'm trying tricks to see what I need to do.
12:24 Dyrcona A script to stop services, reload concerto into the db, and start services again has come in real handy.
12:25 tsbere Dyrcona: Heh, I have a bash alias to do that for me on my dev machine. :D
12:26 * dbs wonders if Dyrcona is finding out why our holds aren't getting trapped at checkin -- this is the TZ testing?
12:28 Dyrcona dbs: It could be, but I'm doing it all on the server where everything is UTC.
12:29 Dyrcona Maybe it was EDT last time.... I believe I did make a new VM since then.
12:29 Dyrcona It traps the first time, but after aborting the transit and checking the copy in again, it's not trapping.

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 144 145 146 147 148