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
| 09:37 | RoganH joined #evergreen | |
| 09:42 | mllewellyn joined #evergreen | |
| 09:44 | BigRig joined #evergreen | |
| 09:52 | berick | eeevil: ideally w/ an LP listing what to test. i'm happy to review, test, sign-off |
| 09:53 | eeevil | berick: you mean you want an lp bug for each bug/fix, or a listing of what's fixed on one bug |
| 09:53 | berick | i think one bug is fine |
| 09:57 | eeevil | k |
| 10:37 | jboyer-isl | It depends on how much (and how directly) misc_util is pulled into a module. I'm probably not giving it the necessary level of thought myself. (I came across that bug while looking for another bug that I apparently never filed) |
| 10:40 | jboyer-isl | display fields would probably take care of any potential issues I have with misc_util going away, I was just thinking of all of the hard-coded tags and fields from that file being pulled behind the scenes, which I suppose isn't really the intent. |
| 11:34 | RoganH_ joined #evergreen | |
| 11:37 | abowling | i'm trying to test changes on the place_hold.js script that affects the place_hold.xul template. i clear my cache, restart apache, and restart services, but it seemingly has no effect. i looked to see if the javascript exists on my local machine, and it doesn't. any ideas? |
| 11:40 | bshum | abowling: So to be clear, you're making changes to that file in the server side installed version? |
| 11:40 | bshum | Somewhere in /openils/var/web/xul/server/... |
| 11:40 | abowling | bshum: yes. |
| 11:42 | bshum | Are you sure that the staff client version of your client is matching to where server links to for the files server-side? |
| 11:42 | abowling | didn't think i'd need to restart apache. just making sure it wasn't cached on the server somewhere. |
| 11:43 | bshum | Or did you try editing the specific version's installed folder content |
| 11:43 | abowling | bshum: yes. it's the EDN master we use for testing. |
| 11:43 | bshum | Well, it sounds like you got all your bases covered to me. Maybe the change you're expecting to happen isn't happening. |
| 11:44 | abowling | bshum: i'm editing the specific installed version file, fwiw |
| 11:44 | abowling | it's confounding |
| 07:58 | akilsdonk joined #evergreen | |
| 08:06 | rjackson-isl joined #evergreen | |
| 08:22 | Ghid0rah joined #evergreen | |
| 08:24 | Ghid0rah | Good morning all. Does anyone know if there is a way to test Evergreen's email notification configuration in Evergreen 2.7.2? |
| 08:29 | mrpeters joined #evergreen | |
| 08:37 | mmorgan joined #evergreen | |
| 08:47 | graced joined #evergreen | |
| 19:26 | conlinism | If I were looking to get involved in contributing to the web front end of Evergreen, how would I do that? |
| 19:35 | csharp | ~contribute |
| 19:35 | pinesol_green | Interested in contributing to the Evergreen project? Please see http://www.evergreen-ils.org/dokuwiki/doku.php?id=contributing and http://evergreen-ils.org/dokuwiki/doku.php?id=eg_developer_overview. |
| 19:35 | csharp | conlinism: basically, read this^^, then install evergreen on a test server and start hacking! |
| 19:39 | conlinism | thanks! |
| 20:22 | rangi joined #evergreen | |
| 20:36 | nhilton joined #evergreen |
| 09:27 | Dyrcona | Debian package maintainers strike again! |
| 09:28 | Dyrcona | Pakaging erlang with the distributed features turned off. |
| 09:29 | Dyrcona | Thereby defeating the whole point of erlang. |
| 09:29 | tsbere | Supposedly fixed, but not on any version we are running on our end. <_< |
| 09:29 | tsbere | (which broke me testing stuff with it this weekend) |
| 09:30 | jeff | "Oh honey, he's teasing you. Nobody has TWO computers." |
| 09:36 | kmlussier | berick: We're due for another Bug Squashing Day in February. But I don't want it to interfere with 2.8 release activities. Do you have any thoughts on what timing would work best? |
| 09:36 | kmlussier | Maybe we should put it off until March. |
| 11:16 | pinesol_green | kmlussier: The operation succeeded. kmlussier hates undrinkable coffee. |
| 11:17 | csharp | @coffee kmlussier |
| 11:17 | * pinesol_green | brews and pours a cup of Kenya Peaberry Thika Gethumbwini, and sends it sliding down the bar to kmlussier |
| 11:18 | kmlussier | csharp: Thank you! I'm sure it will be better than the cup I just poured down the drain. |
| 11:25 | kmlussier | I apparently shouldn't be testing without my usual allotment of caffeine. I just set up a Vandelay match set that says "020 and 022 and 024 and 028" and then couldn't figure out why none of my incoming records were finding matches. |
| 11:33 | jihpringle joined #evergreen | |
| 11:35 | kmlussier | berick: I'm looking at bug 1350371. In the original description, you say Evergreen will "warn" the user if a duplicate PO name is used. The term "warn" makes me think a user can override the warning, but I don't see a way to override it and use the same PO name. |
| 11:35 | pinesol_green | Launchpad bug 1350371 in Evergreen "ACQ improved duplicate order detection" (affected: 1, heat: 6) [Wishlist,New] https://launchpad.net/bugs/1350371 - Assigned to Kathy Lussier (klussier) |
| 11:36 | kmlussier | Should I be able to override it and use the same PO name if I need to? Or is it working as designed? |
| 11:36 | berick | kmlussier: it should probably say "prevent" |
| 14:19 | gmcharlt | ok, hearing no questions, moving on |
| 14:19 | gmcharlt | #topic New business - quality assurance |
| 14:19 | gmcharlt | kmlussier? |
| 14:20 | kmlussier | Sure. The folks at MassLNC were revisiting the QA report done a little over a year ago. |
| 14:21 | kmlussier | Since the report was issued, the community has come together to agree to do PGTap tests. But there are other recommendations that haven't been implemented yet. |
| 14:21 | kmlussier | So I thought it would be good to start a discussion among all of you to get a sense of what you think is needed to implement some of those other recommendations. |
| 14:22 | jeff | especially relevant since we're looking at a soon-to-be era where xulrunner is no more for Evergreen: ``there may be areas where improvements will be limited until Evergreen moves away from XULRunner'' |
| 14:23 | kmlussier | jeff: Are you thinking testing will become easier when we are off XULRunner? |
| 14:24 | dbs | Even on the PGTap side of things, we haven't really kept up with our commitment to add tests as we change the SQL |
| 14:24 | jeff | I was just quoting the part of the report that asserted (now I'm paraphrasing) that a move away from xulrunner would open the door for more improvements to QA and testing. |
| 14:25 | bshum | So, I admittedly haven't read the full report in awhile, but I'm not seeing any specific approaches being suggested. So the question on the floor is whether we would like to plan on finding some specifics and applying them towards say, the web client (as it's being created) |
| 14:25 | kmlussier | Is part of the issue the fact that we don't have people with the expertise and/or time to take charge of QA? |
| 14:26 | eeevil | kmlussier: I think that's The(tm) perpetual challenge ;) |
| 14:26 | gmcharlt | time in particular |
| 14:26 | dbs | But we kind of don't have the time to not do QA either |
| 14:27 | gmcharlt | also true |
| 14:27 | kmlussier | I also think testing goes beyond the client. For example, there were recommendations for a test suite to test for performance, for example. |
| 14:27 | dbs | Lacking at least one person with expertise + time, though, yeah, it's a problem. |
| 14:28 | kmlussier | So, I know there are people in the community who would be willing to put resources into bringing on a person to manage that process if it were needed. |
| 14:29 | kmlussier | First, I think it would be good to know if that is, indeed, what is needed. |
| 14:29 | kmlussier | Also, I didn't know if it would be worthwhile to look at other projects to see how QA is done. And, then, maybe pull the best from those projects to see what would work best for Evergreen. |
| 14:30 | jeffdavis | What would "bringing on a person" entail? |
| 14:30 | berick | well, there are some things we already have a good handle on (e.g. pgtap tests, perl unit tests, perl live tests). for those types of things, i think we just have to make ourselves do it. |
| 14:31 | berick | there's a lot we could do we're just not doing. |
| 14:31 | dbs | amen |
| 14:31 | kmlussier | berick: Does everyone contributing code have a good handle on that? |
| 14:31 | berick | having someone whose job it is to think about it for big picture stuff would be great, but we shouldn't let that slow us down |
| 14:32 | jeff | berick: during sprint 1 of the web client, you had some unit tests in place (correct me if i'm wrong) -- could you hazard a guess as to what percentage of interfaces have unit tests? |
| 14:32 | berick | kmlussier: well, no, because we don't do it regularly enough for everyone of have templates to work from |
| 14:32 | gmcharlt | a somewhat stricter attitude about requiring pgTap tests and Perl unit tests to accompany patches would be a step forward for the 2.8 cycle |
| 14:32 | berick | jeff: those unit tests were almost entirely focused on the services (i.e. the stuff under the interfaces) |
| 14:33 | berick | jeff: so, very little UI coverage |
| 14:33 | berick | gmcharlt: agreed |
| 14:34 | jeff | berick: got it. thanks. |
| 14:35 | phasefx | jfyi, one notion I encountered was to not focus on testing "services" through the UI, but the test the UI itself (widgets, etc.) if testing the UI, and test the services more closely to where they live if testing the services |
| 14:35 | kmlussier | I think my group would be in favor of stricter requirements for tests and whatever else you can do now. |
| 14:35 | gmcharlt | as far as I'm concerned personally, providing pgTap + perl tests for the stuff I'm slated to do for 2.8 is easy enough |
| 14:36 | kmlussier | But if the developers, as a group, told me, "we really need somebody to manage this process," I would do what I could to make that happen. |
| 14:37 | dbs | I imagine the developers are trying to imagine how such a person dropped into our midst could actually manage the process. |
| 14:37 | kmlussier | I'm mostly concerned that there is still more testing beyond pgTap and perl tests that we need to be doing. |
| 14:37 | dbs | Buy-in would be tough. |
| 14:38 | jeff | I consider myself a novice with regard to Perl tests, and moreso with regard to pgTap tests. I'd be willing to extract knowledge and experience from others and formulate something of a reference / set of guidelines for contributors in the hope that it would help myself and others include appropriate tests in contributions. |
| 14:38 | gmcharlt | on the other hand -- somebody who had an explicit committment to review patches (and who could come up the speed) might be an easier dose of medicine, as it were |
| 14:38 | kmlussier | Yes, well, that's why I'm raising the questions here. |
| 14:39 | * dbs | would like to automatically test the TPAC for basic accessibility compliance, ensuring RDFa comes out right, ensuring data is displayed as expected (which would be hella useful if we move misc_util.tt2 into Perl module land) |
| 14:39 | jeff | dbs++ good job putting words to what I was thinking ("dropped into our midst" comment above) |
| 14:40 | kmlussier | Well, any new developer is essentially "dropped into our midst," right? |
| 14:40 | berick | jeff: i'd be happy to help review/edit any such guidlines |
| 14:40 | dbs | Unfortunately most of those tests would require python for RDFLib and I'm not keen on introducing more dependencies |
| 14:40 | gmcharlt | dbs: does that translate to "you are willing to help set up such testing"? I'd be happy to collaborate with you on that |
| 14:41 | jeff | berick++ sounds good. |
| 14:41 | dbs | kmlussier: yes, but the mindset is often such that a new developer == "yay they're helping build this thing" vs "this person is getting in the way" |
| 14:41 | gmcharlt | vs "this stranger is TELLING US WHAT TO DO. OH NOES!" |
| 14:43 | berick | i would welcome someone whose job it was to research and present ideas, proofs-of-concept, etc. on QA stuff. |
| 14:43 | berick | "manage" and "take charge" may not be the right words |
| 14:43 | berick | "drive" maybe |
| 14:43 | jeff | berick: as 2.8 RM how do you feel about gmcharlt's proposal of "a somewhat stricter attitude about requiring" tests? |
| 14:43 | dbs | "Hey, look at what you can do with a few lines of additional code" |
| 14:43 | kmlussier | Yes, "drive" is a good word. :) As gmcharlt said, somebody with an explicit commitment. |
| 14:44 | gmcharlt | berick: and "review patches"... I really think it does need to be grounded |
| 14:44 | berick | jeff: +1 from me for bumping to strictness level 2 |
| 14:44 | berick | gmcharlt: ah, yes, that would ideal |
| 14:45 | jeff | gmcharlt: am i correct in thinking that koha has an explicit "QA" signoff? Is that a mostly automatic (tests passed!) signoff, or is that a human signing off with a specific eye toward QA? |
| 14:46 | jeff | (deja vu -- i may have asked this question before) |
| 14:46 | gmcharlt | jeff: the Koha process seeks two signoffs |
| 14:46 | gmcharlt | 1st signoff is from essentially anybody who can install the patch and run it through its paces |
| 14:47 | dbs | #link One accessibility checking API: http://wave.webaim.org/api/ (costs $$$ but it's an option) |
| 14:47 | gmcharlt | the 2nd, QA signoff is based on an inspection by a human member of the QA team + the patches passing a set of extra, mostly static source-code level tests |
| 14:47 | berick | as far as 2.8 goes, we'll need some guidelines for building tests, what the minimal requirements are. I can build/collaborate on that. i'll obviously need input, though. |
| 14:47 | berick | and since it's late in the game, we'll have to be pretty forgiving |
| 14:48 | jeff | sure. nobody's proposing FESTIVITY^WSTRICTNESS LEVEL 4. |
| 14:49 | gmcharlt | so we have, to sum up, the following concrete suggestions at th emoment |
| 14:49 | gmcharlt | 1. incrementing the strictness level |
| 14:49 | gmcharlt | 2. berick et al writing up some guidelines and templates for pgTAP and perl unit tests |
| 14:49 | gmcharlt | 3. dbs and galen putting together some automatic testing of TPAC and RDFa output |
| 14:50 | gmcharlt | and less concretely, some fuzzy input on desiderata for a "QA person" |
| 14:50 | dbs | #link another accessibility checking API: https://github.com/inclusive-design/AChecker (GPL v2) |
| 14:50 | * gmcharlt | has used AChecker in the past, FWIW |
| 14:51 | kmlussier | gmcharlt: Would it be helpful if someone (I can volunteer) do an environmental scan of other projects and who they handle these issues? |
| 14:52 | gmcharlt | kmlussier: I haz thoughts on the matter and would be interested in working with you on it |
| 14:53 | kmlussier | jeff: The who is part of it, but the overall process too. |
| 14:53 | kmlussier | gmcharlt: Thanks! |
| 14:55 | gmcharlt | so, just to double-check -- are folks (particularly committers) OK with stricter enforcement of providing pgTAP & perl unit tests for the 2.8 cycle? |
| 14:55 | eeevil | may I as that followups happen on the -dev list? (rather than -general, not to exclude folks, but to avoid pulling in -dev help) |
| 14:55 | eeevil | the kmlussier + gmcharlt + dbs + berick + others followups, I mean |
| 14:56 | kmlussier | eeevil: That's fine with me |
| 14:56 | gmcharlt | agreed |
| 14:56 | jeff | It will make some things harder, but those things may well be the things that would most benefit from unit tests. |
| 14:57 | jeff | (or pgTAP tests) |
| 14:57 | eeevil | gmcharlt: for my part (re agreement), yes, where applicable and reasonable (that is, not useless for lack of context), stricter enforcement of tests |
| 14:57 | * eeevil | does not plan to write tests that require a mock env that emulates all of Evergreen ... fwiw ;) |
| 14:57 | gmcharlt | eeevil: indeed - I can point to some examples in recent memory of cases where some testing-for-the-sake-of-following-the-rules was in play |
| 14:58 | jeff | eeevil: I don't think that any of our employers have enough time that tests for the sole sake of tests will be a common thing. :-) |
| 14:58 | phasefx | are we excluding or including integration tests here against live test systems? |
| 14:58 | gmcharlt | but I will emphasize that at the moment, Evergreen is in no danger of that! |
| 14:58 | eeevil | gmcharlt: fair ;) |
| 14:58 | berick | phasefx: I was hoping to encourage the use of live tests for changes that can't be tested in a vacuum, if that's what you're asking |
| 14:58 | gmcharlt | OK, I'm going to summarize, then move on to the next agenda item |
| 14:59 | phasefx | berick: sounds good to me, and I just saw eeevil's desire not to build huge mock environments :) |
| 14:59 | gmcharlt | #item There is general agreement that for the 2.8 cycle, we'll be stricter about requiring relevant pgTAP & perl unit tests |
| 14:59 | gmcharlt | #info There is general agreement that for the 2.8 cycle, we'll be stricter about requiring relevant pgTAP & perl unit tests |
| 14:59 | gmcharlt | #info berick will write some guidelines on writing Perl and pgTAP tests |
| 15:00 | gmcharlt | #info dbs and gmcharlt will work on automating accessibility and RDFa tests of TPAC |
| 15:00 | jeff | berick: see what i did there, how that turned from you reviewing/editing to writing those from scratch? ;-) |
| 15:00 | gmcharlt | #info kmlussier will do an environement scan of QA practices and experts in other project, with help from gmcharlt and others |
| 15:00 | * jeff | ducks |
| 15:21 | gmcharlt | #topic Negative blances / billing improvements |
| 15:21 | gmcharlt | #link https://bugs.launchpad.net/evergreen/+bug/1198465 |
| 15:21 | pinesol_green | Launchpad bug 1198465 in Evergreen "Support for Conditional Negative Balances" (affected: 14, heat: 66) [Wishlist,Confirmed] |
| 15:21 | dbwells | I'm already late for another meeting, so I'll make this quick. |
| 15:21 | dbwells | Basically, I'm just fishing for help in testing some or all of the billing changes which have grown on that bug. |
| 15:22 | dbwells | As I stated in the agenda, I think separating out the root-level stuff and getting that tested/committed first would be a good strategy. Any takers for testing? |
| 15:22 | berick | dbwells: +1 to the idea of breaking out cstore billing to its own LP. I would help poke at that. |
| 15:22 | jeff | I'm interested in testing. |
| 15:22 | berick | it's much more digestable... |
| 15:22 | kmlussier | I'm interested in testing too. |
| 15:22 | dbwells | sweet, thanks all |
| 15:22 | jeff | I hate to ask, but... are there tests in the root-level stuff at this point in time? |
| 15:23 | dbwells | I've been working this morning on getting the cstore stuff separated, it wasn't too bad. |
| 15:23 | dbwells | jeff: Only in that it doesn't (or mightn't) break the existing billing tests. |
| 15:24 | dbwells | At least that portion isn't meant to do anything new. Not that we couldn't always use more tests, of course. |
| 15:24 | jeff | In some ways, that's enough! Always nice when there are existing relevant tests. :-) |
| 15:24 | gmcharlt | #action dbwells will separate the cstore billing code into a separate bug; jeff and berick will help with testing |
| 15:25 | gmcharlt | and I suggest follow-up to open-ils-dev |
| 15:25 | dbwells | I am out for now. Thanks again to those who volunteered; expect to be bugged by me soon. |
| 15:25 | jeff | dbwells++ |
| 15:26 | kmlussier | dbwells++ |
| 16:59 | berick joined #evergreen | |
| 16:59 | Bmagic joined #evergreen | |
| 16:59 | bshum | Calling 0903 |
| 17:03 | pinesol_green | Showing latest 5 of 6 commits to Evergreen... |
| 17:03 | pinesol_green | [evergreen|Jason Stephenson] LP#980296: Add void of lost processing fee on claims returned. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=806ecaa> |
| 17:03 | pinesol_green | [evergreen|Jason Stephenson] LP#980296: Update void on claims returned for longoverdue status. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fc361aa> |
| 17:03 | pinesol_green | [evergreen|Jason Stephenson] LP#980296: pgtap tests for the void on claims returned org settings. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a98eac1> |
| 17:03 | pinesol_green | [evergreen|Kathy Lussier] LP#980296: Release notes entry for voiding lost on Claims Return - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=db91d15> |
| 17:03 | pinesol_green | [evergreen|Ben Shum] LP#980296: Stamping upgrade script for void lost on claims returned, etc. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e75501d> |
| 17:06 | graced joined #evergreen | |
| 17:06 | bshum joined #evergreen | |
| 17:06 | kmlussier joined #evergreen |
| 15:40 | kmlussier | Awww, thanks! I always assumed I was the thorn in everyone's side. ;) |
| 15:41 | kmlussier | buzzy: Do you have credentials to add an announcement to the Evergreen blog or do you want somebody else to do that? |
| 15:42 | buzzy | hmm, that's a good question. let me check |
| 15:43 | berick | bshum: i'm curious if anything came from your testing of bug 1261777 |
| 15:43 | pinesol_green | Launchpad bug 1261777 in Evergreen "User editor cloned address owner link fails to load new tab" (affected: 1, heat: 6) [Medium,Incomplete] https://launchpad.net/bugs/1261777 |
| 15:43 | buzzy | i do, in fact. i'll do that now. |
| 15:43 | bshum | berick: I probably got side tracked and didn't finish testing from a clean install. I can try it again though. |
| 15:44 | bshum | It looks straightforward enough.... |
| 15:45 | berick | bshum: well, i'm just doing some bug wrangling. it's not urgent. |
| 15:45 | bshum | berick: It's fine, wrangle away. I'll add it to my list of things to take a look over though for you. |
| 15:46 | berick | thanks, bshum |
| 16:40 | bshum | pinesol_green: obey me, slave! |
| 16:40 | pinesol_green | bshum: http://wonder-tonic.com/geocitiesizer/content.php?theme=2&music=6&url=evergreen-ils.org |
| 16:43 | Bmagic | bshum: it also writes to /tmp/blablabla file, while the edi process is running, I can snag that file and read it. It has stuff in it! weird |
| 16:43 | kmlussier | bshum/buzzy: I could be wrong, but I believe we allow attendees to edit their registrations in Eventbrite. If so, that might be a way to add on the lunches at a later date. |
| 16:43 | kmlussier | But I can test that further after I register. |
| 16:48 | * kmlussier | thinks she will add the conference to http://opensource.com/resources/conferences-and-events-monthly |
| 16:48 | bshum | @whoami |
| 16:48 | pinesol_green | bshum: bshum |
| 16:48 | bshum | Good. |
| 17:05 | dcook joined #evergreen | |
| 17:05 | kmlussier | Have a nice night everyone! |
| 17:05 | mmorgan left #evergreen | |
| 17:06 | Bmagic | bshum: I setup a ftp server and tested edi against that, it worked! So it is the FTP..... off to contact their server admin. Thanks everyone! |
| 17:07 | bshum | Bmagic: Good luck! |
| 17:08 | jeffdavis | mrpeters: It supports checkout. I don't recall seeing that kind of lag, but I'll ask folks who have done more of the testing. |
| 17:09 | mrpeters | that would be great, i'd love to hear how long it takes. We didn't have as good of results as it seems you have had. |
| 17:12 | jeffdavis | mrpeters: I do know grabbing availability details is usually quite fast. Getting a list of a patron's current holds/checkouts can be a little slow, but still only a few seconds (not as much as 15). I'll let you know what I hear back. |
| 17:13 | mrpeters | thats great to hear |
| 01:33 | RBecker joined #evergreen | |
| 03:03 | vrani_ joined #evergreen | |
| 03:16 | vrani_ joined #evergreen | |
| 05:01 | pinesol_green | Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 12:49 | gmcharlt joined #evergreen | |
| 12:50 | gmcharlt joined #evergreen | |
| 13:07 | buzzy joined #evergreen |
| 00:36 | AliceR joined #evergreen | |
| 02:57 | AliceR joined #evergreen | |
| 04:06 | AliceR joined #evergreen | |
| 04:47 | pinesol_green | Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:01 | burper joined #evergreen | |
| 06:01 | burper left #evergreen | |
| 06:13 | eeevil joined #evergreen |
| 09:57 | kmlussier | bshum: You don't hate server power failures? |
| 09:58 | bshum | Not today anyways. |
| 09:58 | remingtron joined #evergreen | |
| 10:32 | csharp | wow - so postgres replication is not at all scary to setup - nowhere near as complicated as slony |
| 10:32 | csharp | I'm running it in some test VMs - so far so good |
| 10:33 | kmlussier | csharp: Is that something you're thinking of doing in production? |
| 10:33 | bshum | csharp: It is pretty awesome. |
| 10:33 | kmlussier | I know it's something that OmniTI recommended in their report. |
| 13:32 | Dyrcona | I used to like pam, but now I don't. :) |
| 13:33 | eeevil | heh |
| 13:39 | Dyrcona | What I'm not finding is what happens if the limits for all uses is set to 65535 and the line is commented out in su. Will pam use some built-in limit? |
| 13:42 | jeff | even if i thought i knew the answer, i'd test by doing something like echoing the output of uname -a into a file from within an init script that uses su |
| 13:42 | jeff | (from a command run with su from an init script, that is) |
| 13:48 | Dyrcona | Here's a little something from the Debian wiki: Note that pam_limits is not used in /etc/pam.d/common-session and /etc/pam.d/common-session-noninteractive, so it won't be active for daemons |
| 13:51 | Dyrcona | Dunno if that applies here for certain, since the init script does use su. |
| 13:51 | Dyrcona | Dunno if setting in either of those files would do anything. |
| 16:27 | dbs | and then we'll get to try and deal with RDA :) |
| 16:28 | dbs | Next stop, BIBFRAME |
| 16:30 | kmlussier | dbs++ |
| 17:05 | pinesol_green | Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:12 | dbs | Archive::Zip-- |
| 17:13 | dbs | We've been living with broken windows and ugly graffitti too long |
| 17:32 | mmorgan left #evergreen |
| 05:09 | pinesol_green | Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:44 | tsbere_ joined #evergreen | |
| 06:14 | mtate joined #evergreen | |
| 06:14 | eeevil joined #evergreen | |
| 09:39 | * csharp | rubs hands together evilly |
| 09:40 | collum | http://themushroomkingdom.net/media/smw/wav |
| 09:41 | csharp | collum++ |
| 09:41 | bshum | I remember that site |
| 09:42 | bshum | I borrowed clips from there to experiment once on one of my test servers :) |
| 09:45 | bshum | Hmm |
| 09:45 | bshum | https://bugs.launchpad.net/evergreen/+bug/638509 |
| 09:45 | pinesol_green | Launchpad bug 638509 in Evergreen 2.4 "renewing lost items fails unintuitively" (affected: 6, heat: 30) [Medium,Confirmed] |
| 09:45 | bshum | Dyrcona has some code on that bug |
| 09:45 | bshum | Maybe we should pull it out of the dark |
| 11:31 | Dyrcona | This is a case of, "We expect you to know something about Linux before you install Evergreen." ;) |
| 11:31 | kmlussier | I'm filing an LP bug. I'll work on it if I have time, but it will be there in case somebody else has the tuits to do it. |
| 11:32 | * dbs | looks at the "20 * * * *" he has had running in production for the past five years and wonders why he hasn't seen problems |
| 11:32 | bshum | kmlussier: Well not running it during the day may not be a problem for long if we tested tsbere's fix for https://bugs.launchpad.net/evergreen/+bug/1018011 and found it to solve the issue. |
| 11:32 | pinesol_green | Launchpad bug 1018011 in Evergreen "Incorrect copy status caused by reshelving process colliding with item checkout" (affected: 5, heat: 24) [Medium,Confirmed] |
| 11:33 | dbs | Ah, academics don't tend to be busy relative to publics, but yes, those symptoms sound familiar. |
| 11:34 | bshum | dbs: I think Bmagic included a query for the auditor table to identify items that go through these bad transitions. |
| 13:53 | pinesol_green | Launchpad bug 1401177 in Evergreen 2.6 "Results of a metarecord search will display duplicate format icons" (affected: 5, heat: 26) [Medium,Fix committed] |
| 13:54 | dbs | Seq Scan on billing, yay |
| 13:54 | bshum | csharp: See above |
| 13:54 | csharp | dbs: when I tested long ago on our test server with real PINES data, it was speedy to acceptable |
| 13:54 | csharp | dbs: but it's been a while |
| 13:55 | csharp | bshum++ # thanks |
| 13:56 | * dbs | throws in CREATE INDEX CONCURRENTLY m_b_xact_time_idx ON money.billing (xact, billing_ts); and gets an index scan instead |
| 13:59 | dbs | Still 8600 ms |
| 14:00 | dbs | But better than the 16500ms without the index |
| 16:38 | * bshum | likes dbs' patches anyways |
| 16:39 | * kmlussier | loves it when Conifer catches up. :) |
| 16:41 | wjr joined #evergreen | |
| 16:51 | pinesol_green | Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:11 | mmorgan left #evergreen | |
| 17:29 | mrpeters left #evergreen | |
| 20:36 | buzzy joined #evergreen |
| 00:00 | bshum | dbwells++ # 2.6.5 |
| 01:16 | akilsdonk joined #evergreen | |
| 04:08 | dbwells joined #evergreen | |
| 04:54 | pinesol_green | Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:12 | BigRig joined #evergreen | |
| 06:12 | phasefx joined #evergreen | |
| 06:12 | maryj joined #evergreen | |
| 11:39 | bshum | We talked about calling the developer target if we select packager right? |
| 11:39 | bshum | Since we need the developer pre-req's to build the web client properly |
| 11:39 | berick | yes, i'll add that too |
| 11:39 | bshum | berick++ # looking forward to testing :) |
| 11:42 | dbwells | berick: bshum: I'd be happy to look over and otherwise help out with a EG build wiki page. For maintenence releases, I have it mostly boiled down now to a list of 20 or so commands which I copy and paste :) |
| 11:42 | dbwells | A few parts could be easily scripted, but I haven't gotten lazy enough yet. |
| 11:45 | berick | dbwells: this list of which you speak... |
| 12:22 | dbwells | With ".." we see every commit since the common ancestor. With "--cherry-pick --right-only A...B", we see every commit since the common ancestor, minus those which have an equivalent commit on "the other side". That's my understanding, at least :) |
| 12:23 | dbwells | Plus, I think the "--cherry-pick --right-only" options we have in there do nothing with the ".." operator, so something has to give. |
| 12:24 | * berick | escorts 2 git commands into the thunderdome |
| 12:34 | dbwells | I think it only matters when crossing a major version, as that's the only time the common ancestor won't be linear with the possible changes. |
| 12:36 | dbwells | berick: You're probably trying the same thing, but I just tested a changelog from rel_2_5_5...rel_2_6_0 vs rel_2_5_5..rel_2_6_0, and the "..." successfully excluded 950dede414 / 6ec8bcea7e as being equivalent (and thus not a real change). |
| 12:36 | pinesol_green | [evergreen|Liam Whalen] LP#1037171 Removed Expert Search paramters from subject links - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=950dede> |
| 12:36 | pinesol_green | [evergreen|Liam Whalen] LP#1037171 Removed Expert Search paramters from subject links - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6ec8bce> |
| 12:38 | dbwells | With the full command being that from the build script: git log --cherry-pick --right-only --no-merges --pretty --summary --numstat rel_2_5_5...rel_2_6_0 |
| 12:38 | dbwells | vs. git log --cherry-pick --right-only --no-merges --pretty --summary --numstat rel_2_5_5..rel_2_6_0 |
| 12:39 | berick | dbwells: got sidetracked, so thanks for testing.. shall I pull it into master? |
| 12:40 | dbwells | berick: Yes, I am confident now :) |
| 12:40 | berick | cool, will do in a few minutes |
| 12:40 | bshum | dbwells++ |
| 08:08 | akilsdonk joined #evergreen | |
| 08:11 | collum joined #evergreen | |
| 08:12 | ericar joined #evergreen | |
| 08:16 | csharp | tests++ |
| 08:17 | csharp | I made a wrong choice when manually merging a conflicted file and the perl test suite found it when building |
| 08:29 | mrpeters joined #evergreen | |
| 08:32 | dbs | csharp++ # for running tests! |
| 08:33 | mdriscoll joined #evergreen | |
| 08:36 | Dyrcona joined #evergreen | |
| 08:39 | Shae joined #evergreen | |
| 13:55 | csharp | yeah, we're not going to use websockets (in production anyway) |
| 13:56 | bshum | So, like I said, a label :) |
| 13:56 | bshum | But now I'm curious to see if I can build a tarball anyways |
| 13:56 | csharp | well, I would understand the "it's just a label" idea if it wasn't labled alpha :-) |
| 13:56 | csharp | "alpha" means "pre-release, test at your own risk" |
| 13:59 | jeff | pay no attention to that sign that says "EXTREMELY DANGEROUS" |
| 13:59 | jeff | </obSidReference> |
| 14:00 | nhilton joined #evergreen | |
| 14:09 | bshum | csharp: fwiw, the only difference between 2.4.0-alpha and master seems to be the additional commits I added for websockets documentation and some changes to the apache files. |
| 14:09 | dbs | tagging is easy enogh |
| 14:09 | dbs | enough |
| 14:10 | bshum | So essentially, if you've tested alpha and it's not broken, then good odds that'll be the only thing we see for 2.4.0 real |
| 14:10 | bshum | Unless there's more stuff waiting to get pulled in for OpenSRF. |
| 14:10 | bshum | Which I haven't looked at lately actually. |
| 14:11 | dbs | http://evergreen-ils.org/dokuwiki/doku.php?id=dev:release_process:opensrf:2.0 includes the git tag command |
| 14:11 | bshum | dbs: Right, I just have to remember where my keys are |
| 14:13 | * dbs | thinks he probably lost his GPG key too |
| 14:25 | kmlussier | csharp: When are you upgrading? |
| 14:26 | csharp | kmlussier: next weekend (MLK) |
| 14:30 | Dyrcona | I misspoke: I take care of it in a setup script for trusty, not in our local apache config branch. |
| 14:30 | Dyrcona | That makes it easier to test! |
| 14:33 | mrpeters joined #evergreen | |
| 14:35 | * bshum | decides to take a crack at making an OpenSRF release |
| 14:38 | jeff | kmlussier++ |
| 14:53 | jboyer-isl | So we treat those branches like tags, but only in so far as everyone just leaves them alone? |
| 14:53 | berick | jboyer-isl: exactly |
| 14:54 | jboyer-isl | I see. I'm starting to come around on the tagging front. |
| 15:17 | bshum | Alright, I have to poke at my GPG key setup more before I can push the tagged release. |
| 15:17 | bshum | But the generated files do appear to be set |
| 15:17 | bshum | I'll get those moved over to Lupin |
| 15:25 | bshum | Alright, files uploaded |
| 15:25 | bshum | For brave souls: http://evergreen-ils.org/downloads/opensrf-2.4.0.tar.gz |
| 15:26 | bshum | I'm doing a quick test to make sure it isn't borked and then I'll update the downloads page properly. |
| 15:30 | vlewis joined #evergreen | |
| 15:37 | bshum | Success, figured out my GPG situation. |
| 15:37 | bshum | Getting the git tag set |
| 15:39 | edoceo_ joined #evergreen | |
| 15:39 | bshum | Cool, it worked! :D |
| 15:39 | * bshum | is happy |
| 15:39 | Dyrcona | bshum++ |
| 15:40 | Dyrcona | I've tagged releases on a couple of my github repos where I think it makes sense. |
| 15:45 | dbs | bshum++ |
| 15:55 | pinesol_green | kmlussier: yboston was last seen in #evergreen 2 weeks, 4 days, 3 hours, 22 minutes, and 17 seconds ago: <yboston> will keep you posted in janaury |
| 16:30 | dreuther_ joined #evergreen | |
| 16:36 | vlewis_ joined #evergreen | |
| 16:39 | mceraso | bshum: Just finished testing the OpenSRF 2.4 tarball on Ubuntu 14.04 LTS. Works like a charm! |
| 16:39 | * dbs | needs to look deeper into this SIP pattern of OILS bootstrap loaded, login w/ 941, INPUT MSG: '9900302.00', followed immediately by another OILS bootstrap loaded, login w/98.... pattern that happens every 90 seconds |
| 16:40 | bshum | mceraso++ # thanks :) |
| 16:43 | eeevil | dbs: are you using Multiplex (not to be confused with comment's claim of "Mulitplex" -- business in the front, lots of parties in the back?) mode? |
| 16:46 | dbs | eeevil: I haven't specified it in oils_sip.xml, so whatever the default it |
| 16:46 | dbs | is |
| 16:46 | eeevil | dbs: ah. prefork is the default still |
| 16:46 | dbs | SIPConfig.xml seems to suggest that it would be prefork |
| 16:47 | dbs | Might be some setting from our self-check that dates back 3 years that doesn't play well with current SIPServer I guess |
| 16:48 | dbs | eeevil: is "make test" supposed to currently work on SIPServer master? |
| 16:50 | eeevil | dbs: I've no idea, I don't think I've ever tried. the SIPServer code itself has not been made "package-friendly", I don't think. I don't rightly recall if there's even a dummy "ils" implementation module, which I think would be needed for 'make test' |
| 16:50 | dbs | (assuming of course that you've run "PERL5LIB=. ./sip_run.sh" to get the dummy sipserver running) |
| 16:51 | * dbs | answered the second recollection at least :) |
| 16:51 | eeevil | (and I'll bet that it hasn't been kept up to date with stuff we've added to the evergreen "driver") |
| 17:09 | bshum | Ha |
| 17:10 | * csharp | rides off into the sunset |
| 17:11 | mmorgan left #evergreen | |
| 17:13 | pinesol_green | Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:16 | phasefx | that Archive::Zip failure also impacts the Excel Writer module that the reporting system uses |
| 17:17 | bshum | phasefx: What debian are we using for that server? |
| 17:17 | phasefx | wheezy |
| 17:26 | * bshum | refers back to: http://irc.evergreen-ils.org/evergreen/2014-08-04#i_115000 |
| 17:26 | bshum | Where we last talked about packaged vs. CPAN |
| 17:27 | bshum | But yeah, the packaged version is a bit dated |
| 17:30 | eeevil | yeah ... I'd fear 0.47, I think ... there was something specific we use that older versions lacked |
| 17:33 | eeevil | well, it looks like it /should/ work ... anyone have tuits for testing that? |
| 17:34 | eeevil | did precise even have the module? squeeze does not |
| 17:35 | dreuther_ joined #evergreen | |
| 17:35 | bshum | eeevil: I don't see it listed, so I'm guessing no. |
| 17:36 | dreuther__ joined #evergreen |
| 05:13 | pinesol_green | Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:14 | remingtron__ joined #evergreen | |
| 06:37 | phasefx__ joined #evergreen | |
| 07:16 | jboyer-isl joined #evergreen | |
| 07:33 | Callender joined #evergreen | |
| 07:59 | akilsdonk joined #evergreen | |
| 08:03 | bshum | Hmm, Archive::Zip issue on testing? |
| 08:03 | bshum | That's new |
| 08:06 | julialima_ joined #evergreen | |
| 08:16 | ericar joined #evergreen | |
| 08:18 | * csharp | emerges from holiday hibernation |
| 13:31 | jeff | https://bugs.launchpad.net/sipserver |
| 13:35 | eby joined #evergreen | |
| 13:37 | * bshum | has no powers there |
| 13:37 | dbs | jeff++ |
| 13:38 | * dbs | will update the SIPServer README to point there |
| 13:38 | dbs | Meanwhile, wondering whether the SIPServer test suite is supposed to work out of the box with the shipped SIP config |
| 14:13 | abowling joined #evergreen | |
| 14:59 | kbutler joined #evergreen | |
| 15:15 | ericar_ joined #evergreen | |
| 16:36 | bshum | Thanks! |
| 16:37 | dbwells | Feel free to ask me for help if it doesn't work as expected. I am not sure if anyone has used that feature in a live instance. |
| 16:38 | bshum | dbwells: Sounds good. I'm not sure when/if we'll try it out. |
| 16:47 | pinesol_green | [evergreen|Bill Erickson] LP#1406367 Reduce Fine gen. API memory use - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=09642a7> |
| 16:47 | pinesol_green | [evergreen|Bill Erickson] LP#1406367 Fine generator skips no-fines transactions - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=80b673d> |
| 16:47 | pinesol_green | [evergreen|Bill Erickson] LP#1406367 Fine generator skips no-fines transactions (parallel) - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=78d6a87> |
| 16:54 | RBecker joined #evergreen | |
| 16:58 | pinesol_green | Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 16:59 | Dyrcona | Well, that bothers me right after I commit something, too. |
| 16:59 | bshum | Heh |
| 16:59 | bshum | It was broken this morning. |
| 00:56 | DPearl1 joined #evergreen | |
| 04:25 | dcook joined #evergreen | |
| 04:58 | pinesol_green | Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:33 | BigRig joined #evergreen | |
| 08:15 | pie_ joined #evergreen | |
| 12:29 | sbrylander joined #evergreen |
| 14:25 | artunit_ joined #evergreen | |
| 16:29 | artunit_ joined #evergreen | |
| 16:47 | artunit_ joined #evergreen | |
| 17:16 | pinesol_green | Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 21:02 | sarabee joined #evergreen | |
| 21:51 | artunit joined #evergreen |
| 14:09 | bshum | But eh, no problemo :) |
| 14:17 | jboyer-isl joined #evergreen | |
| 14:40 | RoganH joined #evergreen | |
| 15:44 | pinesol_green | [evergreen|Pasi Kallinen] Make Vandelay merge profile names translatable. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e66d78b> |
| 17:01 | pinesol_green | Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:04 | mmorgan left #evergreen | |
| 17:07 | berick | ugh. on more than one box (ubuntu 14.04), retrieving file /reports/fm_IDL.xml via browser craps out w/ an IDLCHUNK parse error. |
| 17:07 | berick | it reads "\x1f\x8b\b" as the first few bytes.. (which is of course not in the IDL). |
| 00:36 | bshum | jcamins: Heh, I was here and then there. |
| 02:13 | abowling joined #evergreen | |
| 02:34 | abowling left #evergreen | |
| 05:04 | pinesol_green | Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:36 | BigRig joined #evergreen | |
| 06:58 | pie_ joined #evergreen | |
| 10:56 | Griff`Ron joined #evergreen |
| 09:02 | bshum | mrpeters: I'm almost certain that the order is relevance based |
| 09:03 | mrpeters | OK, so the same as the default strategy for the regular OPAC? |
| 09:03 | bshum | That would be my expectation. |
| 09:04 | mrpeters | easy way to test, i suppose -- run the same search string in tpac and limit the audiences :) |
| 09:04 | bshum | I'm sure you could try altering it by tacking on more variables to the URL. |
| 09:04 | mrpeters | nope, you nailed it |
| 09:04 | pie_ | bshum: heh. thanks |
| 10:02 | Guest5683 joined #evergreen | |
| 10:03 | pie_ joined #evergreen | |
| 10:14 | RBecker_ joined #evergreen | |
| 10:15 | bshum | @later tell tsbere Hmm, "Config variable ${SERVER_PORT} is not defined" is ending up in my apache warnings whenever I restart on apache 2.4 with Ubuntu Trusty. Test converting our rewrite maps/rules from 2.2 to 2.4. |
| 10:15 | pinesol_green | bshum: The operation succeeded. |
| 10:21 | Dyrcona joined #evergreen | |
| 10:31 | RBecker joined #evergreen | |
| 10:50 | dkyle joined #evergreen | |
| 11:00 | jboyer-isl joined #evergreen | |
| 11:16 | mmorgan | Anyone around who has worked with the Merge Monograph Parts functionality in 2.7? |
| 11:17 | bshum | mmorgan: I tested it |
| 11:17 | bshum | And pushed those commits to master during 2.7 |
| 11:17 | bshum | What seems to be up? |
| 11:21 | bshum | parts-- # asking about parts is dangerous |
| 11:21 | mmorgan joined #evergreen | |
| 11:25 | mmorgan | sorry for dropping out, kicked the power strip :-( |
| 11:25 | bshum | mmorgan: I blamed it on parts, don't worry about it :) |
| 12:04 | mmorgan left #evergreen | |
| 12:26 | * bshum | grumbles at bug 1406788 |
| 12:26 | pinesol_green | Launchpad bug 1406788 in Evergreen "KPAC Login Redirect Issue" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1406788 |
| 12:27 | bshum | abowling++ # I'll test that one cause I probably broke it when I merged redirect changes a couple releases back |
| 12:31 | bshum | abowling: On the other hand, initial testing doesn't seem to redirect it where I think it should. I'll poke at it some more :) |
| 12:32 | jeff | heh. i was just looking at that. :-) |
| 12:32 | bshum | jeff: Heh |
| 12:52 | jboyer-isl joined #evergreen |
| 09:07 | Dyrcona | The quotes very likely change the search. |
| 09:08 | Dyrcona | One would assume it turns it into a phrase. |
| 09:08 | Dyrcona | berick: It turns out that I have not been running the fine generator on my new dev VM for the past ten days. |
| 09:08 | Dyrcona | berick: Anything in particular I should watch for while testing your branch? |
| 09:09 | krvmga | Dyrcona: i'm guessing that is so. what i can't account for is why there are more results with a more restrictive format filter. |
| 09:10 | mmorgan | krvmga: I get more results in our catalog with book(all) - 6304 vs book(regular print) - 4192, so am not seeing the same thing |
| 09:10 | dbs | krvmga: do you page through all of the results to find out how many there actually are? |
| 14:36 | cfarley | So I'm saying, hide everything below the catelog and effectively ignore them. |
| 14:37 | Dyrcona | Yes, but a lot of things expect there to be a tree and go up and down the tree looking for settings, etc. |
| 14:37 | Dyrcona | So, 1 mistake can throw that off. |
| 14:37 | cfarley | I see, maybe I'll have to do some testing |
| 14:38 | Dyrcona | If all you do is allow the top org unit type to have volumes/copies and users, and then just use that org unit type as your only org. unit, you should be OK. |
| 14:39 | Dyrcona | Testing is always good, preferably in a separate installation from production. |
| 14:55 | cfarley | I just noticed that my Catelog and system levels are greyed out in the Pickup location dropdown box on the place hold screen. Does anyone know what is needed to get these enabled? |
| 14:57 | bshum | cfarley: I believe that's controlled via the type of organization unit that's employed. There's a flag on the org unit type that sets it as allowing volumes and copies. If the unit type doesn't allow that, then they're typically not eligible as hold pickup locations. |
| 14:57 | bshum | Generally speaking, it's assumed in the stock setup that the top level and system levels do not actually house copies of materials. |
| 17:02 | pie_ joined #evergreen | |
| 17:02 | pie_ | Hey guys, has anyone ever used usemarcon or have access to some conversion tables/rulesets? |
| 17:03 | mrpeters left #evergreen | |
| 17:07 | pinesol_green | Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:08 | mmorgan left #evergreen | |
| 17:37 | nhilton joined #evergreen | |
| 18:34 | RBecker joined #evergreen |
| 02:58 | b_bonner_ joined #evergreen | |
| 02:59 | jeffdavi1 joined #evergreen | |
| 05:09 | pinesol_green | Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:30 | rjackson-isl joined #evergreen | |
| 07:37 | jboyer-isl joined #evergreen | |
| 07:46 | ericar joined #evergreen | |
| 15:09 | berick | bshum: have you noticed high mem. usage locally? |
| 15:10 | bshum | berick: I actually haven't monitored it that closely. Though the server that runs fines also runs A/T events and we do allocate a lot of memory to the server to avoid running out of room in general. |
| 15:10 | bshum | In the past, I know we've run out of memory before, so we've always kept it at a very high number anyways. |
| 15:11 | berick | bshum: gotcha. yeah, we get mem alerts occasionally. didn't think much about it until i saw what happened on the test server. |
| 15:15 | Dyrcona | I've never gotten memory alerts, but I know it can take a long time to generate fines on a dev/test server that has been kept up to date. |
| 15:15 | Dyrcona | Should be "has not been kept up to date." |
| 15:16 | bshum | The idea of skipping the $0 stuff sounds like a really good thing to me. |
| 15:16 | bshum | I know that ends up being tons for us |
| 15:26 | jeff | 1.2.0.4 -- first version with Hold Capture Verify and Rental support. :-) |
| 15:27 | jeff | November 2008. |
| 15:29 | berick | nice |
| 15:55 | Dyrcona | Well, I threw that branch up on my development server, I'll have to figure out how to test it later. |
| 15:56 | Dyrcona | berick++ |
| 15:56 | berick | Dyrcona++ sweet |
| 16:52 | pinesol_green | Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:08 | mmorgan left #evergreen | |
| 18:07 | cfarley joined #evergreen | |
| 18:10 | cfarley | Hello, I am having problem and hoping that someone has run into it before. I am running 2.6.4 and when I try to place an item on hold through the opac, nothing happens. |
| 04:55 | pinesol_green | Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:34 | eeevil joined #evergreen | |
| 06:34 | mtate joined #evergreen | |
| 06:35 | TaraC joined #evergreen |
| 16:43 | Dyrcona | The mother of all subtitles..... |
| 16:55 | Dyrcona | Well, I'm heading home in a few. |
| 16:55 | * Dyrcona | went into the office to cover the Saturday and to escape the noise. |
| 17:12 | pinesol_green | Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 18:27 | dbs | Hmm. Methinks that deleted records such as https://laurentian.concat.ca/eg/opac/record/832789 should return a 404 instead of a 200. |
| 18:34 | dbs | Actually, 410. |
| 18:35 | dbs | For that matter, a request for a record ID that doesn't exist should return a 404 instead of a 200. |
| 15:20 | bshum | I bet it's http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c0e0e39d49f1188575f609cb1c30f3626da678ad |
| 15:20 | pinesol_green | [evergreen|Josh Stompro] Documentation: LP#1386854 - Locally Hosted Added Content. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c0e0e39> |
| 15:21 | kbutler | Can anyone help me to understand what is the difference between a 'circulation limit set' and a 'circulation limit group'? |
| 15:21 | * dbs | briefly considers adding an integration test for doc builds |
| 15:23 | tsbere | kbutler: Limit group is used in circ tagging. Limit set is a set of conditions to count/limit circs with. |
| 15:24 | kbutler | tsbere: So limit group is not going to be useful for creating circulation rules for patron types? |
| 15:25 | mtcarlson joined #evergreen | |
| 15:31 | bshum | kbutler++ |
| 15:32 | kbutler | bshum++ Thanks! |
| 15:32 | kbutler | tsbere: Hmm. Thanks for the explanation. |
| 16:58 | pinesol_green | Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:10 | jboyer-isl 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