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
| 10:05 | Dyrcona | Bmagic: When I need to tune a Pg installation, I usually spend days pouring over wiki pages and conference slides, and then twiddle things until it is "fast enough." |
| 10:05 | csharp | Bmagic: do you have more than one RAID controller? |
| 10:05 | csharp | Dyrcona: that's my current method too ;-) |
| 10:05 | Bmagic | Dyrcona: what method do you use to test speed? |
| 10:06 | tsbere | JBoyer: For reference, I found that "search in their system" and "login to their system" didn't play nice together in the same link. So I skipped the "search" part. |
| 10:06 | csharp | Bmagic: http://www.postgresql.org/docs/9.3/static/runtime-config-connection.html and following explain every setting in pretty good detail |
| 10:06 | Dyrcona | Bmagic: None that's worth mentioning. |
| 10:07 | Bmagic | csharp: ty |
| 10:07 | Dyrcona | I might time some scripts, etc. |
| 10:08 | JBoyer | I'd like to someday pull an entire day's worth of queries from the logs, keep the dump from that day; clean up any that don't play nice, then see how long it takes to replay that day on a fresh reload. It would be easy to see how big an impact settings changes make across that level of activity. It's more difficult to improve everything when you can only really test this or that slow query. |
| 10:08 | csharp | Bmagic: check 'top' for high wait when things are slow - it might mean you need to reevaluate your disk setup - we're on SSDs now, but when we were on spinning disks, adding a second RAID controller solved all our problems |
| 10:08 | Bmagic | csharp: changing hardware isn't in the cards right now. The fact is, 9.2 was faster |
| 10:08 | Bmagic | on the same hardware |
| 12:22 | geoffsams joined #evergreen | |
| 12:31 | bmills joined #evergreen | |
| 12:34 | jihpringle joined #evergreen | |
| 12:51 | Dyrcona | @decide make new test accounts or crack passwords on existing test accounts? |
| 12:51 | pinesol_green | Dyrcona: go with crack passwords on existing test accounts? |
| 12:56 | RoganH | Clearly that would take less time. Or at least be less tedious. One of those. |
| 12:58 | Dyrcona | Assuming that the majority of the test accounts have four digits for the password, yes. |
| 12:58 | Dyrcona | And by test account, I mean "not real patrons used for testing purposes." |
| 13:02 | Dyrcona | And now, I apparently don't have to.... |
| 13:03 | Dyrcona | We apparently already sent this information, and I was just given the spread sheet that was sent previously. |
| 07:49 | Stompro joined #evergreen | |
| 08:07 | ericar joined #evergreen | |
| 08:09 | JBoyer joined #evergreen | |
| 08:25 | csharp | Bmagic: regarding DB differences between 2.8.2/2.9.1 and autosuggest, what's more likely (from our experience with moving to 9.3 and 9.4) is that the query planner in postgres is working differently than before - if you have (or can assemble) a test server with the old version of EG/PG, you might be able to track the difference in the queries created - then it's a matter of DB and EG query tuning |
| 08:43 | mmorgan joined #evergreen | |
| 08:46 | mrpeters joined #evergreen | |
| 09:05 | Dyrcona joined #evergreen | |
| 09:38 | Dyrcona | Wonder if it did that yesterday and I missed it. |
| 09:38 | Dyrcona | kmlussier: Thanks! |
| 09:40 | Dyrcona | I don't really have time to sort this right now. I'd have to do a clean install. It could be something going on with running the scripts twice. |
| 09:47 | JBoyer | Dyrcona: Does it have that problem with just grunt build, or only grunt all? Skipping the tests may not be ideal, but if it gets things moving on your test server it could always be investigated later. |
| 09:48 | Dyrcona | JBoyer: Good question, and if I knew enough about it, I would have tried that before blowing out the VM and building a fresh one. :) |
| 09:48 | Dyrcona | JBoyer: Don't think I'm intelligent. I am only a bot following a script. :) |
| 09:49 | * Dyrcona | is a total newb when it comes to Node.js and friends. |
| 11:31 | pinesol_green | kmlussier: I am only a bot, please don't think I'm intelligent :) |
| 11:48 | berick | dbwells: fix pushed. I'm working on a follow up patch to make some things more efficient. specifically, reduce the number of times we have to look up the root unit unit ID from the database and use cstore instead of storage for perm checks. |
| 11:48 | berick | the API call will get (intentionally) slower w/ bcrypt, so may as well make some other parts faster/leaner |
| 11:49 | Dyrcona | JBoyer: grunt build works. Guess it is a test that fails. |
| 11:55 | JBoyer | That's good. (for certain values of good...) The specific test that I had fail on me was somehow related to our fmIDL.xml file and either permissions or paths, so I wasn't too worried about it at the time, |
| 11:55 | JBoyer | . |
| 11:56 | Dyrcona | kmlussier: FWIW, my dev vm is running with the branches we discussed. |
| 11:56 | kmlussier | Dyrcona: Great, thank you! |
| 10:18 | * csharp | just turned 42 - so far everything is just as mysterious as before |
| 10:20 | * Dyrcona | is *mumble* *mumble* years old.... |
| 10:23 | jwoodard joined #evergreen | |
| 10:47 | csharp | hmm - looks like the new hold_request_capture_protect_idx index is preventing item checkin with no useful errors to the end user |
| 10:48 | csharp | duplicate key value violates unique constraint "hold_request_capture_protect_idx" - DETAIL: Key (current_copy)=(14779072) already exists. |
| 10:48 | csharp | seems like something the application layer should be testing before it tries to update the hold row |
| 10:49 | csharp | rather than failing gracelessly |
| 10:51 | csharp | 32e415a2 |
| 10:51 | pinesol_green | [evergreen|Mike Rylander] LP#902255: Protect against hold double-capture - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=32e415a> |
| 10:51 | csharp | hmm |
| 10:51 | * csharp | checks that util.js and circ.properties is up-to-date |
| 11:27 | kmlussier | I may have misunderstood, but I didn't think the code in question only comes into play for asynchronous checkin. It was just higlighted as one occurance where double capture can happen. |
| 11:28 | pinesol_green | [evergreen|Jason Stephenson] Forward port 2.9.0 to 2.9.1 db upgrade script. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ea474a9> |
| 11:29 | csharp | kmlussier: yeah, I'm asking them to try with the checkbox unchecked, but it still looks like there's some bugaboo lurking there |
| 11:29 | kmlussier | Yeah, looking at my notes on bug 902255, I was able to replicate the bug without asynchronous checkin being selected. In testing, the user-friendly error message did appear. |
| 11:29 | pinesol_green | Launchpad bug 902255 in Evergreen "possible to double-scan an item during check-in and have it captured by two holds" [Low,Fix released] https://launchpad.net/bugs/902255 |
| 11:31 | csharp | kmlussier: your comment #7 there is exactly what was reported to m |
| 11:31 | csharp | e |
| 15:45 | Bmagic | jeffdavis: I wonder why we didn't have this problem on 9.2 ? |
| 15:47 | jeffdavis | We figured it had more to do with needing to vacuum after the PG+EG upgrade. |
| 15:48 | jeffdavis | Hard to say, though. At least I don't think we had any definitive evidence of our conclusion. |
| 15:51 | csharp | more info on that unapi.bre error - all I've seen and tested appear to be kid's titles, so the KPAC is suspect |
| 15:51 | csharp | @blame kpac |
| 15:51 | pinesol_green | csharp: kpac forgot to give the gerbils their chocolate-frosted sugar bombs |
| 15:58 | dbwells | berick: Got the validate bits in place for AuthProxy.pm. I pushed it (plus your latest fix) out to production here locally, and am going to let it chill for a bit before pushing back to the collab branch. At this point in the day, probably going to be tomorrow. |
| 15:59 | Bmagic | jeffdavis: now that I am looking at config.tt2 I dont see where to turn off autosuggest. I would have expected to see the setting there. where is use_autosuggest.enabled ? Should I just set that variable in config.tt2? |
| 09:11 | Dyrcona | mdriscoll: That's interesting. We were talking about something similar this morning... |
| 09:11 | jboyer-isl | Ah, we're going to be leaning toward extracts/uploads with Z for availability. |
| 09:12 | Dyrcona | mdriscoll: I'll share the branch in a few minutes. |
| 09:12 | mdriscoll | Dyrcona: great I'll test it. |
| 09:14 | yboston joined #evergreen | |
| 09:16 | Dyrcona | And the search that was mentioned as a problem "harry potter rowling" works. |
| 09:19 | mdriscoll | Here's another z39.50 search with punctuation: Monsters inc (CW-9, NOBLE-3, MVLC-594) |
| 10:30 | berick | https://bugs.launchpad.net/evergreen/+bug/1384740 |
| 10:30 | pinesol_green | Launchpad bug 1384740 in Evergreen "Add authority records support to marc stream importer (Connexion)" [Wishlist,Fix committed] |
| 10:30 | berick | it's in master |
| 10:31 | jboyer-isl | berick: Huzzah! Apparently not in the 2.9.cough version I upgraded us to, but we would be happy to apply some additional in-production testing. :D |
| 10:32 | berick | awesome. we've been using the updated script for bib imports. planning to use it for auth soon. |
| 10:34 | jboyer-isl | One of your comments referenced bug 1171984 that was released sometime in 2.8, does that mean anything needs to be changed to address it, or did the options just not do anything until that bug was closed? |
| 10:34 | pinesol_green | Launchpad bug 1171984 in Evergreen "add support in Vandelay for overlaying authorities during import using match sets" [Wishlist,Fix released] https://launchpad.net/bugs/1171984 |
| 11:07 | yboston | remingtron: thanks |
| 11:08 | yboston | yboston: y por cierto muchas felicidades con lo de de tu familia |
| 11:09 | yboston | remingtron: y por cierto muchas felicidades con lo de de tu familia |
| 11:21 | rjackson_isl | berick++ - first import using patched importer and correct parameters worked - next test will be the authority side |
| 11:22 | rjackson_isl | inclued both an overlay and new recs in one imput file... |
| 11:22 | rjackson_isl | s/inclued/included |
| 11:23 | berick | sweet |
| 11:24 | jboyer-isl | Bummer. A parallel reingest is no sweat for the database, but slony does not like it one bit. :-/ |
| 11:25 | Dyrcona | Alas, poor Slony. I knew him well, Horatio. |
| 16:48 | kmlussier | Dyrcona: I was thinking it might be first by database ID. Because Magazine is not first alphabetically on webby |
| 16:48 | kmlussier | Dyrcona: Oh, so that's a problem. |
| 16:48 | kmlussier | We need an Unset there. |
| 16:48 | jihpringle | yboston: I ran into a few bugs while testing, do you know what the best way to report web client bugs is? |
| 16:48 | Dyrcona | Well, you should be able to add a copy without a circ modifier, I think. |
| 16:48 | * kmlussier | wanders off to Launchpad. |
| 16:49 | kmlussier | And this is why it always takes me so long to work on documentation. :) |
| 17:12 | mmorgan left #evergreen | |
| 17:37 | kmlussier | jihpringle: For bug 1537227, the problem is that you aren't using a registered workstation. |
| 17:37 | pinesol_green | Launchpad bug 1537227 in Evergreen "Web Client: Navigation Buttons in Catalogue Not Working" [Undecided,New] https://launchpad.net/bugs/1537227 |
| 17:38 | kmlussier | We came across that one in testing. |
| 17:38 | jihpringle | kmlussier: thanks, I thought it seemed familar |
| 17:38 | kmlussier | Which is why it's really, really important that we have a way to require workstation registration before the web client is rolled in production. There are several things that don't work as expected without a workstation. |
| 17:39 | jihpringle | yes, that;s definitely crucial |
| 13:31 | mllewellyn | IF VENDACCT == '336033V' AND VENDCODE == '1084'; ORG_UNIT_SAN = '336033V'; END; |
| 13:32 | mllewellyn | I can't figure where this LOC thing comes in. |
| 13:32 | berick | mllewellyn: oh! I should have finished reading.. |
| 13:33 | mllewellyn | I wish it were the SAN issue. :( |
| 13:35 | mllewellyn | From our test order. They added the LOC line to show me what they're expecting. |
| 13:35 | mllewellyn | UNB+UNOB:3+336033V:31B+1556150:31B+160113:1310+1' UNH+1+ORDERS:D:96A:UN' BGM+220+21423+9' DTM+137:20160113:102' NAD+BY+336033V 1084::91' NAD+SU+1556150::31B' NAD+SU+2563::92' CUX+2:USD:9' LIN+420651++6315949045:IB' PIA+5+6315949045:IB' IMD+F+BTI+:::Cinderella' IMD+F+BPU+:::Walt Disney Pictures,' IMD+F+BPD+:::2015.' IMD+F+BPH+:::1 videodisc (112 min.) ' QTY+21:5' GIR+001+BRDGOM:LLO++1:LQT+acquisitions:LST+ |
| 13:37 | berick | mllewellyn: hm, we use the LCO (copy id) field, but I don't recall using LOC |
| 13:38 | * Dyrcona | misspoke earlier. I don't have to strip quotes off the term. I misunderstood my error. :) |
| 13:38 | mllewellyn | This is for Enriched AV processing. |
| 15:22 | kmlussier | Yikes. Yeah, record buckets can only handle so many records. |
| 15:23 | phasefx | might be better in the web client with paging |
| 15:23 | Stompro | phasefx, thanks, I wasn't finding anything but wanted to double check. I need to change the item_type on 20K large print titles and I'm just trying to find the best way. I was going to try and use the marc batch edit function. |
| 15:23 | kmlussier | phasefx: You said xul client. Is there hope there will be improvement in this respect in the web client? My webby testing has been limited to buckets with 50 records. |
| 15:23 | Dyrcona | And, that is why I write so many custom scripts. |
| 15:23 | miker | if you just use them for container searches, never accessed as a list, that could be useful |
| 15:23 | phasefx | kmlussier: I think there's always hope. Not sure what the current performance is with webby |
| 14:12 | krvmga | me, too |
| 14:12 | yboston | we can swithc to that in a second. I had a goal to talk a bit about the web client hacking and we already spoke a little abotu it |
| 14:13 | sandbergja_ | sounds good to me |
| 14:13 | yboston | liek I said I will send out a link in the morning. I will also start a Google hangout in the morning |
| 14:13 | yboston | the wiki page will have login info for a test serve that can be used to document the web client |
| 14:14 | yboston | #link https://webby.evergreencatalog.com/eg/staff/ |
| 14:14 | dluch joined #evergreen | |
| 14:14 | yboston | I think that is about it. We might want to check in the morning to verify what everyone will work on |
| 14:15 | yboston | at this point we can switch to talking about the re-org |
| 14:16 | yboston | #topic docs re-org |
| 14:16 | yboston | go ahead |
| 14:16 | sandbergja_ | I think that there was a lot of excitement when we talked about it on the mailing list |
| 14:17 | krvmga | when i originally talked about this idea, i was thinking of "books" for different staff |
| 14:17 | yboston | #link http://wiki.evergreen-ils.org/doku.php?id=evergreen-docs:reorg_2014 |
| 14:34 | sandbergja_ | yes, yboston++ |
| 14:34 | dluch | yes! yboston++ |
| 14:35 | sandbergja_ | how hard would that be to achieve technically? |
| 14:35 | yboston | #idea use the new re-org layout for storing the new web client docs |
| 14:36 | yboston | my rough understanding is... |
| 14:36 | yboston | that Robert Soulliere would need to do some config set ups on his docs server |
| 14:36 | yboston | to handle a new set of templates for the new re-org |
| 14:37 | yboston | though we might want to have a final decision on the re-org style before we start this, though we can just do soemtests |
| 14:37 | yboston | *some tests |
| 14:38 | yboston | in some ways it might not be that differnt from when Robert set ups the docs foreach new version of EG |
| 14:39 | yboston | lets talk about sandbergja_ list of concers, which are very important |
| 14:39 | yboston | 1) when to meet next 2) how to get more people involved |
| 14:40 | yboston | I added 3) what risks shoudl we address, I would also add 4) do we have a final re-org that we can follow |
| 14:40 | sandbergja_ | I feel like we got some consensus around (1) |
| 14:40 | yboston | any other cocnenrs or ideas that we should keep in mind, that perhaps sandbergja_ and I can add to the re-org page in preparation for the eventual re-org meeting? |
| 14:41 | krvmga | i have no others atm |
| 07:47 | ericar joined #evergreen | |
| 08:12 | collum joined #evergreen | |
| 08:30 | Dyrcona joined #evergreen | |
| 08:33 | jboyer-isl | Anyone around who can remind me (if we have) our policy on the pullrequest tag on LP? Wait for outside testing confirmation first, or apply when there's a branch ready to test? |
| 08:36 | Dyrcona | jboyer-isl: Put it on when you have a branch ready to test. |
| 08:36 | jboyer-isl | That's what I figured, thanks Dyrcona. |
| 08:37 | Dyrcona | Branches sometimes get pushed without the bug ever being confirmed. |
| 08:38 | * Dyrcona | deals with the aftermath of having changed his email password. |
| 14:27 | jeff | it's also why patrons with max items out get charge_ok set to N and can't use a 3M selfcheck |
| 14:27 | Bmagic | I see, so it's by design |
| 14:28 | Bmagic | presumably, if the patron didnt have any penalties, they would be able to renew |
| 14:28 | jeff | i'd test to confirm that's what you're running into. |
| 14:28 | Bmagic | I will remove the penalty and try to renew, just a minute |
| 14:28 | jeff | and i wouldn't say "by design" |
| 14:29 | jeff | it's just that penalties have become more nuanced and granular, and there's room for improvement in the SIP code now. |
| 16:26 | tsbere | jeff: Basically, if the holdable *flags* say "no" it doesn't put them in. But it doesn't run the hold *rules* for every copy before putting them in the map. |
| 16:27 | tsbere | So a holdable false copy, location, or status means "no map created". The copy always hitting "not holdable" in the hold matrix won't stop maps from being created. |
| 16:44 | bmills joined #evergreen | |
| 16:57 | jeff | and ahcm is used for at least: opportunistic hold capture, checkout fills related hold, and hold queue stats. also, copy-hold ratios in circ matrix tests. |
| 16:59 | mdriscoll left #evergreen | |
| 17:12 | jeffdavis joined #evergreen | |
| 19:04 | rlefaive joined #evergreen | |
| 20:42 | bshum | @sortinghat |
| 20:42 | pinesol_green | Hmm... bshum... Let me see now... GRYFFINDOR! |
| 21:08 | graced joined #evergreen | |
| 21:12 | miker | jeff: tl;dr -> flags are likely to stay the same over hold-ish time periods, so no map. rule based disqualification is both more complicated and less static (or, that's the supposition) so we make the mapping in hopes that the copy will test "OK for hold" in hold-ish time periods. |
| 21:13 | miker | hth |
| 21:52 | eeevil joined #evergreen | |
| 21:53 | jeff_ joined #evergreen |
| 10:46 | bmills joined #evergreen | |
| 10:48 | Bmagic | Dyrcona: it looks like it's money.payment from this line my $last_payment = $e->search_money_payment(..... then return 1 if ($payment_ts + $interval_secs >= $now); |
| 10:50 | Dyrcona | I thought so, but wasn't sure any more. |
| 10:50 | kmlussier | That's my recollection from testing. |
| 10:56 | maryj joined #evergreen | |
| 11:01 | Christineb joined #evergreen | |
| 11:10 | Bmagic | Does anyone have a library that controls access to the public workstations via login? That uses SIP backend? |
| 11:40 | kmlussier | jboyer-isl: I got the reference. :) |
| 11:41 | Dyrcona | We use 9.3 in production and 9.1 on development/training. |
| 11:42 | Dyrcona | 'Cause we've been too lazy to upgrade the second db server. |
| 11:52 | csharp | kmlussier: we're moving to 9.4 this weekend - been testing on it for months on two test servers with no issues |
| 11:53 | kmlussier | csharp: Awesome! I'll be interested in hearing how things go in production. |
| 12:51 | jeff | _bott_: is GRPL also running 9.4 in production? |
| 12:52 | dbwells_ | kmlussier: We've been on 9.4 in production since 12/22. So far, so good. |
| 13:47 | pinesol_green joined #evergreen | |
| 13:48 | csharp | @dunno |
| 13:48 | pinesol_green | csharp: I see nothing, I know nothing! |
| 13:49 | jeffdavis | I'm working on a new feature in the staff client. We're not using the web client locally yet, but if I am adding it there for feature parity, I guess I'd better know how to test it. :) |
| 13:49 | csharp | @quote random |
| 13:49 | pinesol_green | csharp: Quote #67: "< Rogan_Ni> Star Wars" (added by berick at 01:38 PM, September 17, 2013) |
| 13:49 | Dyrcona | csharp++ |
| 17:27 | kmlussier | For the logs, the depth appears to be 2. |
| 17:29 | berick | kmlussier: i believe it defaults to the depth of the staff login workstation org unit. |
| 17:29 | berick | which would be 2 in a stock EG setup |
| 17:31 | kmlussier | berick: Ah, ok. That makes sense. |
| 17:31 | kmlussier | berick: Can you guess what I'm testing right now? :) |
| 17:32 | berick | heh, i have a theory patron reg is involved |
| 17:34 | kmlussier | berick: I'm hoping to complete the testing on the latest code for the new editor tonight. |
| 17:35 | berick | kmlussier++ |
| 17:35 | kmlussier | But, first, I suppose I should feed the children. Their faces are looking a little gaunt. |
| 17:35 | berick | hah |
| 11:35 | Dyrcona | mceraso: YW! |
| 11:36 | jeff | and /cl |
| 11:36 | jeff | er |
| 11:47 | dbs | csharp: test received (on gitadmin) |
| 11:56 | berick | dbs: thought of one of your SEO talks today as google news showed a headline of 'Heartburn pills linked to increased risk of kidney disease' next to a picture of David Bowie. |
| 12:04 | dbs | berick: ouch |
| 12:09 | csharp | dbs: thanks! |
| 12:29 | jihpringle joined #evergreen | |
| 12:33 | bshum | csharp: That's happened before a couple times now |
| 12:33 | bshum | csharp: I think it's a memory killer issue |
| 12:33 | jeff | anyone generating logs should be forced to parse those logs before committing. |
| 12:33 | jeff | unparsable log entries should be a test failure. |
| 12:34 | jeff | (mostly unrelated to evergreen, just a general "if i ruled the world" whim of this morning) |
| 12:35 | jeff | i'm parsing logs generated by software which i think i wrote in 2008. |
| 12:43 | tsbere | jeff: At least once I wrote something that logged perfectly parseable logs, then the logging system changed and they became useless. So maybe not past-you's fault? ;) |
| 12:45 | csharp | yay! now I'm seeing feedback evergreen-ils.org spam! |
| 12:45 | csharp | (meaning that all is back to normal :-)) |
| 14:55 | csharp | berick: thanks for that info - I'll stop chasing the red herring |
| 14:56 | csharp | jeff: I think your question has got me on a better track - I'll report back after checking on environment stuff |
| 14:56 | berick | the 1 exception is the initial "what am I processing" query taking longer than the $req_timeout, in which case the events would never even get created |
| 14:57 | csharp | well, the good news is that I'm working this out now on a test server rather than doing it next week when everythings on fire ;-) |
| 15:05 | Dyrcona | @praise csharp |
| 15:05 | * pinesol_green | You don't want to get mixed up with someone like csharp. csharp is a loner, Dottie. A rebel. |
| 15:06 | bshum | Memory killers |
| 10:35 | Bmagic | mmorgan: bug 1532236 |
| 10:35 | pinesol_green | Launchpad bug 1532236 in Evergreen "Evergreen should allow for HTML formatted action trigger emails" [Undecided,New] https://launchpad.net/bugs/1532236 |
| 10:36 | mmorgan | Bmagic++ |
| 10:39 | Dyrcona | Hmmm... Maybe 1.4 million barcodes are a bit much for a test. |
| 10:40 | mmorgan | Dyrcona: That would be a thorough test ;-) |
| 10:42 | Dyrcona | Yeah. I'm not sure it would upload though, the file is 21.1 MB according to Nautilus File Manager. |
| 10:43 | Dyrcona | I recall reading somewhere that the limit is 10 MB unless you change it, but that could have been inaccurate information. |
| 10:45 | csharp | Bmagic: regarding bug 1532236, we've been wanting HTML email too - not sure if it needs a new A/T reactor or if we can encode some logic into the current SendEmail.pm that would do what we're after |
| 11:07 | Christineb joined #evergreen | |
| 11:28 | sandbergja joined #evergreen | |
| 11:31 | Stompro | Bmagic++ tsbere++ I've been wondering how to create HTML notices for a while. I think cover art included in notices would be appreciated by many customers. |
| 11:31 | Bmagic | excellent - some testing would great |
| 11:38 | tsbere | Stompro: I disagree on the cover art bit, but as I mentioned yesterday I tend to disable HTML/Rich Text email viewing in general. |
| 11:43 | Stompro | tsbere, the multipart should take care of text email purist such as yourself. The docs to can stress the importance of including the text only version. |
| 11:56 | tsbere | Stompro: I just don't like the idea in general. Then again, I dislike the fact email supports HTML in the first place. Too many things can be "hidden", like link targets. >_> |
| 11:34 | * csharp | finds http://wiki.evergreen-ils.org/doku.php?id=dev:browser_staff:dev_notes |
| 11:34 | Dyrcona | Actually, we're using less these days. |
| 11:35 | Dyrcona | Yeah, I remember reading that there was a reason. |
| 11:35 | berick | Dyrcona: i was wondering about real-world data. most of my tests were on develpment servers. |
| 11:35 | Dyrcona | I can take a peek later. |
| 11:37 | csharp | ah - there it is: https://esilibrary.com/exploring-websockets-and-evergreen-iii-proof-of-concept/#sthash.XUhhjAT7.dpbs |
| 11:39 | * berick | keeps meaning to try https://www.nginx.com/blog/websocket-nginx/ |
| 11:41 | pinesol_green | kitteh_ wrote The Great Big Book of Evergreen. |
| 11:43 | bmills joined #evergreen | |
| 11:43 | mllewellyn joined #evergreen | |
| 11:45 | jeff | I'm thinking of scripting up a SIP smoke test to retrieve all patrons and all items via SIP with the intent of uncovering ways that SIPServer and/or the Evergreen SIP implementation fall over. I might later expand it a bit. Would anyone here be interested in running something like that against live data in a test system? |
| 11:45 | jeff | I suppose I'll just try and make it vaguely non-specific and share and go from there. |
| 11:45 | csharp | jeff: yes, but after our upgrade over next weekend |
| 11:46 | jeff | csharp: what, not during!? |
| 11:47 | berick | wimp |
| 12:47 | pinesol_green | Launchpad bug 1470957 in Evergreen 2.9 "Items are incorrectly sorting when using the Sort By Publication date feature" [Medium,New] |
| 12:47 | bshum | So weird stuff happens with pubdate sorting |
| 12:47 | kmlussier | krvmga: Yeah, looking at bug 1470957, I see it refers to date1, which is a fixed field thing. |
| 12:47 | berick | speaking of acq, looking for takers to test bug #1333254. (No EDI required). |
| 12:47 | pinesol_green | Launchpad bug 1333254 in Evergreen "EDI invoices automatically expend debits" [Wishlist,Confirmed] https://launchpad.net/bugs/1333254 |
| 12:48 | kmlussier | huh, pinesol_green must like berick more than me. |
| 12:48 | kmlussier | bug 1470957 |
| 13:56 | csharp | since bug 1207533 renders Triggered Events effectively useless, we're thinking of greying it out instead |
| 13:56 | pinesol_green | Launchpad bug 1207533 in Evergreen 2.9 "Triggered event log times out for large-data sites" [Medium,Confirmed] https://launchpad.net/bugs/1207533 |
| 14:02 | Stompro joined #evergreen | |
| 14:18 | tsbere | csharp: I bet it is because they share a URL |
| 14:23 | tsbere | csharp: More specifically, I believe the issue is related to the deck.js file and the fact they both use the "browser" URL as their target. |
| 14:25 | * tsbere | has an idea to fix it, but wants to test it quick first....which means waiting for his dev machine to reload |
| 14:29 | jihpringle_ joined #evergreen | |
| 14:29 | jboyer_isl joined #evergreen | |
| 14:29 | collum joined #evergreen | |
| 14:29 | gsams joined #evergreen | |
| 14:32 | csharp | tsbere: I'm heading home, but I'll check back in when I get there (FYI, in case you get to a point where I can assist with testing) |
| 14:33 | tsbere | csharp: My test says my idea works. I'll make a working branch for you to poke at. |
| 14:33 | csharp | rock on |
| 14:36 | rangi` joined #evergreen | |
| 14:36 | tsbere | @later tell csharp http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/tsbere/differentiate_patron_urls |
| 16:03 | Bmagic | agreed - in fact that is our plan |
| 16:03 | Bmagic | but in order to do that, it seems, we have to change the code to "not mess with our headers" |
| 16:05 | tsbere | Bmagic: Should be trivial to make such changes, from what I can see. |
| 16:05 | Bmagic | tsbere: we have it working on a test server by commenting out the three lines there in SendEmail.pm |
| 16:05 | Bmagic | But I thought I would ask if anyone else accomplished this |
| 16:07 | tsbere | Bmagic: I would change them to have "unless $email->header('???')" on the end. |
| 16:07 | tsbere | Then if the A/T sets the headers they stay as what the A/T set, otherwise they get the (hopefully sane) defaults |
| 17:08 | TheMadGunt | Hello out there |
| 17:08 | hopkinsju | The problem is that a search from their system to ours will turn up results one time, then subsequent searches for the same thign turn up 0 results. It'll do that for a while before it starts working again. Seems to me that their system is dropping the connection. |
| 17:08 | hopkinsju | Hi there TheMadGunt |
| 17:10 | TheMadGunt | I was hoping someone could help me out. Stuck on a step doing a test server install |
| 17:11 | TheMadGunt | Step 10.2 - Creating the Database |
| 17:11 | bshum | hopkinsju: It wouldn't surprise me if there was something funky going on. Any log data to support your theory? For us, I always smirked at their SUPER old version of yaz that they were using. |
| 17:11 | hopkinsju | Cool, well hopefully we can help you :-) |
| 17:14 | bshum | Are you using "server edition" 64-bit Ubuntu 14.04 |
| 17:14 | bshum | Not Desktop edition |
| 17:14 | TheMadGunt | No, not desktop |
| 17:14 | bshum | The desktop edition sometimes does funky things and has broken installers. |
| 17:14 | bshum | And nobody's tested on 32-bit anything in... well, forever, probably. |
| 17:15 | hopkinsju | I'm going to turn up logging. |
| 17:15 | TheMadGunt | cool. let me give that a shot and I'll report back either way. THANKS! |
| 17:15 | bshum | Good luck! |
| 17:16 | bshum | Apparently. |
| 17:16 | hopkinsju | *eyeroll* |
| 17:16 | * bshum | smirks at hopkinsju |
| 17:16 | TheMadGunt | I'm in NY. Best time to work on testing things. |
| 17:16 | TheMadGunt | no one to interrupt me. :) |
| 17:16 | bshum | Good stuff... /waves hi from CT |
| 17:16 | hopkinsju | 4pm is usually about the time when I can stop checking email and putting out fires and actually get to work. |
| 13:56 | bshum | We got something like <xsl:variable name="locname" select="$lid" /> in our .xsl file that draws from |
| 13:56 | bshum | So I assume that's how we get the full name of the library for lid |
| 13:57 | jboyer_isl | I think ours was an xsl change. That’s what I was referring to with the contains comment. Something in the xslt processing was using it instead of =. |
| 13:57 | bshum | Maybe I'll make a new variable |
| 13:57 | bshum | And test it by changing one of them to use shortname |
| 13:57 | bshum | And then convert everything over |
| 14:22 | bshum | In any case, tsbere++ rjackson_isl++ jboyer_isl++ |
| 14:22 | bshum | Thanks for feedback guys! Appreciate it :) |
| 15:05 | graced joined #evergreen | |
| 15:16 | Ivran joined #evergreen | |
| 15:19 | Ivran | Would someone be able to tell me what I am doing wrong in trying to run this Evergreen report...? All I am trying to do is run a report that counts the number of patrons assigned a particular stat category. |
| 15:29 | bshum | I think I've heard of what jboyer_isl is describing, but unfortunately have not used it before |
| 15:32 | jboyer_isl | It lets you choose between left, inner, and sometimes right joins on the tables in the reporter. Default means “whatever the system thinks is best” which is usually left, I think. |
| 15:34 | Ivran_ joined #evergreen | |
| 15:34 | Ivran_ | I don't think the web client likes me very much. -- I will give the nullability a test and see what I can learn, though! |
| 15:37 | jboyer_isl | Ivran: you’ll probably want to choose links that have None in the Nullable column when you’re selecting the stat cat fields. That way you can inner join the user and SC tables to only look at users with SC entries, then you have to display the entry value (not sure of the field names off hand) and a count distinct on entry id to get the totals for each value. |
| 15:38 | Ivran_ | jboyer_isl: Thank you! I think I can attempt that well enough. I'll see what I can do. |
| 15:41 | Bmagic | Ivran_: I have had similar difficulties with stat cats - nullable is the answer |
| 15:41 | Bmagic | because not all patrons have a row in the stat cat tables |
| 15:43 | Ivran_ | I'm brand new to this, so I just keep trying until I get it. |
| 15:49 | Ivran_ | Ciao for now. I'll come back if I can't figure it out. Thank you! |
| 15:58 | bshum | dbwells: https://bugs.launchpad.net/evergreen/+bug/1526543 didn't have a pullrequest on it, but it looked fine for testing, I'm going to go ahead and push it through, though for note, the default is that reset_password = 'true' so the test approach as described confused me initially :\ |
| 15:58 | pinesol_green | Launchpad bug 1526543 in Evergreen 2.9 "Cannot disable password reset in TPAC" [Low,New] |
| 15:59 | bshum | I may update the test instruction in the git commit message to reflect the actual default and the need to alter the config.tt2 to set that to false. |
| 16:01 | dbwells | bshum: heh, sorry about that. I guess I assumed it was false, since optional things are often off by default. It does make more sense now that nobody else notice it :) And, thank you! |
| 16:02 | bshum | dbwells: Cool, cool |
| 16:02 | bshum | dbwells++ remingtron++ |
| 13:11 | mmorgan | @hate printed notices |
| 13:11 | pinesol_green | mmorgan: The operation succeeded. mmorgan hates printed notices. |
| 13:14 | jeff | mmorgan: why the hate? |
| 13:15 | mmorgan | jeff: seems like it takes forever (for me) to make the simplest change :-( |
| 13:16 | mmorgan | ... and test it to make sure it's working as intended. |
| 13:20 | mmorgan | could be that I just don't make changes frequently enough to remember how all the moving parts fit together. Seems like I have to relearn it each time. |
| 13:34 | * tsbere | rigged it at MVLC so that most of the notices are static, and what isn't is set by library settings and handled automatically by the script |
| 13:36 | maryj_ joined #evergreen | |
| 13:37 | collum_ joined #evergreen |
| 11:18 | Dyrcona | Third time's the charm, right? |
| 11:18 | Dyrcona | The db upgrade finished, so I don't have to run that again. |
| 11:19 | Dyrcona | It could also be something with the node.js installed from packages on Ubuntu 14.04. |
| 11:19 | bshum | npm install ran fine from my build directory on my test server |
| 11:20 | bshum | I'd have to run through all the steps to know for sure |
| 11:20 | Dyrcona | So, maybe just I'm blocked, or if they had a problem it has been fixed? |
| 11:20 | bshum | I haven't updated the packages on this server lately |
| 11:21 | bshum | Maybe some of the new stuff is borked |
| 10:27 | miker | np |
| 10:28 | mrpeters joined #evergreen | |
| 10:51 | Christineb joined #evergreen | |
| 11:19 | jeff | Hrm. Anyone know offhand what semi-common process can cause a hold to change shelf_time and shelf_expire time? |
| 11:19 | jeff | I wonder if simply re-scanning an already on-shelf hold does that. |
| 11:19 | * jeff | tests |
| 11:21 | berick | pretty sure it would take more than that |
| 11:21 | berick | it would have to be un-shelved in some way |
| 11:22 | berick | i think. like, pickup_lib changed, checked in, changed back, checked in later. |
| 11:23 | jeff | Current example happened at a branch other than the one I'm at. Drat. |
| 11:25 | * jeff | tests |
| 11:29 | jeff | Yeah, it's not a simple "scan it again". |
| 11:29 | jeff | At least, not with default checkin modifiers, etc. |
| 11:42 | jeff | Okay, in this specific example it was "patron didn't want the hold anymore, staff were unfamiliar with how to cancel a hold" |
| 11:43 | jeff | So they did a few things, presumably one of which involved reset/retargeting the hold. |
| 11:43 | jeff | Then they just left it in its captured on-holdshelf state and chucked it in the bin for transit to the owning library. |
| 11:43 | jeff | So we went over how to cancel a hold. |
| 11:47 | tsbere | jeff: I can think of two things. One being manual "find another target" triggering, the other being "the copy that *was* on the shelf was checked out to someone else, and now that is a new copy" |
| 11:47 | * tsbere | is amazed he hasn't had to dig out records of the latter in the past few months, actually... |
| 11:51 | jeff | amusing when the target of a ready for pickup hold changes. |
| 12:29 | jeff | There is a working repo, and a launchpad instance. |
| 12:29 | jeff | http://git.evergreen-ils.org/?p=working/SIPServer.git;a=summary |
| 12:30 | Bmagic | oh |
| 12:30 | jeff | https://bugs.launchpad.net/sipserver |
| 12:30 | jeff | keys via the usual means -- i'd test to see if yours are already in place. |
| 12:31 | Bmagic | weird, I see that I somehow have a commit there already |
| 12:31 | jeff | I suspect that any keys submitted added after the creation of that repo are already in place, but I'm not certain. |
| 12:31 | Bmagic | lol, I guess I forgot |
| 05:09 | rlefaive joined #evergreen | |
| 07:32 | jboyer-isl | miker: Yeah, just venting. I'm probably going to try a couple of OS tests today. (never got around to it yesterday.) The only difference between our G8 server that's working perfectly and these G9's that aren't are their G's. (Same NICs, etc.) I may try 12.04 to see if it makes any difference. |
| 07:33 | jboyer-isl | I would be equal parts relieved / disappointed if that works. |
| 07:43 | graced joined #evergreen | |
| 07:49 | mrpeters joined #evergreen | |
| 07:54 | rlefaive joined #evergreen | |
| 07:55 | rjackson_isl joined #evergreen | |
| 07:57 | ericar joined #evergreen | |
| 08:08 | miker | kmlussier: from yesterday afternoon, I've updated the bugs. tl;dr: mod_perl code is not feasibly testable in the way that opensrf app code (via live tests) or db changes (via pgTAP) are -- and, the changes are covered by syntax checks to the same degree as the rest of the mod_perl code, already. |
| 08:08 | * miker | runs away for an appointment |
| 08:32 | mrpeters1 joined #evergreen | |
| 08:45 | jboyer-isl joined #evergreen | |
| 08:46 | Dyrcona joined #evergreen | |
| 09:58 | jwoodard joined #evergreen | |
| 10:04 | Dyrcona | "He's running the scripts....He's checkin' 'em twice." |
| 10:04 | Dyrcona | "He's gonna find out which are naughty or nice." |
| 10:05 | Dyrcona | "Santa Dev is testing a branch." |
| 10:05 | Dyrcona | Don't mind me.... |
| 10:06 | miker | Dyrcona: when I'd just seen the first line I heard it to the tune of going the distance by cake... |
| 10:06 | Dyrcona | heh. |
| 10:06 | Dyrcona | That could make a good base for a development parody song, too. |
| 10:07 | Dyrcona | He's runnin' the perl tests....He's timin' for speed.... |
| 10:15 | jeff | I wonder if metacpan has a "rhymes with" search option for modules... |
| 10:26 | rlefaive joined #evergreen | |
| 10:54 | ericar_ joined #evergreen | |
| 11:06 | Dyrcona | 4518 files changed, 1017556 insertions(+), 300704 deletions(-) |
| 11:10 | tsbere | Was a bit behind master. ;) |
| 11:10 | Dyrcona | 6,882 commits behind you said. |
| 11:11 | csharp | @quote add 10:04 < Dyrcona> "He's running the scripts....He's checkin' 'em twice. He's gonna find out which are naughty or nice. Santa Dev is testing a branch." |
| 11:11 | pinesol_green | csharp: The operation succeeded. Quote #134 added. |
| 11:12 | tsbere | Not that the rebase changed much beyond "stop merge from throwing a minor fit", I believe |
| 11:12 | Dyrcona | Yeah, warnings about inexact rename detection and setting a limit to at least 2,977. ;) |
| 09:35 | miker | jboyer-isl: I'm sure you've already investigated this, but we've seen auto-sensing duplex settings fail with HP NICs and some switches ...have to force port speeds and duplex settings. the symptoms are what you describe |
| 09:36 | * Dyrcona | has seen auto-sensing fail with a number of different NICs. |
| 09:39 | jlundgren joined #evergreen | |
| 09:44 | kmlussier | A question about our QA guidelines. A good percentage of the fixes I loaded for Bug Squashing Day have changes made to a .pm file, but I don't think any had a regression test. |
| 09:45 | kmlussier | I just want to make sure I'm clear on the guidelines before I start adding needstest tags. Any change made to perl code since May of this year, no matter how large or how small, should have a test? Is that right? |
| 09:46 | ericar_ joined #evergreen | |
| 09:51 | Dyrcona | kmlussier: I don't think we have been quite that strict, although "should" is a recommendation, not a commandment. |
| 09:51 | Dyrcona | My understanding is if the commit messages provide adequate test instructions, the live test can be waived. |
| 09:53 | kmlussier | I thought the waiver was only given when there is a statement from the patch author explaining why a test is infeasible without significant refactoring |
| 09:53 | * csharp | gets indecisive about which bugs to focus on. Candidates today are bug 1175293 (highest "heat" of acq bugs), bug 1413352, and bug 924952 |
| 09:53 | pinesol_green | Launchpad bug 1175293 in Evergreen "ACQ: Allocate to Fund drop down menu (in Funding Source) Not Following Precedents Set by Other Fund Menus" [Medium,Confirmed] https://launchpad.net/bugs/1175293 |
| 09:54 | pinesol_green | Launchpad bug 1413352 in Evergreen "New Brief Record estimated price does not populate" [High,Confirmed] https://launchpad.net/bugs/1413352 |
| 09:54 | pinesol_green | Launchpad bug 924952 in Evergreen "Acquisitions: Order record loads fail when there is a null value in a holdings subfield" [High,Confirmed] https://launchpad.net/bugs/924952 |
| 09:54 | Dyrcona | csharp: Those look like good ones to work on to me. |
| 09:54 | jeff | I'm not sure what's more realistic: working toward a point where we aren't considering waiving tests like that, or expecting that regression testing is accomplished by reading commit messages and manually testing things as directed there. |
| 09:54 | jeff | (on all future commits) |
| 09:55 | yboston joined #evergreen | |
| 09:55 | Dyrcona | jeff: I agree. I think we want tests on all things in the future. It's a matter of taking the time to get there. |
| 09:55 | kmlussier | I didn't think the commit messages / manual instructions were related to whether a test was provided or not. It was just something that is a best practice to include in any bug fix. |
| 09:56 | jeff | @decide kick the can down the road[map] or test paralysis |
| 09:56 | pinesol_green | jeff: go with kick the can down the road http://www.firstpersontetris.com/ |
| 09:56 | Dyrcona | Well, that was my understanding. I could be mistaken. |
| 09:56 | * jeff | gives pinesol_green a look |
| 09:56 | genpaku joined #evergreen | |
| 09:57 | csharp | @decide [someone] or [someone |
| 09:57 | pinesol_green | csharp: Error: Missing "]". You may want to quote your arguments with double quotes in order to prevent extra brackets from being evaluated as nested commands. |
| 09:57 | Dyrcona | I know some bug fixes have been written and pushed since May that have not had live tests. |
| 09:57 | csharp | @decide [someone] or [someone] |
| 09:57 | pinesol_green | go with ericar |
| 09:57 | jeff | here i was hoping that pinesol_green would give us the kobayashi maru style solution when presented with those two equally undesirable options. :P |
| 09:58 | kmlussier | OK, but in re-reading that, if it is waived, an additional signoff is required. So, for the bug I'm looking at now, I guess I shouldn't be merging it because it either requires a test or requires an additional signoff. |
| 09:59 | Dyrcona | What we really need it a complete regression suite. Basically what we have are a strange hybrid of unit tests and some regression tests of some features. |
| 10:00 | kmlussier | But we will have more regression tests of more features if we continue to strongly encourage people to follow the guidelines. |
| 10:01 | kmlussier | Unless there is someone out there who has time to write a complete regression suite. :) |
| 10:02 | Dyrcona | Someone would have to make that a priority, yes, and devote resources to it. |
| 10:05 | dbwells | kmlussier: My understanding of the new test recommendations are the same as yours, though I'm also pretty sure that Dyrcona is right, and others have pushed stuff in without tests (which has generally confused me, and also made me wonder if others felt the descriptive tests were adequate) |
| 10:07 | Dyrcona | It was acknowledged that somethings are difficult to test, but I'll go along with requiring tests if that is what others understood. |
| 10:07 | kmlussier | Yeah, I don't doubt that some things have been merged without the tests. |
| 10:07 | Dyrcona | It could just be a minority (me) who misunderstood. :) |
| 10:14 | dbwells | It also isn't explicit in the 2.9 section of the document, but in my understanding we are still only requiring at least one new relevant test with each patch, not a complete and extensive suite (though it would be welcomed :) ). |
| 10:16 | kmlussier | Ok, so it looks like the guidelines were formalized at the August dev meeting. What I'm going to do then, for the patches I loaded on Sandboxes, is if the patch was created since August and makes any change to perl or database code, I'll add the needstest tag. |
| 10:16 | kmlussier | If it seems excessive for the code being changed, there is always that waiver that a dev can request if it seems excessive. |
| 10:16 | kmlussier | Bleh. Just a bit of redundancy in that sentence. |
| 10:19 | rlefaive joined #evergreen | |
| 10:24 | Dyrcona | I wonder if both pgtap and perl tests are required when the perl tests sufficiently exercise the database changes, but that could be a different discussion. |
| 10:24 | * Dyrcona | has a specific branch in mind where he added perl tests but not a pgtap test for the database changes, because function changes can be tricky in pgtap. |
| 10:24 | kmlussier | My gut reaction is that if the perl test sufficiently exercises the database changes, the perl test should be adequate. |
| 10:25 | dbwells | I agree. |
| 10:27 | Dyrcona | Sounds good to me. :) |
| 10:27 | * Dyrcona | returns to modifying a library's circ parameters. |
| 10:28 | kmlussier | For the discussion we just had, those tests are just for patches that fix bugs, right? In the case of jeff's code for bug 1013786, then, they wouldn't be required since it really is a new feature. |
| 10:28 | pinesol_green | Launchpad bug 1013786 in Evergreen "tpac: Check for password strength at login" [Medium,Confirmed] https://launchpad.net/bugs/1013786 - Assigned to Christine Burns (christine-burns) |
| 10:28 | kmlussier | I know it' says Medium importance, but, at this point, it feels like new feature to me. |
| 10:30 | kmlussier | Heh, I suppose we can remove the jspacremovalblocker tag from that one. :) |
| 10:31 | * jeff | looks at that bug |
| 10:31 | berick | no, we have to merge jspac back in until all of those bugs are closed. |
| 10:32 | jeff | Oh, forgot I added pullrequest-worthy code to that bug. |
| 10:35 | dbwells | I think the test standards, whatever they may be, should apply more or less equally to bugs and new features. The document refers to "new code contributions", so I think it covers everything. |
| 10:36 | dbwells | (Of course, later parts reference "fixes a bug", so who knows :P) |
| 10:37 | * kmlussier | nods |
| 10:40 | Dyrcona | Right, I thought the standard for bug fixes was deliberately lower than for new features, and that may be 1 source of any misunderstanding. |
| 10:42 | * Dyrcona | awaits angularpac.... ;) |
| 10:52 | * Dyrcona | isn't surprised. |
| 10:53 | Dyrcona | i might be surprised when you figure out the why, however. ;) |
| 10:54 | * Dyrcona | should revisit the circ history download bug with a new solution. |
| 10:55 | kmlussier | Once I focused just on patches added since August, the number requiring tests wasn't so high. |
| 10:55 | * kmlussier | returns to actual testing now. :) |
| 10:55 | tsbere | jeff: Do you have metarecord or part holds on no longer existing metarecords/parts? |
| 10:55 | Dyrcona | That would not surprise me. |
| 10:56 | Dyrcona | And I was think parts holds on part that have since disappeared. |
| 12:51 | kmlussier | But I know it doesn't reflect all of the work that has been happening |
| 12:53 | mrpeters1 joined #evergreen | |
| 13:14 | mrpeters joined #evergreen | |
| 13:19 | mmorgan | Bmagic: I'm testing lp 1331174. and am curious what your intervals for LONGOVERDUE and LOST are in production. |
| 13:19 | pinesol_green | Launchpad bug 1331174 in Evergreen "Long Overdue processing needs org unit settings separate from Lost Processing" [Wishlist,Confirmed] https://launchpad.net/bugs/1331174 - Assigned to Michele Morgan (mmorgan) |
| 13:20 | mmorgan | The seed mark Long Overdue trigger worked fine to mark items long overdue at 6 months. |
| 13:22 | mmorgan | Then I changed the mark Lost trigger to mark the items Lost at 7 months. But the Lost trigger didn't find anything to mark Lost. It's looking for transactions with stop_fines NULL or MAXFINES, so my LONGOVERDUE transactions didn't get picked up to be marked Lost. |
| 13:22 | mmorgan | Are you using a custom filter for this? |
| 13:24 | mrpeters joined #evergreen | |
| 13:31 | * mmorgan | run out for a bit |
| 13:38 | jihpringle | kmlussier: Am I correct in assuming that the mlnc2 test server isn't generating and sending email? |
| 13:39 | jihpringle | I've tested lp 1197636 up to the point where the email should be sent |
| 13:39 | pinesol_green | Launchpad bug 1197636 in Evergreen "Email record detail does not check for email" [Medium,Triaged] https://launchpad.net/bugs/1197636 - Assigned to Jennifer Pringle (jpringle-u) |
| 13:40 | tsbere | jihpringle: I do not believe any of those mlnc servers were set up for actually sending email. In general. |
| 13:45 | kmlussier | jihpringle: Sorry! You're correct. It's not configured to send email. I totally overlooked that need when I was setting it up. |
| 14:26 | DPearl joined #evergreen | |
| 14:28 | pinesol_green | [evergreen|Kathy Lussier] LP#1319998 Stamping upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3e831ac> |
| 14:28 | pinesol_green | [evergreen|blake] LP1319998_materialized_summary_billing_del_ADDS_to_balance_owed - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=574cab2> |
| 14:41 | jboyer-isl | miker, Dyrcona: Just getting back from a meeting and reading scrollback. I had not come across suggestions to check that (my google-fu was weak) and it never occurred to me because 2015, but I'm absolutely testing that now. I was about to go install another OS to test, this is much faster. |
| 14:42 | jboyer-isl | If it works, you each get a meal/drink on me in NC. |
| 14:43 | * mmorgan | returns and catches up. |
| 14:45 | jeff | ahh, the fond days when 3com switches could lock up Cisco ethernet interfaces hard enough that Cisco would RMA them, but they really just needed to be power cycled. |
| 14:47 | jlundgren | I think I just confirmed my first (new) bug - https://bugs.launchpad.net/evergreen/+bug/1513231 |
| 14:54 | jboyer-isl | Oops, sad trombone. |
| 14:58 | kmlussier | mmorgan: Are you thinking that you would be setting a transaction to Longoverdue without a bill after, say, 3 months, and then setting it to Lost, with a bill after something like 6 months? |
| 14:59 | jlundgren1 joined #evergreen | |
| 14:59 | mmorgan | kmlussier: That's the scenario I'm testing, yes. |
| 15:00 | kmlussier | Bmagic / mmorgan: Would it be reasonable, then, to add a separate "Lost from Long Overdue" trigger that has the necessary json for those sites that want to use that workflow? |
| 15:01 | kmlussier | I can see why you wouldn't want to add it to the typical Lost trigger since there are sites that want to set it and leave it at Long Overdue. |
| 15:02 | Bmagic | kmlussier: it's probably not a bad idea to throw a stock AT idea in the branch - but there are a few possibilities |
| 15:15 | mmorgan | Would clear documentation on how to accomplish the longoverdue to lost be generally accepted? Or is it better to have the examples? |
| 15:19 | jboyer-isl | Network? More like Notwork. |
| 15:19 | mmorgan | jlundgren++ |
| 15:21 | kmlussier | Christineb: Would it be helpful to try the same workflow (if you have time) on another masslnc VM to see if the issue you encountered was caused by the new code? |
| 15:21 | kmlussier | Christineb: The VM's are nearly identical with the exception of the branches that were added for testing. |
| 15:21 | Christineb | kmlussier - Oh great idea, I will try that |
| 15:23 | kmlussier | mmorgan: I think it's generally preferable to have examples, but I don't think the lack of them is a showstopper. But I want to take a closer look at it too. |
| 15:24 | kmlussier | Christineb: You could probably hop on the one jihpringle is using. The access info is on the same spreadsheet. |
| 16:44 | kmlussier | dbwells: I had hoped to look at bug 1422379 today, but it looks like it wasn't meant to be. I hope to put some eyes on it soon, though. |
| 16:44 | pinesol_green | Launchpad bug 1422379 in Evergreen "Move money.billing timestamps back to moment of fine" [Medium,Triaged] https://launchpad.net/bugs/1422379 - Assigned to Kathy Lussier (klussier) |
| 16:45 | dbwells | kmlussier: Hey, thanks for trying. I've been looking at bugs for the last hour or so, and also generally getting stuck in one way or another. |
| 16:45 | jlundgren1 | stompro++ for testing in master build - https://bugs.launchpad.net/evergreen/+bug/1312699 |
| 16:45 | pinesol_green | Launchpad bug 1312699 in Evergreen "Editable Checkout History" [Wishlist,Triaged] - Assigned to Josh Stompro (u-launchpad-stompro-org) |
| 16:45 | kmlussier | Stompro: I'll need to check, but I think the sorting is something that is present in master already. It was a new 2.9 feature |
| 16:46 | dbwells | I think I'll report some "new" bugs instead (stuff we've had in production for a while, in some cases :( ). |
| 17:18 | kmlussier | Good night mmorgan! |
| 17:18 | kmlussier | Ah well, a bit too late |
| 17:19 | miker | jboyer-isl: based on "network? more like notwork" I'm guessing duplex and speed autosense was not the issue? |
| 17:23 | kmlussier | Just took a look at the signedoff bugs that also has a needstest bug. Other than the bug gmcharlt already commented on, there are two from miker http://bit.ly/1UvXOvc |
| 17:24 | kmlussier | miker: If those are examples of bugs where tests would be infeasible, could you note that on the bugs? I don't have a clear sense of what's infeasible and what's doable. |
| 17:37 | kmlussier | "101 bugs reported by me" Looks like I missed an opportunity to celebrate when I hit the 100 mark. |
| 17:40 | berick | bummed I could not participate today. |
| 17:40 | berick | bug_squashers++ |
| 17:42 | kmlussier | berick: Well, you do a lot of fixing between Bug Squashing Days. :) |
| 10:53 | pinesol_green | csharp: NO. |
| 10:54 | dbwells | csharp: I thought you just applied that fix last week or so? |
| 10:54 | * dbwells | is confused |
| 10:55 | csharp | dbwells: I found it, but was waiting to do a full upgrade to 2.9.1 this weekend :-/ |
| 10:55 | csharp | needless to say, I'll at least be changing that on the live server |
| 10:55 | csharp | er.. live *test* server that is |
| 10:55 | Dyrcona | Yeah, it's a straightforward cherry-pick if you only want the one fix. |
| 10:55 | csharp | @blame csharp |
| 10:55 | pinesol_green | csharp: It really IS csharp's fault! |
| 16:35 | Dyrcona | sftp++ |
| 16:35 | Dyrcona | ;) |
| 16:36 | bshum | ftp-- sftp++ # indeed, if only the rest of the world understood |
| 16:37 | * kmlussier | is going to answer her own question with a 'yes' based on a quick test of webby. |
| 16:37 | tsbere | ftps-- # Too many people assume it is interchangeable with sftp |
| 16:38 | Dyrcona | That's exactly bshum's problem as I understand it. |
| 16:41 | bshum | "You keep using that word. I do not think it means what you think it means." |
| 10:02 | jeff | especially if it was something other than a catalog search followed by placing a hold. |
| 10:03 | jeff | flight recorders. |
| 10:17 | Dyrcona | They make those: event loggers. |
| 10:19 | jeff | screen recording software exists for software testing and usability studies. i've often wanted to install at package and either enable it on machines that are having difficult-to-reproduce issues or have them recording semi-constantly with a X minute cyclical buffer. |
| 10:33 | Dyrcona | Event loggers are more fun: mouse_down btn 1 coords: 865, 124 and you get figure out what they clicked on. |
| 10:36 | Shae joined #evergreen | |
| 10:39 | mmorgan1 joined #evergreen | |
| 15:35 | lualaba | FIXME: If you encounter this alert, please inform your IT/ILS helpdesk staff or your friendly Evergreen developers. Sat Dec 12 2015 00:34:28 GMT+0400 (Georgian Standard Time) The action involved likely failed due to insufficient permissions. However, this part of the software needs to be updated to better understand permission messages from the server, so please let us know about it. PERM_FAILURE Permission Denied |
| 15:35 | lualaba | I try everything but nothing was helped |
| 15:37 | lualaba_ joined #evergreen | |
| 15:48 | jboyer-isl | I don't know if I'm making things better or worse, but I'm trying ubuntu's wily kernels on my new machines to see if that knocks out their network issues. The first test is "does it survive sudo shutdown -r now ?" |
| 15:53 | Bmagic | jboyer-isl++ |
| 15:55 | Bmagic | lualaba_: how about "STAFF_LOGIN" ? |
| 15:57 | jboyer-isl | By Jove; so far so functional. |
| 16:12 | Dyrcona | lualaba: You could try that. A stock installation should just work. |
| 16:12 | lualaba | have any chance to disable permission or delete? |
| 16:12 | lualaba | 2.9 release is stable? |
| 16:12 | Dyrcona | lualaba: I was going to suggest altering the depth that the view_billing_type permission is granted to existing groups as a test. |
| 16:12 | jeff | if the existing admin user works and newly created users do not work, it may be that the new users do not have a working location set. |
| 16:12 | Dyrcona | jeff++ could be that. |
| 16:13 | Dyrcona | I thought of the perm depth because the client appears to checking loc 1. |
| 08:56 | Dyrcona | I'm not sure our libraries would be too keen on their statistics being public, well any more public than they are. |
| 08:57 | Dyrcona | I'm sure some of the directors would love a dashboard app for their own use, though. |
| 08:57 | Dyrcona | mrpeters++ |
| 08:57 | Dyrcona | mrpeters: Thanks for testing the tarball. |
| 08:58 | Dyrcona | And for pointing out the breakage in the first place. |
| 09:00 | RoganH joined #evergreen | |
| 09:02 | * Dyrcona | is not sure how public the statistics become once they are reported to the Commonwealth. |
| 13:53 | * dbs | reads the nice, short LDAP_Auth.pm |
| 13:55 | dbs | looks like setting the host to ldaps://hostname will do the trick. yay |
| 14:17 | dbwells | dbs: I don't believe we are, would be a useful option to add certainly. |
| 14:26 | jeff | the fun next question is usually: what trusted cert store is the connection going to be tested against, if any? |
| 14:27 | jeff | not speaking of direct ldaps in Evergreen authproxy, but in more general terms with perl/python/etc libs. |
| 14:27 | Christineb joined #evergreen | |
| 14:31 | tsbere | jeff: I would assume the default system store. |
| 14:31 | tsbere | Usually that can be changed, but I doubt we did anything to change it. |
| 10:15 | mrpeters | no, i certainly can patch it on our end that is no worries |
| 10:15 | mrpeters | but, maybe we should pull the tarball from the site until fixed? |
| 10:17 | Dyrcona | And, everyone just ignores me.... |
| 10:20 | Dyrcona | mrpeters jeff: I or anyone else can build a new 2.9.1 tarball and test it. I do not have time at this very moment to do that. |
| 10:21 | mrpeters | Dyrcona: I'm not suggesting you should have to. I am happy to fix it and test it -- I just don't know where the bug is |
| 10:21 | Dyrcona | mrpeters: Probably just one of those things that happens at the last minute. |
| 10:22 | mrpeters | no im not trying to assess blame or figure out what caused it -- i'm saying i dont know where the duplicated insert into the upgrade log occurs to fix the tarball and give you a new one |
| 10:22 | Dyrcona | Like you said, it works fine from git. |
| 10:23 | jeff | mrpeters: it should contain only one instance of that line. |
| 10:23 | mrpeters | jeff: perfect, thats exactly what i needed to know |
| 10:23 | Dyrcona | Yeah, probably because make_release was run more than once. |
| 10:23 | mrpeters | lets just pull it from git, don't you think? |
| 10:24 | mrpeters | and put the 002.schema.config.sql from git in the tarball and then i can test it and confirm its fixed and we can release it on the site |
| 10:24 | jeff | I don't know if there are other likely places where there will be issues that share the same underlying cause as that duplication. |
| 10:25 | Dyrcona | As much fun as this is, and as much as this is my fault, I have work to do for my employer, now. I'll catch up later if I can. |
| 10:25 | mrpeters | good point |
| 16:16 | maryj joined #evergreen | |
| 16:20 | Dyrcona | @eightball Will Francis lighten up? |
| 16:20 | pinesol_green | Dyrcona: It is so. |
| 16:37 | phasefx | re: qa tests, I'm changing the ultimate pass/fail logic for the "Installing Evergreen pre-requisites" section, so that it just considers the final return value from the pre-req Makefile. There are 3 "Result: FAIL"'s currently from 3rd party tests in that section, one for Business-PayPal-API, one for Business-OnlinePayment-PayPal, and an expected one for Class-DBI-Frozen-301 |
| 16:45 | rlefaive joined #evergreen | |
| 16:58 | bmills joined #evergreen | |
| 17:00 | jlitrell joined #evergreen |
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