| 13:15 |
dbs |
eeevil: Oh, that README is bound up in a branch with the Encode.pm fixes |
| 13:15 |
eeevil |
dbs: ah, well, that's a one-liner for me ... |
| 13:15 |
eeevil |
ah! |
| 13:15 |
dbs |
(Because I added more tests for the Encode stuff) |
| 13:15 |
eeevil |
dbs++ |
| 13:15 |
bshum |
Ah, dbs++ |
| 13:15 |
dbs |
If we could merge that, we'd fix Fedora and get docs too.. *ahem* :) |
| 13:15 |
bshum |
Can I mark an action item for someone (maybe eeevil to check that in?) |
| 13:16 |
bshum |
#action eeevil to publish detailed plan about freezing baseline schemas between EG releases and using deprecates/supersedes in database upgrade scripts. This will go on the mailing list and the thread should structure further discussion of pros and cons of eeevil's plan. |
| 13:16 |
dbs |
#info branch with pgTAP tests and Encode fixes is in https://bugs.launchpad.net/evergreen/+bug/1242999 |
| 13:16 |
pinesol_green |
Launchpad bug 1242999 in Evergreen "Encode.pm 2.54 breaks database functions (naco_normalize, maintain_control_numbers, others)" (affected: 1, heat: 10) [High,Confirmed] |
| 13:16 |
dbwells |
I intend to re-review and push the Encode.pm stuff later today, or Monday at the latest. |
| 13:16 |
dbs |
dbwells++ |
| 13:38 |
dbwells |
I changed the 2.next tag to 2.6.0-alpha earlier today. |
| 13:38 |
bshum |
I'll take an action item to help do that. Or give dbwells access to the google calendar to set it himself. |
| 13:38 |
bshum |
(probably both actually) |
| 13:38 |
egbuilder |
build #470 of evergreen-master-debian-6.00-x86_64 is complete: Success [build successful] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-debian-6.00-x86_64/builds/470 |
| 13:38 |
dbwells |
bshum++ |
| 13:40 |
bshum |
#action bshum to set new calendar entries for 2.6 milestone events and give access to dbwells to dev calendar. |
| 13:40 |
bshum |
Okay, anything else before we move on? |
| 13:42 |
bshum |
berick: floor is yours |
| 13:42 |
bshum |
(to give to others) |
| 13:42 |
berick |
yep, I'm wondering if there are any comments on the techincal bits, since feedback has been sparse so far. |
| 13:43 |
ldwhalen |
I am concerned about the speed of Angularjs on older machines. I am not sure if this is a valid concern because I have not done any testing. |
| 13:43 |
|
akilsdonk joined #evergreen |
| 13:44 |
berick |
ldwhalen: where does the concern come from? |
| 13:44 |
bshum |
#link Prototype wrap-up report: http://yeti.esilibrary.com/dev/pub/web-staff-report.html |
| 13:44 |
ldwhalen |
Angularjs is obviously doing a lot of work manipulating the DOM and passing information back and forth via the $scope object |
| 13:45 |
RoganH |
I have done very limited testing. I've done demos to get feedback from front line staff on our "spare" machine the front desk. |
| 13:45 |
RoganH |
It's about a five year old low end intel with 2 gigs of RAM. The demo at least ran very well on it. |
| 13:45 |
berick |
so, my usual spiel on angular is that if we weren't using it, we would be doing all the same stuff manually w/ our own code (assuming a dhtml ui). |
| 13:46 |
ldwhalen |
my concern is with a bad model and view implementation it might be slow. I am not concerned with the current prototype. |
| 13:46 |
gmcharlt |
anything can be too slow if coded badly |
| 13:46 |
ldwhalen |
I want to idenitfy if there is a limit to chainging models and views in one screen and how we might avoid |
| 13:46 |
dbs |
ldwhalen: Angular is extremely lean, as far as JavaScript frameworks go |
| 13:47 |
ldwhalen |
alright. I will go and test and come back if I have any concerns. |
| 13:48 |
dbs |
berick: is bootstrap 2 or 3 in use? (Yes, I have not dived into the prototype code yet) |
| 13:48 |
jeff |
ldwhalen++ |
| 13:48 |
berick |
ldwhalen: cool, testing very much appreicated |
| 13:48 |
jeff |
dbs: it appears to be 3.0.1 |
| 13:49 |
* dbs |
looked and confirmed that too |
| 13:49 |
Dyrcona |
My only question is: Are AngularJS and Bootstrap the final word on the staff client? |
| 13:54 |
dbs |
berick: your report made no mention of printing support; any thoughts on that? |
| 13:54 |
jboyer-isl |
(The non-IE support, that is_ |
| 13:54 |
dbwells |
berick: I think last I checked, you were using a third party integration of Angular and Bootstrap. Is that still true? |
| 13:54 |
ldwhalen |
I hope to rid myself of that concern with the testing |
| 13:54 |
jeff |
I understand that bootstrap 3.x is not backward compatible with bootstrap 2.x, and that the effort involved in porting from 2.x to 3.x can vary by site/app, but can be significant. Does bootstrap 3.x have a stated/expected lifespan / support lifecycle? |
| 13:55 |
berick |
dbs: it's covered more fully in the specs and original proposal: printing and offline storage will be a separate project |
| 13:55 |
berick |
dbwells: 3rd-party hosted, yes, that will have to change eventually, but it's easier for testing |
| 13:56 |
berick |
jeff: good question. |
| 13:56 |
dbwells |
berick: no, I mean the AngularUI stuff. I think that is a third party, right? |
| 13:56 |
berick |
dbwells: oh, yes, that is. |
| 13:56 |
rfrasur |
Is this a meeting or general discussion? |
| 14:10 |
gmcharlt |
keeping in mind that oldstable general is expected to go away a year after the release of the current stable |
| 14:10 |
jeff |
+1 stable and oldstable |
| 14:11 |
dbs |
+1 stable and oldstable |
| 14:11 |
Dyrcona |
But, I think the question at hand is how do you support new stable on day one if you haven't started working with testing? |
| 14:11 |
berick |
fwiw, i had wheezy patches on LP 6 months before it was released |
| 14:11 |
berick |
give or take, i don't remember ;) |
| 14:11 |
* csharp |
appears |
| 14:12 |
gmcharlt |
Dyrcona: fair question; but yes, supporting stable does imply that folks exercise OpenSRF and Evergreen in testing beforehand |
| 14:12 |
jeff |
it's probably time to start testing with testing/jessie. i'm happy to help. |
| 14:12 |
csharp |
I think it would be reasonable to take a similar approach to ubuntu LTS and treat the old LTS like Debian oldstable and support it for a year after a new LTS release |
| 14:12 |
gmcharlt |
jeff: just avoid running sudo apt-get install kaboom |
| 08:39 |
|
kbeswick joined #evergreen |
| 08:42 |
|
Shae joined #evergreen |
| 09:02 |
|
timlaptop joined #evergreen |
| 09:06 |
pinesol_green |
[evergreen|Srey Seng] LP#1266937: Fix missing/incorrect regex for authority in Vandelay.pm - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0947992> |
| 09:24 |
pinesol_green |
[evergreen|Dan Scott] Repair the live_t regression tests - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=812a726> |
| 09:29 |
|
Dyrcona joined #evergreen |
| 09:34 |
pinesol_green |
[evergreen|Kyle Tomita] LP1038240 - Patron editor field documentation does not display text - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=df6a6b9> |
| 09:36 |
|
mmorgan joined #evergreen |
| 09:50 |
pinesol_green |
[evergreen|Dan Scott] Tests: Ensure TT2 templates parse cleanly - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5bf117c> |
| 09:54 |
egbuilder |
build #466 of evergreen-master-debian-6.00-x86_64 is complete: Failure [failed test] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-debian-6.00-x86_64/builds/466 blamelist: Dan Scott <dscott laurentian.ca> |
| 09:54 |
egbuilder |
build #472 of evergreen-master-ubuntu-12.04-x86 is complete: Failure [failed test] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-ubuntu-12.04-x86/builds/472 blamelist: Dan Scott <dscottlaurentian.ca> |
| 09:56 |
|
gsams joined #evergreen |
| 09:57 |
jeff |
Test::Output needed as new pre-req on build slaves, it appears. |
| 09:58 |
* dbs |
should be able to arrange for that on a few of those slaves |
| 09:58 |
dbs |
@blame Dan Scott |
| 09:58 |
pinesol_green |
dbs: Dan Scott musta been an Apple employee. |
| 10:02 |
|
collum joined #evergreen |
| 10:05 |
bshum |
ktomita++ # field doc repairs, yay!!!! |
| 10:24 |
|
yboston joined #evergreen |
| 10:27 |
csharp |
okay Test::Output installed on Fedora and Ubuntu buildslaves |
| 10:28 |
bshum |
csharp++ |
| 10:31 |
|
hopkinsju joined #evergreen |
| 10:38 |
dbs |
Test::Output installed on testing.evergreen-ils.org as well |
| 10:41 |
csharp |
dbs++ |
| 10:41 |
egbuilder |
build #473 of evergreen-master-ubuntu-12.04-x86 is complete: Success [build successful] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-ubuntu-12.04-x86/builds/473 |
| 10:41 |
csharp |
yay! |
| 10:42 |
* dbs |
needs to bring over a vpnc conf for upei's build slave still... |
| 10:42 |
csharp |
all is well in the world, so I'll just sit back and ... oh crap! I have an upgrade next week! |
| 10:43 |
bshum |
Hmm |
| 10:43 |
dbs |
ah, http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-fedora-18/builds/440/steps/test/logs/stdio is still failing because of Encode.pm I imagine |
| 10:43 |
bshum |
Contemplating https://bugs.launchpad.net/evergreen/+bug/1208875 |
| 10:43 |
pinesol_green |
Launchpad bug 1208875 in Evergreen "OPAC: My Account: Download Checkout History CSV breaks when there are a large number of items in the history" (affected: 2, heat: 10) [Undecided,New] |
| 10:44 |
dbs |
fedora also failing on "Can't locate Locale/Maketext/Extract.pm" |
| 11:03 |
* dbs |
wonders if the validation result was cached |
| 11:03 |
dbs |
roses: it would be in the database in authority.record_entry as one of the most recently added entries |
| 11:03 |
Dyrcona |
gmcharlt++ |
| 11:06 |
roses |
dbs: We think we have tested possibly the caching issue. ie put it in a couple of weeks ago and it still doesn't work. Are there settings for keeping cache (how long etc) |
| 11:08 |
dbs |
roses: the cache settings are all hard coded; a few weeks ago would certainly be cleared by now |
| 11:09 |
roses |
dbs: we are stumped. Sara (the person who has the issue) has emailed super catalogers but they all seemed not to be using it at this level. |
| 11:10 |
roses |
dbs: Sara said that the people she talked to were just using LOC as is and not adding their own records. |
| 12:24 |
dbs |
and user/dbs/fedora_maketext_2_4 as well |
| 12:32 |
|
rfrasur joined #evergreen |
| 12:36 |
|
jihpringle_ joined #evergreen |
| 12:40 |
csharp |
dbs: signoff branch (for master/2.5) is at user/csharp/fedora_maketext_signoff |
| 12:40 |
csharp |
I tested it on the buildslave - no issue |
| 12:41 |
dbs |
yay! |
| 12:41 |
dbs |
csharp++ |
| 13:02 |
|
kbutler joined #evergreen |
| 14:02 |
yboston |
kmlussier warned that she will not be ble to make it today |
| 14:02 |
yboston |
(Happy new year to everyone) |
| 14:02 |
remingtron |
looks like a small meeting |
| 14:02 |
eeevil |
bshum: oh, the 2.4.5 RC is gold, just needs to be moved into place. never got a "tested, works" from anyone, which is why I didn't just push it out |
| 14:03 |
rfrasur |
(happy new year as well) |
| 14:03 |
* eeevil |
hushes for the dig meeting. sorry |
| 14:03 |
yboston |
I will wait one more minute before starting our (small) meeting |
| 10:16 |
Dyrcona |
Is it a "real" problem, i.e. the bill doesn't actually show as paid, or is it just an cosmetic problem because staff don't like the payment predating the bill? |
| 10:18 |
Dyrcona |
jeff: BTW, I pushed some updated billing branches last night and fixed its issues with the fine generator. So, I'm a bit sensitive about changes that would require me to make more changes to my code. :) |
| 10:19 |
Dyrcona |
Ah, I see how it could be a real problem if you're looking at it on that day.. billing_ts < now() might pose an issue, eh? |
| 10:21 |
phasefx |
incidentally, a qa test involving fines failed the past two nights. I'm poking |
| 10:24 |
|
yboston joined #evergreen |
| 10:25 |
jeff |
Dyrcona: it's an issue when i'm working on bug 1174498 / mmpbbt |
| 10:25 |
pinesol_green |
Launchpad bug 1174498 in Evergreen "Payment by billing type breakdown" (affected: 3, heat: 14) [Wishlist,In progress] https://launchpad.net/bugs/1174498 - Assigned to Jeff Godin (jgodin) |
| 10:35 |
berick |
yeah |
| 10:36 |
RoganH |
I just sat down with three of our full time circ staff and had them play with Bill's web based staff client. They wanted to know how soon it could be finished and they could use it up front. |
| 10:39 |
jeff |
Dyrcona: got to the end of the comment on that function with a "these words sound vaguely familiar" feeling, then read the last statement on the comment, laughed |
| 10:41 |
berick |
RoganH++ # field testing |
| 10:41 |
berick |
very cool |
| 10:43 |
Dyrcona |
jeff: The comments in the function are meant to be helpful, too. :) |
| 10:43 |
Dyrcona |
But, yeah, your code was the inspiration even if it looks very different now. |
| 10:44 |
Dyrcona |
RoganH++ # Being braver than I. |
| 10:59 |
Dyrcona |
jeff: The reason for going by payment/bill amount was that it would likely match lost payments up with lost billings more accurately than a simple date-based approach. |
| 11:00 |
Dyrcona |
tsbere: That's probably true in any setting when humans are involved. :) |
| 11:13 |
|
rfrasur joined #evergreen |
| 11:35 |
bshum |
phasefx: Were those failed tests new to the testing suite? Or was it something that we've changed in master since the new year began? |
| 11:35 |
jeff |
one solution to future-billings and mmpbbt: treat overdue billings with 23:59 timestamp as -1 day :-) |
| 11:36 |
bshum |
phasefx: The only thing that's changed in master was altering the stock org unit data, so maybe that's something. Otherwise, the rest are catalog changes so far as I can tell. |
| 11:38 |
* Dyrcona |
wouldn't be surprised if something in the test environment changed. |
| 11:38 |
phasefx |
bshum: I'm suspecting environment (date, timezone, external package) and not recent code changes |
| 11:38 |
Dyrcona |
jinx! |
| 11:38 |
phasefx |
I've been pulled away from poking though |
| 11:38 |
Dyrcona |
test == more code == more bugs. :p |
| 11:42 |
bshum |
Heh |
| 11:43 |
eeevil |
jeff: re "one solution to future-billings and mmpbbt", how about just billing_ts::date::timestamptz if billing_ts::time = '23:59:59'; -- adjust spelling of time as required |
| 11:43 |
jeff |
eeevil: better, i think. |
| 11:54 |
jeff |
eeevil: i got what you meant, but thanks for making sure. :-) |
| 11:56 |
eeevil |
jeff: probs, yes, re quirks |
| 11:57 |
* jeff |
looks at live_t/05-pay_bills.t |
| 12:01 |
phasefx |
jeff: those tests depend on preceding tests, so 03-overdue-circ is where I would look first; if you're looking because of the failure |
| 12:02 |
jeff |
phasefx: sorry, i was looking because i wanted to add some billing / overdue / checkin / backdate / etc related tests, and wanted to see what was already there |
| 12:02 |
phasefx |
gotcha |
| 12:03 |
jeff |
phasefx: thanks, though -- at least one comment or the commit message made that part clear also (that the tests relied on each other) |
| 12:04 |
jeff |
oh, the text of the test itself clued me in: Two billable xacts for admin user from previous tests |
| 12:33 |
|
snowball_ joined #evergreen |
| 12:33 |
|
snowball_ left #evergreen |
| 12:36 |
phasefx |
so 03-overdue-circ, I think the test assumptions are flawed. Fines didn't get created for the 28th and 29th of December.. those are on a weekend, and hours of operation with the stock test data have those days as closed for BR4. So no fines? |
| 12:37 |
phasefx |
I should use a different org that is always open |
| 12:41 |
tsbere |
phasefx: Should probably test both cases, really... |
| 12:41 |
phasefx |
tsbere: sounds good |
| 12:42 |
jeff |
perhaps. could also create a closing date and test that. not sure how best to test standard hoo closings, though |
| 12:42 |
phasefx |
04-overdue_with_closed_dates.t |
| 12:43 |
phasefx |
I think there is also a DST issue with the tests, but I didn't record it at the time |
| 12:52 |
jeff |
@decide UTC or Swatch Internet Time? |
| 12:52 |
pinesol_green |
jeff: Yeah, well, you know, that's just like uh, your opinion, man. |
| 13:02 |
csharp |
the_dude++ |
| 13:04 |
jeff |
i just tried to type and tab-complete both phasefx and csharp at the same time. it did not work. |
| 13:04 |
jeff |
phasefx: is the random repo still the definitive place for eg_wheezy_installer.sh? |
| 13:06 |
|
stevenyvr2 joined #evergreen |
| 13:10 |
phasefx |
jeff: it is |
| 13:11 |
phasefx |
jeff: I have a link to gitweb from |
| 13:11 |
phasefx |
http://testing.evergreen-ils.org/~live/ |
| 13:13 |
jeff |
phasefx: thanks! |
| 13:16 |
dbs |
phasefx: aha, crap, so my addition of more more interesting HOO broke the live tests. sorry about that. |
| 13:17 |
phasefx |
dbs: s'okay, more interesting data, more interesting tests :) |
| 13:17 |
* dbs |
will attempt to fix |
| 13:19 |
dbs |
oh, right, crapola... these tests can't be run twice in a row :/ |
| 13:19 |
phasefx |
yeah, have to wipe the database at least |
| 13:19 |
phasefx |
we can strive to have tests that clean up after themselves, but I don't think we can/should require it |
| 13:20 |
phasefx |
that said, redoing those existing ones so they're not registering workstations could help |
| 13:20 |
phasefx |
add some stock registrations to concerto |
| 13:22 |
dbs |
Yeah, it's just a bit of a painful stop opensrf / recreate database / start opensrf debug cycle |
| 13:25 |
dbs |
Better than the alternative of entirely manual testing though |
| 13:29 |
dbs |
Mmm. Yeah. Hmm. What if the regression tests just created a brand new OU rather than messing with the sample data? |
| 13:31 |
dbs |
Working through the "Set closing start date 10 days ago and closing end date 9 days ago" logic and figuring out what that means if the OU comes in already having closed dates is hurting my brain atm |
| 13:31 |
jeff |
sounds good to me. either create the testing org unit(s) as part of an earlier test, or define an explicit "testing" set of data to be loaded, distinct from the "sample" data. |
| 13:31 |
dbs |
Or maybe we just start by setting the BR4 HOO to known values (the old defaults) from the start, rather than relying on the sample data |
| 13:31 |
phasefx |
yeah, I think that's a good strategy too, creating data as needed |
| 13:32 |
|
librarian joined #evergreen |
| 13:32 |
phasefx |
we do it with the closed date, since that has to be relative to the test run date |
| 13:44 |
|
hopkinsju joined #evergreen |
| 13:46 |
hopkinsju |
We've got a library that is interested in migrating their historical circs. I've told them that it's really not feasible. We don't have time to run 10 million circulations before we go live with them. Not to mention that many of the circs would fail due to deleted users, etc. I don't suppose there is a simple way of importing this information so that it could be combined with Evergreen circs and reported on? |
| 13:47 |
jeff |
hopkinsju: you could look into importing them as "aged" circulations. the foreign key constraints are then less of an issue. |
| 15:13 |
bshum |
Also, whether authorities make things messier |
| 15:14 |
yboston |
bshum: Happy new year, I will ask the catalogers |
| 15:15 |
yboston |
bshum: what version are you running? we moved to 2.5.1 yesterday |
| 15:16 |
jeff |
huh. seeing a failure with registering a workstation. wonder if i did something wrong. |
| 15:16 |
jeff |
(running tests from eg_wheezy_installer.sh) |
| 15:17 |
jeff |
ah, yep. |
| 15:17 |
jeff |
failed to pass -s, so the required sample data was not present. |
| 15:18 |
bshum |
yboston: We're using master, but basically 2.5.1ish |
| 15:18 |
bshum |
More like whatever 2.5.2 will be |
| 15:18 |
yboston |
bshum: (it was right there in the first one of your bug, my bad) |
| 15:22 |
bshum |
yboston: Post-upgrade fun is always... well... fun. |
| 15:23 |
phasefx |
jeff: the way I use it now is a pristine wheezy image gets restored every night prior to run |
| 15:23 |
jeff |
phasefx: got it. thanks. :-) |
| 15:23 |
phasefx |
and for testing, I was using virtualbox a lot |
| 15:24 |
jeff |
huh. there's a sure fire way of finding a bunch of things to clean up: run the installer + tests with just stdout redirected to a file -- observe the output of stderr. |
| 15:24 |
jeff |
(made worse by my running this in an unsupported way, as previously established) |
| 15:28 |
|
kbeswick joined #evergreen |
| 15:31 |
|
roses joined #evergreen |
| 15:46 |
hopkinsju |
Dyrcona: I ran a query and it turns out that circ_lib is all over the place for these items. Something must have updated them, but I'm not inclined to figure it out at this point. I'm going to see about getting enough information into action.aged_circulation to make it useful. |
| 16:15 |
hbrennan |
Dyrcona, did you attend the conference in Vancouver? I can't remember if I met you |
| 16:15 |
hbrennan |
You are also a OPAC expert, yes? |
| 16:15 |
Dyrcona |
I was there. I don't remember meeting you, so we must not have rubbed elbows. |
| 16:15 |
roses |
csharp: Yep. and it works okay on other fields. Sara called the cataloger at Georgia and some other super catalogers but they didn't have an answer. Do you have a test server that you could test a 651 having more than one thing in it? |
| 16:15 |
Dyrcona |
Not an expert, but I can break things real good. |
| 16:16 |
hbrennan |
You helped me with some weird parts during our launch |
| 16:16 |
csharp |
roses: heh - the "cataloger at Georgia" is my colleague and I would consider her about as expert as you get |
| 11:39 |
Dyrcona |
All it appears to do is cause the code to skip voided fines when looking for the most recent billing to print information to the logs. |
| 11:54 |
jeff |
eeevil: how's your memory of $overbill in commit 2bf6f120 ? :-) |
| 11:54 |
pinesol_green |
[evergreen|miker] auto-billing fixes and hold processing bug - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2bf6f12> |
| 11:54 |
jeff |
i don't see any signs of it being currently used. i wonder if it was used for test/debug. |
| 11:56 |
eeevil |
jeff: I'll look. it was certainly used in the olden days, from the first over-night fine generator script |
| 11:59 |
eeevil |
jeff: or, rather, was something one could specify |
| 12:00 |
jeff |
yeah, i guess "not specified by default" was what i was seeing in my quick look through history. |
| 15:26 |
|
ktomita_ joined #evergreen |
| 15:26 |
|
sseng joined #evergreen |
| 15:26 |
|
fparks joined #evergreen |
| 15:30 |
kmlussier |
In my previous testing, "contains phrase" means contains exact phrase and "matches exactly" meant an exact match. |
| 15:32 |
|
librarian joined #evergreen |
| 15:33 |
kmlussier |
bshum: Everyone should come to Boston. :) |
| 15:50 |
csharp |
RoganH: thanks for the info re: VMs |
| 15:50 |
csharp |
bshum: I was going to build it on Ubuntu 12.04 |
| 15:51 |
RoganH |
csharp: No problem. |
| 16:22 |
bshum |
Isn't that a 2.3 system? |
| 16:22 |
bshum |
Or you working with their 2.5? |
| 16:22 |
bshum |
(new QP and all that jazz, who knows, am I right?) |
| 16:22 |
kmlussier |
Oh, wait. That's right. You're on a test system. Sorry. |
| 16:23 |
bshum |
I'd be curious to see some of the data that's being stored on the system side for the records in question. Like grabbing all the title values from metabib.title_record_entry for a given set of bibs |
| 16:23 |
bshum |
Just to see what's been indexed and how |
| 16:24 |
kmlussier |
In 2.3, "matches exactly" didn't work at all. It retrieved the same results as a simple contains search. |
| 17:11 |
pinesol_green |
Dyrcona: Zoia knows how to make fusilli. |
| 17:12 |
bshum |
Hmm, csharp, do you remember offhand where https://bugs.launchpad.net/evergreen/+bug/1255561 is doing the barcode lookup? |
| 17:12 |
pinesol_green |
Launchpad bug 1255561 in Evergreen "OPAC: username that starts with a number is treated like a barcode" (affected: 1, heat: 6) [Undecided,New] |
| 17:12 |
Dyrcona |
kmlussier: I should have a fix for my fine generator issues tonight, so you can resume testing tomorrow. |
| 17:12 |
bshum |
I have a library who's actually broken by this. Cause apparently their active directory usernames start with numbers... |
| 17:12 |
kmlussier |
Dyrcona++ |
| 17:13 |
tsbere |
bshum: The barcode regex OU setting, at the top level of the tree, may help? |
| 17:32 |
|
dcook joined #evergreen |
| 18:43 |
|
ktomita joined #evergreen |
| 18:43 |
|
ktomita_ joined #evergreen |
| 18:53 |
jeff |
test |
| 18:53 |
jeff |
hah |
| 18:53 |
jeff |
oops. :-) |
| 19:35 |
|
j_scott joined #evergreen |
| 20:23 |
|
stevenyvr2 left #evergreen |
| 21:54 |
|
dcook joined #evergreen |
| 11:24 |
mrpeters |
and then you can examine the configuration to see what you might have missed (permissions, etc.) |
| 11:25 |
bshum |
saravanakumar: When you said Ubuntu 12.04 LTS earlier, was that desktop or server? Or some other flavoring |
| 11:25 |
mrpeters |
^^ good question bshum |
| 11:25 |
saravanakumar |
its a desktop bshum |
| 11:26 |
saravanakumar |
but we are using it as testing machine |
| 11:26 |
bshum |
Evergreen was only tested and supported with the server editions, so I don't know if there's quirks at play with others (though missing dependencies seems like bad install problems) |
| 11:26 |
saravanakumar |
hmm |
| 11:26 |
bshum |
I know there's been reported troubles by others in the past with desktop edition of ubuntu. |
| 11:26 |
saravanakumar |
but its 64bit machine |
| 11:26 |
bshum |
Since it's not supported for Evergreen, we've skipped most of it. |
| 11:29 |
bshum |
But basically, Evergreen is well tested (and running) with libraries on Ubuntu 12.04 LTS server, the 64-bit edition. |
| 11:29 |
bshum |
I don't think we test at all with 32-bit anymore. And not for desktop edition. |
| 11:30 |
mrpeters |
install ubuntu server 12.04 and add a desktop environment later if you need it |
| 11:35 |
bshum |
The missing deps above make me nervous that something went screwy with the Makefile.install ; which wouldn't surprise me if it blew up over the wrong edition of Ubuntu :( |
| 12:20 |
saravanakumar |
ubuntu has same kernel for server and desktop environment from 12.04. So that should work on desktop env too |
| 12:47 |
bshum |
:) |
| 12:52 |
phasefx_ |
anyone running a wheezy server? |
| 12:53 |
bshum |
Not presently. |
| 12:53 |
phasefx_ |
this is driving me nuts: http://paste.evergreen-ils.org/47 |
| 12:54 |
phasefx_ |
that Cannot determine local time zone is happening with the perl live tests in EG on this one server |
| 12:54 |
phasefx_ |
http://testing.evergreen-ils.org/~live/test.22.html |
| 13:01 |
* phasefx_ |
will try an earlier version of DateTime::Timezone |
| 13:03 |
bshum |
I was about to ask, what's the expected output supposed to be? |
| 13:03 |
bshum |
My Ubuntu test server listed 0.70 and 1.42 for versions, respectively. |
| 13:03 |
bshum |
But the output lines following were just the directory I was in, twice. |
| 13:04 |
phasefx_ |
on my squeeze system: DateTime->VERSION 0.61 / DateTime::TimeZone->VERSION 1.20 / /home/opensrf / /home/opensrf |
| 13:04 |
phasefx_ |
no errors |
| 13:04 |
bshum |
I see, so it's supposed to show nothing. Got it :) |
| 13:10 |
* phasefx_ |
tries updating |
| 13:11 |
bshum |
What's in /etc/timezone on your unhappy server? :) |
| 13:12 |
bshum |
(just curious) |
| 13:12 |
phasefx_ |
SystemV/EST5 |
| 13:12 |
phasefx_ |
alright, after an upgrade, that perl snippet reports the same versions but we get the error. The debian version of datetime::timezone did go up |
| 13:13 |
phasefx_ |
from 1:1.58-1+2013c to 1:1.58-1+2013h |
| 13:14 |
phasefx_ |
debian changelog shows updates to an "Olson database" |
| 13:15 |
phasefx_ |
I don't know if this affects anything other than the local server-side perl tests |
| 13:15 |
phasefx_ |
well, it does affect srfsh |
| 13:15 |
phasefx_ |
if doing a checkout.full through it |
| 13:17 |
phasefx_ |
is simply changing the conents of /etc/timezone a sane thing to try? <tries it anyway> |
| 13:17 |
phasefx_ |
ha, that worked |
| 13:17 |
phasefx_ |
changed it to America/New_York |
| 13:18 |
phasefx_ |
bshum++ |
| 13:18 |
bshum |
Oh cool |
| 13:18 |
bshum |
I was off googling SystemV/ESTS |
| 13:18 |
bshum |
I had no clue what that meant :) |
| 13:18 |
phasefx_ |
EST5 |
| 13:18 |
eeevil |
yeah, EST5 is not an olson format tz |
| 13:20 |
eeevil |
i guess debian got a bit more strict in their tz db update for dt::tz... |
| 13:21 |
phasefx_ |
probably worth adding a variation of that perl snippet to settings-tester |
| 13:21 |
phasefx_ |
or a perl live test |
| 13:27 |
|
mceraso joined #evergreen |
| 13:27 |
|
bshum joined #evergreen |
| 13:30 |
|
kmlussier joined #evergreen |
| 10:11 |
csharp |
Fedora's great if you can just stick to the official repos for everything |
| 10:11 |
dbs |
Bmagic: okay, i'm sure you're following some of the bugs that I've run into because Fedora tends to be ahead of most distros. Encode.pm comes to mind |
| 10:11 |
csharp |
3rd-party repos tend to lag a bit in my experience |
| 10:11 |
Bmagic |
csharp: We are running it on debain now, and would like to test the waters more seriously on Fedora due to the Hyper-V issue I mentioned |
| 10:11 |
dbs |
Bmagic: https://bugs.launchpad.net/evergreen/+bug/1242999 for example |
| 10:12 |
pinesol_green |
Launchpad bug 1242999 in Evergreen "Encode.pm 2.54 breaks database functions (naco_normalize, maintain_control_numbers, others)" (affected: 1, heat: 10) [High,Confirmed] |
| 10:12 |
Dyrcona |
csharp: While official Debian and Ubuntu repos tend to lag a lot, and often have bugs that go unfixed. |
| 10:12 |
Bmagic |
dbs: Thanks for the heads up. I've installed this a few times on Fedora and I seem to remember hitting the Encode issue once before |
| 10:12 |
csharp |
Bmagic: have you benchmarked KVM in your testing? that might be a better supported alternative |
| 10:12 |
dbs |
Bmagic: that also motivates me to update the MARC::Record + friend packages that I maintain to be the most current versions :) |
| 10:12 |
* Dyrcona |
uses Ubuntu for those who don't know. |
| 10:13 |
csharp |
Dyrcona: yeah - I'd rather have lingering bugs than zero-day(-ish) bugs if I'm running something in production |
| 10:18 |
dbs |
The good thing about Fedora in production is that its support cycle almost syncs up with Evergreen's |
| 10:18 |
dbs |
So you could just deploy fresh every 12 months :) |
| 10:19 |
Dyrcona |
Ooh, now you're talking about being a couple of releases behind. :) |
| 10:19 |
csharp |
Bmagic: I got OpenSRF master installed on CentOS 6 recently |
| 10:19 |
csharp |
(in a bare-bones test instance, I should add) |
| 10:19 |
Bmagic |
csharp: OpenSRF and Evergreen? |
| 10:19 |
* Dyrcona |
is seriously considering do Linux from Scratch on a laptop if he can find the time. |
| 10:20 |
Bmagic |
Gentoo? |
| 10:27 |
csharp |
s/Debian/packaging for Debian/ |
| 10:28 |
* csharp |
has hopes of cleaning up our deb-builder utility for more general use |
| 10:28 |
csharp |
but that will be after our MLK weekend upgrade |
| 10:28 |
dbs |
Bmagic: well, there's a fix for that in the bug I posted |
| 10:29 |
dbs |
But because nobody else is hitting it yet, nobody else is motivated to really work on testing the final results (understandably) |
| 10:30 |
csharp |
fedora++ |
| 10:30 |
Bmagic |
We really would like this to work on fedora and it seem so close fedora++ |
| 10:32 |
csharp |
Bmagic++ #trailblazing |
| 14:22 |
gmcharlt |
OK, thanks dbwells! |
| 14:22 |
gmcharlt |
moving on to the next item in the agenda |
| 14:22 |
gmcharlt |
#topic Finding volunteer to update the Evergreen map |
| 14:22 |
elfstrand |
We have a beta version but can't get to test with OCLC untill Late Jan might not make it in tiomne for 2.6 |
| 14:22 |
gmcharlt |
sborger: you have the floor |
| 14:23 |
sborger |
Okay, we had a conference program planning committee meeting which prompted us to discuss the State of Evergreen presentation. |
| 14:24 |
sborger |
The State of Evergreen program is traditionally presented at the beginning of the conference and has been accompanied by the Evergreen International map. |
| 11:21 |
|
paxed joined #evergreen |
| 11:21 |
|
tsbere joined #evergreen |
| 11:23 |
|
akilsdonk joined #evergreen |
| 11:24 |
pinesol_green |
[opensrf|Galen Charlton] LP#1180849: test case - ignoring subrequest responses after respond_complete() - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=59b4dd7> |
| 11:24 |
pinesol_green |
[opensrf|Mike Rylander] Protect subrequests from post-complete messages - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=a0d5b05> |
| 11:26 |
|
jboyer-isl joined #evergreen |
| 11:26 |
|
jeffdavis joined #evergreen |
| 11:30 |
pinesol_green |
[opensrf|Bill Erickson] OpenSRF client disconnect robustification (Perl) - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=b0a41d3> |
| 11:30 |
bshum |
I hate netsplits. |
| 11:30 |
rfrasur |
I hate socks that slide off when you're wearing snow boots. |
| 11:36 |
|
b_bonner_ joined #evergreen |
| 11:52 |
csharp |
dbwells: re: bug 1261355, my next step in troubleshooting was to begin commenting out each numbered script subsection in turn until I find the cause on our DB |
| 11:53 |
pinesol_green |
Launchpad bug 1261355 in Evergreen "2.4.3-2.5.0-upgrade-db.sql causing "could not find trigger" PostgreSQL error" (affected: 2, heat: 10) [Undecided,Confirmed] https://launchpad.net/bugs/1261355 |
| 11:55 |
dbwells |
csharp: sounds like a good approach. I was assuming the 'SET CONSTRAINTS' was part of the issue, but Robert's comment makes it sound like the same error can happen when skipping straight to 'COMMIT' |
| 11:55 |
bshum |
dbwells: fwiw, I also tried using a 2.4.3 DB with concerto yesterday when csharp first mentioned it in IRC and couldn't replicate the problems either. |
| 11:56 |
bshum |
I don't have a younger DB (not master) to test further with. |
| 12:02 |
csharp |
it's possible that it's something about older installs that have been upgraded through each release? |
| 12:02 |
* csharp |
shrugs |
| 12:03 |
bshum |
Or it's just a table that has stuff in it that concerto doesn't normally. |
| 12:20 |
bshum |
Fwiw, it's not unprecedented to split apart pieces of the major version upgrade scripts into separate BEGIN; COMMIT; blocks. It's just not good for safe rollbacks :( |
| 12:20 |
tsbere |
The big monolithic upgrade scripts should probably be rigged in "schema changes first, then data changes" order or something. But I don't use them so I dunno. |
| 12:20 |
bshum |
Yeah, there's alot of hand editing that goes into them. |
| 12:21 |
csharp |
well, there has been less hand editing this go-round for me, but yeah |
| 12:22 |
|
enrichtomsk joined #evergreen |
| 12:23 |
csharp |
for our 2.5.1 test server, running the numbered upgrade scripts to go from 2.4.3 to 2.5.1 was fine, so I may do 'for i in `cat list-of-numbered-scripts`; do PGUSER=evergreen psql -f $i evergreen; done' |
| 12:26 |
csharp |
the only issue with that is the partial reingests that get kicked off sometimes, but Ctrl-C is easy enough |
| 12:27 |
bshum |
See, csharp, you're only inches from just running master :) |
| 12:27 |
csharp |
well, on the DB, maybe ;-) |
| 12:27 |
* csharp |
resists the pull of the dark side |
| 10:05 |
* csharp |
decides to run VACUUM ANALYZE before running the script again |
| 11:07 |
|
RBecker joined #evergreen |
| 11:20 |
csharp |
nope - vacuum didn't help :-/ |
| 13:42 |
bshum |
Hmm, unrelated but the original 0827 doesn't have that in it. It's only in the upgrade script itself. So we probably never stumbled over that particular issue. |
| 13:43 |
bshum |
csharp: My vague googling is coming up with slony threads that include references to that error you mention about "could not find trigger" |
| 13:43 |
bshum |
Since we don't use slony, but you do, maybe that is related. |
| 13:43 |
|
stevenyvr2 joined #evergreen |
| 13:44 |
|
stevenyvr2 left #evergreen |
| 13:45 |
bshum |
Either way, I haven't run a version upgrade script in so long that I probably should stop now and let other folks think through it. |
| 13:45 |
bshum |
Good luck csharp, sorry I can't be more helpful right now. |
| 14:01 |
bshum |
Unrelated, it may be that we need both the --create-database and --create-schema flags for eg_db_config to create a remote database. The README only notes --create-database |
| 14:04 |
bshum |
And fwiw csharp, a clean 2.4.3 database with concerto running the 2.4.3-2.5.0 script went through just fine. Not that it's a good test, cause real production data is always better. But it doesn't seem to be an immediately broken script :( |
| 14:16 |
csharp |
bshum: thanks - I have another test db and I'm going to run the same script on it to see if it's a data corruption issue or something |
| 14:22 |
bshum |
@later tell dbs Curious if you think this article I was just reading about dojo.require and Firefox rendering makes sense. Maybe it could help with our autosuggest brokenness with Firefox lately? http://stackoverflow.com/questions/1943082/dojo-require-prevents-firefox-from-rendering-the-page |
| 14:22 |
pinesol_green |
bshum: The operation succeeded. |
| 14:24 |
bshum |
csharp: Cool deal, curious to see what happens :) |
| 14:27 |
bshum |
Eh, probably not it dbs, maybe nevermind |
| 14:36 |
bshum |
Hmm, so I turned on autosuggest on our test database. And then if I search in Chrome for something, it'll suggest it to me. |
| 14:36 |
bshum |
Interestingly, if I then search for the same term in Firefox, it suggests it to me. |
| 14:37 |
bshum |
It's probably cache or something |
| 14:45 |
bshum |
Oh well, off to shovel some snow and then get ready for the first Christmas party of this week. |
| 16:11 |
ldwhalen |
is anyone around who understands how pgTap tests are supposed to be used? |
| 16:14 |
jeff |
have you looked at the existing docs and the notes that dbs put in the Encode.pm bug? |
| 16:15 |
ldwhalen |
no, I looked at 1194246 |
| 16:17 |
jeff |
bug 1242999 |
| 16:17 |
ldwhalen |
thanks! |
| 16:17 |
jeff |
beyond that i don't have direct experience yet, but ask away! |
| 16:18 |
jeff |
(and soneone else with more direct experience may answer) |
| 16:19 |
ldwhalen |
I am modifying query_parser_fts, and I am not sure what type of tests I might run. I will look into this bug. |
| 16:28 |
ldwhalen |
From what I can see the pgTAP tests are testing the effects of data within the database. This modification is |
| 16:29 |
ldwhalen |
to a function. There are tests that could be run against it. But, I am not sure what the scope should be. |
| 16:29 |
ldwhalen |
It has 12 input parameters, so a complete test would be massive. |
| 16:30 |
ldwhalen |
I am going to add it to a workingg branch and put a pull request on the lp bug because that has been requested |
| 16:30 |
ldwhalen |
and these changes have been running live on Sitka for months. If a test is needed, I will write one. |
| 17:01 |
csharp |
interesting... if I 'grep block_check 2.4.3-2.5.0-upgrade-db.sql | cut -d"'" -f2' and apply those updates one at a time, I get no errors |
| 17:02 |
csharp |
so it must be something about the script + my data |
| 17:02 |
csharp |
or the script itself |
| 12:00 |
pinesol_green |
2.0.x: You are nothing but a gleeking tongueful of tottering urine. |
| 12:00 |
jcamins |
^^ 2.0.x has been deprecated |
| 12:01 |
Dyrcona |
2.0.x needs to be buried, not insulted. ;) |
| 12:02 |
jeff |
@decide real data or made up test cases |
| 12:02 |
pinesol_green |
jeff: Beyond here be dragons. |
| 12:03 |
jeff |
bah. |
| 12:05 |
Dyrcona |
@eightball real data or made up test cases? |
| 12:05 |
pinesol_green |
Dyrcona: _I_ don't know. |
| 12:06 |
berick |
@eightball does @eightball ever give an answer? |
| 12:06 |
pinesol_green |
berick: The outlook is good. |
| 12:51 |
bshum |
jeff: Could always submit a proposal for the next site selection committee :) |
| 13:14 |
bshum |
Dyrcona++ # for Marque.pm |
| 13:14 |
Dyrcona |
Shh! It isn't ready for prime time, yet. |
| 13:14 |
* csharp |
was about to ask |
| 13:15 |
csharp |
Dyrcona: I may have said before, but I'll be happy to test that when you're ready |
| 13:40 |
|
kmlussier joined #evergreen |
| 13:48 |
|
akilsdonk joined #evergreen |
| 13:53 |
kmlussier |
I briefly looked at bug 1234845 on Dyrcona's server a while back, but now I'm giving it closer scrutiny on another server. Could somebody give me some information on where the ranked_volumes function comes into play? Is it related to the way copies are retrieved on the search results page? |
| 14:15 |
pinesol_green |
Launchpad bug 1236979 in Evergreen "Speed up bibs-by-item-age" (affected: 1, heat: 10) [Medium,Confirmed] https://launchpad.net/bugs/1236979 |
| 14:15 |
Dyrcona |
jeff: *Which* pickaxe? |
| 14:16 |
jeff |
Dyrcona: -S |
| 14:16 |
* kmlussier |
assumes so since the difference in performance between the production and test server is very noticeable indeed. |
| 14:16 |
Dyrcona |
The BitCoin miner, the MMORPG.... |
| 14:17 |
eeevil |
kmlussier: yes (that's the item-age freshmeat feed). the ranked_volumes change is only part of the fix, of course, the other is an entirely new stored proc that replaces a big query |
| 14:17 |
jeff |
this pickaxe: git log -SCHECKIN_BYPASS_HOLD_FULFILL --pretty=oneline --abbrev-commit |
| 15:09 |
pinesol_green |
Launchpad bug 1207903 in Evergreen "Lost billing amounts should be more configurable" (affected: 1, heat: 6) [Wishlist,Triaged] https://launchpad.net/bugs/1207903 |
| 15:14 |
mmorgan |
dbwells++ |
| 15:15 |
mmorgan |
Back to the "cost" field for a moment. Is that not visible anywhere in the client? Just for reporting? |
| 15:19 |
jeff |
it is not visible in the client when viewing a copy. it may be visible somewhere in Acq. it can be reported on. |
| 15:19 |
jeff |
at our library, we intend to move item cost from a copy note to asset.copy.cost and use it for reporting collection value / depreciation |
| 15:31 |
jeff |
dbwells++ remingtron++ for bug 1207903. Looks good at a quick glance. Any reason I shouldn't give it a test and commit to master sometime this weekend? |
| 15:31 |
pinesol_green |
Launchpad bug 1207903 in Evergreen "Lost billing amounts should be more configurable" (affected: 2, heat: 10) [Wishlist,Triaged] https://launchpad.net/bugs/1207903 |
| 16:18 |
|
dMiller__ joined #evergreen |
| 16:44 |
smyers_ |
I have a z39.50 problem and was wondering if someone would be willing to help find the issue |
| 17:00 |
smyers_ |
the odd thing is as soon as I point this at the production environment I get results |
| 17:00 |
Dyrcona |
Well, something is different. You also get different results from the two environments in the browser. |
| 17:01 |
smyers_ |
that would be expected to some degree as the databases are different |
| 17:01 |
Dyrcona |
Is the test environment a copy of production? If not, you should go over what makes it different. |
| 17:01 |
smyers_ |
the underlying data is older but that should be it |
| 17:02 |
|
mrpeters left #evergreen |
| 17:02 |
Dyrcona |
I've had lots of fun migrating Vietnamese records this year and pestered gmcharlt with sample files, that every time I see Vietnamese like that, I tend to blame charset issues. |
