Evergreen ILS Website

IRC log for #evergreen, 2018-06-08

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

Time Nick Message
02:27 annagoben joined #evergreen
06:30 pinesol_green News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
07:11 rjackson_isl joined #evergreen
07:44 bdljohn joined #evergreen
08:23 rlefaive joined #evergreen
08:32 JBoyer sandbergja++ # Finding tuits for bug 1772444 where I had none
08:32 pinesol_green Launchpad bug 1772444 in Evergreen 3.0 "User information missing from billing receipts" [Undecided,Confirmed] https://launchpad.net/bugs/1772444
08:34 stephengwills joined #evergreen
08:41 idjit joined #evergreen
08:42 mmorgan joined #evergreen
08:49 rlefaive joined #evergreen
08:52 rlefaive joined #evergreen
08:59 rlefaive joined #evergreen
09:02 lsach joined #evergreen
09:12 kmlussier joined #evergreen
09:30 jvwoolf joined #evergreen
09:38 JBoyer acl_support++ # /me learns that non-Windows/non-VMS/etc. filesystems have come a long way since last paying attention to them.
09:51 kmlussier Good morning #evergreen!
09:52 kmlussier @coffee [someone]
09:52 * pinesol_green brews and pours a cup of Aricha Selection Seven Ethiopia Yirgacheffe, and sends it sliding down the bar to abneiman
09:52 kmlussier @tea [someone]
09:52 * pinesol_green brews and pours a pot of Holy Basil Purple Leaf, and sends it sliding down the bar to cesardv (http://ratetea.com/tea/upton/holy​-basil-purple-leaf-organic/1937/)
09:52 abneiman kmlussier++ # much-needed caffeine :)
09:53 kmlussier Poor cesardv didn't get any caffeine in his pot of tea. :(
09:55 abneiman yeah, but that tea sounds delicious though
09:58 idjit does anyone happen to have a test server with concerto data handy? i've got an oddity.
09:58 idjit and i'm not sure if it's just me or not
09:59 kmlussier idjit: https://mlnc4.noblenet.org
09:59 kmlussier Admin login is admin / evergreen123
10:00 idjit kmlussier++ # thanks!
10:02 idjit ok, my adventure started at bug 1775216. but i'm not sure if this is the same or different.
10:02 pinesol_green Launchpad bug 1775216 in Evergreen "Inconsistency between client and opac availability counts for statuses with is available flag" [Medium,Confirmed] https://launchpad.net/bugs/1775216
10:03 idjit https://mlnc4.noblenet.org/eg/opac/r​ecord/30?copy_limit=50;copy_offset=0 says there are 25 of 29 copies available, but only lists 24 copies. and i haven't yet figured out where the other 5 copies went.
10:03 idjit and the staff client view (https://mlnc4.noblenet.org/eg​/staff/cat/catalog/record/30) says that there are only 24 copies.
10:08 kmlussier mlnc2 has 2.12 and shows the correct count - https://mlnc2.noblenet.org/eg/opac/r​ecord/30?copy_limit=50;copy_offset=0
10:08 Christineb joined #evergreen
10:09 kmlussier I should start up a 3.0 VM and see what happens there. I suspect it broke in 3.0, which is what we saw with bug 1775216
10:09 pinesol_green Launchpad bug 1775216 in Evergreen "Inconsistency between client and opac availability counts for statuses with is available flag" [Medium,Confirmed] https://launchpad.net/bugs/1775216
10:10 kmlussier I guess it's not just the availability counts that are off.
10:11 idjit correct or consistent? i fear that the 24 might be wrong. copy id 31 (barcode CONC4000066) for example doesn't show up in any of the lists, but it looks normal enough in copy status. compare to copy id 431 (barcode CONC90000466).
10:12 idjit hrm.. location "reserves" instead of "stacks"... i wonder if the others are there too. i'll get back to you if i learn something. i'm just glad to confirm behavior is consistent on other instances.
10:16 Dyrcona joined #evergreen
10:17 kmlussier Reserves is OPAC visible for BR1, so it should be showing. I don't see anything else on that record that says it's not opac visible. Also, it's not displaying in the client either, which will show things that are not opac visible. hmmm
10:18 idjit fwiw, that's my patch on 1775216. i found this trying to write a pgtap test for it. the test fails since counts are still inconsistent, but for reasons other than the availability. should i add the test to the branch anyway, or wait until its passing?
10:23 kmlussier idjit: Well, it appears that the test is probably working, so you could add it. But there may be another bug that needs fixing.
10:24 kmlussier Also, idjit++ # Adding tests
10:27 kmlussier Nothing from BR1 is displaying on that record. That seems odd.
10:28 idjit in case it helps, the wayward copy ids for record 30 are 31, 531, 1031, 1531, and  2031
10:28 idjit and other records with similar situations include ids 24, 40, 93, 97, and 100. they all look to be in the same boat.
10:30 kmlussier I think the call numbers may be deleted?
10:30 idjit i hadn't thought of that. checking...
10:31 kmlussier But the copies are not deleted.
10:31 * mmorgan thinks kmlussier may be on to something
10:31 kmlussier There are two call numbers owned by BR1 on that record. Both are deleted.
10:37 idjit looks like it. i still get a mismatched count for records 24, 93, 97, and 100, but at least #93 lists the right number of items in the opac.
10:40 kmlussier It appears, then, as if the pre-3.0 method of counting copies appropriately excluded copies attached to a deleted call number, but, as of 3.0, those aren't being excluded from the count. Does that sound right?
10:40 idjit are you asking me if that sounds like the correct behavior (i have no idea), a reasonable theory for what we're seeing (that sounds about right), or asking someone else if they know what's going on? :-)
10:42 yboston joined #evergreen
10:42 kmlussier The 2nd. Is the a reasonable theory for what we're seeing.
10:42 mmorgan kmlussier: I'm not sure that's exactly what I'm seeing on another test system.
10:43 kmlussier mmorgan: Are you not seeing those types of copies being counted or are you seeing something totally different affecting the counts?
10:44 idjit deleted call numbers are certainly a part of it. that accounts for all of the missing copies on record #30.
10:44 mmorgan Well, first it's a 3.1 beta system, so not sure what that throws into the mix.
10:44 kmlussier mmorgan: I'm looking at 3.1.1
10:45 mmorgan Ok.
10:46 mmorgan I have 24 copies, not deleted, their call numbers aren't deleted either. In the public catalog, I see total copy count as 22
10:46 mmorgan I also have 7 undeleted copies on 2 deleted call numbers.
10:47 kmlussier mmorgan: It's possible there are multiple issues affecting copy counts.
10:47 mmorgan Yes, making it harder to pin down!
10:47 kmlussier mmorgan: What record id is it? I think I know which server it is.
10:48 mmorgan It's record 30. I'll paste a query that I used to see exactly what's on the record.
10:49 pastebot "mmorgan" at 64.57.241.14 pasted "Copy query" (9 lines) at http://paste.evergreen-ils.org/9703
10:57 beanjammin joined #evergreen
10:59 pastebot "mmorgan" at 64.57.241.14 pasted "Copy query results on mlnc4 - with status" (32 lines) at http://paste.evergreen-ils.org/9708
11:00 miker hrm... deleted CNs with extant copies is Bad Data (tm) ... is that consistently happening across concerto instances? that data is side loaded, so...
11:01 kmlussier miker: Yes, it's bad data and, unfortunately, bad data sometimes happens in the wild too. It appears to be happening across concerto instances.
11:01 kmlussier Actually, bad data is probably more likely to happen in the wild. :)
11:02 gsams joined #evergreen
11:02 mmorgan Indeed it is!
11:03 miker kmlussier: bad data does happen in the wild, sure. I think the fix is to stop the bad data from creeping in, and provide ways to detect/repair it, rather than making accommodations for it, though. (however, idjit's patch is a fix for a bug separate from bad data. I'll be looking at it later today, tuits willing)
11:05 kmlussier miker: But the pre-3.0 code apparently handled this potential scenario appropriately? Shouldn't the 3.0 plus code do the same?
11:05 mmorgan I undeleted the two deleted call numbers on my test system, and the copy counts are correct now.
11:05 kmlussier Actually, I should verify that the 2.12 system has the same bad data before I say that with certainty.
11:06 * mmorgan runs off to check for undeleted copies on delete call numbers in the wild (production server, that is)
11:06 miker I think "appropriately" may be open to question. but differently, it seems.  It didn't explicitly check for the deleted flag on an intervening table, but I'd argue that's a deficiency in the previous code, and checking deleted=f is more correct
11:07 miker but if the effect of the old code is desirable (ignore deletedness of CNs with live copies) then I think the fix is to provide an upgrade that undeletes call numbers that have live copies. does that sound reasonable?
11:08 miker and, we should be looking for how CNs might be deleted with live copies (or copies added to deleted CNs, perhaps)
11:08 miker but if we're only seeing this on concerto data, I'd make the side-loading scripts suspect number one...
11:10 kmlussier I don't know. Is anyone seeing this kind of data on production systems? I don't have a production system to check.
11:10 Dyrcona Deleted call numbers with not deleted copies?
11:10 kmlussier yes
11:10 miker kmlussier: I'm looking at one big data set right now
11:10 * kmlussier suspects that, if it did happen, it would occur through direct database updates.
11:10 Dyrcona Probably. I'll check.
11:10 miker select count(*) from asset.call_number cn where deleted and exists (select 1 from asset.copy where call_number = cn.id);
11:10 miker er, that's not complete
11:10 * mmorgan found 63 undeleted copies on deleted call numbers (live bibs)
11:11 miker select count(*) from asset.call_number cn where deleted and exists (select 1 from asset.copy where call_number = cn.id and not deleted);
11:12 mmorgan Here's what I used...
11:12 pastebot "mmorgan" at 64.57.241.14 pasted "query for copies on deleted call numbers" (6 lines) at http://paste.evergreen-ils.org/9714
11:13 Dyrcona I have 4. Didn't check if the bibs were deleted or not.
11:14 dbs Maybe the concerto data deliberately sets up the acn/acp situation?
11:14 Dyrcona One of these call numbers has id -1.
11:14 mmorgan miker's query gave me 102
11:15 miker Dyrcona: heh ... I've seen CN -1 get deleted before. it shouldn't be, but it doesn't actually create problems, I think.
11:15 Dyrcona I did a select cound(distinct acn.id) ....
11:15 Dyrcona s/cound/count/
11:15 Dyrcona miker: I've seen it before, too, but don't recall the problems.
11:16 Dyrcona I'll undelete it in a sec.
11:16 kmlussier miker: I might be misunderstanding what you said above, but I think your description above of the old code ignoring the deletedness of CNs with live copies isn't what was happening.
11:16 miker I have a theory I'm testing... I wonder if the copies were accidentally deleted and then someone undeleted them in the DB directly without undeleting the CN (which was auto-deleted with the last copy)
11:16 kmlussier Undeleted copies that are attached to a deleted CN do not display in the holdings list. This seems correct to me.
11:17 Dyrcona select count(distinct acn.id) from asset.call_number acn join asset.copy acp on acp.call_number = acn.id and not acp.deleted where acn.deleted;
11:17 dbs 120 instances of acn=deleted acp=not deleted in production here
11:17 miker and, for me at least, that theory seems to hold water.
11:17 kmlussier Prior to 3.0, the count also did not count those holdings, making it consistent with the catalog display. That also seems correct to me.
11:17 miker I looked at the auditor table for asset.copy and see the copies were deleted in the past
11:17 miker only direct db access can undelete copies, so...
11:18 yboston joined #evergreen
11:18 miker (that is, my 3 instances in the wild)
11:20 idjit completely unrelated, should https://mlnc4.noblenet.org/eg/opac/r​ecord/24?copy_limit=50;copy_offset=0 have a green header bar, like https://mlnc2.noblenet.org/eg/opac/r​ecord/24?copy_limit=50;copy_offset=0 does?
11:20 kmlussier Whatever we for those specific copies, I think the logic used to determine what displays in the holdings table should match the logic of what is counted above.
11:21 kmlussier idjit: That's related to whether you're already logged into the client or not. It is removed when you have a client login.
11:21 idjit oh, i see. thanks!
11:21 kmlussier idjit: no problem!
11:22 miker kmlussier: agreed, count and list should match.  I /think/ that means checking the deleted flag on asset.call_number, right?
11:22 kmlussier miker: Yes
11:22 kmlussier miker: But the counts in 3.0+ is not checking the deleted flag
11:22 kmlussier s/is/are
11:23 idjit ^opac counts aren't checking deleted flag. it looks like staff client counts are.
11:23 idjit (3.0+)
11:23 kmlussier Yes, what idjit said. I forgot about the client/opac differences.
11:24 miker right, that's what idjit's patch does IIUC
11:24 idjit the patch does not care about deleted. it cares about if the copy status has "is_available" set to true or false in config.copy_status.
11:25 * miker goes looking for the code before speaking more :)
11:26 idjit what i mean is: there's more than one difference between the staff client and opac queries. asset.opac_ou_record_copy_count vs asset.staff_ou_record_copy_count.
11:27 miker idjit: ok, gotcha. I looked at the tip commit and that code does include "AND NOT cn.deleted", and misremembered the previous commit ... the patron version needs to learn that part
11:27 kmlussier Yes, the original report related to availability counts, but, in writing a test for that fix, idjit discovered this other issue with the delete cns
11:27 kmlussier idjit++
11:28 miker since they're very related, I'm in favor of fixing both in one branch, and adding a "UPDATE asset.call_number SET deleted=false WHERE..." to the upgrade script. fwiw
11:29 kmlussier +1
11:30 idjit what about the lasso and metarecord versions of these functions?
11:31 mmorgan miker: Could there be potential problems with collisions with undeleted call numbers that are otherwise identical?
11:32 miker mmorgan: yes. would it be preferable to merge those copies to live CNs?
11:33 mmorgan Yes, I would say so.
11:33 miker that's straight-forward enough, I think
11:35 Dyrcona Hm... One of these deleted call numbers was created post upgrade and I know we have not updated any copies in the database since.
11:37 kmlussier Dyrcona: Possibly a web client issue that hasn't been discovered yet?
11:38 Dyrcona kmlussier: Looks like it. It was created 6/1 and deleted 5 minutes later. The copy is not deleted.
11:39 miker Dyrcona: to the logs!(?)
11:39 Dyrcona Maybe later.
11:49 mmorgan Interesting, one of the items with a deleted call number has been in that state for several years but has managed to circulate six times without being visible in the catalog.
11:52 miker mmorgan: the magic of shelf browsing? :)
11:53 mmorgan Yes, or perhaps holds
11:55 kmlussier mmorgan: How could there be a hold if it's not visible in the catalog?
11:56 mmorgan Other libraries have copies so the record is visible. Looks like a title that might attract holds, to me: https://evergreen.noblenet.​org/eg/opac/record/3019368
12:03 beanjammin joined #evergreen
12:22 jihpringle joined #evergreen
12:34 idjit y'all sick of me yet? perhaps a cat would help... https://i.imgur.com/KIPOlfY.gifv
12:34 idjit anyway, holdings view (web staff client, 3.1) includes call numbers that have no copies, so for record #30 it says there are 26 items, but opac view say 24 items. is "inconsistent" or "expected"?
12:45 kmlussier idjit: We are never sick of people working to fix a bug!
12:48 kmlussier idjit: Are you asking if call numbers with no copies should be counted? No, I wouldn't think so. Quite often, the client will show more copies than in the opac, but it's usually due to copies that are not opac visibile.
12:48 kmlussier visible, even
12:50 kmlussier Poor kitty.
12:50 rlefaive joined #evergreen
12:56 mmorgan kmlussier: idjit: I think the empty call numbers should show in holdings maintenance as long as they are not deleted. Empty call numbers shouldn't be included in copy counts, though.
12:59 kmlussier Yes, but I don't believe they are showing in current Evergreen holdings view right now. That patch hasn't been merged yet. I was specifically referring to the count in my answer.
13:21 idjit that looks good then. the rows in the holdings view are numbered, so if you scroll down you can see there are 26 holdings, but 24 records. (because two CNs have no copies).
13:21 idjit s/records/copies/
13:41 jeffdavis Dyrcona: yesterday you mentioned problems with copy templates - are you seeing the problem described in bug 1772062 ?
13:41 pinesol_green Launchpad bug 1772062 in Evergreen "Copy Template Missing Values When Applied" [High,Confirmed] https://launchpad.net/bugs/1772062
13:41 rlefaive joined #evergreen
13:47 Dyrcona jeffdavis: I don't recall seeing reports of that. We were getting reports of the templates drop down being empty.
13:49 jeffdavis interesting, thanks
14:06 Dyrcona jeffdavis: I think the two bugs might be related just the same.
14:07 Dyrcona I don't see all of our tickets by default, so I'm looking through some others.
14:08 kmlussier The templates being empty might be related to bug 1773995.
14:08 pinesol_green Launchpad bug 1773995 in Evergreen "web client: xul copy template conversion does not immediately propagate xul templates to templates tab" [Medium,Confirmed] https://launchpad.net/bugs/1773995
14:09 Dyrcona Someone did report stat cats not applying when they used a template, but then when they logged out and logged back in, the templates drop down was empty.
14:09 Dyrcona kmlussier: It's almost always a case of "they showed up yesterday (i.e. pre-opensrf update) and they're gone today."
14:10 Dyrcona So, I reverted the OpenSRF patch and went back to the older apache-websocket module.
14:10 * kmlussier thinks she missed something in that bug description.
14:10 kmlussier Dyrcona: Sure, I wouldn't be surprised if there were more causes. That's just the one I was able to make happen.
14:11 Dyrcona OK.
14:11 Dyrcona It looks like only 1 ticket out of about 5 mentions templates not applying completely.
14:12 Dyrcona The other tickets are of the variety of some or all of our templates are missing (mostly all).
14:12 Dyrcona And that one ticket that does mention templates not applying everything is the one I mentioned where the templates later disappeared.
14:19 rlefaive joined #evergreen
14:24 kmlussier @dessert [someone]
14:24 * pinesol_green grabs some coffee frappes for jvwoolf
14:25 kmlussier If I had known it was going to be coffee frappes, I would have given it to myself.
14:27 idjit what is asset.copy_vis_attr_cache?
14:31 pastebot "idjit" at 64.57.241.14 pasted "evergreen=# select target_copy" (28 lines) at http://paste.evergreen-ils.org/9803
14:31 idjit i'm still on asset.opac_ou_record_copy_count and i'm getting incorrect counts on concerto data for records 24, 93, 97, and 100. something looks wrong with the data here.
14:34 JBoyer joined #evergreen
14:38 kmlussier idjit: It was added with bug 1698206 and is what we now use to determine if a copy is opac visible or not.
14:38 pinesol_green Launchpad bug 1698206 in Evergreen "Eliminate staged search" [Wishlist,Fix released] https://launchpad.net/bugs/1698206
14:47 idjit kmlussier: thanks. it looks like i managed to bork my data then. i'm not getting the same counts on mlnc4.noblenet.org. is it necessarily a problem if the same copy has multiple rows in asset.copy_vis_attr_cache? should  that be a unique key for this table?
14:48 idjit i'm curious if that first query in my paste a minute ago is expected to return anything or not. i suspect not, since those four extra records are the exact four that are making my test fail.
14:56 idjit wait! it's a foreign item. ....what the heck is a foreign item, and should that be included on the copy counts?
14:59 kmlussier idjit: Those are for peer bibs, which I'm not very familiar with. There is a bug related to copy counts for peer bibs that pre-dates asset.copy_vis_attr_cache.
14:59 kmlussier bug 1587620
14:59 pinesol_green Launchpad bug 1587620 in Evergreen "Staff copy counts do not include peer bib copies" [Undecided,New] https://launchpad.net/bugs/1587620
15:00 idjit kmlussier++ # that's gotta be it. thanks!
15:00 kmlussier idjit: I also just tried your sql query on mlnc4 and I'm getting the same results.
15:01 idjit https://mlnc4.noblenet.org/eg/opac/record/24 says there are 32 copies, https://egmaster.grpl.org/eg/opac/re​cord/93?copy_limit=50;copy_offset=0 says 31 copies. the difference is the foreign/peer one. so my test is still failing. guess i figured out which bug to work on next :-)
15:02 idjit yeah, so the same copyid is allowed to show up multiple times in that table if it's a foreign/peer copy for the listed records. the concerto dataset only has the one copy that uses this.
15:02 idjit the opac version of copy counts joins on the copy_vis table, but the staff version doesn't, which is why the counts are off.
15:03 rlefaive joined #evergreen
15:15 pinesol_green [evergreen|Cesar Velez] LP#1745422 - Add Parts column to Patron holds grids and detail view - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=0da274f>
15:15 pinesol_green [evergreen|Michele Morgan] LP#1745422 - Removed three commented out lines from the code and signoff. - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=6a41918>
15:19 miker idjit: you could get multiple rows for one copy if the copy is involved in conjoined bibs (that is, linked to a "foreign" record)
15:19 miker oh, nm, you figured that out :)
15:20 idjit miker++ still appreciate it. :-)
15:20 * miker promises, again, to read all scrollback before answering...
15:21 sandbergja joined #evergreen
15:24 kmlussier miker: lol - that could be our new conference karaoke challenge. Anyone who adds to a discussion without reading scrollback has to sing.
15:25 * kmlussier will do anything to get out of the current karaoke challenge that involves meeting annual report deadlines.
15:25 miker heh
15:30 * rhamby makes notes to start logging irc for kmlussier not reading back
15:30 kmlussier Darn! I didn't realize rhamby was paying attention.
15:31 miker rhamby /always/ reads the scrollback
15:52 * berick sings Don't call it a scrollback
15:53 rhamby berick++
16:47 * miker reads berick's first line in the LP comment as "push-ed", like Shakespearian "banish'd"
16:49 berick bless'ed be the lp reader
16:49 kmlussier berick++ # Fighting white screens.
16:54 jvwoolf left #evergreen
16:57 yboston joined #evergreen
17:01 pinesol_green [evergreen|a. bellenir] LP1775294: item status should show floating group name - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=10e9ee8>
17:06 kmlussier I think that may be idjit's first contribution that has been merged. idjit++
17:06 idjit whoo! \o/
17:07 mmorgan idjit++
17:07 berick idjit++ # woo
17:07 * idjit blushes
17:08 mmorgan left #evergreen
17:09 idjit kmlussier: regarding bug 1743801, honestly, i had the same reservations. i think it'd be better if fine_level and loan_duration were "fleshable" fields in the fieldmapper. but the DB constraint says ANY (ARRAY[1, 2, 3]), and it's not a foreign key to anything.
17:09 pinesol_green Launchpad bug 1743801 in Evergreen 3.0 "web client: item status list view display issues" [High,Confirmed] https://launchpad.net/bugs/1743801
17:11 kmlussier idjit: Yes, I think it's probably fine the way it is, but I wanted another set of eyes to look at it just in case I was missing something.
17:11 idjit were you going to merge the optional page for "yes/no" instead of "true/false" as well? (that bug is a mess. damn n00bz dont know how to submit a proper patch.)
17:11 idjit s/page/patch/
17:19 pinesol_green [evergreen|Geoff Sams] LP#16989634 - Changing z-index to 4 to allow active text boxes to pass under patron tabs naturally. - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=60caf87>
17:23 kmlussier idjit: No, I was going to suggest a new bug for it if people still thought it was an issue. I personally think it's fine the way it is, but I'm happy to go with community consensus.
17:23 kmlussier It's hard to get that consensus on a bug with so many pieces to it.
17:24 kmlussier gsams++ # First code contribution!
17:25 idjit kmlussier: oh, perfect. it was referenced on bug 1741347, too, so i think you're right; a separate issue would be best.
17:25 pinesol_green Launchpad bug 1741347 in Evergreen "Web client: display issues in Copy buckets" [Undecided,New] https://launchpad.net/bugs/1741347
17:25 idjit gsams++
17:25 idjit kmlussier++
17:32 gsams kmlussier: Thanks!  It was small, but I was happy to start somewhere!
17:34 kmlussier gsams: Most of us started small. But once you get that first commit in, there's no stopping you. :)
17:34 kmlussier https://wiki.evergreen-ils.org/dok​u.php?id=contributing:contributors has been updated. A very nice way to end the work week.
17:34 kmlussier Have a nice weekend everyone!
18:17 jeffdavis anyone have a magic spell handy for automatically killing long-running search queries?
18:18 jeffdavis (I know how to manually inspect and cancel backend)
18:26 jeffdavis nvm, found it
18:30 pinesol_green News from qatests: Failed Log Output: osrfsys.log - Expected 3 errors but encountered 6. <http://testing.evergreen-ils.org/~live>
18:37 stephengwills joined #evergreen
19:49 bdljohn joined #evergreen
21:07 bdljohn joined #evergreen

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat