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. |
07:39 |
|
rjackson-isl joined #evergreen |
08:07 |
|
Dyrcona joined #evergreen |
08:10 |
|
jboyer-isl joined #evergreen |
08:24 |
csharp |
dbwells: I'm interested in 2.5.1... are you awaiting testing feedback that it works? I'm willing to do a test install if that helps |
08:25 |
csharp |
specifically, I'd like to branch off of rel_2_5_1 via git when that gets created |
08:26 |
|
akilsdonk joined #evergreen |
08:27 |
Dyrcona |
csharp: You could just branch off of rel_2_5 now and then change the upstream when 2_5_1 is created. Anything destined for 2_5_1 should go into 2_5. |
08:28 |
Dyrcona |
Which reminds me that we're doing a test upgrade on my development server today before this weekend's update. |
08:29 |
Dyrcona |
As a general recommendation, if you have local changes and you want to track the release branches, I'd suggest basing your local branch off of rel_X_Y and not rel_X_Y_Z anyway. |
08:30 |
csharp |
actually, that's a great idea |
08:30 |
csharp |
it won't matter as much once we lock in on our go-live version, but during this test phase that's better |
08:31 |
Dyrcona |
If you follow rel_X_Y you should pickup anything destined for rel_X_Y_Z, and you'll always be up to date as of your build. |
08:33 |
Dyrcona |
git++ |
08:34 |
* Dyrcona |
checks if yesterday's database reload was successful. |
14:05 |
rsoulliere |
I can go first. |
14:05 |
rsoulliere |
#topic Conversion Coordinator Report |
14:05 |
yboston |
go ahead rsoulliere |
14:06 |
rsoulliere |
#info EG 2.5 documentation is now being processed on the documentation web server. |
14:06 |
rsoulliere |
#info I shared some information and tools with yboston regarding processing documentation from the repositories. Here are some of the tools in a repository I set up a long time ago: |
14:06 |
rsoulliere |
#link https://github.com/rsoulliere/Evergreen_Documentation_Tools |
14:06 |
rsoulliere |
#info If anyone else is interested in setting up their own documentation site for testing or experimenting and needs some technical assistance to get started, let me know. |
14:06 |
rsoulliere |
That is all. |
14:07 |
yboston |
rsoulliere++ |
14:07 |
kmlussier |
I can go next. |
14:07 |
yboston |
rsoulliere: I have a comment for you |
14:09 |
yboston |
I don't want to cause the nightly builds to be broken for several days |
14:10 |
rsoulliere |
Typos etc... shouldn't bring the whole documentation site to a crash. |
14:10 |
yboston |
rsoulliere: I guess we can start with a few as see how it goes. So far I just waited until the next day to see if the one page was built successfully. |
14:11 |
rsoulliere |
I would test locally using the basic ascidoc command and upload if it passes the test. |
14:11 |
rsoulliere |
I probably would load a bit at a time as you suggest. |
14:11 |
yboston |
any particular combination of parameters? |
14:11 |
rsoulliere |
If you notice anything not appearing, let me know via email and I can troubleshoot on the server. |
14:12 |
yboston |
also, I had issues with the bash source highlighting on OS X, was not sure how to fix |
14:13 |
|
dMiller___ joined #evergreen |
14:13 |
rsoulliere |
yboston re: parameters: I think the basic html conversion should be a good test. That should catch most syntax issues. |
14:13 |
yboston |
rsoulliere: OK |
14:13 |
|
jboyer_isl joined #evergreen |
14:13 |
rsoulliere |
re OSX highlighting: do you mean display issues in safari? |
14:26 |
yboston |
Any comments or questions? |
14:27 |
yboston |
My elevator speech about the hack-a-way, it was great for getting new folks trained on DIG workflows and asciidoc. It was hard to find small taks for volunteers to work on |
14:28 |
kbutler |
yboston: Thank you for hosting. I thought it was productive. |
14:28 |
yboston |
we still have files that were worked on that need to be pushed to the repository |
14:28 |
yboston |
kbutler: thanks |
14:29 |
yboston |
I hope by January all of the work that was started (and finished) at the hack-a-way has been integrated to the docs. |
14:30 |
yboston |
I also hope that it iwllbe easier to find tasks to give to newcomers not that we have a video tutorial to get more people u to speed |
14:30 |
yboston |
(now that we have) |
14:32 |
yboston |
Also, at the next conference, we should have a whole day to work on docs. Hope that we can apply other lesson of this hack-a-way to that hackfest |
14:32 |
yboston |
BTW< thanks to ESI, that was the test server we ended up using the most |
14:33 |
yboston |
Any comments or questions? |
14:35 |
kmlussier |
Sounds like you all got a lot accomplished. Nice work! |
14:35 |
kmlussier |
yboston++ for pulling it together. |
14:36 |
yboston |
Next year I plan to again offer to host, but perhaps we can all decide meet somewhere else in Massachusetts |
15:44 |
|
dMiller___ joined #evergreen |
15:53 |
|
stevenyvr2 joined #evergreen |
16:07 |
Dyrcona |
At some point, you just have to stop typing/editing and hit the "Publish" button. :) |
16:13 |
remingtron |
yboston: when publishing docs, we could use the master branch as our test version. If it breaks, it's okay because it's only the dev version! Once it's fixed, pull it into 2.5 and 2.4. |
16:13 |
|
timlaptop joined #evergreen |
16:14 |
remingtron |
yboston: I'll send this idea to the DIG list for discussion |
16:14 |
Dyrcona |
If anyone is interested in what I was doing to use the asciidoc blogpost program to post to blogger: http://blog.sigio.com/2012/05/look-ma-no-hands_15.html |
16:14 |
yboston |
remingtron: that is a great idea |
16:14 |
Dyrcona |
If anyone cares about my other, more personal, blog: http://kissmysock.wordpress.com/ |
17:24 |
Dyrcona |
more like the first one, yes. |
17:25 |
ElliotFriend |
with all that said, what would be the best way to move towards a workflow like that, as opposed to the way I'm doing it? |
17:26 |
ElliotFriend |
Set it up like that on a new set of servers? |
17:26 |
Dyrcona |
Do you have a server that you use for testing or development? |
17:27 |
Dyrcona |
I'd try it out on a test server to start with. |
17:27 |
ElliotFriend |
Both are VMs. I have a test server that is a clone of the production one |
17:27 |
Dyrcona |
I'd set it up on the test vm first. |
17:27 |
ElliotFriend |
I only ever spin up the test one to run through an upgrade, before applying it to production |
17:27 |
ElliotFriend |
sounds good |
17:28 |
Dyrcona |
It is about time for me to head home. I can sign back in when I get there if you want to discuss the work flow some more. |
17:29 |
ElliotFriend |
I think I'm alright. Thanks again! I repeat, Evergreen people sure are swell! |