| 09:03 |
csharp |
btw, I'm one who would volunteer to help new devs get things up and running, for the record |
| 09:03 |
wsmoak |
I don’t even know how much it would cost (or how it works) but what about some sort of image that runs on Amazon or Google’s things? |
| 09:04 |
wsmoak |
I’d be willing to pay for the server time (vs. running my own server here, which is probably what it would take…) |
| 09:04 |
csharp |
you could definitely run a test server in the cloud, sure |
| 09:04 |
wsmoak |
but I need my very own instance to break and then press a button and re-make |
| 09:05 |
RoganH |
There are a couple of tools floating around for making VMs that you could do development on. |
| 09:05 |
csharp |
you would need maybe 8 - 16 GB of storage, minimum 4 GB RAM, and 2 - 4 processor cords |
| 09:05 |
mrpeters |
VM's and snapshots are the easy reset button :P |
| 09:05 |
RoganH |
csharp: I thought you were going to break out into 80s power cords there for a minute. :) |
| 09:06 |
RoganH |
berick's scripts pop to mind which I've used |
| 09:06 |
RoganH |
tsbere also has a method that I've heard good things about though I haven't tried it myself. I know kmlussier uses it for building VMs for bug testing. |
| 09:06 |
Stompro |
I really liked the Evergreen VM that used to be available.. but I realize that it takes a bit of work to keep it up to date. |
| 09:07 |
wsmoak |
it needs to not be a separate thing that only new devs ever use … or it won’t get maintained |
| 09:07 |
mrpeters |
yeah the vm thing never worked well |
| 09:12 |
|
maryj joined #evergreen |
| 09:12 |
wsmoak |
basically, I do not want to be a sysadmin. I *can* do those things, I have done, but it’s not what I want to spend my time on these days. |
| 09:12 |
RoganH |
Installing Evergreen really isn't that hard, it's just very time consuming and methodical, hence the tools to speed it up. |
| 09:12 |
RoganH |
Note that these are for doing bug testing and development, not building a production environment. |
| 09:12 |
mrpeters |
i'll give you time consuming for sure |
| 09:13 |
mrpeters |
but, to fix bugs, you should be capable of installing OpenSRF/Evergreen |
| 09:13 |
RoganH |
I agree. |
| 05:08 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:36 |
|
wsmoak joined #evergreen |
| 06:37 |
|
eeevil joined #evergreen |
| 06:37 |
|
mtate joined #evergreen |
| 08:28 |
|
mdriscoll1 joined #evergreen |
| 08:30 |
|
graced joined #evergreen |
| 08:35 |
|
Stompro joined #evergreen |
| 08:37 |
bshum |
Stompro: I'm generally +1 to using the PostgreSQL apt repo and suggesting others to use newer PostgreSQL versions as long as the community users have had enough time to check things are working well. |
| 08:37 |
bshum |
The trick is just getting enough testing done for all the combinations. |
| 08:39 |
bshum |
That said, adding an extra repo might be more work than needed for some folks if the main repository for a given distribution already contains a reasonably new enough version of PostgreSQL. |
| 08:39 |
* bshum |
is of many minds on much of this. |
| 08:42 |
bshum |
Might be a good question to ask during the developer meeting this afternoon... |
| 08:44 |
Stompro |
bshum: Thanks, I'll work on something for the upgrade/install docs. |
| 08:44 |
|
artunit joined #evergreen |
| 08:45 |
|
mmorgan1 left #evergreen |
| 11:34 |
bshum |
Aha, okay |
| 11:34 |
bshum |
So that's why we haven't noticed that issue yet. |
| 11:34 |
bshum |
We're still doing it the old way |
| 11:34 |
mrpeters |
yeah, they both work well, im just more comfortable with this method |
| 11:35 |
mrpeters |
you can get some MONSTER xsl sheets when you're doing test's all throughout them |
| 11:35 |
jboyer-isl |
Ah. mrpeters just wrap that circ.target_copy.call_number.label in helpers.escape_xml() and it will be fine. (but the old notices will stay busted.) |
| 11:35 |
jboyer-isl |
In the A/T template, that is. |
| 11:35 |
mrpeters |
jboyer-isl: oh, sweet...i can do that |
| 14:09 |
bshum |
I know I need more time to digest things on that |
| 14:09 |
* dbs |
disappears to do some hardware stuff, grr |
| 14:10 |
bshum |
Let's defer on that subject till we get some more time to read through and respond to the latest? |
| 14:10 |
kmlussier |
I plan to test it soon, but I haven't had a chance look closely enough to come up with any questions yet. |
| 14:10 |
bshum |
Though I think for the action item, it's settled since it looks like dbwells did update the bug with new details. |
| 14:10 |
bshum |
Next past item |
| 14:10 |
bshum |
#info gmcharlt to release OpenSRF 2.4 when ready |
| 14:44 |
Dyrcona |
It points at something of mine that no longer exists. |
| 14:44 |
kmlussier |
The OPW wiki isn't an ideal place to share these scripts. If we think they might be useful to people, then maybe adding them to the install docs or the readme, as dbs previously suggested, is a good idea. |
| 14:45 |
* Dyrcona |
puts curmudgeon hat on. |
| 14:45 |
Dyrcona |
I think the current installation procedure is a good test for potential developers. |
| 14:46 |
Dyrcona |
If you can't follow a README, do a manuals installation, and troubleshoot issues, you're going to have a very hard time later figuring out why your code broke something. |
| 14:46 |
kmlussier |
Dyrcona: The curmudgeon hat suits you. :) |
| 14:47 |
Stompro |
Dyrcona: I understand your view, but if people give up during the install phase, then there is never the possibility of them contributing at all. |
| 15:10 |
|
Christineb left #evergreen |
| 15:15 |
kmlussier |
krvmga: When I look at http://bark.cwmars.org/eg/opac/record/3254422?query=frozen%20-kjklfjdkaljfd;qtype=title;fg%3Aformat_filters=10;locg=1;expand=marchtml#marchtml, I still see a 246 with Disney Frozen |
| 15:16 |
krvmga |
kmlussier: yes, jschrader added other 246 fields without "Disney" in them |
| 15:17 |
kmlussier |
I would leave one 246 there that just says Frozen as a better test. |
| 15:18 |
bshum |
parts++ |
| 15:18 |
kmlussier |
Heh...I was going to wait until you were on the road to do that. |
| 15:18 |
krvmga |
kmlussier: she's not in the office today. when i see her next, we'll try and see. |
| 16:04 |
|
nhilton joined #evergreen |
| 16:34 |
|
nhilton_ joined #evergreen |
| 16:50 |
|
nhilton joined #evergreen |
| 16:51 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:00 |
|
mdriscoll1 left #evergreen |
| 17:02 |
|
mtcarlson joined #evergreen |
| 17:17 |
|
mmorgan left #evergreen |
| 00:39 |
|
artunit_ joined #evergreen |
| 02:15 |
|
eby_ joined #evergreen |
| 02:38 |
|
rangi` joined #evergreen |
| 04:54 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:35 |
|
eeevil joined #evergreen |
| 06:48 |
|
wsmoak joined #evergreen |
| 07:39 |
|
sarabee joined #evergreen |
| 08:55 |
csharp |
yes |
| 08:56 |
csharp |
oops - "yes" was meant for another window ;-) |
| 09:02 |
|
ericar_ joined #evergreen |
| 09:13 |
remingtron |
super old bug 921142 (heat 44!) ready for testing/pushing |
| 09:13 |
pinesol_green |
Launchpad bug 921142 in Evergreen 2.4 "Fixed fields are required to have all positions entered. " (affected: 6, heat: 44) [Medium,Confirmed] https://launchpad.net/bugs/921142 |
| 09:22 |
|
mrpeters joined #evergreen |
| 09:23 |
jeff |
next time, on "this old bug" |
| 11:02 |
|
maryj joined #evergreen |
| 12:41 |
|
nhilton joined #evergreen |
| 12:43 |
|
mrpeters joined #evergreen |
| 13:13 |
csharp |
did anyone ever mirror the old SVN repo site? I'm wondering if some old PINES development is still recoverable |
| 13:15 |
csharp |
specifically, I'm looking for the bad debt interface that was briefly alive on our test server c. 2009 |
| 13:28 |
bshum |
csharp: Yeah I think MVLC has a mirror of the SVN |
| 13:28 |
bshum |
Or a converted git copy anyways |
| 13:28 |
bshum |
But I'm not sure |
| 13:45 |
csharp |
I'm sure I just have a simple config option wrong |
| 13:45 |
csharp |
and I'm doing copy paste coding right now without really knowing the knobs and switches for apache/mod_perl |
| 13:52 |
eeevil |
csharp: that looks fine |
| 13:52 |
csharp |
ok thanks |
| 13:56 |
|
Stompro_home joined #evergreen |
| 14:13 |
csharp |
ah - that's interesting - no interface loads, but if I add anything to the url (e.g. https://test-brick01-head/baddebt/test), I get a downloaded CSV file that says Upload Failure |
| 14:14 |
csharp |
I don't understand enough about perl/CGI to know how to get the show_template subroutine to work |
| 14:21 |
csharp |
okay, so I can see that it at least is running the handler subroutine, but I don't see where show_template is invoked in that |
| 14:23 |
eeevil |
csharp: it seems it's not. http://pastie.org/9712488 should do it. I'll look at the git history right quick |
| 14:25 |
csharp |
eeevil++ # that did it |
| 14:25 |
eeevil |
cool. if you bug it I'll toss up a branch, eh? |
| 14:27 |
csharp |
sure thing |
| 14:28 |
csharp |
well, after I figure out why my test.csv file resulted in "Upload Failure" ;-) |
| 14:28 |
csharp |
ah - yeah, we're suffering bitrot here: Method [open-ils.cstore.direct.money.billable_xact.retrieve] not found for service open-ils.cstore |
| 14:29 |
csharp |
I'll look into it, now that I've got the scent ;-) |
| 14:31 |
jeff |
downtrodden and bitrotten |
| 14:32 |
eeevil |
ah, well, that'd be ungood to continue using in any case. it needs to be moved to pcrud re "no more private services in mod_perl" (but that's a broader project which will likely include IDL changes) |
| 14:32 |
csharp |
oh - ok |
| 15:21 |
hopkinsju |
Pssh. More like Google Earth |
| 15:21 |
bshum |
If my client is any indication |
| 15:21 |
dbs |
csharp: mebbe! |
| 15:22 |
csharp |
I have a crazy ticket in from one of our libraries where the production client is auto-updating itself to the test client version |
| 15:22 |
bshum |
I think there are some fun color/font addons you can use from Firefox to make your staff client more interesting looking :) |
| 15:23 |
csharp |
they swear that they aren't caching anything, but it's happening now when the test server is completely down |
| 15:23 |
dbs |
"evergreen -ProfileManager" to create a new profile maybe |
| 15:23 |
bshum |
It could be a bad upgrade path |
| 15:23 |
bshum |
Or cross-shared hostname/versions between your test and production environments. |
| 15:23 |
csharp |
I've tried to recreate the issue with no success |
| 15:23 |
bshum |
Like go to the test server to get your updates |
| 15:23 |
hopkinsju |
Do you have the test client build on the production server by mistake? |
| 15:23 |
csharp |
autoupdate host on the production clients is next.gapines.org... oh |
| 15:23 |
bshum |
Or like the test server client was installed with the same path as production |
| 15:24 |
csharp |
s/production clients/test clients/g |
| 15:24 |
csharp |
I wonder if they've been using test clients from last year's upgrade with the next.gapines.org path this whole time |
| 15:25 |
bshum |
Could be |
| 15:25 |
csharp |
huh - that's a distinct possibility |
| 15:25 |
csharp |
I only have random screenshots |
| 15:25 |
* bshum |
loves the time that a library was using the test server hostname as production for a few days before we noticed things seemed... wrong. |
| 15:26 |
csharp |
OMG, that's happened to us too |
| 15:26 |
bshum |
That's why I have completely different stamping now for our test group and production groups. |
| 15:26 |
csharp |
I thought about that, but I didn't want to create a stumbling block for testing |
| 15:26 |
* bshum |
wants more Evergreen staff client logo colors. |
| 15:26 |
bshum |
Red and orange/yellow aren't enough! |
| 15:27 |
bshum |
But yeah |
| 15:27 |
bshum |
I use rigbeta for my test server clients |
| 15:27 |
bshum |
And rigrelease for my regular production ones |
| 15:28 |
bshum |
So any red icon'd staff client for us is a test one |
| 15:28 |
bshum |
And orange/yellow = production |
| 15:28 |
bshum |
But as you say, we don't have nearly as much end-user library testing as we'd perhaps wish for. |
| 15:29 |
csharp |
we use the red icon for testing too |
| 15:30 |
jeff |
one of our "test before upgrade" setups had a garish yellow background in many staff (especially circ-related) interfaces to avoid the "oops, did production work in test env" situation. |
| 15:30 |
jeff |
but it would be nice to have support for that baked in, maybe as a new feature in the web client. |
| 15:31 |
jeff |
pre-login/post-login message / banner / popup, banner across the entire top of the page, or some combination of those things. |
| 15:33 |
bshum |
Hmm |
| 15:33 |
bshum |
I don't see why not |
| 15:35 |
csharp |
we used to use the "reddish" opac theme on our test server, but that didn't help from the client |
| 15:35 |
bshum |
Oh that's a throwback to the old days :) |
| 15:35 |
bshum |
I guess those files still exist. We need to finish ripping all that out sometime... |
| 15:36 |
csharp |
so theoretically, if the client has next.gapines.org in its autoupdate.js file, it might grab those update files even if it's logging into gapines.org? |
| 15:37 |
csharp |
well, the next server hasn't been updated since last year |
| 15:37 |
bshum |
Since that's where it'd check towards |
| 15:37 |
bshum |
Not the hostname you enter |
| 15:37 |
csharp |
right |
| 15:37 |
csharp |
okay - this is making more sense now |
| 15:39 |
csharp |
it never occurred to me that staff would be using test clients in production without realizing it |
| 15:39 |
csharp |
but we've never disallowed them in production either (via symlink) |
| 15:40 |
bshum |
Indeed. |
| 16:33 |
* jeff |
laughs at himself |
| 16:37 |
|
kmlussier joined #evergreen |
| 16:38 |
kmlussier |
dbwells++ |
| 16:39 |
kmlussier |
I'll try to fit in testing the new Negative Balance branch as soon as I can. |
| 16:39 |
* kmlussier |
disappears again. |
| 16:43 |
jeff |
mumble mumble billing mumble mumble |
| 16:43 |
jeff |
mous and mus can differ when there are closed xacts with non-zero balance_owed. |
| 16:44 |
jeff |
and the number of users where SUM(mmbxs.balance_owed) <> mous.balance_owed is different from the number of distinct users where mmbxs.xact_finish IS NOT NULL AND mmbxs.balance_owed <> 0 |
| 08:24 |
bshum |
Fair enough, just checking. |
| 08:25 |
* bshum |
is always antsy when it comes to backporting SQL upgrades to older versions. |
| 08:28 |
|
mdriscoll joined #evergreen |
| 08:28 |
csharp |
bshum: fwiw, I tested in master and 2.5.1 when I signed off |
| 08:29 |
|
mrpeters joined #evergreen |
| 08:30 |
bshum |
csharp: For your addition, putting the DROP TRIGGER IF EXISTS in the base schema, do we need that in the base schema? I figure we don't need it when creating fresh DBs |
| 08:30 |
bshum |
Definitely handy for the upgrade script though |
| 10:00 |
kmlussier |
mmorgan++ #Thanks! |
| 10:01 |
kmlussier |
yboston: You're assigned to bug 1287791. Are you still looking at that one? |
| 10:01 |
pinesol_green |
Launchpad bug 1287791 in Evergreen "More right-click authority cleanup" (affected: 1, heat: 8) [Medium,Confirmed] https://launchpad.net/bugs/1287791 - Assigned to Yamil (ysuarez) |
| 10:01 |
* kmlussier |
can load it on a Sandbox if you want to test it. |
| 10:01 |
yboston |
no, I would need the help of one of the catalogers here, but they are not available |
| 10:02 |
kmlussier |
yboston: OK, should I remove you for now in case somebody else wants to test it? |
| 10:02 |
yboston |
yes |
| 10:04 |
kmlussier |
Hmmm...I might be able to test that one if there were more info in the bug report on what I should be looking for. |
| 10:13 |
csharp |
looks like bug 1175308 is relevant |
| 10:13 |
pinesol_green |
Launchpad bug 1175308 in Evergreen "MARC editor right-click authority search is confusing" (affected: 3, heat: 16) [Medium,Fix released] https://launchpad.net/bugs/1175308 |
| 10:18 |
kmlussier |
csharp: Thanks, that helps a little bit, but still doesn't tell me the problem bug 1287791 is trying to solve. I'll post a comment on the bug to see if I can get more details. |
| 10:45 |
* tsbere |
probably doesn't have time to obtain said understanding at the moment either |
| 10:46 |
csharp |
tsbere: understood |
| 10:54 |
eeevil |
kmlussier: the pre-patch bug is that we were searching on all subfields, not just controlled ones, with the right-click. so, extraneous (from the authority POV) breaks the search |
| 10:54 |
kmlussier |
eeevil: OK, thanks. If I have a moment, I'll see if I can replicate it then test the fix. |
| 11:08 |
jeff |
nice thing about trying to use gmail keyboard shortcuts in irc, since most don't involve an Enter, you have a chance to catch your mistake before sharing it with the world. |
| 11:09 |
mrpeters |
lol jeff |
| 11:09 |
mrpeters |
i always liked the gmail labs app to solve a math problem before you send |
| 11:26 |
kmlussier |
eeevil++ #Helping to rescue paxed's patch |
| 11:26 |
* mrpeters |
tries to install Evergreen without OpenSRF -- fail! |
| 11:27 |
mrpeters |
im spoiled not installing by hand anymore heh |
| 11:37 |
eeevil |
kmlussier++ # testing patches! |
| 11:37 |
|
sandbergja joined #evergreen |
| 11:40 |
kmlussier |
eeevil: Heh, I'm actually doing very little testing today, but maybe I can get some done this afternoon. |
| 11:43 |
mrpeters |
hrmmm |
| 11:43 |
mrpeters |
14.04 not liking OpenSRF master |
| 11:43 |
mrpeters |
checking for apache2... no |
| 12:29 |
pinesol_green |
Launchpad bug 1208915 in Evergreen "Apache 2.4.6 warns about eg.conf" (affected: 2, heat: 10) [Undecided,New] |
| 12:29 |
bshum |
Actually yeah nevermind |
| 12:29 |
bshum |
I got it |
| 12:30 |
berick |
i have a jessie vm i can test on if needed |
| 12:30 |
bshum |
We already fixed it in another bug |
| 12:30 |
bshum |
Looks like a dupe remnant |
| 12:31 |
berick |
cool |
| 12:50 |
mrpeters |
anyone else using opensrf/evergreen master (as of today) on 14.04? getting nothing relevant in logs about this 500 error |
| 12:50 |
mrpeters |
apache 2.4.7, fwiw |
| 12:51 |
* csharp |
learns that "propagation" of authority records is limited to linking with bibs |
| 12:51 |
bshum |
mrpeters: My test VM is 14.04 with master as of a few days ago and have no errors. |
| 12:51 |
mrpeters |
opensrf master too? |
| 12:51 |
bshum |
Yes |
| 12:51 |
mrpeters |
damn, i hate wasting half a day i could have been looking at bugs trying to get this running |
| 13:33 |
dbs |
could be that the servers are overloaded because of the Firefox Dev release today :? |
| 13:37 |
Dyrcona |
Could be.... |
| 13:38 |
kmlussier |
jihpringle: Do you use the Load Catalog Record IDS interface in acq at all? |
| 13:38 |
jihpringle |
we've testes it but don't really use it |
| 13:38 |
jihpringle |
testes = tested |
| 13:38 |
csharp |
hmm - that setting is not stopping authority propogation - looks like if the reingest on same marc setting is enabled, it just powers through |
| 13:39 |
* csharp |
consider re-adding the old setting |
| 13:39 |
kmlussier |
Ah, ok. We don't use it much either, but I'm noticing that it has a "Load more terms" button. The label doesn't make sense to me. |
| 14:50 |
eeevil |
the mines, they are ready |
| 14:50 |
csharp |
thanks |
| 14:50 |
csharp |
;-) |
| 14:53 |
* mmorgan |
resurfaces from testing lp 1210541 if anyone wants to have a look. |
| 14:53 |
pinesol_green |
Launchpad bug 1210541 in Evergreen "Copy locations table should have a 'deleted' flag" (affected: 9, heat: 52) [Wishlist,Confirmed] https://launchpad.net/bugs/1210541 |
| 14:53 |
mmorgan |
jboyer-isl++ |
| 14:55 |
jboyer-isl |
Stompro++ for finding the seed data damage I left in there. |
| 16:41 |
bshum |
Looks reasonable to me. |
| 16:42 |
mmorgan |
Invalid it is! |
| 16:42 |
|
kbutler joined #evergreen |
| 17:12 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:13 |
|
mmorgan left #evergreen |
| 17:21 |
|
nhilton_ joined #evergreen |
| 18:09 |
|
artunit joined #evergreen |
| 20:53 |
|
mmorgan1 joined #evergreen |
| 20:58 |
pinesol_green |
[evergreen|Thomas Berezansky] LP#1012308: Teach the staff client to use titlesort - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b343d1c> |
| 20:59 |
bshum |
Calling 0897 |
| 21:06 |
pinesol_green |
[evergreen|Chris Sharp] LP#1391290: Respect setting to disable authority propagation on reingest - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b72d5f6> |
| 21:06 |
pinesol_green |
[evergreen|Ben Shum] LP#1391290: Stamping upgrade script for authority reingest setting - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=afe883f> |
| 21:06 |
|
geoffsams joined #evergreen |
| 21:11 |
|
sarabee joined #evergreen |
| 21:22 |
pinesol_green |
[evergreen|Jason Etheridge] LP#1386260: DST bugs in perl live tests (03-overdue_circ.t) - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=af46860> |
| 21:22 |
pinesol_green |
[evergreen|Jason Etheridge] LP#1386260: DST bugs in perl live tests (04-overdue_with_closed_dates.t) - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=600b508> |
| 21:22 |
bshum |
Maybe now we'll have a happy live test again :) |
| 21:22 |
bshum |
phasefx++ |
| 21:24 |
|
kmlussier joined #evergreen |
| 21:37 |
|
artunit joined #evergreen |
| 21:40 |
pinesol_green |
[evergreen|Josh Stompro] LP#1133158 - Fix typos in action_trigger_runner.pl - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ff79901> |
| 09:32 |
mmorgan |
looks like a lot of those for the same threadtrace. |
| 09:35 |
csharp |
yeah - there's a duration for each individual opensrf message |
| 09:36 |
mmorgan |
ok, so the actual time of the transaction is the difference between the first and last timestamp for the threadtrace? |
| 09:36 |
csharp |
also, it depends on your loglevel (set in opensrf_core.xml) as to whether you get duration for full "transactions" (for lack of a better term to describe something like a checkin) |
| 09:36 |
csharp |
yes |
| 09:37 |
csharp |
if you up one of the loglevel values to debug (4), you get more information |
| 09:37 |
csharp |
but also far larger log files, so it's a tradeoff |
| 09:39 |
csharp |
I think it's the private opensrf loglevel that you'd need to increase - we do that on test servers, but not production |
| 09:40 |
|
yboston joined #evergreen |
| 09:41 |
mmorgan |
ok thanks. This is all really helpful. I spend a fair amount of time poking through logs, nice to understand them a little better. |
| 09:41 |
mmorgan |
csharp++ |
| 10:39 |
jeff |
bshum: nagios checks for ntp are handy there. |
| 10:43 |
bshum |
jeff: I'll add it to my list of things to build into my monitoring server |
| 10:43 |
bshum |
When I build it later :) |
| 10:44 |
csharp |
jeff: great idea |
| 10:45 |
csharp |
Dyrcona: awesome! I'm using yesterday's version on a test server now |
| 10:46 |
|
RoganH joined #evergreen |
| 10:48 |
|
kmlussier joined #evergreen |
| 10:51 |
Dyrcona |
csharp: cool. I'm testing the command line options to skip browse, search and facet reingest and just do the record attributes, now. |
| 10:51 |
* csharp |
signs off on the fix for bug 1390225 |
| 10:51 |
pinesol_green |
Launchpad bug 1390225 in Evergreen 2.7 "auth timeout redirect causes an error" (affected: 1, heat: 8) [Undecided,New] https://launchpad.net/bugs/1390225 |
| 10:51 |
csharp |
Dyrcona: rock on |
| 12:06 |
Dyrcona |
Ah, so looks like it is time to upgrade, then. :) |
| 12:07 |
jeff |
well past. |
| 12:14 |
|
nhilton joined #evergreen |
| 12:20 |
Stompro |
Dyrcona: auto-updates - I think it is more complex than that, at lease for my testing system. Looks like the auto-update requires a valid SSL cert, and some options that are set at configure time. And it doesn't look like the auto-update works if I used the staff client listed on the egdownloads page, you have to have already installed a custom built staff client. |
| 12:21 |
tsbere |
Stompro: Auto-updates don't work with community staff clients, but you don't have to use configure-time options. Staff-client build time options work as well, though the configure time options speed that up. As for the valid SSL cert, if your update host starts with http:// you can bypass that (though I wouldn't do that for production systems) |
| 12:22 |
* tsbere |
will also admit to not having *tested* http:// updates in quite a while, though |
| 12:23 |
Stompro |
tsbere: Thanks for the tips. |
| 12:24 |
tsbere |
Stompro: Oh, and while it is certaintly *easier* when it is, your updates host doesn't have to be the same server as your evergreen install. |
| 12:26 |
Dyrcona |
Heh. You'd think I would have rememberd updates_host. I just did an update with updates-client this morning. :p |
| 12:48 |
Dyrcona |
I'll leave that up to you and dbwells to decide. :) |
| 13:04 |
* phasefx_ |
has a fix for lp1386260 if someone wants to poke at it |
| 13:06 |
bshum |
bug 1386260 |
| 13:06 |
pinesol_green |
Launchpad bug 1386260 in Evergreen "DST bugs in perl live tests" (affected: 1, heat: 6) [Undecided,In progress] https://launchpad.net/bugs/1386260 - Assigned to Jason Etheridge (phasefx) |
| 13:08 |
phasefx_ |
you can do perl live_t/03-overdue_circ.t to test on a stock install with concerto |
| 13:09 |
* phasefx_ |
will add that to the bug |
| 13:10 |
Dyrcona |
csharp: I pushed the changes I mentioned to my evergreen_utilities repo. I also made a change to db_upgrade.pl, but you probably don't use that one. |
| 13:10 |
|
akilsdonk_ joined #evergreen |
| 13:14 |
Dyrcona |
csharp: might want to wait. I just noticed a serious thinko/bug in my pingest changes. It won't work right as is if you try to do attribute and search or facet ingest at the same time. |
| 13:19 |
phasefx |
oy, I just fixed one test.. not all of them, doh |
| 13:39 |
csharp |
Dyrcona: no problem - I haven't pulled in today's changes yet |
| 13:39 |
|
kmlussier joined #evergreen |
| 13:40 |
phasefx |
alright, fix re-pushed for bug 1386260 :-) |
| 13:40 |
pinesol_green |
Launchpad bug 1386260 in Evergreen "DST bugs in perl live tests" (affected: 1, heat: 6) [Undecided,In progress] https://launchpad.net/bugs/1386260 - Assigned to Jason Etheridge (phasefx) |
| 13:41 |
Dyrcona |
csharp: I'm having some "fun" with a little hidden global variable voodo.... I was wondering why it worked at all until I noticed a little $lists++; tucked away in the browse_ingest subroutine. |
| 13:42 |
jeff |
blargh. character encoding issues. |
| 13:44 |
Dyrcona |
Anyway, the bug I noticed is that I had doubled the number of child processes without also adjusting the number of lists, so the program could exit prematurely. |
| 13:49 |
Dyrcona |
Often makes those "vendor records" easier for MARC::Record to digest. Just ignore the comments in the output. :) |
| 13:50 |
jeff |
no, if yaz-marcdump can't parse without errors/warnings, you reject the file ;-) |
| 13:51 |
Dyrcona |
Then, I'd almost never load anything. ;) |
| 13:51 |
jeff |
last if $outcount >= 50; |
| 13:51 |
* jeff |
frowns |
| 13:52 |
jeff |
i need to develop better habits with regard to "# XXX: remove after testing" or somesuch. |
| 13:52 |
jeff |
though part of me wants hard limits (just not that low) in place for some automated things. |
| 13:52 |
Dyrcona |
jeff: command line option to limit, by default set to zero, which means do the whole thing. |
| 13:54 |
Dyrcona |
Well, perl -c says syntax OK. Guess that means I can commit. :) |
| 13:54 |
tsbere |
jeff: I tend to use TODO for things I intend to change/remove before pushing, and XXX for things I see as longer-term warning notes |
| 13:55 |
* jeff |
wonders what the larger convention is |
| 13:55 |
jeff |
i suppose what matters most is the local / codebase convention |
| 13:55 |
tsbere |
jeff: Oh, and "To whomever works on this code next:" for "we should do this later, because I am being lazy and don't feel like doing it now" (but I avoid doing that if I know what should be changed/done anyway) |
| 13:59 |
Dyrcona |
jeff: I've sometimes added --dry-run or similar options to my own stuff for testing purposes. |
| 13:59 |
* jeff |
nods |
| 13:59 |
jeff |
lots of this kind of thing is solved by good habits early: config file, command line arguments, etc. |
| 13:59 |
Dyrcona |
Or in a case where I was deleting files, a --delete option to actually do the delete, otherwise it just printed out what would be deleted without deleting. |
| 14:49 |
yboston |
remingtron: is that what you meant? |
| 14:49 |
yboston |
I was not aware of that |
| 14:50 |
remingtron |
hm, let me check his email... |
| 14:50 |
yboston |
also, we could have the second server be used to test re-organizations |
| 14:50 |
kmlussier |
It's not just the multiple builds. If we want to make changes to the docs site, it's good to have a place to test them out ahead of time before putting them into production. |
| 14:50 |
yboston |
though in theory we can set up Robert's server to do that, though I beleive his servers are pretty taxed already |
| 14:50 |
remingtron |
on 10/3/2014 Robert emailed me and yboston, saying he added a 1pm build time to his docs server |
| 14:50 |
* kmlussier |
is thinking of some of the ideas snigdha26 raised at the last DIG meeting. |
| 14:51 |
yboston |
I need to learn how to read better |
| 14:51 |
remingtron |
yboston: no prob, you're a busy guy |
| 14:52 |
remingtron |
yboston: did we have a potential host for our new test docs VM? |
| 14:52 |
yboston |
PINES provides VMs for the EG community |
| 14:52 |
yboston |
and Galen started the discussion on provisioning a server for us |
| 14:53 |
remingtron |
anything we need to do to keep that moving forward? |
| 14:58 |
yboston |
my apologies that we have hit the hour mark already, I can stay on longer |
| 14:58 |
kmlussier |
But is this a leftover agenda item from last month? |
| 14:59 |
yboston |
I thought ti was leftover, but I could be wrong |
| 14:59 |
remingtron |
I don't recall discussing it much, or at least not deciding to try anything |
| 14:59 |
remingtron |
maybe we got sidetracked with needing a test server |
| 14:59 |
remingtron |
but I think we can decide to try things before the server is ready |
| 15:00 |
kmlussier |
remingtron: I think we're in an awkward period at the moment because snigdha26 has incorporated a lot of these ideas in her proposal, but the application review period isn't over yet. |
| 15:00 |
remingtron |
kmlussier: right, you mean that if accepted, she would do these things herself? |
| 15:00 |
kmlussier |
remingtron: Yes, exactly. |
| 16:09 |
pinesol_green |
Launchpad bug 1390225 in Evergreen 2.7 "auth timeout redirect causes an error" (affected: 1, heat: 6) [Undecided,New] |
| 16:11 |
|
sandbergja joined #evergreen |
| 16:11 |
|
RoganH joined #evergreen |
| 16:11 |
jeff |
commit c2c720d is what i had way-back-when |
| 16:11 |
jeff |
and the bot doesn't do working branches. |
| 16:11 |
jeff |
c2c720d |
| 16:11 |
jeff |
er, http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=c2c720de6fb83aa1acc678de78a1695cf8201eb5 |
| 16:17 |
jeff |
eeevil: heh. specific to the issue in bug 1390225, i remembered that earlier this morning i had minimized a browser window to test that very thing. just un-minimized it, and guess what? error. :-) |
| 16:17 |
pinesol_green |
Launchpad bug 1390225 in Evergreen 2.7 "auth timeout redirect causes an error" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1390225 |
| 16:17 |
jeff |
eeevil: sorry for not thinking of that specific case in our conversation earlier. :-) |
| 16:17 |
* jeff |
returns to looking oddly at this bib that is j in the leader but i in the mra |
| 16:50 |
|
mrpeters joined #evergreen |
| 17:00 |
|
mdriscoll left #evergreen |
| 17:04 |
gsams |
The system should be able to process the transactions pretty quickly, at least I would expect it to. It's a source of confusion for me anyway |
| 17:05 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:10 |
|
mmorgan left #evergreen |
| 17:25 |
|
kmlussier joined #evergreen |
| 17:26 |
gsams |
I'm thinking it might be exageration by circulation employees at the moment |
| 17:26 |
gsams |
ran a test of 50 items in less than 50 seconds |
| 17:27 |
gsams |
I might need to run that during different hours to test peak times |
| 17:28 |
gsams |
of course, this library has some people that circulate 100-200 items at a time |
| 17:46 |
gsams |
well, testing aside, how does this function in other systems? Does anyone handle renewals concurrently? |
| 17:47 |
|
kmlussier joined #evergreen |
| 19:34 |
|
nhilton joined #evergreen |
| 19:55 |
|
remingtron joined #evergreen |
| 02:21 |
|
dbwells joined #evergreen |
| 02:58 |
|
dreuther joined #evergreen |
| 02:58 |
|
chatley joined #evergreen |
| 05:08 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:43 |
|
phasefx joined #evergreen |
| 07:19 |
csharp |
@later tell Bmagic yeah, I've consistently seen that problem with the permissions group UI. The problem with "just use the database" is that it puts a burden on system staff with server-level access to do things that should be available to non-technical users. |
| 07:19 |
pinesol_green |
csharp: The operation succeeded. |
| 09:16 |
bshum |
Before I cut 2.7.1 today, hoping finish looking over https://bugs.launchpad.net/evergreen/+bug/1366964 |
| 09:16 |
pinesol_green |
Launchpad bug 1366964 in Evergreen "Transaction Issues with libdbi 0.9.0" (affected: 1, heat: 6) [Undecided,Confirmed] |
| 09:17 |
bshum |
And also, have to finish setting up my build environment to get the web client stuff properly into the tarball |
| 09:18 |
csharp |
bshum: what would be the most effective way to test the fix to the libdbi bug? |
| 09:19 |
csharp |
Dyrcona: weren't you only experiencing the issue under conditions of higher load? |
| 09:19 |
* csharp |
re-reads |
| 09:19 |
bshum |
csharp: I was going to try following what happened in the bug report as far as copy creation goes. And also figure out the perl test that was included. |
| 09:20 |
csharp |
ah - there's a test |
| 09:20 |
Dyrcona |
csharp: No, it had nothing to do with load. pcrud transactions simply failed. |
| 09:20 |
bshum |
berick++ |
| 09:20 |
csharp |
Dyrcona: okay - my quick read several months ago clearly led to inaccurate impressions of the issue :-) |
| 09:20 |
bshum |
csharp: If you have time to spare a look, extra eyes never hurt. |
| 09:20 |
Dyrcona |
The fix is very simple and seems to work, but a mass delete script I tested on precise after applying the change gave me several "unknown errors." |
| 09:21 |
csharp |
well, since we're an ubuntu shop, and this is a obvious impediment, I only think it fair that we participate ;-) |
| 09:36 |
|
RoganH joined #evergreen |
| 09:41 |
|
kmlussier joined #evergreen |
| 09:54 |
|
sarabee joined #evergreen |
| 09:58 |
* csharp |
tests the fix for bug 1366964 without issues |
| 09:58 |
pinesol_green |
Launchpad bug 1366964 in Evergreen "Transaction Issues with libdbi 0.9.0" (affected: 1, heat: 6) [Undecided,Confirmed] https://launchpad.net/bugs/1366964 |
| 09:58 |
berick |
to be clear, the fix to 1366964 doesn't prevent "unknown errors" (from the DB), it just allows cstore to recognize them as transient instead of "OMG DB IS DOWN" |
| 09:58 |
csharp |
live test works fine |
| 10:01 |
Dyrcona |
berick: I suspected as much. I'll sign off on it. |
| 10:02 |
berick |
Dyrcona++ |
| 10:02 |
berick |
csharp++ # testing |
| 10:02 |
Dyrcona |
If csharp wants to sign off, too, that's cool. I can wait and sign his branch then push that. |
| 10:03 |
Dyrcona |
It's today we want to release the dot releases for 2.5, 2.6, and 2.7, right? |
| 10:05 |
bshum |
Dyrcona: That's certainly my goal for 2.7. |
| 10:06 |
bshum |
Dyrcona: Sounds right to me. |
| 10:07 |
Dyrcona |
Will do. |
| 10:07 |
|
RoganH joined #evergreen |
| 10:11 |
pinesol_green |
[evergreen|Bill Erickson] LP#1366964 Update libdbi connection test error parsing - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ca4e28a> |
| 10:12 |
Dyrcona |
Done and done. |
| 10:12 |
berick |
woot |
| 10:13 |
Bmagic |
csharp: thanks for the feedback. Glad it's not just my system |
| 11:16 |
|
kmlussier joined #evergreen |
| 11:23 |
kmlussier |
jboyer-isl: Is bug 1210541 ready for a pullrequest tag? |
| 11:23 |
pinesol_green |
Launchpad bug 1210541 in Evergreen "Copy locations table should have a 'deleted' flag" (affected: 9, heat: 52) [Wishlist,Confirmed] https://launchpad.net/bugs/1210541 - Assigned to Jason Boyer (jboyer) |
| 11:24 |
jboyer-isl |
I think so. I've tested it a bit but I haven't heard of anyone else trying it out. |
| 11:26 |
jboyer-isl |
kmlussier, It worked well enough for me the day of the hackaway, for what that's worth. |
| 11:26 |
kmlussier |
jboyer-isl: OK, I'll add one then. I think we have somebody here is interested in trying it out. |
| 11:27 |
jboyer-isl |
Good to hear. Hopefully there's nothing to find. :) |
| 11:36 |
|
dreuther joined #evergreen |
| 15:57 |
bshum |
Maybe it'll be helpful in my future |
| 15:58 |
berick |
yeah, the git stuff was necessary on wheezy |
| 15:58 |
bshum |
I'm still deciding if I want to upgrade my laptop to utopic unicorn... |
| 15:59 |
berick |
well, hmm, trusty install 0.10.25. earliest i tested was 0.10.28 -- |
| 16:00 |
berick |
not entirely sure what I just said is true, but likely true |
| 16:00 |
bshum |
Heh |
| 16:00 |
berick |
i'll give it a shot |
| 16:01 |
bshum |
I didn't get to finish up the written instructions for the README in Evergreen for webclient building. |
| 16:34 |
gmcharlt |
eeevil++ |
| 16:38 |
|
nhilton_ joined #evergreen |
| 16:42 |
|
nhilton joined #evergreen |
| 16:51 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 16:51 |
|
mrpeters left #evergreen |
| 16:52 |
|
kmlussier left #evergreen |
| 16:54 |
phasefx |
that last failure includes one not related to DST: open-ils.cstore 2014-11-05 16:27:37 [ERR :21897:oils_sql.c:2483:] open-ils.cstore ERROR inserting config::copy_status object using query [INSERT INTO config.copy_status (holdable,id,name,opac_visible,copy_active,restrict_copy_delete) VALUES (DEFAULT,1,DEFAULT,DEFAULT,DEFAULT,DEFAULT);]: 0 ERROR: null value in column "name" violates not-null constraint |
| 16:55 |
bshum |
Hmm |
| 16:56 |
bshum |
That's the new test |
| 16:56 |
bshum |
For the libdbi thing? |
| 16:56 |
|
dMiller_ joined #evergreen |
| 16:57 |
bshum |
Yep |
| 16:57 |
phasefx |
the test itself didn't throw an error |
| 16:58 |
bshum |
Hmm |
| 16:58 |
phasefx |
live_t/08-lp1366964-libdbi-error.t ..... ok |
| 16:59 |
berick |
that's supposed to happen |
| 16:59 |
berick |
the point of the test is to see how it recovers from a DB error |
| 16:59 |
dbwells |
That's great :) |
| 17:00 |
phasefx |
k, then when we can tell the webifier thing to expect an error |
| 17:00 |
* phasefx |
will poke |
| 17:01 |
berick |
phasefx++ |
| 17:01 |
berick |
didn't realize it would bark at that |
| 17:03 |
berick |
bshum: btw, initial test of nodejs package on trust looks good. will document when i get some time |
| 17:03 |
bshum |
berick++ # cool! |
| 17:08 |
|
mmorgan left #evergreen |
| 17:08 |
phasefx |
for reference, http://git.evergreen-ils.org/?p=working/random.git;a=commitdiff;h=2983559ea27c6506f750a757e64d9bb4d5b43548 Haven't tested it yet |
| 17:09 |
phasefx |
so that makes two exeptions that are DBI related :) |
| 17:09 |
phasefx |
exceptions, even |
| 17:10 |
bshum |
phasefx++ # nifty |
| 17:39 |
|
nhilton joined #evergreen |
| 17:54 |
|
nhilton_ joined #evergreen |
| 08:49 |
|
tsbere joined #evergreen |
| 08:50 |
kmlussier |
mrpeters: DIG will take submissions in any format. We prefer AsciiDoc, but we have people who can convert content into AsciiDoc if it's submitted in another format. |
| 08:52 |
mrpeters |
i can whip something up much quicker today without learning the formatting, though i probably should just do that |
| 09:07 |
bshum |
eeevil: Hmm, should we push these changes to master/rel_2_7 as bug fixes? http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/miker/web-client-sprint1-bug-fixing |
| 09:08 |
bshum |
They're not attached to any particular LP, but I assume they should be tested and included. |
| 09:12 |
|
tspindler joined #evergreen |
| 09:25 |
|
Dyrcona joined #evergreen |
| 09:33 |
|
StomproJ joined #evergreen |
| 11:02 |
kmlussier |
rfrasur++ |
| 11:02 |
rfrasur |
Oy, we'll see. Y'all know my lack of technical know how. But...something is better than nothing, right? |
| 11:04 |
yboston |
dwells: got a second? |
| 11:05 |
kmlussier |
rfrasur: Our new Get Involved page may help - http://evergreen-ils.org/involvement/ |
| 11:06 |
kmlussier |
I'm going to update that page soonish to include testing too. |
| 11:06 |
|
sandbergja joined #evergreen |
| 11:06 |
rfrasur |
Perfect. |
| 11:20 |
|
mrpeters joined #evergreen |
| 13:21 |
berick |
bshum: I'll trade you bug #1366964 for bug #1369169 |
| 13:21 |
pinesol_green |
Launchpad bug 1366964 in Evergreen "Transaction Issues with libdbi 0.9.0" (affected: 1, heat: 6) [Undecided,Confirmed] https://launchpad.net/bugs/1366964 |
| 13:21 |
pinesol_green |
Launchpad bug 1369169 in OpenSRF "Add install instructions for websockets to README (and other cleanup)" (affected: 1, heat: 6) [Medium,Triaged] https://launchpad.net/bugs/1369169 |
| 13:24 |
Dyrcona |
berick: I can test 1366964. I was waiting until some other testing was done on a vm running precise, but the person I was working with is on vacation this week, I think. |
| 13:25 |
berick |
Dyrcona: sweet.. well, except the part where you were trying to do something else and can't ;) |
| 13:25 |
Dyrcona |
:) |
| 13:26 |
|
dkyle joined #evergreen |
| 15:27 |
hbrennan |
csharp: Are those dates pretty well locked in? It's a graduation weekend, so I need all the time I can get to make it work |
| 15:30 |
csharp |
hbrennan: I don't have enough information to answer that, but from Buzzy's report to the EOB, it sounds firm |
| 15:31 |
hbrennan |
csharp: Thanks |
| 16:10 |
jeff |
perl packages that include Simple in the name yet depend on: |
| 16:10 |
jeff |
==> Found dependencies: Capture::Tiny, Sub::Exporter, MooX::Types::MooseLike::Base, Email::Abstract, Email::Simple, List::MoreUtils, Try::Tiny, Test::More, MooX::Types::MooseLike, Moo::Role, Throwable::Error, Module::Runtime, Moo, Sub::Exporter::Util, Email::Address |
| 16:12 |
|
wsmoak joined #evergreen |
| 16:12 |
|
wsmoak joined #evergreen |
| 16:15 |
jeff |
> 34 distributions installed |
| 16:21 |
wsmoak |
well csharp this is no fun at all. I talked to my local librarians and they say that all their issues with PINES are fixed promptly and they don’t really need anything. :) |
| 16:21 |
kmlussier |
:D |
| 16:22 |
kmlussier |
@praise PINES |
| 16:42 |
frank__ |
yes, the problem is that we planned to upgrade to 2.6.3 until december, Is there something I could do to solve this problem without upgrade? |
| 16:43 |
Dyrcona |
frank__: Upgrading is the best bet, but you could apply the code from the above bug. |
| 16:48 |
frank__ |
ok Dyrcona, thanks |
| 17:00 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:11 |
|
mmorgan left #evergreen |
| 18:19 |
|
kmlussier joined #evergreen |
| 18:25 |
|
nhilton joined #evergreen |
| 09:10 |
* pinesol_green |
grabs some Apple Crisp for csharp |
| 09:12 |
wsmoak |
good morning |
| 09:12 |
wsmoak |
remind me… what version is Pines on? (Is there a way I can tell?) https://gapines.org/eg/opac/home |
| 09:12 |
csharp |
wsmoak: we're on 2.5.1 |
| 09:12 |
csharp |
well, with backports, so 2.5.1+ |
| 09:13 |
csharp |
wsmoak: we have a test server running 2.7.0 at http://next.gapines.org if you're interested in that too |
| 09:13 |
wsmoak |
well, I guess that will shortcut me going to talk to the librarian to figure out where the IT folks are :) |
| 09:14 |
bshum |
csharp++ |
| 09:14 |
csharp |
wsmoak: are you at a PINES library? |
| 10:49 |
jboyer-isl |
jeff, Thanks, I must not have been searching for the right thing because I didn't find either of those. |
| 10:54 |
|
kmlussier joined #evergreen |
| 11:12 |
|
dcook__ joined #evergreen |
| 11:15 |
yboston |
Hello everyone, I could use some advice about upgrading Postgres 9.1 to 9.2 on a test server. |
| 11:15 |
yboston |
I want to set up this test server with production data, but my hosted productions server is running PG 9.2 |
| 11:15 |
yboston |
I have used apt-get to install postgres-9.2 on a EG 2.6.2 server, and I just ran pg_upgradecluster and got the following errors that makes me think I might have missed some steps |
| 11:15 |
pastebot |
"yboston" at 64.57.241.14 pasted "errors running pg_upgrade_cluster" (465 lines) at http://paste.evergreen-ils.org/10 |
| 11:16 |
yboston |
I ran: pg_dropcluster --stop 9.2 main then pg_upgradecluster 9.1 main |
| 11:16 |
yboston |
^^ here are the errors |
| 11:21 |
yboston |
Dyrcona: thanks again |
| 11:24 |
yboston |
I wonder if it would be easier in the future to tweak the EG intall makefiles so that when I install EG I end up with PG 9.2 instead of 9.1? |
| 11:25 |
|
sandbergja joined #evergreen |
| 11:25 |
bshum |
yboston: I've done that before for some of my test servers where the default was 9.1 but I wanted 9.3. |
| 11:25 |
bshum |
Lots of paths to completion :) |
| 11:26 |
dbwells |
jboyer-isl: We had a computer science project team work on building a mapping system prototype for us last Dec. It never made it to production in any form. Still, I think I am going to try to find that code, and will post it if it is available somewhere. |
| 11:26 |
Dyrcona |
yboston: If I've wanted something other than the default Pg version for my distro, I've usually installed the appropriate PG packages first, and then I install Evergreen. |
| 11:27 |
jboyer-isl |
dbwells: thanks, that would be cool. |
| 12:33 |
* phasefx |
deletes his unfillable hold now |
| 12:33 |
bshum |
kmlussier: I wonder if that's a matter of adding ffilter="true" to the parts field in hold_pull_list.tt2 |
| 12:34 |
bshum |
If so, then fwiw, Copy Status is also not a field you can filter on? |
| 12:34 |
kmlussier |
Really? I didn't notice that one. |
| 12:34 |
kmlussier |
I was thinking it was probably a simple thing to fix, but I hadn't gotten around to looking at it. |
| 12:36 |
kmlussier |
bshum: copy status gives the appearance of being sortable. But the system I'm on shows all available items, so I can't test it out to make sure it works. |
| 12:36 |
bshum |
kmlussier: Hmm, fsort=false |
| 12:36 |
bshum |
Is next to the parts one |
| 12:37 |
* bshum |
sighs |
| 12:49 |
bshum |
Yep, changing that to fsort="true" adds a selector for parts sorting |
| 12:49 |
bshum |
Since that's always been false, since the initial add of the simplified pull list, I'd be curious if there was a design reason for that, but I doubt it. |
| 12:50 |
bshum |
Open-ILS/src/templates/circ/hold_pull_list.tt2 |
| 12:51 |
kmlussier |
IIRC, parts weren't displaying at all during my early tests of the simplified pull lists. I'm guessing it the sorting was overlooked when it was added to the display. |
| 12:52 |
kmlussier |
And then it was overlooked when I tested it. :( |
| 13:44 |
|
_bott_ joined #evergreen |
| 13:57 |
csharp |
@karma vandelay |
| 13:57 |
pinesol_green |
csharp: Karma for "vandelay" has been increased 1 time and decreased 0 times for a total karma of 1. |
| 14:31 |
|
vlewis_ joined #evergreen |
| 14:32 |
|
chatley joined #evergreen |
| 14:32 |
mmorgan |
hbrennan: As long as no one runs the "Clear holdshelf" process, the item will stay on the holdshelf. |
| 14:33 |
hbrennan |
mmorgan: That process isn't just pulling up the list from Circ> Clear Hold Shelf, right? It's the actual check in of the item to either clear it back to Available or jump to the next person in line? |
| 14:34 |
hbrennan |
It's times like this that I really need a time machine so I can fast forward and test things like this |
| 14:34 |
|
buzzy joined #evergreen |
| 14:35 |
csharp |
hbrennan: correct, as far as I remember |
| 14:36 |
berick |
hbrennan: just to clarify, clear shelf cancels the hold then generates a report of likely next actions for the item (hold, transit, back to shelf). it doesn't actualy perform the checkin. |
| 14:36 |
hbrennan |
csharp: I'm glad I'm not the only one with a fuzzy recollection on how this works |
| 14:36 |
csharp |
check in of the item will change its status |
| 14:37 |
csharp |
hbrennan: oh, and we don't have a time machine, but our test server is the best we can get: http://next.gapines.org |
| 14:37 |
csharp |
;-) |
| 14:37 |
hbrennan |
Excellent. The reason I ask is that our hold notices for email and text clogged up, and haven't gone out since Monday. Everyone received their notice this morning, but the time has been ticking since Monday. |
| 14:38 |
hbrennan |
I'm glad we have a little control over the process. :) |
| 14:39 |
hbrennan |
berick: So if we don't pull items from the clear list, those items are essentially in limbo... neither still officially on hold for the original person, but not starting the clock for the next in line either? |
| 16:31 |
mmorgan |
berick: hbrennan: not to labor the point about clearing the holdshelf (ok, I will :)) after the hold is cancelled, the item does indeed show in browse holds shelf, but you can't tell where it is just by looking at the *item* |
| 16:37 |
berick |
mmorgan: well, dang. i guess you can't |
| 16:42 |
mmorgan |
Yeah :-(, lp 1271182 |
| 16:42 |
pinesol_green |
Launchpad bug 1271182 in Evergreen "Item status set as "incorrectly set to on holds shelf"" (affected: 2, heat: 10) [Undecided,Confirmed] https://launchpad.net/bugs/1271182 |
| 16:58 |
|
mdriscoll left #evergreen |
| 17:03 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:10 |
|
mmorgan left #evergreen |
| 17:12 |
|
buzzy joined #evergreen |
| 18:06 |
|
buzzy joined #evergreen |
