| 05:00 |
|
RAIDoperator joined #evergreen |
| 05:02 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:44 |
|
Callender joined #evergreen |
| 07:52 |
|
geoffsams joined #evergreen |
| 07:56 |
|
jboyer-home joined #evergreen |
| 12:43 |
jeff |
rsoulliere: have you tried with a small batch of records as input? |
| 12:44 |
Dyrcona |
yeah, I had tried to make that go away when it comes from standard input but it didn't work out. |
| 12:44 |
Dyrcona |
That message should have probably just been removed. |
| 12:46 |
rsoulliere |
Jeff: let me try a few tests on my end and I will report back. |
| 12:48 |
jeff |
fwiw, i don't think it will cause any issue, but i don't think marc_export requires that you pass your opensrf config file location if it's in the default location, and I don't think it knows about or respects a -c argument, just --config |
| 12:48 |
jeff |
i also don't think the previous version paid attention to a -c either, but i could be wrong there. |
| 12:48 |
jeff |
it's likely not causing any issues, just isn't doing anything. |
| 13:04 |
jcamins |
RoganH: yeah, I've done that. Not with passwords, because I never hit enter after typing in a password. |
| 13:05 |
RoganH |
I want one of those eye trackers that change your active window based on where you're looking. Tragically my library probably won't consider laziness an adequate disability to justify the accommodation. |
| 13:05 |
jcamins |
At least, I try not to. |
| 13:05 |
rsoulliere |
marc export testing update: I ran the marc_export script on a small list of ids and it worked as expected. Looking over the logs... one correlation is that if my text file had no records, the script imported all records. |
| 13:05 |
jcamins |
dbs: that's exactly why I don't hit enter after entering a password. |
| 13:06 |
dbs |
jcamins: thanks |
| 13:07 |
jcamins |
dbs: no judgement intended. |
| 13:26 |
Dyrcona |
--all isn't a default. |
| 13:26 |
Dyrcona |
If you give it no arguments or standard input, it sits there doing nothing. |
| 13:27 |
Dyrcona |
That's why it prints "waiting for input." |
| 13:27 |
dbs |
13:11 < rsoulliere> marc export testing update: I ran the marc_export script on a small list of ids and it worked as expected. Looking over the logs... one correlation is that if my text file had no records, the script imported all records. |
| 13:32 |
Dyrcona |
---all still isn't a default. It's because standard input was empty. |
| 13:32 |
Dyrcona |
Different bug. |
| 13:33 |
jeff |
i'm not sure that empty stdin would still export all -- but that's based on a quick read of the code earlier, so i'll defer to rsoulliere's empirical test results :-) |
| 13:33 |
Dyrcona |
The export code doesn't check Config::need_ids, so if the idlist is empty it looks like it will export everything. |
| 13:34 |
jeff |
aha |
| 13:35 |
hbrennan |
What does the Global checkbox mean/do in Circulation Limit Sets? |
| 13:43 |
dbs |
but I should have been explicit about that |
| 13:45 |
|
RoganH joined #evergreen |
| 13:54 |
|
RoganH joined #evergreen |
| 14:03 |
Dyrcona |
Well, it never got tested with an empty file or pipe, so same difference. |
| 14:49 |
|
sseng_ joined #evergreen |
| 14:49 |
|
ktomita joined #evergreen |
| 15:49 |
|
jeff joined #evergreen |
| 14:14 |
bshum |
gmcharlt: Springing this on you, but do you have any thoughts about 2.4 work? |
| 14:14 |
gmcharlt |
bshum: aiming for a release after ALA |
| 14:14 |
bshum |
#info gmcharlt aiming for an OpenSRF 2.4 release after ALA |
| 14:15 |
gmcharlt |
main thing I'd like at this point is more testing of the websocket work by berick |
| 14:15 |
bshum |
#info Get more testing of the websocket work started by berick, see https://bugs.launchpad.net/opensrf/+bug/1268619 and others |
| 14:15 |
pinesol_green |
Launchpad bug 1268619 in OpenSRF "WebSockets Gateway and JS Library" (affected: 1, heat: 6) [Undecided,New] |
| 14:16 |
bshum |
Sounds like a good thing. |
| 14:17 |
bshum |
Okay, we'll follow up on that after ALA, but in the meantime, folks should check out the bug and other announcements to help start testing the upcoming work for OpenSRF. |
| 14:18 |
bshum |
Thanks for the update gmcharlt++ |
| 14:18 |
bshum |
#topic Evergreen maintenance releases |
| 14:19 |
dbwells |
#info 2.5.5 and 2.6.1 are out |
| 14:19 |
bshum |
The next date on the calendar for that is 6/18, do we want to stick to that or perhaps shift things slightly? |
| 14:20 |
bshum |
dbwells++ # doing the release dance |
| 14:31 |
bshum |
I guess it depends on how comfortable you are separating the parts of the sprint into separate bugs |
| 14:31 |
bshum |
We could track the whole sprint as a blueprint and link it to each bug separately. |
| 14:31 |
bshum |
I guess it's more about how the final code will be presented. |
| 14:32 |
berick |
well, for the initial round of testing, i'm considering maintaining maybe a simple list somewhere. there will be /lots/ of little things. opening LP's for each would be cumbersome, imo. |
| 14:32 |
dbs |
#info dbs, Laurentian University |
| 14:32 |
berick |
after that's settled down, though, then we can leverage LP in the usual fashion |
| 14:33 |
bshum |
Sounds reasonable to me. |
| 14:35 |
dbs |
tpac-style |
| 14:35 |
bshum |
Next release meaning 2.7? |
| 14:35 |
RoganH |
I'm in favor of that. |
| 14:36 |
berick |
it will mean we really need to get in the websockets testing |
| 14:36 |
dbwells |
+1 to including as a preview |
| 14:36 |
bshum |
+1 to preview |
| 14:36 |
berick |
bshum: right, next meaning 2.7 |
| 15:01 |
kmlussier |
My concern is that this bug ultimately has big impacts on end users, and they aren't really seeing the nuances of the different approaches. |
| 15:01 |
RoganH |
kmlussier: I'm willing to read through it all. I agree it's important. I'm willing to do so and post about it but with the caveat that I might need correction if I miss a nuance. |
| 15:02 |
RoganH |
(Actually that seems likely that I will.) |
| 15:02 |
kmlussier |
For end users (not the devs), it might also be useful to have side-by-side screenshots of what happens. But, although I have done numerous screenshots in my last round of testing, I don't have much for what the original approach did. |
| 15:03 |
|
shadowspar joined #evergreen |
| 15:03 |
|
berick joined #evergreen |
| 15:03 |
|
JLDAGH joined #evergreen |
| 15:19 |
kmlussier |
I've been tied up in meetings all week and have just been catching up on this discussion. The rec_descriptor issue that bshum raised, where is that causing performance problems? I know reports was one of the areas bshum was poking at, but I'm confused as how it's related to holds. |
| 15:19 |
eeevil |
that's really just for reports, though. step 2 is use attr_flat instead |
| 15:20 |
jeff |
kmlussier: it can also slow down the hold permit checks at check when opportunistic hold capture takes place |
| 15:20 |
eeevil |
kmlussier: for cases where we have to test 100 holds and find that none will work for this copy, it's adding too much time to checkin. for normal cases where we only need to test a couple, it's not noticeable |
| 15:20 |
jeff |
kmlussier: given an item on a bib with many holds, but the item is not eligible for any of the holds, it can lead to timeouts at checkin |
| 15:21 |
bshum |
Well, it's noticeable all the time if you care about milliseconds (like our new library using a SIP sorter for checkins) does. |
| 15:21 |
kmlussier |
So this is when the retarget checkin modifier is being used? |
| 15:30 |
eeevil |
so, age protection and transit distance restriction are likely drivers. bshum, do you use either of those? |
| 15:31 |
eeevil |
kmlussier: not ... exactly |
| 15:31 |
eeevil |
kmlussier: but, parts of "restrictive rule" will contribute to potentially exposing the issue |
| 15:31 |
bshum |
eeevil: No to age protection, and as for transit distance, sort of, but I have to do some more investigation on what that's actually doing if anything. |
| 15:32 |
bshum |
eeevil: I think we have some rules set with transit distance true and a value of 2 or something in the matrix |
| 15:32 |
bshum |
For stuff that was intended to be local pickup only or something. |
| 15:32 |
bshum |
Not sure if those were written correctly, actually, now that I'm looking at it again. |
| 15:38 |
bshum |
eeevil: This isn't exactly apples, but I did a hold permit test on our old production DB hardware (pre-mvf upgrade scripts, etc.) vs. live and it was something like 12-18 ms vs. 400-800 ms |
| 15:38 |
bshum |
When I ripped out the rec_descriptor bits in live, that went down to like 24 ms or so |
| 15:38 |
bshum |
So I'm not sure transit range hurt me as much as that did |
| 15:39 |
eeevil |
bshum: well, it's not that |
| 15:39 |
eeevil |
I'm not saying that the problem isn't mrd |
| 15:40 |
eeevil |
what I'm saying is that it only really matters when you have a very long list of holds to test for |
| 15:40 |
eeevil |
and none of them pass |
| 15:40 |
eeevil |
if the first one passes, we look no further and capture |
| 15:40 |
eeevil |
but if we have to roll through all 100, then the difference matters |
| 15:41 |
eeevil |
so, if we create a mat-view for mrd, this will likely not be an issue |
| 15:41 |
eeevil |
in the case I just described |
| 15:41 |
eeevil |
but my point is that 99.9% of the time, you're not in that situation where there are 100+ unfillable holds |
| 15:42 |
eeevil |
which, again, is not to say that we shouldn't fix this ... we have several options |
| 15:42 |
eeevil |
but just to say that we're not seeing across-the-board 2.6 fail because most of the time it doesn't matter |
| 15:43 |
eeevil |
transit range is what can cause all 100+ holds to fail for a given (distant) copy. that's a trigger that can expose a given staff user to this behavior |
| 15:44 |
eeevil |
but transit range isn't the cause ... does that make sense? |
| 15:44 |
kmlussier |
eeevil: I think that 99.9% number is highly dependent on the Evergreen site. You're probably right when it comes to the networks I work with, but aren't there a fair number of Evergreen sites that rely more heavily on transit distance rules? |
| 15:46 |
eeevil |
kmlussier: the transit distance restriction is just how the door opens. it doesn't mean that they will suffer from this |
| 15:46 |
eeevil |
they still need tons of /distant/ holds that are at the front of the "queue" (hold sort order) |
| 15:49 |
eeevil |
dbwells: indeed, just so |
| 15:49 |
dbwells |
bshum: eeevil: I am getting better plans using the view in the paste above (as described by eeevil). |
| 15:50 |
eeevil |
bshum: if that view replacement doesn't go far enough, a mat-view based on that is the next step, and that's as fast as mrd can get (faster than since 1.0, when it was a table) |
| 15:50 |
dbwells |
I was testing with dkyle's original query, since it was a handy case for testing, so I'll be interested to see if it also helps bshum's holds case. |
| 15:55 |
* bshum |
live tests, because hey, that's just how we roll now |
| 15:55 |
kmlussier |
bshum++ |
| 15:55 |
kmlussier |
bshum: Better you than me. :) |
| 16:04 |
hbrennan |
bshum: It's more exciting that way |
| 16:12 |
hbrennan |
and I didn't break anything! |
| 16:12 |
gsams |
woo! |
| 16:13 |
hbrennan |
Since all checkout limits were previously being regulated by the penalties we removed, I had to create some new limit sets and circ policies for our different groups |
| 16:13 |
bshum |
dbwells: eeevil: Only a preliminary test, but I applied that new paste for the rec_descriptor and asked jventuro to run a test report using a fixed field data element. It ran successfully. |
| 16:13 |
hbrennan |
First time since Equinox set up our policies that anyone has touched them... I didn't even have permission to view them yesterday |
| 16:14 |
bshum |
She's going to test another one (the report that we know broke for sure) while I did back out the original find_hold_matrix_matchpoint function to retest my case. |
| 16:14 |
hbrennan |
so equinox++ too |
| 16:14 |
hbrennan |
since they were humored more than anything by our situation this morning |
| 16:15 |
gsams |
hbrennan: that was more or less what I was with mine. It wasn't the first time I had seen it myself anyway, I have bshum to thank for that one though. |
| 16:20 |
hbrennan |
I I struggled with printing a page of the policies, because it was cutting off #15 on the list |
| 16:20 |
hbrennan |
so I had to screenshot it |
| 16:21 |
kmlussier |
But there is filtering on those screens now. Makes them much easier to use. |
| 16:23 |
bshum |
dbwells: eeevil: Yes, the permit hold test is faster now with the new rec_descriptor view in place. Or at least not above 50 ms, so reasonable. |
| 16:23 |
eeevil |
cool ... simple CREATE OR REPLACE VIEW upgrade script, then |
| 16:23 |
eeevil |
dbwells++ |
| 16:23 |
eeevil |
bshum++ |
| 17:12 |
gsams |
which is a bit less than helpful in our case |
| 17:12 |
gsams |
I'm not really sure where this would be going wrong though |
| 17:18 |
|
berick joined #evergreen |
| 17:19 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 18:47 |
|
hbrennan joined #evergreen |
| 19:16 |
|
hbrennan joined #evergreen |
| 21:02 |
|
GtownJoe joined #evergreen |
| 01:17 |
|
bmills joined #evergreen |
| 04:09 |
|
remingtron_ joined #evergreen |
| 05:20 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:27 |
bshum |
Bleh, old report template running super long because it seems to rely on metabib.rec_descriptor for getting item type. That's annoying :( |
| 05:27 |
bshum |
View of view of view |
| 05:27 |
bshum |
Bleh |
| 13:05 |
|
hbrennan joined #evergreen |
| 13:11 |
|
kbeswick joined #evergreen |
| 13:21 |
eeevil |
bshum: a view that uses select-clause subqueries against record_attr_flat to simulate rec_descriptor would be an improvement ... we could skip the hstore step in that case |
| 13:23 |
bshum |
eeevil: Sounds logical. Fwiw crosstab is definitely super slow so far in my local testing so that seems a deadend. |
| 13:24 |
bshum |
eeevil: In reading your reply and other places rec_descriptor gets used, I'm suddenly wary of circ/hold matrix |
| 13:24 |
bshum |
With the lookup functions I mean. |
| 13:25 |
eeevil |
nah, it ends up /only/ doing the hstore<->record dance for the one record's data |
| 13:26 |
eeevil |
reports are a problem because a join is not necessarily (or even likely) going to use an index lookup on the record id column from mrd |
| 13:26 |
eeevil |
the circ/hold stuff does |
| 16:59 |
berick |
bshum: yep |
| 16:59 |
bshum |
The client was understandably impatient and gave me a network error while I waited for it. |
| 17:01 |
|
jwoodard joined #evergreen |
| 17:03 |
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:05 |
|
mrpeters left #evergreen |
| 17:09 |
gsams |
trying to export marc records using the marc_export tool in 2.3.5 right now, our newest library seems to not get pulled with --library, just runs for 60 seconds and quits with nothing |
| 17:11 |
gsams |
is there something that I am missing to get marc_export to see the new library by its shortname? |
| 17:14 |
bshum |
gsams: What's the full command that you're attempting to use? |
| 17:17 |
|
ldwhalen_mobile joined #evergreen |
| 17:18 |
|
ningalls joined #evergreen |
| 17:24 |
bshum |
I think it's bombing out while running through the retarget permit test on all the holds. |
| 17:25 |
bshum |
None of the 122 unfilled holds are for the library checking it in, or item owning. |
| 17:25 |
bshum |
And the rules don't allow the item to be holdable by the other libs. |
| 17:25 |
bshum |
But because there's so many holds, it just kills the time |
| 17:26 |
bshum |
Sigh |
| 17:28 |
|
kmlussier joined #evergreen |
| 17:34 |
jeff |
i blame commit ae9641 |
| 17:34 |
pinesol_green |
[evergreen|Thomas Berezansky] Nearest Hold: Look at 100 instead of 10 holds - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ae9641c> |
| 17:34 |
jeff |
who came up with that idea and said it was alright, anyway? ;-) |
| 17:35 |
jeff |
`` Jeff Godin claims they have done this and it has produced no issues for them.'' |
| 17:35 |
gmcharlt |
jeff: you should have a serious chat with that fellow |
| 17:35 |
* jeff |
ducks |
| 17:36 |
jeff |
if checkin modifier "speedy" is set, consider (and test) only ten holds... otherwise, do 100. if checkin modifier "exhaustive" set, check all holds... ;-) |
| 17:36 |
bshum |
Heh |
| 17:37 |
bshum |
I'm wondering if my problems might be PG 9.3 related |
| 17:37 |
jeff |
bshum: in one case where i was looking at things (and i think i was talking out loud here also) i found that the hold permit tests seemed to be running twice at checkin. no idea if that's been that way for a while, or if it's avoidable. |
| 17:37 |
jeff |
you might pull on that thread a little if you're digging into this, though. |
| 17:38 |
bshum |
2542c713ea4a0d686d7b7ceae352929b60a80806 since it mentions PG 9.3 and hold matrix functions |
| 17:38 |
pinesol_green |
[evergreen|Mike Rylander] LP#1277731: Disambiguate parameter/column names - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2542c71> |
| 17:38 |
bshum |
But really, I think I'm just running on fumes now :) |
| 17:41 |
dbwells |
gsams: One thing to consider is that --library specifies the owning_lib, not the circ_lib. Not sure if that is a factor in your scenario. |
| 17:42 |
gsams |
dbwells: that is actually what I want, I plan to use marc_export as a temporary measure for Boopsie uploads for this library |
| 17:44 |
dbwells |
gsams: if you search asset.call_number, do you find rows where the owning_lib matches the id for NRH from actor.org_unit? |
| 17:47 |
bshum |
So |
| 17:47 |
bshum |
A retarget test |
| 17:47 |
bshum |
Time pre-upgrade DB: 13 ms. Time on production: 500+ ms |
| 17:49 |
dbwells |
gsams: Also, if it runs exactly for 60 seconds, that smells like a timeout issue. I'd consider checking what query is running in the DB when the script exits and go from there. |
| 18:06 |
gsams |
dbwells: asset.call_number returns 162k rows for that owning lib |
| 18:15 |
dbwells |
gsams: I'm heading out in just a few minutes, but if you want to explore the timeout angle, you could try passing a second argument to the $recids json_query in marc_export. Something like '{timeout => 600, substream => 1}' (that might not be exactly right, and I can't recall if 'substream' is necessary, but something like that). |
| 01:03 |
|
artunit_ joined #evergreen |
| 03:56 |
|
b_bonner joined #evergreen |
| 03:56 |
|
mtcarlson_away joined #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:33 |
|
Callender joined #evergreen |
| 07:23 |
|
artunit joined #evergreen |
| 07:44 |
|
akilsdonk joined #evergreen |
| 15:01 |
bshum |
eeevil: Hmm, the uncontrolled table has nothing in there either |
| 15:02 |
bshum |
metabib.uncontrolled_record_attr_value |
| 15:02 |
bshum |
Assuming that's the one you mean |
| 15:03 |
jeff |
jboyer-isl: i was about to ask you something starting with "in your testing", but then i saw your comment. :-) |
| 15:03 |
bshum |
eeevil: Hmm, might it be that because "multi" is still set to TRUE for that definition, that's a potential issue? |
| 15:05 |
jeff |
jboyer-isl: i like your approach of "don't let these API calls transfer captured holds at all" |
| 15:05 |
jeff |
jboyer-isl: it gets around the issue of inconsistent ahcm when opting not to retarget (but still transferring) the captured holds |
| 15:17 |
* jeff |
eyes OpenILS::Application::Cat::Merge::merge_records as potentially dead code |
| 15:18 |
jeff |
jboyer-isl: what methods have you used to clean up after this -- as you described it -- "havoc"? :-) |
| 15:20 |
jboyer-isl |
Since we don't know about it until after it's happened, usually the staff have already either checked the item out to someone or placed a new hold. We haven't yet gone to great lengths to correct anything. I think it was only reported a couple of times between our figuring out what was going on and my applying that basic patch. |
| 15:24 |
jeff |
neither old-school merge nor in-db merge seem to have paid any attention to title holds (though i didn't go digging too far back to confirm on the old-school method) |
| 15:30 |
jeff |
jboyer-isl: and the staff client appears to be the only thing calling open-ils.circ.hold.change_title[.specific_holds], and i don't see any references to OpenILS::Application::Circ::Holds::change_hold_title[_for_specific_holds] so i think that answering the question of "what's the impact when these holds are left on the old bib but their copies are moved" and "add a join to skip copies with in-transit holds also" followed by some testing should help bring |
| 15:38 |
|
rjackson-isl joined #evergreen |
| 15:38 |
|
jboyer-isl joined #evergreen |
| 15:39 |
jeff |
I can see two scenarios where Transfer Title Holds can be used. In one, there are no planned changes to copies or bibs, we're just moving the hold or holds. In the other, we've transferred (possibly as part of a merge) or are about to transfer copies to another bib. |
| 15:40 |
bshum |
Doh, array_to_string(array_agg()) crept in again over string_agg() |
| 15:40 |
bshum |
Just saw it part of function metabib.reingest_record_attributes() |
| 15:42 |
jeff |
In the second, I don't know that we care if the already-captured holds stay behind on the old title record unless a) it will break fulfillment / transit completion -> available -> fulfillment or b) the hold gets out of its captured status for some reason, in which case it'll likely end up being an unfillable hold |
| 16:11 |
|
Callender joined #evergreen |
| 16:12 |
eeevil |
kmlussier / bshum: vandelay can match against random tag data without record attrs being involved (see: isbn), so ISTM there should be a way without involving the existing attr defs |
| 16:13 |
RoganH |
bshum: short email sent to dev list. We'll see where the discussion goes. :) |
| 16:13 |
kmlussier |
eeevil: The record attrs was what was recommended to me by an ESI developer back when we were testing the Vandelay development because the standard Vandelay matchpoints required that a subfield be used. |
| 16:15 |
eeevil |
kmlussier: gotcha. this is a solvable issue, probably very simply |
| 16:17 |
eeevil |
bshum: looking at the code, record_attr_flat /does/ include uncontrolled values |
| 16:17 |
eeevil |
so, I was wrong up there -^ |
| 13:28 |
Dyrcona |
Anything added in 2013 or later is fine. |
| 13:29 |
Dyrcona |
Now, I might have done something in the database to cause it. I can't rule that out. |
| 13:32 |
Dyrcona |
None of my other book bags show duplicates, but they also don't have anything added in October of 2012, just September and November. |
| 13:33 |
jeff |
Dyrcona: I was able to add duplicate items to a list just now in our 2.5.1 system running lightly-ported 2.1 era templates |
| 13:34 |
jeff |
so if it was something done post-2.5.1, or something done at the template level, i obviously don't have that in place. |
| 13:35 |
jeff |
but other than that it was pretty easy to add three items to a temp list, then go to my lists and add them to a new list, then go back and add two of the three items to the temp list and then add those to the previously-created list. |
| 13:35 |
jeff |
don't have running master handy to test with. |
| 13:37 |
Dyrcona |
I can't find any Launchpad bugs. |
| 13:38 |
hbrennan |
Nor I. |
| 13:40 |
Dyrcona |
I am going to try to come up with a query to see how widespread this is. If it only affects my one list, then I'll get one with things and ignore it. |
| 14:21 |
Dyrcona |
Well, it does not appear to be confined to a single point in time, so it is something that is ongoing for us at least. |
| 14:24 |
|
kbeswick joined #evergreen |
| 14:25 |
Dyrcona |
Well, that's not good. |
| 14:25 |
Dyrcona |
Trying to test a hypothesis about this being related to temporary lists, I get an internal server error on my dev machine. |
| 14:27 |
hbrennan |
I did see a bug report on internal server error on lists, when changing name... |
| 14:27 |
kmlussier |
I think I just saw Dyrcona fall down a rabbit hole. |
| 14:28 |
Dyrcona |
heh. I've been that hole since about 11:30 am. :) |
| 16:52 |
|
kmlussier left #evergreen |
| 16:58 |
|
afterl left #evergreen |
| 17:19 |
|
mmorgan left #evergreen |
| 17:21 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:35 |
jeffdavis |
In 2.6, if I do a search with "Group Formats & Editions" checked, then click "Place Hold" on a metarecord (a result with a count in parentheses after the title), it should attempt to place a metarecord hold, correct? |
| 17:36 |
jeffdavis |
I feel like this is a dumb question, but on our test servers, the hold_type param in the Place Hold URL is T instead of M. |
| 18:26 |
bshum |
jeffdavis: I just tested it on one of our test servers and mine came up with M and not T when clicking place hold for a metarecord |
| 18:27 |
bshum |
Not sure why yours would say "T" |
| 18:35 |
jeffdavis |
Neither am I. :S Thanks for checking. |
| 18:49 |
|
ericar joined #evergreen |
| 19:11 |
jeffdavis |
Ah, looks like a bug introduced when merging our TPAC customizations into 2.6, phew. |
| 01:33 |
|
eeevil joined #evergreen |
| 01:33 |
|
phasefx2 joined #evergreen |
| 03:11 |
|
dcook joined #evergreen |
| 04:51 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:17 |
|
artunit_ joined #evergreen |
| 06:53 |
|
mrpeters joined #evergreen |
| 07:19 |
|
edoceo joined #evergreen |
| 09:43 |
bshum |
I haven't heard of anything like that, and we use 7 64-bit all the time |
| 09:43 |
csharp |
okay - good to know |
| 09:44 |
bshum |
Well, "we" being most of our libraries / all of the rest of Biblio staff |
| 09:44 |
csharp |
well I only have access to 32-bit Windows 7 right now, so that rules out the main thing I was going to test |
| 09:44 |
|
kbeswick joined #evergreen |
| 09:45 |
csharp |
I assume it's one of those bugs that is elicited by a specific workflow |
| 09:54 |
* csharp |
daydreams about the beach he'll be sitting on tomorrow |
| 09:58 |
jeff |
Dyrcona: tt filter plugin for ncip work, or something else? |
| 09:59 |
Dyrcona |
jeff: For Evergren, actually. |
| 09:59 |
Dyrcona |
Evergre[e]n, even. :) |
| 11:23 |
Dyrcona |
And, Nautilus decides to take a nap. |
| 11:25 |
Dyrcona |
yboston: Dunno for sure, but don't think you're missing anything. |
| 11:26 |
berick |
yboston: what interace? |
| 11:26 |
yboston |
berick: my apologies, the are using the the GUI batch import |
| 11:26 |
yboston |
on the client |
| 11:27 |
yboston |
Dyrcona: thanks, I was afraid I was missing something obvious. I am currently playing around with Supercat URLs to see recently imported bibs, but I am not seeing DB ids listed so far in my tests |
| 11:28 |
yboston |
for the record, the catalogers import one or two bib records, and then want to immediatly start editing those records. having the bib id would allow them to jump to that record. |
| 11:29 |
yboston |
Right now they immediatly try to search for the record, but I beleive there is a delay for the records to be compeltly ingested, so they don't get a match to the just imported record |
| 11:29 |
yboston |
*immediately |
| 11:30 |
jeff |
or they searched for it in the catalog, then imported, then search again and their search results from the first time are still cached, etc. |
| 11:31 |
jeff |
i thought that there was a way to get to the marc editor from the import queue view, but i could be wrong. one workaround would be to append negative nonsense to their search to force it to not use the cached search results. |
| 11:32 |
jeff |
i.e., if you searched for Example Terms, you could search for Example Terms -sdhkjhgrh |
| 11:35 |
yboston |
jeff: thanks for alerting me about the search caching behavior, good to know, I knew there was some caching, but not any details about it |
| 11:37 |
yboston |
jeef (or someone else): how long are searches / search results typically cached? (just out of curiosity) |
| 11:40 |
berick |
yboston: default is 5 minutes. it's configurable in opensrf.xml, though |
| 11:40 |
yboston |
berick: thanks for all the info. |
| 11:41 |
yboston |
I guess I can put in a wishlist item for this, I am just glad I was not missing something obvious |
| 11:43 |
yboston |
I wonder what other catalogers do to work around this, though I am sure others have very different workflows or it takes them more than 5 minutes to search for the recently imported record |
| 11:45 |
yboston |
btw, I am trying to get the BD ids by testing out supercat URLs like this one http://catalog.berklee.edu/opac/extras/feed/freshmeat/htmlholdings/biblio/import/200/ |
| 11:45 |
yboston |
but so far I am not getting the db id, can anyone recommend other supercat URLs (or something similar) to try to stumble on the DB ids? |
| 11:46 |
yboston |
thnaks in advance |
| 11:54 |
pastebot |
"berick" at 64.57.241.14 pasted "for yboston -- show imported record ID in Vandelay queue" (20 lines) at http://paste.evergreen-ils.org/59 |
| 11:57 |
berick |
e.g. https://bill-dev2.esilibrary.com/eg/vandelay/vandelay?qid=11&qtype=bib (only works in FF for now -- still importing -- jump to page 100) |
| 11:59 |
|
kmlussier left #evergreen |
| 15:05 |
hbrennan |
thank you thank you for plugging that into git |
| 15:05 |
hbrennan |
If this gets fixed our library will rejoice |
| 15:06 |
hbrennan |
I will help in any way possible |
| 15:06 |
bshum |
I'm not a fan of how the links are generated in general. I'd kind of prefer if they were more combined in some way, having two links to the same title seems pointless to me (with the 490 and 800 on the same bib) |
| 15:07 |
bshum |
Also, I'm not sure why the hanging punctuation doesn't go away, I thought I saw stuff that seemed to be replacing it, but I have to read it more closely. |
| 15:07 |
bshum |
The hanging ; at the end of the entry on the test record on spork1 annoys me :) |
| 15:07 |
Bmagic |
bshum: perhaps the limit sets need to be "global" let me try that |
| 15:09 |
bshum |
Bmagic: I'd be curious if maybe changing it to use fallthrough = TRUE would alter how it behaves. What that would mean is that if rule 261 is linked to any other rule events, or used in concert with other rules, it might also extend the limit set to those other rule interactions. |
| 15:09 |
hbrennan |
It's definitely not very friendly |
| 15:11 |
jeff |
while reserving the right to revise my opinion, i'd say show the 490 where ind1=0, because that indicates that there will not be a corresponding 830 |
| 15:13 |
hbrennan |
so if there isn't any 800 info, show a link for the 490? |
| 15:13 |
hbrennan |
I'm rusty on cataloging |
| 15:13 |
bshum |
kmlussier: Do you remember offhand any graphic_880 test bibs in the concerto set that link to series? I want to see how it's presented... |
| 15:13 |
* bshum |
needs more google powers |
| 15:13 |
jeff |
I don't recall offhand what series-related adjustments we've made to our templates (or haven't backported), but http://catalog.tadl.org/eg/opac/record/46650237?locg=22 is an example of a record with a 490 with ind1=0 and no 830. I'd like the information (book 3 of The Hardy boys mystery series) to be displayed somewhere. |
| 15:14 |
bshum |
jeff: Yeah, that's part of what I'm concerned with monkeying with the links. I think we should revise how the links work but also preserve displaying the full series statements. |
| 15:15 |
* kmlussier |
looks. |
| 16:26 |
pinesol_green |
jboyer-home: Down time is a fact of business when you're a poor 501c3 corporation. |
| 16:27 |
|
ldw joined #evergreen |
| 16:27 |
Dyrcona |
jboyer-home++ |
| 16:28 |
Dyrcona |
Mabye I should test with a patron who has less than 4,196 circs in their history. |
| 16:29 |
bshum |
kmlussier: Oh, uh... your question from like hours ago. Whenever the next week starts is probably fine for the next dev meeting. |
| 16:29 |
* kmlussier |
had already forgotten she asked the question. :) |
| 16:29 |
* bshum |
doesn't have a strong opinion right now |
| 17:03 |
Dyrcona |
Well, going home for the day. |
| 17:03 |
Dyrcona |
Oddly enough, it feels like I just got here. |
| 17:05 |
|
mmorgan left #evergreen |
| 17:24 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:25 |
Bmagic |
bshum: to your knowledge, in order to allow for example 5 items of 3 different circ mods: dvd,book,audio for a total of 15, can I just associate 3 different limit sets to the same circ policy, or do I need 3 circ policies with a single limit set each? |
| 17:26 |
bshum |
Bmagic: Err, 5 of each sounds like 3 different limit sets to me. |
| 17:27 |
bshum |
Cause you wouldn't allow someone to get 10 of dvd and 5 of book to make up 15? |
| 19:57 |
hbrennan |
bshum: I'm curious what library "spork1" is.... That's the library with the same record info, but they've managed to hide the series author info from the link, so the link actually works. Perhaps there is a quick fix for now. |
| 19:59 |
hbrennan |
You can send me a later or I'll just find you next week. I forgot I'm out of here early today |
| 19:59 |
hbrennan |
Thanks! |
| 19:59 |
bshum |
hbrennan: that's my test server |
| 19:59 |
hbrennan |
ohhh |
| 19:59 |
bshum |
It's not a live system |
| 19:59 |
hbrennan |
So is that something you just did today? |
| 02:05 |
|
wjr joined #evergreen |
| 05:25 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:03 |
|
collum joined #evergreen |
| 08:08 |
|
ericar joined #evergreen |
| 08:09 |
|
akilsdonk joined #evergreen |
| 11:44 |
pinesol_green |
After restoring a database, make sure to reset the search_path accordingly with something like: alter database unpredicable_haxxors_go_away set search_path = 'evergreen, public, pg_catalog'; |
| 11:44 |
bshum |
dbwells++ |
| 11:44 |
dbwells |
bshum++ thanks |
| 11:49 |
mrpeters |
evergreen=# alter database evergreen set search_path = 'evergreen, public, pg_catalog'; |
| 11:49 |
mrpeters |
NOTICE: schema "evergreen, public, pg_catalog" does not exist |
| 11:49 |
mrpeters |
. |
| 11:50 |
mrpeters |
is that the right syntax for multiple schemas? |
| 11:51 |
mrpeters |
ALTER DATABASE evergreen SET search_path TO evergreen, public, pg_catalog; |
| 11:52 |
mrpeters |
if you want to fix pinesol :) |
| 11:54 |
mrpeters |
ew - ERROR: cannot ALTER TABLE "record_entry" because it has pending trigger events -- that should be fun |
| 11:55 |
mrpeters |
easy in a test db, maybe more tricky in production |
| 12:02 |
|
kmlussier joined #evergreen |
| 12:25 |
bshum |
mrpeters: = worked fine for me the other day, over TO |
| 12:25 |
bshum |
Maybe it's a version thing. |
| 12:26 |
bshum |
Or how the command was issued |
| 12:26 |
mrpeters |
maybe |
| 12:27 |
Dyrcona |
mrpeters: try it at night when no one should be cataloging. |
| 12:27 |
mrpeters |
Dyrcona: its a test db |
| 12:28 |
Dyrcona |
Ah. i saw production above. |
| 12:28 |
mrpeters |
what do i need to do to clean up? |
| 12:28 |
mrpeters |
i have no pending at.events |
| 14:49 |
pinesol_green |
kmlussier: Have you tried turning it off and back on again? |
| 14:49 |
pinesol_green |
kmlussier: I am only a bot, please don't think I'm intelligent :) |
| 14:50 |
hbrennan |
haha |
| 14:50 |
jeff |
$logger->info('some text') isn't logging where i would expect. that's unusual. |
| 14:51 |
jeff |
test/dev system, might just be configured wrong. |
| 14:52 |
dbwells |
bshum: P.S. if you (or someone else with editing privileges) could run that last ~no, it would fix the quote issue mrpeters pointed out earlier. Whether we use '=' or 'TO' doesn't seem to matter, but feel free to change that as well. |
| 14:52 |
bshum |
Oh sure. |
| 14:53 |
bshum |
~no search_path is <reply> After restoring a database, make sure to reset the search_path accordingly with something like: ALTER DATABASE unpredicable_haxxors_go_away SET search_path = 'evergreen, public, pg_catalog'; |
| 14:53 |
pinesol_green |
I'll remember that bshum |
| 14:56 |
yboston |
heads up, DIG will have its (rescheduled) monthly meeting at 3 PM EST ( a few minutes from now) |
| 14:58 |
bshum |
kmlussier: kbutler: hbrennan: Hmm, with testing, I can't seem to create the problem I thought existed with the password and phone thing. Nevermind, guess it does work the way I thought it should... |
| 14:58 |
hbrennan |
So it only changes during the first entering of phone? |
| 14:59 |
bshum |
Yeah, it seems to only apply it during new registrations so far in my testing. |
| 14:59 |
kbutler |
hmm |
| 14:59 |
bshum |
Changing it after, and then updating the password doesn't change it |
| 14:59 |
bshum |
At least on my test users |
| 14:59 |
bshum |
Err, changing the phone afterwards doesn't change the password from what I changed it to.... |
| 14:59 |
* bshum |
can't explain anything today apparently |
| 15:00 |
jeff |
ah. logging was not the issue. |
| 15:00 |
hbrennan |
On a related note, I noticed before that the password boxes weren't talking to each other.. so it didn't matter if they matched.. has that bug been fixed? |
| 15:00 |
bshum |
o.O |
| 16:15 |
yboston |
remingtron: BTW, the error with Asciidoc to HTML is that asciidoc get confused about image paths because we are using the "include:file_name.txt" directive, in terms of resloving paths |
| 16:21 |
|
tspindler left #evergreen |
| 16:27 |
remingtron |
yboston: glad you're making progress. Is there a particular reason you want to build it all locally? |
| 16:29 |
yboston |
remingtron: So I can test major changes to the docs, to see if I am breaking the converson |
| 16:29 |
yboston |
*converson |
| 16:29 |
yboston |
remingtron: without waiting until midnight for the docs server to proces the content |
| 16:30 |
yboston |
remingtron: also, to fostre redundancy in case the server goes down |
| 16:38 |
remingtron |
yboston: right, nice to not have to wait until midnight to see what breaks. :) |
| 16:38 |
yboston |
remingtron: I'll keep you posted on my progress |
| 16:38 |
remingtron |
great, thanks |
| 17:08 |
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 |
| 19:55 |
bshum |
gmcharlt: Just read https://bugs.launchpad.net/evergreen/+bug/1326983, sounds straightforward, but I have a question about it. the .example file doesn't overwrite an existing file if setup on the system, right? So we need to inform folks about the bug fix (if they don't actually read the changelogs). Release notes aren't really done for point releases, but maybe there's some other method we can think of. |
| 19:55 |
pinesol_green |
Launchpad bug 1326983 in Evergreen 2.5 "stock A/T filter for hold_request.shelf_expires_soon hook is too broad" (affected: 1, heat: 6) [Low,New] |
| 00:23 |
|
dluch joined #evergreen |
| 00:44 |
|
gsams joined #evergreen |
| 04:53 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:44 |
|
timf joined #evergreen |
| 07:14 |
|
collum joined #evergreen |
| 07:52 |
|
jboyer-isl joined #evergreen |
| 08:31 |
|
tspindler joined #evergreen |
| 08:40 |
|
mmorgan joined #evergreen |
| 08:55 |
|
Shae joined #evergreen |
| 09:09 |
jeff |
p/c |
| 09:11 |
|
kbeswick joined #evergreen |
| 09:17 |
|
yboston joined #evergreen |
| 09:39 |
jeff |
part of me wants a set of live tests with the usual data, then a set of live tests with evil data. |
| 09:39 |
jeff |
and of course, the middle ground is adding more unusual-but-perfectly-reasonable data to the "usual data" |
| 09:39 |
wlambert__ |
Good morning. I'm trying to get a new global admin account added to my test installation. I can get the account created, but when I try to log in to the staff client it fails. I've made sure the 'Work OU' box is checked. |
| 09:40 |
wlambert__ |
When I try to change user from the Admin menu I get more details. First the login fails then I get a javascript error - TypeError:$("username").select is not a function |
| 09:40 |
wlambert__ |
In the text at the top of the login screen I get the following: open0ols.auth.authenticate.complete |
| 09:41 |
wlambert__ |
oops. that was supposed to be open-ils.auth.. |
| 09:41 |
wlambert__ |
Any of you guys have any ideas? I'm stumped...again |
| 09:41 |
wlambert__ |
BTW this is Staff Client 2.6 and Evergreen.... |
| 09:41 |
wlambert__ |
just a sec |
| 09:42 |
wlambert__ |
Evergreen 2.6 |
| 09:56 |
|
ldw joined #evergreen |
| 09:57 |
|
kmlussier joined #evergreen |
| 10:13 |
bshum |
wlambert__: I don't think I've seen that particular error before. And it doesn't show up in my googling so far. |
| 14:39 |
bshum |
:) |
| 14:39 |
csharp |
I'm wondering if it makes sense to create a new contrib branch to handle README updates ;-) |
| 14:40 |
bshum |
We could worry about it after we commit the initial stuff for 14.04 |
| 14:40 |
csharp |
ok - sounds good |
| 14:40 |
csharp |
I'm re-testing my branch now |
| 14:40 |
bshum |
The more prodding we do though, the more I worry about backporting it to rel_2_6 in hindsight |
| 14:41 |
csharp |
yeah - I'll keep that in mind |
| 14:41 |
bshum |
That said, I'm perfectly happy putting a note somewhere, only use Precise with 2.6 and less. :D |
| 14:51 |
pinesol_green |
Launchpad bug 1208915 in Evergreen "Apache 2.4.6 warns about eg.conf" (affected: 2, heat: 10) [Undecided,New] https://launchpad.net/bugs/1208915 |
| 14:51 |
bshum |
Aha |
| 14:51 |
|
kbeswick joined #evergreen |
| 14:52 |
csharp |
catalog works |
| 14:52 |
csharp |
I'll need to tail the logs and test the client next |
| 14:53 |
csharp |
oh - and standardizing logging with rsyslog by default is something else I'd like to work on |
| 14:54 |
bshum |
I hear you there |
| 14:54 |
csharp |
and creating an example init/upstart/systemd script |
| 14:54 |
bshum |
I need to finally write a new logging central server |
| 14:54 |
bshum |
With rsyslog instead of old style syslog-ng |
| 15:03 |
|
hbrennan joined #evergreen |
| 15:06 |
|
mmorgan left #evergreen |
| 15:39 |
mceraso |
dbwells: I tested the 2.6.1 maintenance release using Ubuntu 12.04 LTS. Everything works well |
| 15:40 |
dbwells |
mceraso++ # thanks! |
| 15:51 |
|
gerson joined #evergreen |
| 15:58 |
gmcharlt |
mceraso++ |
| 16:54 |
Dyrcona |
Turns out that what I added was being ignored. |
| 17:01 |
|
artunit joined #evergreen |
| 17:11 |
|
mtate joined #evergreen |
| 17:26 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 18:44 |
|
zerick2 joined #evergreen |
| 18:58 |
|
zerick2 joined #evergreen |
| 19:14 |
|
t8r joined #evergreen |
| 10:01 |
Dyrcona |
eeevil: Cool! That is very useful. |
| 10:02 |
eeevil |
Dyrcona: obv, it's missing the icon_format part, but does simple_record (and friends) not work for that? |
| 10:07 |
|
wlambert joined #evergreen |
| 10:10 |
wlambert |
Good morning. I'm not usually one to ask for help, but I'm having some issues with my test installation. In particular I'm having issues installing Business::ISBN from cpan on a fresh 64 bit Ubuntu Precise server. Has anyone else experienced this issue? |
| 10:11 |
pastebot |
"wlambert" at 64.57.241.14 pasted "cpan Business::ISBN Error" (102 lines) at http://paste.evergreen-ils.org/53 |
| 10:12 |
wlambert |
Wow that is neat. That is the output I get from cpan. |
| 10:15 |
Dyrcona |
wlambert: Install it from the package libbusiness-isbn-perl via apt-get. |
| 10:17 |
csharp |
ah - yeah, patrons wouldn't like that |
| 10:18 |
csharp |
*those* users |
| 10:18 |
Dyrcona |
csharp: I usually only hear complaints from staff, only because most patrons don't know I exist. :) |
| 10:19 |
Dyrcona |
I'm using mafe and mtfe with some nasty joins and aggregates in a test query. |
| 10:19 |
kmlussier |
Dyrcona: That sounds interesting. Is your goal to fix the problem that arises with downloading long circ histories? |
| 10:19 |
Dyrcona |
kmlussier: Exactly that. |
| 10:20 |
Bmagic |
How does Evergreen know which limit_set to choose when there is more than one assocaited with the same matchpoint? |
| 10:27 |
Dyrcona |
Bmagic: No, it is the name of the limit set itself. |
| 10:27 |
jeff |
We're sorry, jeff, but your input focus is in another window! |
| 10:27 |
Bmagic |
That's what I thought http://docs.evergreen-ils.org/2.3/_circulation_limit_sets.html is confusing me |
| 10:28 |
Dyrcona |
Bmagic: That's OK. It confuses me, too, and helped to develop and test it. :) |
| 10:28 |
Bmagic |
Really, there is nothing about the definition of a limit set that means anything as far as the type of item or patron ect. The only thing that really means anything is the maximum items out |
| 10:29 |
Dyrcona |
Bmagic: The limit set is more a place holder. The names mean what you want them to mean, and should be related to what the rules actually do. |
| 10:29 |
* Dyrcona |
will look at his own for examples. |
| 10:34 |
csharp |
plus, it would be nice to recommend installation from OS packages rather than CPAN (where possible) |
| 10:34 |
csharp |
"if you're on debian/ubuntu, do 'sudo apt-get install ....'" |
| 10:34 |
wlambert |
I realized what I'd missed as soon as you guys started commenting. I really appreciate the help! |
| 10:34 |
bshum |
csharp: Well as of 14.04, all them are packages (which I tested myself when we setup our new standalone DB server) |
| 10:35 |
Dyrcona |
csharp: Sometimes O/S packages are broken. |
| 10:35 |
bshum |
csharp: I've been curious to know how Jessie is, but I think Wheezy isn't quite there. |
| 10:35 |
* Dyrcona |
gives the horde "maintainer" for Debian/Ubuntu the hairy eyball. |
| 10:42 |
jeff |
leave the system perl alone, use perlbrew and cpanm. :-) |
| 10:42 |
* csharp |
would at least like us to go the way of Koha and eventually have our own deb repo |
| 10:43 |
Dyrcona |
wlambert: Well, you probably could get away with an all-in-one server, but I'd make it kind of beefy, like 64GB or more of RAM with SSD for storage. |
| 10:43 |
jeff |
(i don't actually yet advocate that for evergreen, since i haven't tried it for the full system, even in test/dev) |
| 10:43 |
csharp |
even if we're not looking for full exception |
| 10:43 |
jeff |
my preferred debian mirror has disappeared from DNS. :P |
| 10:43 |
jeff |
this is mildly annoying. |
| 12:47 |
Dyrcona |
jboyer-home: It means the function was called with a full, field mapped ahr object, not just a database id. |
| 12:49 |
jboyer-home |
I found where that log line is printed and assumed it was something like that (We had a lot of trouble with similar issues because we used circ scripts for so long) Do you have a lot of questions about seemingly “impossible” holds captures, or are they not causing you problems there? |
| 12:49 |
Dyrcona |
jboyer-home: I don't think that would cause the impossible hold captures. It's more likely a case of you have a hold matrix matchpoint that is triggered when you don't expect it to. |
| 12:51 |
jboyer-home |
I tested the item and usr by hand with action.hold_permit_test and it failed, as it should. It’s possible that rsyslog lost the rest of the transaction I suppose, but I’m at a loss as to what might have happened. |
| 12:53 |
Dyrcona |
Dunno. Holds are complicated. |
| 12:54 |
jboyer-home |
Yeah, I’m trying to dig into it here, I was just hoping someone would say “Oh that, check this out: etc.” |
| 12:55 |
mmorgan |
jboyer-home: is it possible that the item was edited after capture? Just grasping at straws... |
| 16:45 |
gmcharlt |
csharp: yes |
| 16:46 |
csharp |
gmcharlt: excellent - thank you |
| 17:07 |
|
mmorgan left #evergreen |
| 17:13 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 18:32 |
|
Dyrcona joined #evergreen |
| 18:34 |
Dyrcona |
Shucks. |
| 18:35 |
Dyrcona |
jboyer-* is not around. |
| 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:46 |
|
timf joined #evergreen |
| 07:44 |
|
collum joined #evergreen |
| 08:16 |
|
rjackson-isl joined #evergreen |
| 09:17 |
csharp |
so is anyone out there in Evergreen land running their staff workstations in virtualized environments? I'm specifically interested in whether anyone's running Windows on VMWare, but I wanted to cast a wide net |
| 09:18 |
RoganH |
I have one library that runs on the MS platform (can't remember it's name). |
| 09:18 |
csharp |
one of our member libraries is complaining of constant freezes and needs for restarts and I was looking for a comparison point |
| 09:19 |
RoganH |
I know a few more that have talked about it. I'll check to see where they are in their testing. |
| 09:19 |
csharp |
RoganH: thanks! |
| 09:19 |
RoganH |
Actually, now that I think about it, we have another who has been virtual for a long time and they might be VMWare. I tend to forget about them because they did it before it was cool. |
| 09:20 |
RoganH |
They had a really top notch IT guy at the time. |
| 09:21 |
csharp |
phasefx: yeah, I would *love* to steer them towards something like Lubuntu, but that's almost certainly out of the question ;-) |
| 09:21 |
* csharp |
reboots the Fedora buildslave |
| 09:22 |
phasefx |
csharp: if it's all configured, they can just pretend it's a weird app :) |
| 09:22 |
RoganH |
OK, I'm seeing a very narrow problem with searching for email. Can I get anyone else to test it in their staff clients? |
| 09:22 |
csharp |
heh - yeah, I'll see if I can sneak that in ;-) |
| 09:22 |
RoganH |
What happens is if you search for an email that starts with an 'a.' will fail. |
| 09:23 |
RoganH |
So, for example, a.smith generic.net will generate an error. Or A.smithgeneric.net |
| 09:27 |
RoganH |
We've been playing around to narrow down the criteria. It's odd. |
| 09:28 |
RoganH |
Specifically I get a 500 network error. |
| 09:28 |
jeff |
and server side, what is the error? |
| 09:28 |
RoganH |
I tested this last night at 11 pm when there was no server load. |
| 09:29 |
RoganH |
I haven't gone that far yet. I was looking to see if others knew of anything similar but it sounds like a unique to us thing now. |
| 09:30 |
RoganH |
The weird ones are kind of fun so long as they don't affect too many situations. :) |
| 09:30 |
jeff |
RoganH: not that I think that method has changed much recently, but what version are you on? |
| 09:30 |
RoganH |
jeff: 2.5.3 |
| 09:30 |
jeff |
thanks. |
| 09:32 |
bshum |
Well, I modded one of my test accounts to include a style of email like a.testsomewhere.com |
| 09:32 |
bshum |
And while it took awhile to search, it did retrieve the patron in search |
| 09:33 |
bshum |
Might just be a timing issue of some sort. Where the DB takes just a little too long, and the service stops paying attention? |
| 09:33 |
jeff |
server logs are going to be the next best clue. |
| 09:33 |
bshum |
Indeed. |
| 09:34 |
RoganH |
bshum: that's what I'm thinking but yeah, just odd since it coughs up responses to just "a" or "a." with no problem but we've all seen weirder |
| 11:21 |
Bmagic |
who is using keepalived ? |
| 11:44 |
csharp |
bshum: can you catch me up on the status of 14.04 and Evergreen? |
| 11:49 |
Dyrcona |
csharp: I can tell you that on the vms and other computers where we at MVLC have tried upgrading from 12.04 to 14.04, we've had horrible luck. |
| 11:49 |
csharp |
yeah, I expected that from my early tests |
| 11:50 |
csharp |
right now I'm going for clean install - I just didn't want to duplicate effort |
| 11:50 |
Dyrcona |
Even going from 13.10 to 14.04 on my laptop left it in a state that it wouldn't boot. |
| 11:50 |
csharp |
my "desktop" ubuntu upgrades went fine |
| 11:50 |
csharp |
but we don't really upgrade |
| 11:59 |
* csharp |
invites berick to correct him, though |
| 12:01 |
tsbere |
csharp: Given some of the headaches with previous attempts of my own to upgrade dojo I would recommend we remove it, not update it. >_> |
| 12:02 |
* tsbere |
thinks he had found that we are using features that they did not continue to include in later versions |
| 12:05 |
csharp |
ah - well if going forward with dojo isn't certain, I'll not spend too much time on it |
| 12:06 |
csharp |
I'm just reacting to some UI glitch-type frustrations discovered when testing acq, and was hoping to ameliorate things |
| 12:10 |
|
ericar joined #evergreen |
| 12:12 |
csharp |
no mention of dojo in the agendas/minutes of dev meetings over the last year |
| 12:12 |
csharp |
I guess with angular.js in the picture, that would be the preferred toolset, though, right? |
| 12:13 |
csharp |
@ana TOO MANY TOOLSETS |
| 12:13 |
pinesol_green |
csharp: Tamest loony to so |
| 12:14 |
dbs |
angular is not a toolset the way that dojo is (at least, not in terms of widgets) |
| 12:14 |
dbs |
It tries to be minimalist |
| 12:21 |
mrpeters |
was considering upgrading to 14.04 when we upgrade someone to 2.6 |
| 12:22 |
csharp |
mrpeters: I'm working on that right now |
| 12:22 |
csharp |
bshum: did you have an EG branch you were working on? or was my branch the only one? |
| 12:22 |
mrpeters |
yeah, cool. i need to set up their testing server within the next week or two so i may have to just roll with 12.04 for that, and then 14.04 for production |
| 12:23 |
bshum |
csharp: I think yours is the only one I know about. |
| 12:23 |
mrpeters |
which i dont love, but we can always rebuild test server at a later date |
| 12:23 |
csharp |
bshum: okay - cool - thanks! |
| 12:23 |
berick |
csharp: i would love to replace the dojo UIs with angular versions, but there is no specific plan in place to do that yet |
| 12:23 |
csharp |
berick: do you think it's best then to stay with old dojo for the foreseeable future? |
| 13:22 |
csharp |
yeah - that happens here too |
| 13:23 |
csharp |
I'm going to investigate eeevil's suggestion to identify those records and export them piecemeal to stay under the size limit |
| 13:23 |
csharp |
identifying the records will be the hardest part of that |
| 13:26 |
egbuilder |
build #594 of evergreen-master-fedora-18 is complete: Failure [failed test] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-fedora-18/builds/594 blamelist: Mike Rylander <mrylandergmail.com> |
| 13:26 |
Dyrcona |
I read that as "is complete failure" though guess it amounts to the same. |
| 13:29 |
csharp |
that's after upgrading to Fedora 20, FYI |
| 13:30 |
csharp |
looks like there are some deps that got tore up |
| 13:30 |
Dyrcona |
Perl 5.18? |
| 13:30 |
dbwells |
csharp: I'm double-checking the commit I just pushed. Are you saying that probably isn't the problem? |
| 13:30 |
Dyrcona |
My understanding is some tests and some CPAN modules's tests fail under Perl 5.18. |
| 13:30 |
bshum |
Yeah there's some bugs for that. |
| 13:30 |
csharp |
dbwells: I'm saying that it's likely an OS problem |
| 13:31 |
csharp |
I'm looking now |
| 13:37 |
mrpeters |
and open-ils.circ is definetly running with listener/drone, etc. |
| 13:37 |
csharp |
dbwells: I don't have control over the Debian VM |
| 13:38 |
csharp |
however, with mundungus up and running, creating one under everyone's control is easy ;-) |
| 13:38 |
dbwells |
csharp: that's fine, I'd just like to see one successful buildbot test before I package 2.6.1 today :) |
| 13:38 |
Dyrcona |
mrpeters: Not seen that one. |
| 13:38 |
csharp |
dbwells: ok, ubuntu 12.04 buildslave is back up |
| 13:39 |
dbwells |
csharp: sweet, thank you |
| 13:47 |
mrpeters |
Dyrcona: yeah, and i assume plenty have installed 2.6 from tarballs, so we just need to find our needle in the haystack :) |
| 13:48 |
Dyrcona |
mrpeters: Well, I don't make that assumption, but I've installed it from git. |
| 13:48 |
|
hbrennan joined #evergreen |
| 13:48 |
csharp |
dbwells: fedora buildslave was updated and is ready for testing... I don't know how to trigger a rebuild |
| 13:49 |
mrpeters |
yeah, ill fire up a new vm and install the old fashioned slow way :P |
| 13:49 |
Dyrcona |
I typically only see problems like that when I'm fooling around in development and have edited code. |
| 13:50 |
Dyrcona |
mrpeters: Try this: perl -c /usr/local/share/perl/5.14.2/OpenILS/Application/Circ.pm |
| 14:08 |
mrpeters |
you got us started down the right road now, we'll get this sorted |
| 14:08 |
mrpeters |
apt-get install libjson-perl did the trick! |
| 14:10 |
pinesol_green |
[evergreen|Mike Rylander] LP#1321017: Order constituent records by quality - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4897a05> |
| 14:15 |
egbuilder |
build #595 of evergreen-master-fedora-18 is complete: Success [build successful] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-fedora-18/builds/595 |
| 14:33 |
csharp |
yay! |
| 14:46 |
Dyrcona |
\o/ |
| 14:51 |
|
mmorgan1 joined #evergreen |
| 16:34 |
dbwells |
jeff: thanks |
| 16:45 |
|
kbeswick joined #evergreen |
| 16:56 |
|
jwoodard joined #evergreen |
| 17:31 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:56 |
|
ktomita_ joined #evergreen |
| 18:41 |
|
timf joined #evergreen |
| 19:19 |
pastebot |
"gsams" at 64.57.241.14 pasted "How I solved the duplication of "Lost Materials", "Overdues", "Lost Materials Processing Fee" in that SQL Query" (61 lines) at http://paste.evergreen-ils.org/51 |
| 08:33 |
kmlussier |
Has anyone else had trouble with these group format and edition searches? |
| 08:33 |
|
collum joined #evergreen |
| 08:34 |
|
Shae joined #evergreen |
| 08:35 |
bshum |
I haven't tried combining fields. Only used keyword to test. Sigh. |
| 08:36 |
csharp |
well, that should at least be obvious in the osrferror.log |
| 08:37 |
bshum |
One side thought is whether we should be adding the new qtype selector choices on that advanced search page too |
| 08:37 |
bshum |
Unrelated |
| 08:56 |
csharp |
awesome |
| 08:58 |
bshum |
dbwells: Yeah I hadn't gotten to the OR operator yet, but suspected :\ |
| 08:59 |
dbwells |
It doesn't even need to be two fields. Just putting 'one && two' in the basic search box will trigger the bug when adding 'Group formats'. |
| 09:00 |
bshum |
Yeesh |
| 09:00 |
bshum |
Nothing quite like live testing bugs in production :) |
| 09:00 |
kmlussier |
It's too bad I didn't start preparing for my new features demo before you all upgraded. :) |
| 09:02 |
dbwells |
@blame kmlussier |
| 09:02 |
pinesol_green |
dbwells: kmlussier is why we can never have nice things! |
| 15:17 |
eeevil |
Dyrcona: how about something like: where => {+ccvm => { id => { '<@' => { transform => 'intset', value => {'+mravl' => 'vector' }}}}} [entirely untested] |
| 15:17 |
Dyrcona |
eeevil: That's better than what I got. I'll give it a whirl. |
| 15:22 |
|
hbrennan joined #evergreen |
| 15:27 |
bshum |
berick++ # we'll test it a bit and I'll probably sign / push it soon |
| 15:28 |
bshum |
I wonder if dbwells has cut the maintenance releases yet, or if this can be one of the last things we get in there... |
| 15:40 |
dbwells |
bshum: Since we had our upgrade scheduled for last Friday, I decided it made more sense to release afterwards in case we encountered any new bugs. If you can get this in today, please do, but I'm less comfortable stretching much beyond that. |
| 15:40 |
bshum |
dbwells++ # sounds like a plan, 2.6.1 ftw! :) |
| 15:40 |
bshum |
I don't have much else new to push through on my end at the moment. |
| 16:45 |
jcamins |
My public libraries give me a headache. |
| 16:47 |
|
tspindler left #evergreen |
| 16:53 |
jcamins |
bshum: the first line is excellent. |
| 16:56 |
pinesol_green |
[evergreen|Bill Erickson] LP#1322303 cleanse backdate for checkin overdue voiding - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e3e264a> |
| 17:15 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:21 |
* eeevil |
looks up |
| 17:21 |
|
mmorgan left #evergreen |
| 17:27 |
eeevil |
@later tell krvmga this is precisely the situation where search.relevance_adjustment comes into play. In particular, the first_word bump. though, ideally, it would be a more generic "starts with" adjustment. of course, an actual title search does a LOT better in terms of ranking |
