| 11:22 |
|
sandbergja joined #evergreen |
| 11:31 |
|
buzzy joined #evergreen |
| 11:52 |
|
kitteh_ joined #evergreen |
| 11:54 |
yboston |
Hello everyone, DIG will need access to a test server running 2.8.x, I suspect we may be able to use webby? Any other recommendations? |
| 11:55 |
tsbere |
yboston: kmlussier may be willing to spin up one of the masslnc test boxes for ya, though those don't get the web client going currently. |
| 11:55 |
yboston |
tsbere: thanks |
| 11:56 |
kmlussier |
yboston: The server on the community servers page already has 2.8. But, as tsbere said, it doesn't have webby. |
| 11:56 |
kmlussier |
I usually use webby for web client docs. |
| 14:30 |
dbs |
https://bugs.launchpad.net/evergreen/+bug/1031335 I think? |
| 14:30 |
pinesol_green |
Launchpad bug 1031335 in Evergreen 2.7 "Email templates should always escape headers" (affected: 2, heat: 10) [Undecided,Confirmed] |
| 14:32 |
dbs |
tsbere: around, but not in a headspace to recall or revisit library/copy ranking design decisions very effectively |
| 14:47 |
mmorgan |
Anyone around to poke webby? I was hoping to test a few things, but can't login :-( |
| 14:58 |
mmorgan |
Hey, webby's back! Thanks to whoever poked! |
| 14:58 |
eeevil |
mmorgan: the drive's filled up, I'm looking for places to free space now |
| 14:58 |
eeevil |
it'll die before too long ;) |
| 14:59 |
mmorgan |
Aww. That's sad :-( |
| 14:59 |
bshum |
Like a balloon inflating till it explodes. |
| 14:59 |
bshum |
*pop* |
| 15:01 |
mmorgan |
When dev servers get endearing names like 'webby', it's sad when they go away. |
| 15:03 |
berick |
mmorgan: wait til you're testing on "widdlepuppy" |
| 15:05 |
mmorgan |
widdlepuppy? I can't stand it! ;-) |
| 15:14 |
eeevil |
mmorgan: ok, it should stay up for a while, cleared about 500MB. we'll look at increasing space generally soon |
| 15:15 |
mmorgan |
eeevil++ |
| 16:36 |
|
mrpeters left #evergreen |
| 16:45 |
|
vlewis joined #evergreen |
| 17:00 |
|
mmorgan left #evergreen |
| 17:07 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:23 |
|
Newziky left #evergreen |
| 17:43 |
|
bmills1 joined #evergreen |
| 20:08 |
|
nuentoter joined #evergreen |
| 00:08 |
|
sarabee joined #evergreen |
| 05:09 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:42 |
|
ericar joined #evergreen |
| 07:51 |
|
graced joined #evergreen |
| 07:55 |
|
jboyer-isl joined #evergreen |
| 09:30 |
bshum |
Though I'm unsure if maybe there were weird permission issue or something. |
| 09:31 |
Dyrcona |
Well, I got several errors about stuff not being installed/not able to be opened without the sudo. |
| 09:31 |
Dyrcona |
With sudo, it just worked. |
| 09:31 |
bshum |
You testing with Ubuntu 12.04 or 14.04? |
| 09:37 |
bshum |
Alright, so I can't find the branch anywhere, so I must have just been modifying a local copy Evergreen-README on lupin directly. We can diff those changes against master and get a branch started though. |
| 09:42 |
|
RoganH joined #evergreen |
| 09:54 |
Dyrcona |
14.04 |
| 09:55 |
bshum |
Dyrcona: I pushed a collab branch with the changes I started to http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/bshum/README-webclient |
| 11:32 |
|
Shirleyh joined #evergreen |
| 11:42 |
jjk |
Good morning |
| 11:42 |
jeff |
jjk: good morning! |
| 11:43 |
jjk |
I'm attempting to upgrade an older 2.3 install to the current version but have run into issues with the database schema updates. I'm hoping some folks here can point me in the right direction. |
| 11:45 |
jjk |
I have a test database that started at 2.3.5 and I've successfully run the schema updates all the way up to 2.3.12. |
| 11:47 |
jjk |
When trying to upgrade the schema using 2.3-2.4.0-upgrade-db.sql I quickly receive the following errors: |
| 11:47 |
jjk |
psql:version-upgrade/2.3-2.4.0-upgrade-db.sql:96: NOTICE: extension "tsearch2" already exists, skipping |
| 11:47 |
jjk |
psql:version-upgrade/2.3-2.4.0-upgrade-db.sql:98: ERROR: cannot drop extension tsearch2 because other objects depend on it |
| 11:48 |
jjk |
I've not found much in the way of similar issues. |
| 11:53 |
bshum |
jjk: So that sounds like you have something custom in your database that relies on tsearch2 extension |
| 11:54 |
bshum |
I found something like that when we upgraded as well, some locally created views for reporting had used that extension and needed to be rewritten |
| 11:55 |
* bshum |
upgraded forever ago and doesn't remember how he ultimately identified all the things that used that extension. |
| 11:57 |
jjk |
bshum: Thanks. I'll look at the reports. |
| 11:58 |
|
TaraC joined #evergreen |
| 12:01 |
bshum |
jjk: Out of curiosity, what version of PostgreSQL are you using for your tests? |
| 12:01 |
bshum |
(i.e. did you also test upgrading your postgresql installation to newer versions 9.1+) |
| 12:02 |
bshum |
And you might find it interesting |
| 12:02 |
bshum |
To try the drop extension directly |
| 12:02 |
bshum |
And see if it spits back what is still depending on it |
| 12:03 |
bshum |
Hmm |
| 12:03 |
bshum |
csharp: Did we archive the old evergreen-admin mailing list? |
| 12:04 |
bshum |
csharp: Nevermind, found what I was looking for |
| 12:04 |
bshum |
jjk: You might see some value in discussion from this mailing list entry: http://list.evergreen-ils.org/pipermail/evergreen-admin/2014-May/000086.html |
| 12:05 |
jjk |
bshum: I'm running 9.1 on Debian, specifically 9.1.14-0+deb7u1 |
| 12:05 |
bshum |
jjk: Based on what they say there, I would check to make sure the search_path is set right, and then see if there's any "DETAIL" that comes up after the "ERROR" part when you try to drop the extension. |
| 12:05 |
bshum |
~search_path |
| 14:08 |
kmlussier |
Wow! That was fast. Thanks gmcharlt! |
| 14:08 |
kmlussier |
gmcharlt++ |
| 14:19 |
jeffdavis |
What's the status of NCIPServer? |
| 14:22 |
kmlussier |
jeffdavis: We have it in testing now to use with AutoGraphics. |
| 14:22 |
jeffdavis |
kmlussier: that's excellent, thank you |
| 14:24 |
Dyrcona |
jeffdavis: You can't use the master branch with Evergreen at the moment. |
| 14:24 |
Dyrcona |
rangi or someone (me?) has to do some integration. I changed the interfaces a good bit. |
| 14:29 |
Dyrcona |
And sometimes different products from the same vendor. |
| 14:31 |
|
kitteh_ joined #evergreen |
| 14:31 |
jeffdavis |
Dyrcona: ah yes, "standards" that are actually their own special case of https://xkcd.com/927/ -- good times! |
| 14:31 |
bshum |
Haha, the hover is funny |
| 14:32 |
bshum |
Stompro++ # tested the change for OpenSRF instructions for Ejabberd for Debian Jessie and they look good. I'll sign and push that on for a future OpenSRF 2.4.1 release. |
| 14:33 |
Dyrcona |
Well, I don't even really consider NCIP to be a standard myself. It's list of features that you can implement. |
| 14:34 |
Dyrcona |
And every vendor seems to pick their own way to do things, and too many messages are similar, but different. |
| 14:34 |
Dyrcona |
So, yeah, we need an actual standard. |
| 15:24 |
tsbere |
Bmagic: set passwd = 'new password' ;) |
| 15:24 |
Bmagic |
oh, lol |
| 15:24 |
bshum |
Bmagic: You can just do UPDATE actor.usr SET passwd = 'something' WHERE id = sillyuser; |
| 15:24 |
Stompro |
bshum, it took me a while to add the second example to the docs also... I thought I compiled it and tested how it looked, did you not like how it looked or did it break when you tried it. |
| 15:24 |
bshum |
and the function will hash it out for you |
| 15:25 |
Bmagic |
great! that worked |
| 15:25 |
bshum |
Stompro: I was just trying to see if I could make it more consistent looking with the rest of the styling. |
| 16:44 |
mmorgan |
mrpeters: Not an expert, but I don't know of any other way to do that. |
| 16:44 |
Dyrcona |
I was going to say that I think it is the only way to do it, but got sidetracked. |
| 16:45 |
mrpeters |
mmorgan: i didnt think so either, but so much awesome stuff has been done with the in-staff client configuration menus that i wasnt sure |
| 16:52 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:16 |
pinesol_green |
[opensrf|Ben Shum] Docs: Keep all source syntax consistent in README - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=ef80e4c> |
| 17:16 |
pinesol_green |
[opensrf|Ben Shum] Docs: Add [source, bash] to code blocks that were not defined in README - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=52b6eca> |
| 17:16 |
pinesol_green |
[opensrf|Ben Shum] Docs: Emphasize variables and paths consistently in README - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=86e6d84> |
| 17:16 |
pinesol_green |
[opensrf|Josh Stompro] LP#1445503 - Updated Ejabberd setup steps for Ejabberd 14.x for Debian Jessie - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=e421bb3> |
| 17:18 |
pinesol_green |
[opensrf|Ben Shum] Docs: Fix mailing list link for help in README - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=966fb05> |
| 17:18 |
bshum |
I give up on the asciidoc syntax for now. I will slay that eventually though. |
| 17:18 |
|
mmorgan left #evergreen |
| 17:21 |
bshum |
So, for the Evergreen bugs targeting issues with Debian Jessie |
| 17:44 |
pinesol_green |
[evergreen|Josh Stompro] LP#1445187 - Force disable of deflate - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b949202> |
| 17:44 |
pinesol_green |
[evergreen|Josh Stompro] LP#1362260 - Email::Sender/libemail-send-perl change in Jessie - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ad879d4> |
| 17:50 |
pinesol_green |
[evergreen|Josh Stompro] LP#1445182 Changed Debian Jessie dependency install to use packages for dbi dbd-pgsql. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d5089b7> |
| 17:54 |
bshum |
Stompro++ # I pushed ahead everything and I seem to be well on my way towards a happy Jessie test server. |
| 18:08 |
bshum |
Hmm |
| 18:10 |
bshum |
Looks like we'll need to create a file for 000.english.pg94.fts-config.sql |
| 18:10 |
bshum |
In order for PG 9.4 to be used when creating the database |
| 18:11 |
bshum |
To test, I've just copied the 93 one to be named 94 and seeing how that goes. |
| 18:25 |
bshum |
I appended my findings to the bug |
| 18:30 |
bshum |
Stompro: I set https://bugs.launchpad.net/evergreen/+bug/1445150 back to Triaged while we test the last little bit I think we need to create a working database on PG 9.4 using the scripts. |
| 18:30 |
pinesol_green |
Launchpad bug 1445150 in Evergreen 2.7 "Debian Jessie includes Postgresql 9.4 - update software dependency makefile" (affected: 1, heat: 6) [Medium,Triaged] |
| 18:31 |
bshum |
When we get time, someone else should check that initial working branch, and then make any special adjustments. |
| 18:31 |
bshum |
Otherwise, as far as I can see, I have a functional Evergreen install on Debian 8.0 Jessie |
| 05:00 |
|
collum joined #evergreen |
| 05:14 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:48 |
kmlussier |
Good morning #evergreen |
| 07:49 |
kmlussier |
@coffee y'all |
| 07:49 |
* pinesol_green |
brews and pours a cup of Kenya Ndaroini Microlot, and sends it sliding down the bar to y'all |
| 12:18 |
* tsbere |
hasn't had much reason to use that part of PHP lately so isn't all that familiar with it personally |
| 12:19 |
jeff |
you're the only reason I ran into it just now. ;-) |
| 12:19 |
jeff |
PHPSIP2 won't connect to localhost because of it -- simple fix. |
| 12:22 |
tsbere |
as I said, lately. I haven't done much with phpsip2 for a while. |
| 12:23 |
* tsbere |
also rarely has phpsip2 talk to localhost, for that matter, even when testing things >_> |
| 12:23 |
berick |
because i'm not a huge fan of php, i started on this a while back: https://github.com/berick/pysip2 |
| 12:23 |
berick |
in case anyone prefers python |
| 12:23 |
berick |
for sip tseting |
| 16:55 |
* pinesol_green |
grabs some Pumpkin Pie for kmlussier |
| 16:55 |
mmorgan |
Good idea! |
| 16:55 |
mmorgan |
@dessert |
| 16:55 |
* pinesol_green |
grabs some wild Alaskan rhubarb pie for mmorgan |
| 16:56 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:10 |
|
mmorgan left #evergreen |
| 17:20 |
|
buzzy joined #evergreen |
| 18:02 |
kmlussier |
evergreen-ils.org is quite sluggish at the moment |
| 20:33 |
jonadab |
(It updates CPAN and a bunch of related modules.) |
| 20:34 |
jonadab |
Oh, I should probably clarify: since you were using make, I've been assuming that you already installed build-essential or the equivalent system package. |
| 20:34 |
jonadab |
So you have gcc and make and all that stuff. |
| 20:35 |
nuentoter |
our library is looking to switch very soon to evergreen and i'm setting up a left over computer as a test server to check it out and see what will work for us |
| 20:35 |
nuentoter |
pretty sure most of that can preinstalled on this distro |
| 20:35 |
jonadab |
Yeah, I'm doing a similar thing to work on migrating our data. |
| 20:36 |
jonadab |
nuentoter: Oh, could be. I use Debian, which doesn't install that stuff by default, but the build-essential metapackage depends on all of it. |
| 20:36 |
nuentoter |
im on debian jessie for first time |
| 03:11 |
|
tsbere joined #evergreen |
| 03:52 |
* bshum |
generally agrees with dbs and tries to remind people about said older bugs. |
| 04:47 |
|
book` joined #evergreen |
| 04:59 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:06 |
csharp |
bshum: argh - I hate launchpad |
| 07:06 |
* csharp |
remembered that the issue had been discussed before, but didn't remember the bug and it didn't appear in search results |
| 07:07 |
csharp |
so in the old bug I suggested the alternative of commenting out the lines in fm_IDL.xml, but I've changed my mind on that, obviously ;-) |
| 10:12 |
jeff |
but have not checked lately. |
| 10:12 |
jeff |
what version are you seeing that behavior on? |
| 10:12 |
krvmga |
jeff: 2.7.4 |
| 10:13 |
jeff |
convenient for me to test! |
| 10:13 |
Dyrcona |
Hmm. I could check right quick. |
| 10:13 |
jeff |
krvmga: i suspect something other than the copy status is to blame, unless you've heavily tweaked your templates. |
| 10:13 |
bshum |
I'm pretty sure I remember it displaying when we tested it. Or rather, it displayed as a bill or something elsewhere. |
| 10:13 |
bshum |
And basically that still showed in the same place as items out |
| 10:13 |
krvmga |
jeff: our myopac templates are pretty vanilla. |
| 10:16 |
Dyrcona |
Well, I just set one of my items to lost on my dev system and it doesn't show up in my list of items out in the OPAC. |
| 10:16 |
jeff |
krvmga: tested by checking an item out to a patron and then marking it lost by patron. it is no longer visible under Items Checked Out, but is visible as a bill in the main myopac page at /eg/opac/myopac/main -- under Fines |
| 10:17 |
* Dyrcona |
confirms it shows up under fines. |
| 10:17 |
jeff |
I get a Title, Author, Checkout Date, Due Date, Date Returned shows (fines accruing) [er, they aren't actually] and there's a balance owed. |
| 10:17 |
jeff |
(under Fines) |
| 10:18 |
Dyrcona |
Well, the question is should lost items show in items out, or just under fines. |
| 10:19 |
Dyrcona |
I'd be more likely to say Long Overdue should show up under items out. |
| 10:19 |
Dyrcona |
Or more correctly, "Checked Out." |
| 10:21 |
krvmga |
i think the issue has been reported to me incorrectly. i just looked at a test account and the Lost items show up but under Returned/Renewed it says (fines accruing) but under Balance Owed it's showing a replacement cost |
| 10:21 |
krvmga |
i think the person who reported it might have gotten confused by "(fines accruing)" |
| 10:22 |
Dyrcona |
Well it shouldn't say that. It is an error. |
| 10:22 |
Dyrcona |
Maybe it should say "Lost" instead? |
| 10:22 |
krvmga |
Dyrcona: is it a bug error or a configuration error on our part, do you think? |
| 10:23 |
krvmga |
if it's a bug, i'll report it. i just want to make sure it's not anything we're doing wrong. |
| 10:24 |
Dyrcona |
I'd say find out from your staff what the real problem is, and then open a bug. |
| 10:24 |
Dyrcona |
We can always set it to invalid if it turns out to be configuration. :) |
| 10:28 |
krvmga |
staff are saying that the patron's Lost items show up under Fines (as previously mentioned) but, if a patron looks at Items Checked Out, the screen shows "You have no items checked out." |
| 10:29 |
krvmga |
a patron's Lost item is still checked out to the patron, no? |
| 10:30 |
krvmga |
maybe this is where not showing Lost in the OPAC is having the impact. |
| 10:31 |
krvmga |
i'm testing by turning OPAC visibility back on for Lost for a little while |
| 10:35 |
jeff |
i think that "(fines accruing)" is based simply on the lack of a checkin time. |
| 10:35 |
jeff |
should be a somewhat easy fix to correct/clarify that. |
| 10:49 |
jeff |
hah! there's actually a TODO in the template |
| 10:50 |
krvmga |
jeff: lol |
| 10:51 |
Dyrcona |
Not surprising. :) |
| 11:00 |
krvmga |
ok, i have tested with showing Lost in the OPAC. Lost items are now OPAC visible in our catalog. logging out and logging in again as the test patron. Current Items Checked Out still shows "You have no items checked out". I'm guessing this means OPAC visibility of Lost status has no impact here. |
| 11:00 |
Dyrcona |
Sounds like something else is going on. |
| 11:10 |
kmlussier |
Although Evergreen considers lost items to still be checked out to the patron, as a patron I don't think I would expect it to show in Items Out. If it is truly lost, it's lost. |
| 11:10 |
kmlussier |
I agree with Dyrcona that I would expect long overdue to still display there. |
| 15:16 |
pinesol_green |
Launchpad bug 1125270 in Evergreen "Error updating function in 2.0-2.1-upgrade-db.sql for 2.3" (affected: 1, heat: 6) [Low,Triaged] |
| 15:16 |
bshum |
I wrote some minor patches to fix those two and even though I sure hope nobody is still on 2.0 or 2.3, it'd be nice to close out those bugs. |
| 15:17 |
* bshum |
would have probably just pushed those already, but just checking real quick one last time. |
| 15:30 |
csharp |
bshum: so to test bug 1125270, one would need to install 2.0 and run the 2.0 to 2.1 upgrade script? |
| 15:30 |
pinesol_green |
Launchpad bug 1125270 in Evergreen "Error updating function in 2.0-2.1-upgrade-db.sql for 2.3" (affected: 1, heat: 6) [Low,Triaged] https://launchpad.net/bugs/1125270 |
| 15:30 |
bshum |
csharp: If you were being thorough, I suppose yes. |
| 15:30 |
csharp |
I mean, it's probably fine to push as-is |
| 10:10 |
Dyrcona |
Well, more sites are using acq these days, so that experience is changing. |
| 10:15 |
csharp |
Dyrcona: have you done any more experimentation with EG on 14.04? looks to me like most of the bigger issues are fixed... |
| 10:16 |
csharp |
I'm working on building our debs on 14.04 and jessie right now, but I'm deep in the weeds of packaging best practices right now |
| 10:16 |
Dyrcona |
You mean for acq? If so, no. I don't really have much of a way to test, since I don't actually have any vendor accounts. |
| 10:16 |
csharp |
nah, just in general |
| 10:16 |
Dyrcona |
In general, I have been running Evergreen on 14.04 with success for about a year. |
| 10:16 |
csharp |
I think I have the ruby problem solved for now |
| 10:16 |
csharp |
oh good to know |
| 10:16 |
Dyrcona |
yep. I saw that. |
| 10:17 |
Dyrcona |
I thought about faking an EDI transaction for testing. |
| 10:17 |
Dyrcona |
That is, setting up a bogus vendor with a canned order and response to send. |
| 10:17 |
berick |
we've deployed 2 ubuntu 14.04 servers to productoin. |
| 10:17 |
berick |
soon, soon we'll be free of centos |
| 10:19 |
csharp |
I have an aging OpenSRF branch that installed dependencies from EPEL and got it up and running on CentOS |
| 10:19 |
csharp |
6, I think |
| 10:19 |
csharp |
but I didn't get as far as Evergreen |
| 10:22 |
bshum |
I think for front-end app servers, I'm not too nervous about Ubuntu 14.04. But for backend utilities, I get a little anxious to test further. |
| 10:22 |
bshum |
Acq EDI stuff, sure, but also have to test things like print notice generation, other scripts. |
| 10:22 |
bshum |
z39.50, who knows? :) |
| 10:23 |
berick |
bshum: we should be fully migrated by the end of May. i'll let you know how it goes |
| 10:23 |
bshum |
berick++ |
| 10:24 |
csharp |
oh yeah - z39.50 is broken in 12.04 too, right? |
| 17:15 |
bshum |
Hmm |
| 17:16 |
bshum |
We can't seem to add any bibs with URIs to lists. |
| 17:16 |
bshum |
That's special. |
| 17:16 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:18 |
mmorgan |
bshum: lp 1246385 ? |
| 17:18 |
pinesol_green |
Launchpad bug 1246385 in Evergreen "internal server error when adding an item to a list from within staff client" (affected: 1, heat: 6) [Undecided,Confirmed] https://launchpad.net/bugs/1246385 |
| 17:18 |
bshum |
No, this is in public side |
| 17:19 |
bshum |
If I go to try adding a bib that's a URI (aka, $9 trick), it just stays off the list and I get a refreshed page that still says "add to list" |
| 17:19 |
mmorgan |
Oh, ok. sounded familiar. But it's too late in the day... |
| 17:19 |
bshum |
I'm going to have to get a test system going with 2.8 stock to see if it's a template issue in our systems, or if it's a 2.8 regression. |
| 17:20 |
bshum |
It's not broken on MVLC's or PINES systems, but they're on 2.7ish |
| 17:20 |
bshum |
mmorgan: We should probably close that bug. Since no one's confirmed anything since it was reported "fixed" or at least "not broken" for 2.5. |
| 17:22 |
mmorgan |
Oh, probably so. |
| 17:24 |
|
mmorgan left #evergreen |
| 17:37 |
kmlussier |
bshum: There's a bug for that. And old one |
| 17:38 |
kmlussier |
bug 979038 |
| 17:38 |
pinesol_green |
Launchpad bug 979038 in Evergreen "tpac: Records with a located URI cannot be added to a list" (affected: 3, heat: 18) [Low,Confirmed] https://launchpad.net/bugs/979038 - Assigned to Jeff Godin (jgodin) |
| 17:40 |
kmlussier |
Filed that one while C/W MARS and NOBLE were getting ready to go live on Evergreen. |
| 17:40 |
bshum |
kmlussier: That sounds more like my problem. |
| 17:40 |
bshum |
I didn't notice it on MVLC/PINES cause I was only testing temp lists on there (no account to test real with) |
| 17:40 |
bshum |
But temp lists don't even take ours on our systems. |
| 17:40 |
bshum |
But maybe that's cause we don't use the temp list warning or whatnots. Who knows. |
| 17:41 |
bshum |
Sigh, oh well. |
| 17:41 |
* bshum |
clicks "affects me too" and contemplates dinner. |
| 17:43 |
kmlussier |
jeff: Do you still want to be the assignee on that bug? |
| 18:16 |
bshum |
csharp: Should we be deprecating https://bugs.launchpad.net/evergreen/+bug/1050384 in favor of your newly filed https://bugs.launchpad.net/evergreen/+bug/1450218 |
| 18:16 |
pinesol_green |
Launchpad bug 1050384 in Evergreen "Views referenced in reporter UI are not created by default" (affected: 1, heat: 6) [Low,Confirmed] |
| 04:21 |
|
StomproJosh joined #evergreen |
| 04:23 |
|
jeff_ joined #evergreen |
| 04:26 |
|
eady joined #evergreen |
| 05:19 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:20 |
|
TaraC_ joined #evergreen |
| 07:51 |
|
jboyer-isl joined #evergreen |
| 08:20 |
|
Newziky joined #evergreen |
| 14:20 |
* csharp |
dives in and hopes for the best |
| 14:20 |
jboyer-isl |
csharp: If that will work, you'll likely have to use \$ because it looks like it's expecting regex syntax, where $ is special. |
| 14:22 |
berick |
csharp: record display attributes only affect display :( |
| 14:22 |
csharp |
it makes sense to me that it would be regexp syntax, and I'm told that was tried and didn't work, but I'll test it myself |
| 14:22 |
csharp |
berick: ah |
| 14:23 |
csharp |
hmm - so the acq code expects *no* dollar sign, but the file has them - is there a way to remove them within EG? or would that have to be done externally? |
| 14:23 |
csharp |
well, specifically, the DB rejects the '$' character as non-numeric |
| 14:23 |
csharp |
so I guess the acq code doesn't know or care |
| 14:24 |
berick |
code would have to be added to make that happen within ACQ |
| 14:27 |
* tsbere |
loves the vendor "But other <ils> customers have no issues" response - Half the time I get a list of those "other customers" I find they aren't using Evergreen. |
| 14:27 |
berick |
acq being what it is, there are a number of vendor-specific hacks in the acq code. adding one to strip '$' from the price field does not seem crazy. |
| 14:28 |
tsbere |
Of course, then there are the vendors that say "But other <ils> customers have no issues" with <ils> *not* being Evergreen. At which point I get to say "That is all well and good. We are using Evergreen, not <other ils>" >_> |
| 14:28 |
berick |
or strip all non-numbers |
| 15:26 |
* csharp |
creates bug 1449724 |
| 15:26 |
pinesol_green |
Launchpad bug 1449724 in Evergreen "Acq Record Import Fails because of dollar sign in price field" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1449724 |
| 15:45 |
|
maryj joined #evergreen |
| 16:12 |
|
Newziky1 joined #evergreen |
| 16:22 |
|
ericar joined #evergreen |
| 16:34 |
|
Newziky1 joined #evergreen |
| 16:47 |
|
mrpeters joined #evergreen |
| 16:56 |
|
Newziky1 joined #evergreen |
| 17:01 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:06 |
|
mmorgan left #evergreen |
| 17:36 |
|
bbqben joined #evergreen |
| 17:44 |
|
Newziky left #evergreen |
| 01:52 |
|
jeffdavis joined #evergreen |
| 03:09 |
|
gsams joined #evergreen |
| 05:03 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:34 |
|
rjackson_isl joined #evergreen |
| 07:39 |
|
graced joined #evergreen |
| 07:39 |
|
sarabee joined #evergreen |
| 11:34 |
csharp |
berick: I could see that you made a lot of progress on it ;-) |
| 11:34 |
berick |
maybe we can get some progress on that at egcon |
| 11:34 |
csharp |
I'll totally help with that if I can |
| 11:34 |
berick |
yes, you can help test |
| 11:34 |
csharp |
perfect |
| 11:34 |
berick |
IIRC, there's just a few fields remaining that have to be mapped. |
| 11:34 |
berick |
then it's testing time |
| 11:35 |
csharp |
awesome |
| 11:37 |
csharp |
so once the A/T thing is in place, it might be worth incorporating edi /openils stuff into the standard installation process |
| 11:38 |
csharp |
"thing"... "stuff" - technical jargon be damned! |
| 13:37 |
eeevil |
has anyone other than gmcharlt looked at LP 1438136? |
| 13:37 |
pinesol_green |
Launchpad bug 1438136 in Evergreen "OPAC searching significantly slowed by adding format filters" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1438136 |
| 13:37 |
eeevil |
or, the linked branch, more correctly |
| 13:40 |
csharp |
eeevil: I applied it to a test server and see far faster search times - I don't have an opinion about the implementation beyond that though |
| 13:40 |
Dyrcona |
eeevil: I loaded it on my dev system, which is 9.1 and apparently didn't need it, but I can say it caused no problems there. |
| 13:40 |
eeevil |
just hoping for a merge before the next point release, is all |
| 13:41 |
RoganH |
I can add it to our test and measure results tonight. |
| 13:48 |
|
dac joined #evergreen |
| 13:52 |
kmlussier |
eeevil: Is C/W MARS in production? If so, would it help if they added a comment to the LP bug reporting that it's working well for them? |
| 13:53 |
eeevil |
kmlussier: they're using it, and I think it would. I'm trying to avoid self-merging, but if that's what is needed to get it in, I will |
| 14:05 |
|
jonadab_znc joined #evergreen |
| 14:05 |
jboyer-isl |
(Also, time works ever against me. :( ) |
| 14:05 |
Dyrcona |
Well, I have no business signing off, since I obviously didn't look hard enough. :) |
| 14:22 |
RoganH |
I was just looking at our current search return numbers but they're even on our low powered test system orders of magnitude faster than csharp's. I don't know if I'd find anything worth signing off on other than "this didn't screw up an existing system" |
| 14:28 |
kmlussier |
After talking to C/W MARS, I'm not comfortable signing off either. They aren't seeing the huge difference between limited searches and non-limited searches anymore. However, they are seeing slower overall search performance since their upgrade. |
| 14:28 |
kmlussier |
Since the patch was applied as part of their upgrade, it's difficult for me to know if that change was partially caused by the patch or whether it was due to something else. |
| 14:39 |
csharp |
kmlussier: Terran was just testing here, and the challenge was trying to find search terms that weren't already cached by the live server - dunno if that's a factor there, but after a number of tries, Terran definitely sees the difference between pre- and post-fix |
| 14:42 |
kmlussier |
csharp: Yeah. I can definitely say that the format limiting problem was resolved. Their format-limited searches were timing out on their test system before their upgrade. |
| 14:43 |
kmlussier |
I just don't know if the other reported search slowness was a result of the patch, a result of the upgrade, or the result of something else. Too many moving parts. |
| 14:44 |
csharp |
kmlussier: well, the sure fire way to know is with an actual query from the postgres logs |
| 14:44 |
csharp |
that can be EXPLAIN ANALYZEd |
| 14:49 |
kmlussier |
I'll forward that along to them |
| 01:04 |
|
DPearl joined #evergreen |
| 04:14 |
kmlussier |
jonadab: Well, there is the Douglas county model for purchasing ebooks - http://douglascountylibraries.org/content/ebooks-and-DCL |
| 04:53 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:35 |
|
rjackson_isl joined #evergreen |
| 07:45 |
|
graced joined #evergreen |
| 07:50 |
|
mrpeters joined #evergreen |
| 12:32 |
csharp |
tsbere: that's nice to know |
| 12:33 |
csharp |
well, one of the selling points on our end for RT is that it's in use by other EG sites, which might lead to some EG/RT integration ideas in the future? |
| 12:34 |
csharp |
one of the originally envisioned features of Evergreen was helpdesk integration, but it didn't get very far |
| 12:38 |
bshum |
You know, speaking of bib sources... |
| 12:38 |
bshum |
Anyone got a test server with 2.8/master around and can test something for me |
| 12:38 |
bshum |
So I got a report from our staff that loading bibs is causing the bib source to change to the latest source on merges. |
| 12:38 |
bshum |
Instead of staying at the original source. |
| 12:39 |
bshum |
During match-only merge. |
| 12:39 |
bshum |
I'm getting into it shortly, but curious to see if I can verify that it's not just our systems. |
| 12:39 |
Dyrcona |
I could test it, but I'm too busy to do that today. |
| 12:47 |
|
bmills1 joined #evergreen |
| 12:54 |
|
sandbergja joined #evergreen |
| 13:13 |
bshum |
Aha |
| 13:20 |
bshum |
But long-term, it sounds like we should file a bug to make this some sort of setting controlled option. |
| 13:21 |
mllewellyn |
like a bib source hierarchy |
| 13:24 |
Dyrcona |
The bib source change was intended to make records get the bib source selected in the vandelay import because we had fresh records loading (not overlay records) and getting a null bib source. |
| 13:24 |
Dyrcona |
The branch was evaluated on that basis, and overlay was not on my radar in the testing that I did. |
| 13:26 |
bshum |
I could see avoiding that being helpful. |
| 13:27 |
* bshum |
rips it out for now so that mllewellyn's work isn't disrupted. |
| 13:27 |
bshum |
I'll file a new bug on the subject in a bit. |
| 14:09 |
bshum |
mllewellyn: I filed https://bugs.launchpad.net/evergreen/+bug/1447746 to make sure I didn't forget it. |
| 14:09 |
pinesol_green |
Launchpad bug 1447746 in Evergreen "Do not update bib source on match-only merge" (affected: 1, heat: 6) [Undecided,New] |
| 14:10 |
kmlussier |
berick (or anyone else who knows the answer): I've seen instructions to install hatch on linux and on windows. Will it also work on macs? |
| 14:11 |
jeff |
it is intended to, but I've not been able to test that becase of my ancient version of OS X. |
| 14:12 |
kmlussier |
jeff: OK, thank you! |
| 14:15 |
mllewellyn |
bshum: thank you |
| 14:15 |
bshum |
mllewellyn++ # getting the word out |
| 15:36 |
berick |
so, it didin't really take hold for 2.8 for various reasons. |
| 15:36 |
berick |
i'd really like some input on the wiki doc before we start forcing anything |
| 15:37 |
berick |
and if we're goign to start requiring QA contributions for 2.9, we need to solidify the plan now-ish |
| 15:37 |
jeff |
short of boiling the ocean, what do you think our approach should be for "this changes the behavior of something large and complex which has no existing tests"? |
| 15:37 |
jeff |
(not that this particular ocean doesn't deserve boiling...) |
| 15:38 |
berick |
jeff: do you mean areas of the code where there is no test structure? |
| 15:38 |
jeff |
case-by-case exception with a high bar, but discretion to the RM? |
| 15:38 |
jeff |
berick: yes, exactly. |
| 15:38 |
berick |
honestly, if we could people started on using the test structure we have, that would be a big win |
| 15:38 |
bshum |
Speaking of RM, who'll that be for 2.9 :) |
| 15:39 |
berick |
bshum: yeah, this conversation makes me think again about nominating RM's earlier in the process |
| 15:40 |
bshum |
Yeah, I think we should start thinking like that. |
| 15:40 |
dbwells |
If we want the RM to make calls on "tested enough"-ness, we'll more or less need the RM to approve everything. That's pretty far from what we've done before, but certainly exists in other projects, from what I'm told. |
| 15:40 |
kmlussier |
I don't feel qualified to comment on the wiki page, but if there is anything somebody like me can do to help with this, let me know. |
| 15:41 |
jeff |
dbwells: I was thinking more along the lines of "has tests == good, anyone can merge", vs "no tests because REASONS, merge is at RM discretion" |
| 15:41 |
dbwells |
jeff: makes sense, thanks for clarifying |
| 15:41 |
gmcharlt |
dbwells: from somebody who has been RM in such a kind of project... that is a big burden to put on the RM |
| 15:42 |
dbs |
Are tests in place for the web staff client, along the lines of https://docs.angularjs.org/guide/unit-testing ? |
| 15:42 |
dbwells |
gmcharlt: I can imagine. |
| 15:43 |
berick |
expanding on jeff's last comment.. "no tests because no framework exists to test this" would cover a lot things |
| 15:43 |
berick |
that would leave a fairly limited number of cases where the RM would have to decide |
| 15:43 |
gmcharlt |
now giving the RM more mental space to throw things back if not done enough -- and have those decisions not be nibbled to death by the Ducks of Merge It Now -- is something that would be a step forward |
| 15:44 |
dbwells |
the endless nibbling! |
| 15:44 |
csharp |
probably an obvious point, but it also raises the bar for a qualified RM |
| 15:44 |
jeffdavis |
Is there a tag in LP meaning "has code, needs tests"? |
| 15:44 |
bshum |
jeffdavis: needsignoff ? |
| 15:45 |
jeffdavis |
Do we want something more specific? |
| 15:46 |
* gmcharlt |
is inclined to think so - at least to try it out |
| 15:46 |
jeffdavis |
Signoff to me implies "I've tried this, it works on my system." |
| 15:46 |
gmcharlt |
"needstest"? |
| 15:46 |
jeff |
needstests? needsqa? |
| 15:46 |
gmcharlt |
er, needstests |
| 15:46 |
gmcharlt |
(not One Test To Rule Them All) |
| 15:46 |
* csharp |
is having deja vu |
| 15:46 |
jeff |
csharp: that might be bad. is it bad? |
| 15:47 |
dbs |
#qualityisjob1 |
| 15:49 |
* gmcharlt |
tosses out a wild idea |
| 15:49 |
gmcharlt |
do we want to make QA the Official Theme (TM) of the dev portion of hackfest/ |
| 15:49 |
gmcharlt |
? |
| 15:49 |
jeff |
dbs: there are some tests for the angular bits, using karma. commit 75e466e contains one example. i can't say what coverage is like. |
| 15:49 |
pinesol_green |
[evergreen|Bill Erickson] LP#1402797 browser client interval parser - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=75e466e> |
| 15:50 |
|
bmills1 joined #evergreen |
| 15:50 |
jeff |
gmcharlt: if nothing came out of the hackfest but every interested contributor was better equipped to write tests... i'm not sure i'd be disappointed. |
| 15:51 |
* gmcharlt |
sources a troop of cats to give out at the conferences |
| 15:51 |
gmcharlt |
very special cats |
| 15:51 |
gmcharlt |
cats who hiss ... if one does a git push with adding something to t/ |
| 15:52 |
dbwells |
gmcharlt: I'd be up for QA time during the hackfest. |
| 15:52 |
csharp |
#info gmcharlt's Cats of Doom: http://cat.evergreen-ils.org.meowbify.com/ |
| 15:52 |
jeff |
"QA time" might be easier to pull off. :-) |
| 15:53 |
jboyer-isl |
I could certainly use an intro. I felt a little bad about how much went into the "delete acpl" commits without any tests but human ones. |
| 15:53 |
* gmcharlt |
is more than happy to put together some starting material for a QA time |
| 15:53 |
dbwells |
#action AllTheDevs will read and think about berick's QA page, and come to the conference ready to discuss and take action |
| 15:53 |
berick |
you_all++ |
| 16:26 |
jeffdavis |
I can think of two pieces that might help to get more folks trying it out. |
| 16:26 |
jeffdavis |
1. Documentation. This has been on my todo list for a while. |
| 16:26 |
jeff |
jeffdavis: can you summarize your environment with regard to auth methods, what patron identifier is used, and if you have just a single overdrive account for the entire consortium or if you have per-system, and if there's any use of "overdrive advantage" (where systems participate in a large collection but can then ALSO add items that only their patrons get)? |
| 16:26 |
jeffdavis |
2. Testing credentials that can be shared among EG developers. |
| 16:26 |
dbwells |
#link https://launchpad.net/overdrive-eg-opac |
| 16:28 |
dbwells |
jeffdavis: I think testing credentials would be great. I'm not sure how many of us have access otherwise to OverDrive. |
| 16:28 |
* csharp |
might be able to get credentials, but not sure if he could share them :-/ |
| 16:28 |
jeffdavis |
I can commit to contacting Overdrive about that. |
| 16:29 |
jeff |
My experience with getting API access from them (prod and/or testing) has been... yeah. |
| 16:29 |
dbwells |
#info jeffdavis suggests that any potential testers file bugs at the link given above |
| 16:30 |
jeffdavis |
They do have a testing environment which in theory shold not be tied to anyone's "real" OverDrive accounts, so it's at least a theoretical possibility, IIUC. |
| 16:30 |
kmlussier |
Thanks all! |
| 16:30 |
* kmlussier |
needs to disappear |
| 16:30 |
dbwells |
#action jeffdavis will pursue contacting OverDrive to ask about test credentials / a test environment |
| 16:30 |
* csharp |
too |
| 16:31 |
dbwells |
Ok, wrapping things up unless someone speaks up... |
| 16:31 |
jeffdavis |
jeff: we have two OverDrive accounts, each used by a different chunk of our libraries |
| 01:52 |
|
geoffsams joined #evergreen |
| 05:04 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:39 |
|
graced joined #evergreen |
| 07:46 |
|
krvmga joined #evergreen |
| 07:50 |
|
mrpeters joined #evergreen |
| 09:46 |
csharp |
gmcharlt: also, if you want the files from the GPLS server, I'm sure I can get those to you - just need to check with a couple of folks on this end that all is ok |
| 09:46 |
gmcharlt |
csharp: thanks! |
| 10:40 |
|
collum joined #evergreen |
| 10:47 |
jboyer-isl |
eeevil: I thought I'd try to test the inverse of your fix for bug 1438136 (common searches, uncommon attributes, I think), but I can't use the queries in that ticket to find common or uncommon values in pg 9.1. Do you know off hand of a good way to get those on more uh, mature, versions of pg? |
| 10:47 |
pinesol_green |
Launchpad bug 1438136 in Evergreen "OPAC searching significantly slowed by adding format filters" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1438136 |
| 10:51 |
|
mllewellyn joined #evergreen |
| 10:54 |
eeevil |
jboyer-isl: let me look. in the mean time, were you able to test the branch, or does it not work for you on 9.1? |
| 10:55 |
rjackson_isl |
eeevil: jboyer-isl is afk currently - just thought I would let you know as he isn't ignoring you! |
| 10:55 |
eeevil |
jboyer-isl: ah ... well, I can tell it wont work. the array stats arrive in 9.2 |
| 10:55 |
eeevil |
rjackson_isl: thanks! :) |
| 10:57 |
|
ningalls joined #evergreen |
| 11:06 |
jboyer-isl |
I haven't tested the branch itself (only the core query test in the ticket) because the only non-production database machines I have available are miserably slow regardless of what's searched how. :( |
| 11:09 |
eeevil |
jboyer-isl: ha! understood |
| 11:21 |
jeff |
something i haven't spent much time thinking about yet, but thought I'd throw out for feedback: we have the materialized view asset.opac_visible_copies, which aiui is mostly (exclusively?) for performance reasons -- it saves us from having to join a lot of things and examine a lot of columns at search time. |
| 11:22 |
eeevil |
jeff: yes |
| 11:22 |
csharp |
I put the branch on a test server and am seeing much better search returns, but for some reason, running the core query from one of the search attempts took just as long as before - I'm assuming I was doing something dumb (I'll add that I was exhausted when I looked last night ;-)) |
| 11:23 |
csharp |
next.gapines.org vs. gapines.org (if someone is interested in front end results) |
| 11:23 |
csharp |
next has the patch, gapines.org doesn't |
| 11:23 |
jeff |
with that as (very light) inspiration, would a materialized view representing (something like) record, circ_lib, shelving location be of much help in making locations() filtering faster, or in enabling crazy things like faceting on copy locations? |
| 11:24 |
jeff |
also, does the idea get crazier if you expand/replace the idea with copy location groups? |
| 11:25 |
csharp |
specific searches: http://gapines.org/eg/opac/results?query=lusitania&qtype=keyword&fi%3Asearch_format=book&locg=117&sort= vs http://next.gapines.org/eg/opac/results?query=lusitania&qtype=keyword&fi%3Asearch_format=book&locg=117 |
| 15:43 |
jeff |
eeevil: yikes |
| 15:43 |
|
Newziky left #evergreen |
| 16:03 |
* dbwells |
sheds a tear for his AMD stock |
| 16:06 |
Dyrcona |
Stompro++ # For testing with Jessie. |
| 16:58 |
|
gsams joined #evergreen |
| 16:58 |
|
StomproJ joined #evergreen |
| 17:20 |
|
mmorgan left #evergreen |
| 09:34 |
Dyrcona |
S'pose you could consider 1 physical server a "brick" if you're running all the pieces on vms on that server.... |
| 09:34 |
Dyrcona |
Meh. Words. |
| 09:35 |
csharp |
right ;-) |
| 09:37 |
Dyrcona |
Speaking of building VMs.... I'm going to build two today to test csharp's changes for Safe.pm. |
| 09:37 |
csharp |
it's also worth considering that virtual machines have become dominant enough that it's worth reconsidering cluster architecture |
| 09:37 |
|
yboston joined #evergreen |
| 09:37 |
Stompro |
Thanks for the info all. |
| 11:28 |
csharp |
I think we can assume jessie's all good if 14.04 works |
| 11:29 |
Dyrcona |
Ok. I'll comment on the bug to that effect. |
| 11:32 |
Dyrcona |
csharp++ |
| 11:34 |
bshum |
yboston: On a more practical note, I was thinking to cut 2.7.5 later next week; give folks some time to test and push on more bug fixes. |
| 11:35 |
bshum |
Personally, I'm poking at more stuff for 2.8.1 though. Now that Bibliomation is on 2.8 and all. |
| 11:35 |
bshum |
And eating food. |
| 11:36 |
bshum |
I mean literally, every time I'm in Hong Kong, it's "hey long time no see" and "you hungry? Eat this..." |
| 11:36 |
kmlussier |
bshum: You |
| 11:36 |
kmlussier |
bshum: You're eating food at 11:30 PM? |
| 11:37 |
bshum |
No, I just got back from eating "dinner" |
| 13:59 |
pinesol_green |
Launchpad bug 1438136 in Evergreen "OPAC searching significantly slowed by adding format filters" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1438136 |
| 14:00 |
krvmga |
csharp: yes, exactly |
| 14:00 |
krvmga |
i checked, though, and we have the index |
| 14:00 |
csharp |
krvmga: there's a branch eeevil put up (that I haven't yet tested) that should help |
| 14:01 |
bbqben |
Hi all - EOB meeting starting here in two shakes |
| 14:01 |
kmlussier |
krvmga: Is it just the All Books limiter or others as well? |
| 14:01 |
krvmga |
gmcharlt: are you aware of this for our upgrade? |
| 14:27 |
csharp |
logs++ |
| 14:27 |
bbqben |
logs++ all y'all++ |
| 14:27 |
abneiman |
csharp++ |
| 14:28 |
bbqben |
ok, amensia in check - will update the call and prep it for later |
| 14:28 |
bbqben |
anyone test the voter reg survey? |
| 14:28 |
bbqben |
#info https://www.surveymonkey.com/r/RXVRSKJ |
| 14:28 |
kmlussier |
I looked at it. Didn't submit, though. It looked good to me. |
| 14:29 |
bbqben |
don't recall what other info we collected last year (survey's decommissed) but very open to feedback |
| 14:29 |
bbqben |
kmlussier - thanks |
| 14:29 |
csharp |
it just asked for my name, org, and whether I was legit - is that all it's supposed to do? |
| 14:30 |
abneiman |
I'll test it right after this meeting ... i.e., my first meeting-free time today :-/ |
| 14:30 |
bbqben |
csharp - pretty much |
| 14:30 |
csharp |
ok |
| 14:30 |
bbqben |
csharp - will take the names and load them to opavote later on |
| 15:16 |
krvmga |
kmlussier: no, i just don't want the searches to be slow. |
| 15:17 |
krvmga |
kmlussier: since i'm the public face of the opac around here, i would be hanged in effigy if not in reality |
| 15:18 |
krvmga |
i even get scowls from central site staff sometimes as though i'm truly the god of the opac and can do anything mwahahahahaha! |
| 15:18 |
gmcharlt |
krvmga: I'm quite sure you'll be fine - there's a workable patch available for testing that can be tested on Monday before you all go fully live |
| 15:18 |
krvmga |
gmcharlt: thanks. |
| 15:47 |
Dyrcona |
Though krvmga has left, I have loaded the branch in question on my development server and searches with formats don't seem slower than those without. |
| 15:48 |
Dyrcona |
IOW, it appears to have helped things. |
| 16:46 |
kmlussier |
eeevil++ |
| 16:47 |
|
Newziky left #evergreen |
| 17:22 |
|
mmorgan left #evergreen |
| 17:36 |
eeevil |
@later tell Dyrcona belated thanks for testing the search branch, though think your dataset may not need it? |
| 17:36 |
pinesol_green |
eeevil: The operation succeeded. |
| 17:38 |
|
akilsdonk joined #evergreen |
| 17:44 |
csharp |
gmcharlt++ # clarifying the logo stuff |
| 08:46 |
krvmga |
csharp: :) |
| 08:46 |
Dyrcona |
krvmga: Well, there are two things going on. 1) a suboptimal query, and 2) csharp's installation missing an index. |
| 08:46 |
Dyrcona |
Number 1 gets you either way. |
| 08:47 |
Dyrcona |
eeevil: If you think it would be helpful, I'll run the tests on my database in a bit. |
| 08:47 |
krvmga |
Dyrcona: gonna have to check if we're missing the index, too. |
| 08:47 |
Dyrcona |
I meant to yesterday, but got busy with other stuff. |
| 08:47 |
eeevil |
Dyrcona: more data is more better, thanks! |
| 10:23 |
Dyrcona |
Hmm. Turns out I get a conflict. |
| 10:25 |
Dyrcona |
Minor conflicts with the conditional negative balance branch and recent changes to master. |
| 10:25 |
Dyrcona |
Easily resolved, I think. |
| 10:31 |
dbwells |
There is at least two lines with bugs in the negative balances branch which were discovered when I was testing for fine issue in master. I should go ahead and rebase it, since a few more pieces are in master now. |
| 10:32 |
Dyrcona |
dwells: That's cool. |
| 10:32 |
Dyrcona |
dbwells, even. |
| 10:33 |
Dyrcona |
My fingers appear to be on strike. |
| 10:42 |
pinesol_green |
Launchpad bug 1424646 in Evergreen "Paid-For Long Overdue Items Still Appear in "Other/Special Circulations" Window" (affected: 7, heat: 32) [Undecided,New] https://launchpad.net/bugs/1424646 |
| 10:42 |
csharp |
signoff branch a'comin' |
| 10:43 |
mmorgan |
Bmagic++ csharp++ |
| 10:43 |
Bmagic |
csharp++ # testing |
| 10:47 |
Dyrcona |
@quote random |
| 10:47 |
pinesol_green |
Dyrcona: Quote #85: "< bshum> *Everything* is awesome." (added by csharp at 09:29 AM, May 27, 2014) |
| 10:48 |
csharp |
https://www.youtube.com/watch?v=StTqXEQ2l-Y |
| 14:08 |
|
RoganH joined #evergreen |
| 14:12 |
* csharp |
changed makefiles for wheezy/jessie/precise/trusty, but left squeeze alone |
| 14:12 |
csharp |
bug 1444623 |
| 14:12 |
pinesol_green |
Launchpad bug 1444623 in Evergreen ""Safe" is no longer needed as a separate CPAN package" (affected: 1, heat: 6) [Medium,Confirmed] https://launchpad.net/bugs/1444623 - Assigned to Chris Sharp (chrissharp123) |
| 14:13 |
|
Newziky joined #evergreen |
| 14:14 |
|
Newziky left #evergreen |
| 14:24 |
|
ericar_ joined #evergreen |
| 16:22 |
|
bmills joined #evergreen |
| 16:39 |
|
mrpeters left #evergreen |
| 16:50 |
|
artunit joined #evergreen |
| 17:06 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:14 |
|
jihpringle joined #evergreen |
| 17:16 |
|
mmorgan left #evergreen |
| 17:21 |
|
jboyer-isl joined #evergreen |
| 11:23 |
bshum |
https://bugs.launchpad.net/evergreen/+bug/1189980 |
| 11:23 |
pinesol_green |
Launchpad bug 1189980 in Evergreen "Clear Shelf-Expired Holds confirmation needed" (affected: 4, heat: 18) [Wishlist,Confirmed] |
| 11:23 |
jboyer-isl |
Ah, bshum beat me to the paste. :) |
| 11:24 |
bshum |
Dyrcona++ # rescuing me from bad mistakes |
| 11:24 |
bshum |
berick++ # we're testing your fix now |
| 11:24 |
bshum |
I'll get a bug report going on it later this afternoon after I finish writing up after-action reports. |
| 11:27 |
Dyrcona |
I'll add the if statements in the other two places, just in case. |
| 11:28 |
Dyrcona |
I'm not sure how to trigger clear_shelf_cache. |
| 11:33 |
berick |
that's called by the UI after running clear-shelf |
| 12:58 |
Dyrcona |
csharp: You'll likely end up with a lot more .in files. |
| 12:58 |
Dyrcona |
Well, maybe not a lot, but I'd suspect a few. |
| 13:07 |
|
bmills joined #evergreen |
| 13:10 |
dbs |
csharp: I run EG/OpenSRF in FHS locations on Fedora, I put a bunch of work into patches that were accepted for that purpose a while back |
| 13:11 |
dbs |
just bear in mind that I might have missed lots of scripts that wouldn't get invoked in regular dev/testing workflows that would suddenly become important in production |
| 13:12 |
dbs |
I was hoping that we would cut over to standard FHS locations rather than continuing to document --prefix=/openils but since we've followed the latter path, wouldn't be surprised if more non-relocatable stuff creeps in |
| 13:43 |
csharp |
dbs: great - looks like a good foundation |
| 13:43 |
csharp |
I'll try and get that working on Ubuntu 14.04 and/or Debian jessie |
| 13:45 |
* csharp |
wants the next Debian release to be "lotso" |
| 13:52 |
eeevil |
(from before) |
| 14:12 |
jboyer-isl |
eeevil: does that "not FHS" mean that it currently can't work from /usr/bin, or just that it will work from some other prefix and /usr/bin is uncertain? |
| 14:13 |
jeff |
jboyer-isl: i took his statement to mean that eeevil has experience operating from a non-FHS, non-/openils location. |
| 14:13 |
berick |
jboyer-isl: i think he means he didn't specifically test FHS, but did test other non-/openils options |
| 14:16 |
jboyer-isl |
jeff, berick: makes sense, thanks. |
| 14:19 |
eeevil |
jboyer-isl: there's no reason it won't work under FHS, but I'm using under a set of paths that are non-FHS |
| 14:19 |
eeevil |
what berick said :) |
| 14:24 |
berick |
jeff++ |
| 14:26 |
eeevil |
Callender++ |
| 14:26 |
berick |
Callender++ indeed |
| 14:26 |
jeff |
upgrade-wise, i just tested and cherry-picked things beforehand. Callender pulled the trigger in production, and every single contributor helped build a quality release. upgrades keep getting smoother. |
| 14:27 |
jeff |
and yes, i'll repeat my increments from this morning's "no longer on 2.5 dance": ESI++ and Callender++ in particular :-) |
| 14:30 |
|
Newziky1 left #evergreen |
| 14:31 |
jeff |
I think part of it is "lots of development effort focused elsewhere", part of it is "things are a bit more mature/stable", but also a good helping of "intentional efforts to make upgrades less painful" :-) |
| 14:32 |
jeff |
I was surprised at how few external systems/processes needed tweaking as part of the upgrade. Even the number of (immediately required) changes to templates was low. |
| 14:33 |
jeff |
And by low, I think I mean "zero changes required to maintain functionality", though of course we'll be making changes to enable new features, etc. |
| 14:59 |
|
bmills joined #evergreen |
| 15:11 |
|
TaraC joined #evergreen |
| 15:15 |
|
bmills1 joined #evergreen |
| 15:27 |
jeff |
It's gone well enough that I'm putting non-upgrade-related template changes in place (closing pre-upgrade tickets) and experimenting with sitemaps and robots.txt changes. |
| 16:20 |
|
RBecker joined #evergreen |
| 16:27 |
pinesol_green |
[evergreen|Galen Charlton] LP#1442701: prune 'message_id' and 'single' CGI params from TPAC dashboard links - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=07da4e2> |
| 16:29 |
pinesol_green |
[evergreen|Galen Charlton] LP#1442695: install purge_pending_users.srfsh to /openils/bin by default - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=73d671a> |
| 16:30 |
|
sarabee joined #evergreen |
| 16:31 |
pinesol_green |
[evergreen|Dan Wells] LP#1443952 Move overdue restore above lost void/adjustment - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=749e63f> |
| 16:31 |
pinesol_green |
[evergreen|Dan Wells] LP#1443952 Lost fine handling refactor - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6b0d8e7> |
| 16:43 |
|
bmills 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:39 |
|
mglass joined #evergreen |
| 17:40 |
|
Newziky left #evergreen |
| 18:02 |
|
akilsdonk joined #evergreen |
