| 00:50 |
|
mceraso joined #evergreen |
| 04:23 |
|
mceraso_ 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:14 |
|
23LAAVGRD joined #evergreen |
| 07:14 |
|
timlaptop joined #evergreen |
| 07:33 |
|
rjackson-isl joined #evergreen |
| 11:54 |
|
jeffdavis joined #evergreen |
| 12:09 |
|
jihpringle joined #evergreen |
| 12:15 |
|
sseng joined #evergreen |
| 12:39 |
jeffdavis |
what are the search issues with production data that dbwells mentioned in the RC update email? |
| 12:39 |
jeffdavis |
we've got a 2.6 beta test server with 200K bibs, can do some testing there if it would help |
| 12:40 |
dbwells |
jeffdavis: part of the reason for delay is that the issue isn't clear yet (to me, at least) |
| 12:40 |
bshum |
jeffdavis: One question, did you do any reingests on that test system already? |
| 12:41 |
bshum |
The initial issue I would see is that 1) no format icons would be visible, and 2) using any of the search filters would not find any specific materials |
| 12:41 |
bshum |
Till something gets reingested somewhere, somehow |
| 12:41 |
bshum |
And the "somehow" is the part I've been trying to get to the bottom of |
| 12:42 |
dbwells |
jeffdavis: yes, bshum is the mysterious "reporter", so he knows better than I. |
| 12:47 |
jeffdavis |
for this test server I didn't run the upgrade scripts on production data, we have a test dataset containing a subset of 200K bibs (and other stuff) from our prod system |
| 12:47 |
jeffdavis |
process was (1) create clean 2.6 database, (2) insert bibs and other data |
| 12:47 |
berick |
the upgrade scripts aren't forcing a re-ingest, at least not the last time I checked. |
| 12:48 |
jeffdavis |
I don't see the issues with format icons etc that bshum mentioned. |
| 12:48 |
berick |
jeffdavis: yeah, on a new DB, it should not be an issue |
| 08:09 |
|
kmlussier joined #evergreen |
| 08:16 |
|
jboyer-laptaupe joined #evergreen |
| 08:33 |
|
jboyer_laptaupe joined #evergreen |
| 09:01 |
csharp |
ldwhalen: check out master, then create a signoff branch from master, then 'git cherry-pick -s' each commit, then push your signoff branch to working |
| 09:04 |
|
ericar joined #evergreen |
| 09:13 |
|
jboyer__laptaupe joined #evergreen |
| 09:16 |
|
jboyer_laptaupe joined #evergreen |
| 09:17 |
|
RoganH joined #evergreen |
| 09:19 |
* csharp |
wishes he had more time to test/signoff on 2.6 fixes |
| 09:19 |
csharp |
it's been a crazy few weeks in PINES land |
| 09:20 |
bradl |
csharp: what's going on in PINES land? |
| 09:20 |
bradl |
I mean, besides the /usual/ crazy :) |
| 09:22 |
RoganH |
when everything is crazy, everything is usual. <- one of the first things I learned in public libraries |
| 13:37 |
jl- |
I'm just gonna stick with debian for consistency |
| 13:37 |
berick |
debian++ |
| 13:37 |
berick |
(for servers, anyway) |
| 13:37 |
dbwells |
Anyone here willing to test and push bug #1243023? Everything but the upgrade script and the test already has two signoffs, if that helps. |
| 13:37 |
pinesol_green |
Launchpad bug 1243023 in Evergreen 2.5 "Browse catalogue titles are doubly escaped?" (affected: 1, heat: 8) [Undecided,Confirmed] https://launchpad.net/bugs/1243023 |
| 13:43 |
eeevil |
dbwells: I assume you just copied over the functions in question for the upgrade script? |
| 13:44 |
dbwells |
eeevil: that was certainly my intention |
| 13:46 |
dbwells |
My only real concern would be missing a function or copying the wrong one somehow. |
| 13:51 |
dbwells |
eeevil: Looking again, I think I need a few more things in that upgrade. Do I need to create evergreen.oils_xslt_process and also manually drop the public ones? |
| 13:52 |
dbwells |
Nothing changed in that function other than the schema, so I wasn't sure what was necessary there. |
| 13:53 |
dbwells |
One thing which confused me generally is that all my test DBs already had those functions in the evergreen schema, but I now see that my production DB has them in public. Hmmmm... |
| 13:54 |
jeff |
and I'd wager that some databases have them in both places, potentially conflicting. :-) |
| 13:54 |
tsbere |
dbwells: I recommend a DROP FUNCTION with an IF EXISTS clause for the public one |
| 13:55 |
tsbere |
after a "create or replace" in the evergreen schema, anyway |
| 00:57 |
|
berick joined #evergreen |
| 01:09 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 01:32 |
|
berick joined #evergreen |
| 01:43 |
Guest37050 |
I read that as "Incoming from qantas" |
| 01:43 |
Guest37050 |
Had me freaked out for a moment there.. |
| 06:14 |
|
timlaptop joined #evergreen |
| 07:41 |
csharp |
@librarian |
| 07:41 |
pinesol_green |
csharp: Management:11, Cataloging:16, Acquisitions:14, Reference:13, Circulation:12, Systems:7, Research:6, Custodial:10 |
| 07:49 |
* phasefx |
still hasn't had time to poke at the test failure :( |
| 08:02 |
|
dac joined #evergreen |
| 08:06 |
|
akilsdonk joined #evergreen |
| 08:10 |
|
dluch joined #evergreen |
| 08:50 |
|
mmorgan joined #evergreen |
| 08:58 |
jeff |
good morning! |
| 09:09 |
_bott_ |
So, how much snow is forecast for Boston tomorrow? ...better this week than next. |
| 09:13 |
dbwells |
phasefx: I wonder if the failed tests are a DST thing. Maybe rewrite the circs to 20 days, one hour ago? Obviously we would need to pick an interval where the number of fine calcs is the same regardless of the 'missing' hour. |
| 09:16 |
phasefx |
dbwells: I think it is a DST thing |
| 09:17 |
* Dyrcona |
snickers: "Tests...." |
| 09:18 |
dbwells |
Probably easy to solve for now, maybe tricky to solve forever. Maybe we would need to do X days and 12 hours to get away from the edges. |
| 09:18 |
phasefx |
better to have tests to fix than no tests at all; as long as we do fix them |
| 09:18 |
* phasefx |
is just tuit-less at the moment |
| 09:23 |
kmlussier |
_bott_: Last I saw, Boston is mostly getting rain tomorrow. The snow will be falling a little further north. |
| 09:31 |
dbwells |
phasefx: fwiw, those tests just ran fine for me. Perhaps the problem is triggered when running within an hour of midnight. If that is the case, I'm not sure what would be worth doing about it. |
| 09:32 |
|
yboston joined #evergreen |
| 09:32 |
phasefx |
dbwells: ah; in that case, I'm happy to move the tests to run later or earlier |
| 09:32 |
phasefx |
still not perfection, but... |
| 09:34 |
* phasefx |
will take good enough |
| 09:35 |
dbwells |
I think that's a reasonable stance |
| 09:39 |
* Dyrcona |
builds a fresh VM to rid it of clutter. |
| 09:57 |
|
kayals joined #evergreen |
| 12:47 |
tsbere |
kayals: What kind of notices are you trying to make them for? Hold available are one of the only ones with SMS data available right now... |
| 12:49 |
|
dluch joined #evergreen |
| 13:08 |
|
afterl joined #evergreen |
| 13:10 |
bshum |
I didn't get to reply to dbwells' suggestion, but I see "bugmaster evergreen-ils.org" coming up so I assume we're testing a new LP account? |
| 13:11 |
* kmlussier |
has already set up a filter to divert those messages. |
| 13:11 |
kmlussier |
dbwells++ |
| 13:11 |
dbwells |
bshum: yes. I'll reply to that thread once I get these bugs all moved so people can better see what they think. |
| 16:18 |
jboyer-laptaupe |
int(16.90 * 100) = 1689. Dammit, floating point. :( |
| 16:20 |
|
hbrennan joined #evergreen |
| 16:24 |
|
dconnor_ joined #evergreen |
| 16:29 |
jeff |
Hrm. Anyone here have confirmation / refutation of print_win.js functions like print_do_sums working or not-working in 2.5? |
| 16:29 |
|
oralov joined #evergreen |
| 16:30 |
jeff |
co-worker's been trying to get it working on a test client, sounds like he's headed down to check at the circ desk to see if it stopped working there. |
| 16:45 |
|
akilsdonk joined #evergreen |
| 17:05 |
jeff |
and... seems broken. argh. |
| 17:08 |
jeff |
oh! now i suspect print_custom is at fault. |
| 17:11 |
|
mmorgan left #evergreen |
| 17:14 |
|
tfaile_ joined #evergreen |
| 17:18 |
|
afterl left #evergreen |
| 17:21 |
jeff |
yeah. well, that's one of those "broken for HOW long and unreported?" things. :-) |
| 17:22 |
|
eby__ joined #evergreen |
| 17:24 |
|
DPearl joined #evergreen |
| 17:26 |
|
dmsander joined #evergreen |
| 00:47 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:47 |
|
remingtron_ joined #evergreen |
| 06:47 |
|
jboyer_isl joined #evergreen |
| 06:47 |
|
sseng_ joined #evergreen |
| 06:48 |
|
fparks joined #evergreen |
| 06:48 |
|
BigRig_ joined #evergreen |
| 06:48 |
|
tfaile joined #evergreen |
| 06:58 |
phasefx |
that test failure came from live_t/03-overdue_circ.t, expected 13 bills, got 12. probably bad logic in the test surrounding certain dates and not in Evergreen. Will look later, unless someone gets the itch :) |
| 07:07 |
* phasefx |
had to double-take, but today's xkcd: http://xkcd.com/1340/ apropos dates |
| 07:31 |
csharp |
wow - so we'll really be kicking ourselves in 8000 years for not starting to use the five-digit year now, right? ;-) |
| 07:40 |
|
rjackson-isl joined #evergreen |
| 08:00 |
|
collum joined #evergreen |
| 09:48 |
jeff |
pg 9.2 vs 9.3? |
| 09:48 |
jeff |
dumb luck on my dataset? |
| 09:49 |
|
mrpeters joined #evergreen |
| 09:49 |
eeevil |
you could, conceivably, use it at the end, like: //*[local-name() == "leader"]/substring(.,7,1) ... but I haven't tested it. |
| 09:49 |
eeevil |
jeff: I'm surprised it works, TBH |
| 09:50 |
eeevil |
it's been a pain point for me since we first started thinking about in-db indexing |
| 09:50 |
Dyrcona |
jeff: If I add the name space for xpath-functions, I get the following: DETAIL: xmlXPathCompOpEval: function substring not found |
| 09:54 |
* jeff |
runs a "just how many marc values are invalid xml" query in the reporting db |
| 09:56 |
dbwells |
jeff: Which version of pg are you running? |
| 11:00 |
csharp |
@eightball is there a statute of limitations for cataloging errors? |
| 11:00 |
pinesol_green |
csharp: Maybe... |
| 11:04 |
|
dave_bn joined #evergreen |
| 11:05 |
dave_bn |
hi everyone! |
| 11:05 |
dave_bn |
I am looking for a quick way to test evergreen |
| 11:06 |
dave_bn |
so I need to install it on a test server. Is there an automated installation script that comes with a documentation? |
| 11:06 |
dave_bn |
or perhaps a virtual image I could deploy |
| 11:06 |
dave_bn |
or more or less easy installation instructions. |
| 11:07 |
dave_bn |
I have spent several hours with the official installation guides and also with sitka and paxed scripts, but have not been able to configure them properly due to lack of documentation. |
| 11:08 |
jeff |
what documentation did you find lacking? |
| 11:08 |
jeff |
i don't know that there is a current VM image for download, but I do know of at least one public "attempt to install everything automatically" script. let me see if i can find the url before someone else. |
| 11:09 |
dave_bn |
jeff: thank you for your help |
| 11:09 |
dave_bn |
I have spend many hours trying to install with official documentation and then with sitka's and paxed's scripts |
| 11:10 |
jeff |
you specifically mentioned that you found a lack of documentation for something. can you give me further details on that? i'd like to see what can be done to resolve the issue. |
| 11:11 |
yboston |
dave_bn: related to jeff's question, can you post the link to the documentation you are using? or some info on it. i ask because often those that have issues with installation are following outdated installation instructions |
| 11:11 |
jeff |
i have used the installer here with reasonable success recently for installing a test/dev system: http://git.evergreen-ils.org/?p=working/random.git;a=shortlog;h=refs/heads/collab/phasefx/wheezy_installer |
| 11:12 |
paxed |
i doubt my script actually works anymore |
| 11:12 |
jeff |
a more direct link, if you're not using git to clone the random repo: http://git.evergreen-ils.org/?p=working/random.git;a=tree;f=installer/wheezy;h=92dd7d1d5d0f5acfe0b49793eb5e65af78d68455;hb=refs/heads/collab/phasefx/wheezy_installer |
| 11:19 |
dave_bn |
paxed: it did do quite well, stopped at database creation, I think. |
| 11:25 |
csharp |
dave_bn: happy to help |
| 11:25 |
csharp |
I can vouch for it working |
| 11:25 |
dave_bn |
jeff: regarding the lack of documentaiton, I meant the lack of documenatiaon for the sitka and paxed automated scripts |
| 11:25 |
csharp |
I really only install from source now when testing community stuff |
| 11:26 |
jeff |
dave_bn: ah. thanks! that clears that part up. now, how about the discrepancies you found? |
| 11:29 |
Dyrcona |
dave_bn: My suggestion for installation is ignore any documentation on the web, and use the README files inside the tarballs. |
| 11:30 |
Dyrcona |
dave_bn: My next suggestion for installation for installation is don't use the tarballs and install from a git clone. |
| 11:33 |
bshum |
Oh that. |
| 11:34 |
bshum |
*too |
| 11:34 |
dave_bn |
jeff: and when I installed opensrf, I needed to put all the password in configuration, which took some time, only to find out that the configuration files would be overwritten by evergreen installation guide later :) and I would need to put the passwords again |
| 11:35 |
jeff |
dave_bn: slightly annoying, but it is important to test opensrf before continuing on to evergreen installation. :-) |
| 11:35 |
dave_bn |
dyrcona: I see. but the APT method is reliable, yes? |
| 11:35 |
Dyrcona |
I always make sure that the following are installed before proceeding: acpid, vim, openssh-server, screen, wget, git-core, build-essential, zip, nsis, man-db, autoconf, automake, libtool, aptitude, tmux |
| 11:35 |
Dyrcona |
dave_bn: Dunno. I only ever install from git checkouts. |
| 11:42 |
jeff |
dave_bn: was the point of confusion that you didn't realize that you needed to enter the passwords twice, so you skipped that step after installing evergreen? |
| 11:42 |
dave_bn |
Dyrcona: no :) this is the reason I have not been able to follow the instructions properly obviously |
| 11:43 |
dave_bn |
jeff: no, I just had to look throught the xml configuration file twice, and I guess the first time it was not really required, as following the EG guide overwrites the opensrf configuration anyway |
| 11:46 |
Dyrcona |
dave_bn: If you want to test OpenSRF before installing Evergreen, it is necessary to put the passwords in the file. |
| 11:47 |
Dyrcona |
I always test OpenSRF by doing the math add 2,2 call before installing Evergreen when I set up a new VM. |
| 11:47 |
|
mtate joined #evergreen |
| 11:51 |
|
kayals_ joined #evergreen |
| 11:58 |
dave_bn |
Dyrcona: I see. It also helped me understand the process, though was a bit time consuming at first. I guess I will be able to to it faster the next time. |
| 12:44 |
csharp |
or during installation? |
| 12:45 |
eeevil |
bshum: working/collab/miker/metarecord-deleted-constituents updated |
| 12:45 |
dave_bn |
csharp: this is during installation. should I reboot manually now? |
| 12:45 |
csharp |
dave_bn: you shouldn't have to |
| 12:45 |
csharp |
dave_bn: give me a minute to try something on my test server |
| 12:45 |
ldwhalen |
ktomita: I think the hardest part to test is the warning message appearing when it should not appear. From my testing it works as it should, but there may be cases where the variables I am using are persisting when they should not, so the message might appear elsewhere. I do not expect this to happen, but that is a concern. |
| 12:47 |
ktomita |
ldwhalen: I will look out for that. |
| 12:47 |
ldwhalen |
ktomita: thank you for looking at the branches |
| 12:47 |
bshum |
eeevil: Cool, I'll check that in, once I figure out what that internal flag is all about. I didn't remember that one before. |
| 12:52 |
|
akilsdonk_ joined #evergreen |
| 12:52 |
bshum |
Calling 0872 |
| 12:53 |
|
dave_bn joined #evergreen |
| 12:53 |
csharp |
dave_bn: almost done with my test... |
| 12:53 |
dave_bn |
csharp: thanks for your help |
| 12:54 |
csharp |
dave_bn: no problem - I want our APT repo to be a viable option for installing stock test servers ;-) |
| 12:55 |
eeevil |
How would you like comments that apply to the OmniTI suggestions you put up on the wiki? (re: http://wiki.evergreen-ils.org/doku.php?id=dev:testing:performance_report ) ... would you like them in-line on that page? |
| 12:57 |
pinesol_green |
[evergreen|Mike Rylander] LP#1284864: Don't leak deleted constituent records - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5f03068> |
| 12:57 |
|
akilsdonk joined #evergreen |
| 12:57 |
pinesol_green |
[evergreen|Mike Rylander] LP#1284864: Forcibly update deleted MR masters - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f4d5813> |
| 13:44 |
ldwhalen |
bshum: is is it broken when you do not use a pubdate in the search? |
| 13:44 |
bshum |
ldwhalen: I was just doing a title search and it dies horribly. I could try other types of searches too. |
| 13:45 |
Dyrcona |
ldwhalen: I verified it doing only a title. |
| 13:45 |
ldwhalen |
bshum: I have a fix for a similar bug when using a pubdate. It has been tested. I will push it to a working branch. There is an issue when the source does not return results. |
| 13:46 |
bshum |
Given that the source is the native catalog (aka our own system) that's not very comforting either. |
| 13:46 |
bshum |
But I'll be curious to see what you saw with pubdate |
| 13:48 |
bshum |
And sorry phasefx, just got distracted by this z3950 bug. But I plan to take a closer look at that bug with localstore.rdf. Seems like something we should try fixing as a performance type of issue. |
| 14:34 |
csharp |
dave_bn: a word of caution... now that you have Evergreen installed, I would recommend commenting out the apt/sources.list entry |
| 14:35 |
csharp |
otherwise you may risk inadvertently "upgrading" when our folks put in newer versions of Evergreen/OpenSRF |
| 14:35 |
dave_bn |
csharp: thank you, will do that. |
| 14:35 |
csharp |
we haven't tested upgrading via APT yet |
| 14:36 |
dave_bn |
csharp: i see :) which staff client would be compatible with the current version I have installed? |
| 14:36 |
jeff |
or risk getting owned when they turn evil ;-) |
| 14:36 |
csharp |
jeff: exactly! |
| 00:04 |
|
kmlussier joined #evergreen |
| 01:11 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 02:21 |
|
berick joined #evergreen |
| 02:53 |
|
gsams joined #evergreen |
| 02:53 |
|
mtj_ joined #evergreen |
| 09:15 |
jeff |
jl-: in addition to the data set at archive.org for openlibrary, there's a batch (or two!) of gutenberg records here: http://www.gutenberg.org/wiki/Gutenberg:Offline_Catalogs |
| 09:15 |
jeff |
dbwells++ |
| 09:17 |
|
dluch joined #evergreen |
| 09:20 |
* dbwells |
creates a '--load-sample-harvard' option, watches his test machine go up in smoke |
| 09:21 |
jeff |
--generate-random-bibs |
| 09:21 |
jeff |
--count 100M |
| 09:31 |
|
yboston joined #evergreen |
| 11:19 |
pinesol_green |
Launchpad bug 1289450 in Evergreen "mark OpenSRF 2.3.0 as minimum required version" (affected: 1, heat: 6) [Low,New] |
| 11:19 |
|
Callender__ joined #evergreen |
| 11:22 |
wlayton |
gmcharlt: thanks! |
| 11:23 |
remingtron |
berickm: testing your branch on bug 1281750 raised an unrelated bug, I think. Can you (or others) confirm? |
| 11:23 |
pinesol_green |
Launchpad bug 1281750 in Evergreen 2.5 "Fetching user group info on deleted users creates unnecessary load" (affected: 2, heat: 10) [High,Confirmed] https://launchpad.net/bugs/1281750 |
| 11:23 |
remingtron |
open-ils.actor.usergroup.leaders.retrieve always returns all users in group, but master_account='f' for all but one |
| 11:23 |
remingtron |
my guess is 'if $u->master_account' evals the string 'f' as true? |
| 12:48 |
jeff |
and now i know where these records came from. :-) |
| 12:48 |
jeff |
email++ |
| 12:48 |
jeff |
(correlation between create_date of this batch and an old 2011 email of a pair of libraries going live) :-) |
| 12:51 |
bshum |
dbwells: Testing the negative balance branch on the test system. So far, found a lost bill, paid it off to zero, then checked in the item to go and delete it. So far no negative bills appear and no errors. Good first sign for me. |
| 12:51 |
bshum |
We'll keep testing here next week to look at some of the other scenarios. |
| 12:53 |
kmlussier |
dbwells: Dyrcona has loaded the branch on his test server too. But I probably won't get a chance to look at it until after the conference. |
| 13:00 |
dbwells |
bshum++ kmlussier++ |
| 13:02 |
jeff |
"Computer-generated, six-character numeric string that indicates the date the MARC record was created. Recorded in the pattern yymmdd." |
| 13:03 |
jeff |
which will become more useless first, 008/00-05 or MARC itself? :P |
| 13:04 |
bshum |
eeevil: I'm mostly worried about the deleted bibs. The other thing is just junky bibs ruining our lives :) |
| 13:04 |
bshum |
eeevil: So happy to try whatever you point me at. |
| 13:04 |
eeevil |
cool |
| 13:05 |
bshum |
Our test system is working with berick's lightly squashed branch too. So hopefully I can check out some of the other things that have been fixed and get that signed off and in |
| 13:05 |
gmcharlt |
bshum: OpenSRF master now eschews AUTOLAOD |
| 13:05 |
jeff |
i mocked the two digit year-ness of 008/00-05, but in doing so realized what i was seeing. |
| 13:05 |
gmcharlt |
it also dislieks AUTOLOAD |
| 13:15 |
jeff |
Dyrcona: "required" in what sense? :-) |
| 13:19 |
Dyrcona |
meh. It's MARC, it's gonna be junk. |
| 13:27 |
pastebot |
"eeevil" at 64.57.241.14 pasted "for bshu. should avoid deleted metarecord constituents" (34 lines) at http://paste.evergreen-ils.org/28 |
| 13:31 |
* bshum |
tests |
| 13:33 |
bshum |
eeevil: It doesn't like that |
| 13:33 |
bshum |
egweb: Context Loader error: Can't call method "content" on an undefined value at /usr/local/share/perl/5.14.2/OpenILS/WWW/EGCatLoader/Util.pm line 301. |
| 13:34 |
eeevil |
hrm. interesting (and odd). well, I'll look futher |
| 13:34 |
bshum |
Oh wait, maybe just a bad refresh, hang on. |
| 13:34 |
bshum |
Nope |
| 13:42 |
bshum |
egweb: Context Loader error: Can't locate object method "new" via package "OpenILS::WWW::EGCatLoader" at /usr/local/share/perl/5.14.2/OpenILS/WWW/EGWeb.pm line 111.\n |
| 13:43 |
bshum |
Is the error though |
| 13:43 |
eeevil |
we may want to wait for berick ... I'm not seeing where he's gathering the constituent record ids, and that's where we need to filter out deleted records |
| 13:44 |
* bshum |
puts things back for now to test other stuff |
| 14:05 |
wlayton |
stupid git question: how do I pull in berickm 's prototype code at http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/berick/web-staff-proto |
| 14:05 |
wlayton |
ideally, I'd like to pull that into a separate branch |
| 14:06 |
bshum |
You can always checkout that branch with something like git checkout -b localbranch remote/remotebranch |
| 14:31 |
jeff |
@whocares git |
| 14:31 |
pinesol_green |
Dyrcona, tsbere, bshum and csharp love git |
| 14:31 |
pinesol_green |
kmlussier hates git |
| 14:31 |
dbwells |
eeevil: Yeah, sorry, got your comment after I posted my question. Did a quick test by deleting record 15 from the DB (it was master of a group of three), but it looks like the master_record is still set to 15. |
| 14:31 |
bshum |
Maybe git should hate kmlussier :) |
| 14:31 |
kmlussier |
git does hate kmlussier. That's the problem. |
| 14:31 |
|
_bott_ joined #evergreen |
| 14:34 |
jeff |
hey, the history's there. :-) |
| 14:35 |
bshum |
Hehe |
| 14:35 |
jeff |
it's just no longer an active, running service (if you followed the recommendations when upgrading). ;-) |
| 14:36 |
bshum |
I'll admit, I found out that I initially installed an older git branch because I was using the ingest change to mark times since the last time I upgraded our test server and was surprised to still see it in my opensrf.xml.example |
| 14:36 |
|
hbrennan joined #evergreen |
| 14:37 |
bshum |
So jeff, your change spared me from looking really stupid for claiming we'd "upgraded" our test systems. |
| 14:38 |
bshum |
As for old demons though, I didn't mean it, really I didn't! |
| 14:39 |
dbwells |
That's what they all say |
| 14:40 |
pinesol_green |
[evergreen|Elliot V] LP#1077811 Inconsistent INSTALL Instructions - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f102496> |
| 14:52 |
bshum |
yboston++ # and now I get what MX / LATAM is all about. |
| 15:44 |
berick |
jeff: it's fixed in currrent master, btw |
| 15:44 |
jeff |
yep! :-) |
| 15:45 |
berick |
that's the first (and only, so far) instance of that I've hit |
| 15:55 |
bshum |
eeevil: I can confirm that the reason I've had icon / format search issues is due to lacking reingests. I'll schedule some time over the weekend to populate our test DB. |
| 15:55 |
eeevil |
bshum: I'm both glad to hear it's reingest-related and sad to hear you'll have to reingest ;) |
| 15:56 |
bshum |
Fwiw, the icons look really cool for the two or three bibs I manually reingested to test that out. |
| 15:57 |
bshum |
Or rather, I can see potential there. |
| 15:58 |
bshum |
For configuring these things, I'm thinking it's the coded value maps? |
| 15:58 |
dbwells |
bshum: Are you saying a full reingest is needed, or just the new attribute-only reingest? |
| 15:58 |
bshum |
dbwells: Let me try attribute-only if I can find the instructions for that. I just did a full reingest to get it over with to make it known to myself that it wasn't just broken. |
| 16:01 |
dbwells |
bshum: You could reingest all the attributes, or even try just the icon_format with a spell eeevil gave on the bug: select count(metabib.reingest_record_attributes(id,'{icon_format}'::TEXT[],marc,false)) from biblio.record_entry where id > 0 and not deleted; |
| 16:16 |
berick |
eeevil: i'm curious, what benefit do you see in using sync requests? |
| 16:17 |
dbwells |
bshum: But any that are now 'multi' could potentially improve by being reingested, I think. |
| 16:17 |
bshum |
Maybe I should just do a full reingest over the weekend anyways then. I'm sure I can ask someone to come up with more reasons :) |
| 16:18 |
* dbwells |
thinks this is going to need some more testing and consideration |
| 16:18 |
eeevil |
berick: the chance to reuse some existing code in the SC rewrite, primarily |
| 16:18 |
eeevil |
(and flexibility) |
| 16:18 |
eeevil |
dbwells: most are now multi, in fact |
| 16:28 |
dbwells |
in bib records |
| 16:28 |
berick |
eeevil: pcrud transactions don't require sync calls.. i'm confused what sync buys you there |
| 16:28 |
eeevil |
but, if I have to give up sync-ish code for callbacks and promises to get fast and small and non-brittle code, it's a small price ;) |
| 16:29 |
bshum |
dbwells: We have....1163490 bibs (not deleted) |
| 16:29 |
bshum |
In this test system |
| 16:30 |
dbwells |
bshum: My *very* rough estimate is that that last command I gave would take about an hour for a DB that size, give or take. |
| 16:30 |
bshum |
dbwells: Worth a shot then. Full reingest would certainly take longer. |
| 16:31 |
eeevil |
berick: it's the conceptual (not code-ish) difference between "rewrite the permission list for a user" (conceptually atomic) and "update these 500 copies, and tell me along the way how we're doing" (conceptually streaming) |
| 16:34 |
eeevil |
bshum: did you have a bug for the MR display issues? with berick's help, I think I've killed it (and fixed some other general MR problems) |
| 16:34 |
bshum |
eeevil: I haven't had a chance to file it yet now that you mention it. |
| 16:35 |
eeevil |
I can, if you like |
| 16:35 |
bshum |
That'd be great, and I'm happy to test those fixes too |
| 16:35 |
eeevil |
bshum: actually, you know, I'll just tack it onto berick's ... bug 1284864 |
| 16:35 |
pinesol_green |
Launchpad bug 1284864 in Evergreen "TPAC metarecord / formats repairs and usability additions" (affected: 1, heat: 6) [Undecided,Confirmed] https://launchpad.net/bugs/1284864 |
| 16:35 |
bshum |
eeevil: That sounds good to me. |
| 16:37 |
bshum |
Definitely, berick++ |
| 16:37 |
kmlussier |
@marc 505 |
| 16:37 |
pinesol_green |
kmlussier: The titles of separate works or parts of an item or the table of contents. The field may also contain statements of responsibility and volume numbers or other sequential designations. (Repeatable) [a,g,r,t,u,6,8] |
| 16:38 |
bshum |
I haven't been able to try metarecord holds yet since without the formats, it seemed unhappy with them |
| 16:38 |
bshum |
I'm hopeful that post reingest that'll be good to test |
| 16:43 |
eeevil |
bshum: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/miker/metarecord-deleted-constituents |
| 16:46 |
dbwells |
eeevil: so it looks like we were on the right track earlier? |
| 16:48 |
dbwells |
glad to see it wasn't a waste of time then :) |
| 18:18 |
bshum |
dbwells: Fwiw, 67m33.520s for that script you had me run |
| 18:18 |
bshum |
So pretty right on the money |
| 18:19 |
dbwells |
bshum: sweet, thanks! Did it get the icons to show up as expected? |
| 18:20 |
bshum |
I'm about to apply the fix for deleted bib leakage first |
| 18:20 |
bshum |
Then fire up the test server |
| 18:20 |
bshum |
Two shakes and I should know |
| 18:20 |
dbwells |
ok, I'm heading out right now, so I'll see how it went later. Have a good weekend. |
| 18:21 |
bshum |
Have a good one! |
| 18:21 |
bshum |
dbwells++ |
| 09:53 |
Dyrcona |
@dnd |
| 09:53 |
pinesol_green |
Dyrcona: strength:16 dexterity:9 constitution:16 intelligence:9 wisdom:12 charisma:7 |
| 09:53 |
Dyrcona |
random_stats-- |
| 09:54 |
jeff |
hey, build tests pass! |
| 09:54 |
jeff |
i wish i knew more c. |
| 09:55 |
csharp |
C++ #ha! |
| 09:57 |
|
ericar_ joined #evergreen |
| 10:23 |
bshum |
Doh, time change this weekend? *big sigh* |
| 10:56 |
bshum |
dbs++ |
| 10:56 |
eeevil |
bshum: Imma look at the located URIs thing from the other day RSN |
| 10:57 |
phasefx |
bshum: just forward porting for those who still use it. Not pushing for integration into master |
| 10:57 |
bshum |
eeevil: Sounds good, I'm going to reingest a few more test records (not enough time to do the whole thing) |
| 10:57 |
bshum |
(yet) |
| 10:57 |
bshum |
phasefx: Cool, just thought I'd check. |
| 10:57 |
bshum |
Thanks |
| 10:58 |
pastebot |
"eeevil" at 64.57.241.14 pasted "for bshum ... please toss on your test server :)" (33 lines) at http://paste.evergreen-ils.org/26 |
| 11:00 |
bshum |
Well, there's a syntax error |
| 11:00 |
bshum |
Missing parenthesis / hanging ; maybe |
| 11:01 |
eeevil |
um ... doesn't look like it to me... |
| 11:01 |
* eeevil |
runs to a meeting, will look after |
| 11:02 |
tsbere |
bshum/eevil: Perhaps add a ")x" before the order by at the end? |
| 11:03 |
tsbere |
(sans quotes, but with the x) |
| 11:06 |
bshum |
tsbere: Indeed that lets it run. I'll test further once I get to the office in a bit. |
| 11:07 |
eeevil |
tsbere: ah, yep. the upgrade script was already broken in that way ... so, I'll fix that too in a patch. bshum: ... nm :) |
| 11:12 |
|
kmlussier joined #evergreen |
| 11:29 |
eeevil |
bshum: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/miker/located-uris-leaking (with the subquery fixed. thanks, tsbere) |
| 13:45 |
bshum |
berick++ |
| 13:49 |
pinesol_green |
[evergreen|Bill Erickson] LP#1287973 recover row breaks in TPAC advanced search - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=51473ec> |
| 13:53 |
|
Bmagic joined #evergreen |
| 13:56 |
bshum |
eeevil: Tested that new function and at least I'm not seeing crazy URIs everywhere :) |
| 13:57 |
|
krvmga joined #evergreen |
| 13:58 |
krvmga |
if baker and taylor doesn't supply a jacket image, can be supply our own? |
| 13:58 |
bshum |
krvmga: For...... the catalog? |
| 14:00 |
eeevil |
dbwells: process question... are we saying, collectively, that one should be able to upgrade from, say, alpha to beta to RC to gold? |
| 14:01 |
eeevil |
dbwells: or is the only promise for 2.5.current to 2.6.0 to work? |
| 14:01 |
dbwells |
eeevil: my understanding has always been the second |
| 14:01 |
eeevil |
(I'd rather just fix the existing upgrade scripts, especially now that we're past beta, and say "testing should be on a fresh system, either upgraded or baseline, not upgraded from the previous beta") |
| 14:02 |
bshum |
I agree. People shouldn't necessarily expect that it'll go alpha --> beta --> rc, etc. |
| 14:02 |
eeevil |
good, ok ... then I can answer bshum! ;) |
| 14:02 |
bshum |
That said, |
| 17:53 |
bshum |
dcook: No it's probably just my generally addled brain trying to make weird phrases. I do that all the time. |
| 17:55 |
bshum |
Some weird place between whipping up something (conjuring) and tack, like sticking in a pin in something. A small trivial thing. |
| 17:55 |
dcook |
Fair enough :) |
| 17:57 |
bshum |
dbwells: I put a time on 0864 this time, so I'll get a sense of how long it'll take to complete on our duplicate production hardware with the test database. |
| 18:17 |
bshum |
Hmm, running for 20+ minutes now. Guess I'll check back at it tomorrow. |
| 18:17 |
bshum |
Or later tonight I mean |
| 18:20 |
pinesol_green |
[evergreen|Dan Wells] Forward-port 2.5.2-2.5.3 upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5d62e7d> |
| 18:30 |
pastebot |
"bshum" at 64.57.241.14 pasted "For hbrennan, top 50 karma entries in the pinesol_green database" (51 lines) at http://paste.evergreen-ils.org/27 |
| 18:30 |
* bshum |
amuses himself with the c|16 entry there at the end. c++ :P |
| 09:37 |
pinesol_green |
Dyrcona: The operation succeeded. |
| 09:38 |
csharp |
@later tell huginn please tell #koha we said "hello" |
| 09:38 |
pinesol_green |
csharp: The operation succeeded. |
| 09:40 |
phasefx |
any objections to subscribing pinesol to http://testing.evergreen-ils.org/~live/ in this channel? It's been doing it in #openils-evergreen for a while now as an experiment |
| 09:40 |
csharp |
phasefx: no objections here |
| 09:41 |
Dyrcona |
My question would be: How spammy is that? |
| 09:41 |
phasefx |
one message a day |
| 09:41 |
bshum |
Fix the live test failure and I'll say yes. |
| 09:41 |
bshum |
:D |
| 09:42 |
bshum |
Cause otherwise it'll just make me sad to see that message. |
| 09:42 |
Dyrcona |
I don't think one message a day would be a problem. |
| 09:42 |
* phasefx |
was kind of hoping folks seeing the failure message would cause some impetus to getting it fixed :) |
| 09:42 |
|
yboston joined #evergreen |
| 09:42 |
phasefx |
there's a bug report for it <looks> |
| 09:43 |
csharp |
looks like a missing perl lib? |
| 09:43 |
jeff |
I started looking at Test::Output last night. I'm interested in getting it fixed. I don't like the idea of us getting used to live tests failing. :-) |
| 09:43 |
jeff |
and yes, bug 1279420 |
| 09:43 |
phasefx |
bug 1279420 |
| 09:43 |
pinesol_green |
Launchpad bug 1279420 in Evergreen "need Test::Output prerequisite" (affected: 1, heat: 6) [Medium,Triaged] https://launchpad.net/bugs/1279420 |
| 09:43 |
phasefx |
jeff++ |
| 09:46 |
csharp |
I can test the ubuntu targets |
| 09:46 |
phasefx |
csharp++ |
| 09:52 |
dbs |
phasefx: can you add a <meta charset="utf-8"> tag to the head of the testing output? |
| 09:53 |
dbs |
jeff++ |
| 09:54 |
phasefx |
dbs: can do, and it's all in a public git branch |
| 09:56 |
phasefx |
(that it refreshes and pulls from every night before running) |
| 09:57 |
phasefx |
dbs: so just a <meta charset="utf-8"> between <head> and </head> somewhere? no need to close with a </meta> ? |
| 11:12 |
csharp |
@love kvm |
| 11:12 |
pinesol_green |
csharp: The operation succeeded. csharp loves kvm. |
| 11:16 |
* Dyrcona |
uses kvm + qemu. |
| 11:17 |
csharp |
I'm still kind of stuck on virtualbox for local desktop stuff (running windows VMs) because of not-so-awesome network bridging in NetworkManager |
| 11:17 |
csharp |
as soon as that's better, I'll switch completely |
| 11:19 |
csharp |
(last time I tested that was on F19 last summer - now on Ubuntu 13.10) |
| 11:20 |
dbs |
windows vms are the one thing I havent' been able to get working in kvm. but I don't want to taint my system with virtualbox kernel modules... so no windows vms for me. |
| 11:20 |
csharp |
dbs: understood |
| 11:20 |
csharp |
with the Linux staff client, I boot mine less and less frequently |
| 11:21 |
dbs |
(mostly from a "hate it when a kernel bug report gets created but not submitted because the tainted module") |
| 11:22 |
|
collum joined #evergreen |
| 11:25 |
|
dreuther joined #evergreen |
| 11:34 |
pinesol_green |
[evergreen|Jason Etheridge] LP#1279420 Add Test::Output prerequisite - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0cbadcc> |
| 11:35 |
phasefx |
jeff++ |
| 11:58 |
csharp |
jeff++ phasefx++ |
| 11:58 |
csharp |
I didn't finish getting my dev servers built - is there still a need for me to test? |
| 12:04 |
|
ericar joined #evergreen |
| 12:08 |
|
snowcatt joined #evergreen |
| 12:08 |
|
frank__ joined #evergreen |
| 14:12 |
|
mcooper joined #evergreen |
| 14:23 |
|
eby joined #evergreen |
| 14:33 |
|
jihpringle joined #evergreen |
| 14:36 |
jeff |
so, Business::Stripe fails tests under perl 5.18 |
| 14:38 |
jeff |
there's a pull request to fix it, but it seems to have gone unnoticed. i'm going to try to get an alternative fix accepted, but if it isn't accepted and a new release added to CPAN, we might need to force the install for at least fedora. |
| 15:04 |
gmcharlt |
jeff: does it appaer that the maintainer is responsive at all? |
| 15:10 |
|
ericar joined #evergreen |
| 15:12 |
jeff |
Unclear. The repo for the distribution hasn't been updated in ~2y. The pull request is old, but it's also a bit messy. I'll know on the "responsive" or not in a few days. :-) |
| 12:47 |
bshum |
http://openkiosk.mozdevgroup.com/ |
| 12:47 |
bshum |
(oh they changed their website...) |
| 12:51 |
mmorgan |
Do slips print with either of those? |
| 12:52 |
bshum |
mmorgan: I... think it can. But I haven't tested it quite yet. |
| 12:54 |
mmorgan |
We've had trouble getting the slips to print with different kiosks, but we'll take a look at these. Thanks! |
| 12:57 |
|
krvmga joined #evergreen |
| 12:58 |
krvmga |
i've got a situation where one of the holds that a patron has placed is causing errors. in the staff client, looking at the patron's holds, there is one that is always "retrieving" and i can't see what it is. how can i get at that hold? |
| 13:18 |
bshum |
mmorgan: Oh you know... there was a bug for awhile in selfcheck |
| 13:18 |
bshum |
Where the receipts didn't print at all due to a javascript error |
| 13:19 |
bshum |
But I can't remember if that was ever resolved in more recent versions. Or if it only affected certain parts of the receipts. Like billings. |
| 13:20 |
mmorgan |
Do bugs work as sacrificial offerings? :) |
| 13:22 |
mmorgan |
I know a few kiosks have been tried and some printed but had other issues. We need to do some more testing, these suggestions will help. |
| 13:23 |
mmorgan |
dbs++ bshum++ Wyuli++ |
| 13:25 |
|
jwoodard joined #evergreen |
| 13:33 |
tsbere |
bshum: I think part of the problem with printing is "modern web browsers don't allow automatic printing, or interaction with printer settings in general, at all from web pages anymore" |
| 13:36 |
Wyuli |
mmorgan, tsbere: The Evergreen self-check module and I are not on real good terms. :\ There's a pretty slick open source self checkout packge that runs on PHP and is pretty slick. |
| 15:37 |
Wyuli |
jboyer-isl++ Thanks; I think that solves the mystery rather succinctly. :) |
| 15:38 |
berick |
dbwells++ # 2.6 beta summary |
| 15:48 |
|
senator joined #evergreen |
| 15:54 |
eeevil |
I think we have code attached to all the RC blockers now ... https://bugs.launchpad.net/evergreen/+bugs?field.tag=2.6-rc-blocker is looking for testers. IMO, the sooner we can get those big ones out of the way the sooner we can start sweeping up the smaller bugs ... so, here's a call for testing, folks! |
| 15:55 |
dbs |
eeevil++ |
| 15:56 |
dbwells |
eeevil++ |
| 16:01 |
gmcharlt |
eeevil++ |
| 16:52 |
|
kbeswick left #evergreen |
| 17:20 |
|
mmorgan left #evergreen |
| 17:25 |
|
dcook joined #evergreen |
| 17:26 |
* bshum |
twiddles his thumbs waiting for 0864 to run on his test server. (finish already!!) |
| 17:31 |
bshum |
And it dies. |
| 17:31 |
bshum |
Oy :( |
| 17:31 |
dbwells |
:( |
| 17:31 |
bshum |
Stupid reporter.classic_current_circ depends on rec_descriptor stuff |
| 17:31 |
bshum |
Guess that's a killer. |
| 17:52 |
bshum |
:) |
| 17:52 |
pinesol_green |
Launchpad bug 1287510 in Evergreen "2.5.2-2.5.3-upgrade-db.sql and ERROR: column "behind_desk" does not exist" (affected: 1, heat: 6) [Undecided,New] |
| 17:53 |
|
Callender_ joined #evergreen |
| 17:54 |
bshum |
Oh you know dbwells |
| 17:54 |
bshum |
This is a bad, bad test |
| 17:54 |
bshum |
I keep forgetting I'm using my Thinkpad with the SSD |
| 17:54 |
bshum |
So it's probably doing the job much faster than it does with our regular disk servers. |
| 17:54 |
bshum |
I'll let you know when I run it on the other machines. |
| 17:54 |
|
mrpeters left #evergreen |
| 17:56 |
dbwells |
Oh, I was really just curious if we were talking minutes, 10s of minutes, or hours. I am not too worried about it. |
| 17:56 |
bshum |
Well, on the Thinkpad with SSD, it was no more than just minutes then. |
| 18:07 |
bshum |
And that classic reporter issue |
| 18:07 |
bshum |
We'll figure out what to do about it sometime before release I guess :\ |
| 18:07 |
dbwells |
bshum++ # thanks, man |
| 18:08 |
bshum |
I'll finish whipping my test Evergreen frontend into shape and then see what things look like tomorrow. |
| 18:31 |
bshum |
@later tell berick When you have a chance, curious to get your opinion on this new bug https://bugs.launchpad.net/evergreen/+bug/1287973 |
| 18:31 |
pinesol_green |
bshum: The operation succeeded. |
| 18:31 |
pinesol_green |
Launchpad bug 1287973 in Evergreen "TPAC - CSS for advanced search filters" (affected: 1, heat: 6) [Undecided,New] |
| 18:31 |
bshum |
It's a tiny thing, but it irks me enough that I'd like to get to the bottom of it before 2.6 is "done" |
| 18:50 |
eeevil |
bshum: there definitely is. I plan to merge a squashed, rebased version of that branch tomorrow morning |
| 18:50 |
bshum |
eeevil: Ah, cool. I'll watch for it then. |
| 18:51 |
bshum |
And make sure that nobody clicks on that option in advanced search during tomorrow's demos :) |
| 18:51 |
eeevil |
:) |
| 18:52 |
eeevil |
I'm not certain that what you're seeing is covered, but I am certain that there are bug fixes and that it works on fresh and upgraded test instances 'round here |
| 18:52 |
eeevil |
(and that we don't see ... that) |
| 18:52 |
|
ericar joined #evergreen |
| 18:52 |
bshum |
I have to take a closer look at these icon_format things |
| 18:52 |
eeevil |
bshum: I assume you reingested (or, at least the attrs, if not the full records)? |
| 19:08 |
* bshum |
looks again |
| 19:08 |
eeevil |
well, as far as duplication is concerned... |
| 19:08 |
eeevil |
but I might have misunderstood you |
| 19:09 |
bshum |
It's alright, I often have trouble with my words. And this is the first time I've actually had time to try applying these things to a test system. |
| 19:14 |
eeevil |
you know ... we might need to add "AND all_orgs.flag" (and wrap the pair in parens) for the right hand side of the OR in those where clauses. (let me know if you're not following ... I'm not giving a ton of context, I know) |
| 19:14 |
bshum |
Oh I'm surely lost. But maybe that's a consequence of not going home to eat dinner. |
| 19:15 |
eeevil |
heh ... poke me tomorrow re evergreen.located_uris() and all_orgs.flag, I'll know what you mean ;) |
| 10:15 |
|
akilsdonk_ joined #evergreen |
| 10:15 |
|
mtcarlsoz joined #evergreen |
| 10:33 |
|
gmcharlt joined #evergreen |
| 10:36 |
jeff |
csharp: am i remembering correctly that you had a favorite tool for use on test/dev systems with regard to accepting all mail, but not relaying it on to its actual intended destination? |
| 10:36 |
jeff |
it might have been a specific configuration of sendmail/exim/postfix, or it might have been a special-purpose MTA. ring any bells? |
| 10:43 |
|
mrpeters joined #evergreen |
| 10:45 |
Dyrcona |
jeff: You could always setup an inetd entry on port 25 and redirect it to /dev/null. ;) |
| 10:46 |
Dyrcona |
That will "accept" all incoming mail and not send it on. |
| 10:46 |
jeff |
someone suggested nc -l > /dev/null :-) |
| 10:46 |
Dyrcona |
Yeah. |
| 10:46 |
Dyrcona |
It won't do SMTP, though, so the other end might get confused. |
| 10:46 |
tsbere_ |
jeff: I had, at one point, configured our mail server to accept all mail from our test systems but drop it into a local mailbox instead of the real destination(s) |
| 10:46 |
jeff |
i don't think that either option would -- right, exactly. |
| 10:47 |
jeff |
i might get some spam from old spambots, but not much else. :-) |
| 10:47 |
csharp |
jeff: one of our admins had set up postfix to send to a directory (not /dev/null :-), but a similar idea), and it was set up so we could connect an email client to it to see what was sent |
| 11:13 |
pinesol_green |
Launchpad bug 1272316 in Evergreen "much slower holds processing in 2.4+" (affected: 10, heat: 46) [High,Confirmed] |
| 11:14 |
eeevil |
kmlussier: absolutely |
| 11:14 |
kmlussier |
Great - thanks! |
| 11:14 |
eeevil |
I'm actually holding off cutting 2.4.next to give a couple folks a chance to test |
| 11:14 |
eeevil |
however, I'll probably not wait much longer, since csharp has confirmed its efficacy and was the OP on the bug |
| 11:15 |
eeevil |
IIRC |
| 11:15 |
eeevil |
yeah, he was |
| 11:15 |
kmlussier |
OK, good to know. I think we have a couple of people who are anxious to see it in production. |
| 11:18 |
eeevil |
kmlussier: IIRC, Dyrcona applied my SQL-ified, rebased version of depesz's ranked volumes patch (https://bugs.launchpad.net/evergreen/+bug/1234845) ... if you can confirm it's good for you, we could get that in soon, too. though that will probably not be 2.4 material (I'll have to look more closely) |
| 11:18 |
pinesol_green |
Launchpad bug 1234845 in Evergreen "possible optimization for evergreen.ranked_volumes database function" (affected: 2, heat: 12) [Medium,Triaged] |
| 11:18 |
eeevil |
kmlussier: applied to his test system, I mean |
| 11:19 |
Dyrcona |
Yep. |
| 11:19 |
kmlussier |
eeevil: I should have time to look at it today. |
| 11:19 |
* gmcharlt |
tosses OpenSRF bug https://bugs.launchpad.net/opensrf/+bug/1286198 out for consideration |
| 11:22 |
eeevil |
kmlussier: thanks |
| 11:23 |
eeevil |
kmlussier: re the other one ... the issues you found confuse me, and I haven't looked back at it in a couple weeks |
| 11:23 |
* eeevil |
tosses it on the pile |
| 11:25 |
kmlussier |
eeevil: When you have time to look at it, let me know. The examples I used are outdated because new items have been added to the database since I first reported it. I'm happy to redo my testing at a time when eyes are on it. |
| 11:25 |
eeevil |
thanks! |
| 11:25 |
eeevil |
I will ping you before I start |
| 11:29 |
Dyrcona |
gmcharlt: You have to change each bug independently of the others, unless you write a script. |
| 11:40 |
jeff |
Dyrcona: yup. looks like the same issue. |
| 11:41 |
gmcharlt |
heads up to those who run on OpenSRF master - I will be pushing lp1179660 at some point soonish |
| 11:41 |
gmcharlt |
bug 1179660 |
| 11:41 |
pinesol_green |
Launchpad bug 1179660 in OpenSRF "OpenSRF.pm AUTOLOAD complicates testing / serves little purpose" (affected: 1, heat: 6) [Medium,Triaged] https://launchpad.net/bugs/1179660 |
| 11:42 |
gmcharlt |
there is a decent chance that it will expose further AUTOLOAD dependers in the Evergreen codebase |
| 11:42 |
gmcharlt |
in fact, that's exactly why I want to push it |
| 11:43 |
Dyrcona |
gmcharlt: Good to know. I won't update my development environment for a few days, but when I do, I'll update OpenSRF, too. |
| 12:33 |
|
Shae_ joined #evergreen |
| 12:33 |
bshum |
eeevil: Oh I have it queued up in my master branch, but hadn't looked at the backports quite yet. |
| 12:34 |
eeevil |
bshum: if you sign off on the master/2.6 version, I'll do the heavy lifting for backport. FWIW, we've pushed it into a 2.4 instance already |
| 12:35 |
bshum |
eeevil: Yeah I wasn't too worried about the backport testing since I knew folks were on the case. |
| 12:35 |
bshum |
Give me two seconds |
| 12:36 |
eeevil |
bshum: I'll give you FOUR |
| 12:36 |
bshum |
Heh |
| 12:36 |
bshum |
I have to double check which upgrade number we're on |
| 15:00 |
jeff |
bah |
| 15:00 |
|
DPearl joined #evergreen |
| 15:23 |
jboyer-isl |
Is there some trick I'm missing with respect to rsyslog and eg-stats-collector? I followed the instructions here: http://git.evergreen-ils.org/?p=contrib/equinox.git;a=blob;f=monitoring/eg-stats/README and my logging machine is just dumping all kinds of stuff in the egstats file. |
| 15:29 |
kmlussier |
I'm looking at the new ranked volumes function on Dyrcona's server. It looks good, but then I got distracted by the shiny new "Group Formats and Editions" checkbox. |
| 15:30 |
kmlussier |
But I can't get it to work correctly on any search I try. When I click on a title to see the grouped records, I always get 0 results. |
| 15:30 |
kmlussier |
Is it possible the ranked volumes branch I'm testing affects it? I don't see any other dev branches on Jason's server that should affect the search results page. |
| 15:33 |
berick |
kmlussier: can't say for sure, but i would recommend merging https://bugs.launchpad.net/evergreen/+bug/1284864 before testing MR stuff. lots of fixes in there. |
| 15:33 |
pinesol_green |
Launchpad bug 1284864 in Evergreen "TPAC metarecord / formats repairs and usability additions" (affected: 1, heat: 6) [Undecided,New] - Assigned to Bill Erickson (erickson-esilibrary) |
| 15:37 |
|
dreuther joined #evergreen |
| 15:37 |
kmlussier |
I was just looking at those, but didn't see this particular problem being noted. |
| 17:04 |
|
DPearl1 joined #evergreen |
| 17:05 |
Bmagic |
Honestly, I am totally confused about Encode.pm |
| 17:05 |
Bmagic |
I think that I have struggled with this for years now |
| 17:08 |
Bmagic |
I have written code to test the string for utf8 and wide characters ahead of time and then encode/decode depending. I have liftedcode from EG and sometimes messing with some other modules. It's all inconsistant and I have given up trying to figure this out but it keeps coming back and biting me |
| 17:11 |
|
23LAAEWVZ joined #evergreen |
| 17:11 |
Bmagic |
I would love a second set of eyes on this http://pastebin.com/e7D1s6Ys |
| 17:12 |
Bmagic |
specifially sub query{} |
| 02:16 |
bshum |
Yeah, error is gone. Nevermind, all is well after all. |
| 02:50 |
|
gmcharlt joined #evergreen |
| 07:35 |
|
rjackson-isl joined #evergreen |
| 07:54 |
csharp |
bshum++ # testing through the night |
| 08:07 |
|
remingtron joined #evergreen |
| 08:08 |
|
akilsdonk joined #evergreen |
| 08:13 |
|
kbeswick joined #evergreen |
| 08:26 |
|
kmlussier joined #evergreen |
| 08:28 |
kmlussier |
A question for csharp, bshum, and/or eeevil regarding the fix for https://bugs.launchpad.net/evergreen/+bug/1272316/ |
| 08:28 |
pinesol_green |
Launchpad bug 1272316 in Evergreen "much slower holds processing in 2.4+" (affected: 10, heat: 46) [High,Confirmed] |
| 08:29 |
kmlussier |
It looks like most of the testing involved holds placement. Are you also seeing improvement for retargeting holds at checkin? Or is this fix specifically for the "place holds" issue? |
| 08:29 |
|
Shae joined #evergreen |
| 08:30 |
csharp |
kmlussier: we were not aware of a problem at checkin in PINES, so I haven't investigated that |
| 08:33 |
csharp |
I'm investigating why our users are able to edit their own accounts in Evergreen 2.5.1 - I'm not sure that this wasn't going on before that... In any case, I'm looking closely at Open-ILS/xul/staff_client/server/patron/user_edit.js for clues |
| 08:34 |
csharp |
kmlussier: let me check that and get back to you |
| 08:34 |
kmlussier |
csharp++ Thanks! |
| 08:49 |
|
timlaptop joined #evergreen |
| 09:07 |
csharp |
kmlussier: from my testing, I can see the hold targeter churning through far faster than before |
| 09:07 |
csharp |
before the messages would hang, then move, then hang then move |
| 09:08 |
csharp |
now they're moving pretty fast |
| 09:08 |
|
tsbere_ joined #evergreen |
| 09:10 |
csharp |
on a related note, has anyone implemented a "delete holds and notify the patron when all eligible copies are in a non-holdable status" feature? |
| 09:10 |
csharp |
I'm assuming A/T could handle that |
| 09:10 |
csharp |
s/eligible/previously eligible/ |
| 09:12 |
jeff |
We don't currently have anything like that, and I'd be a bit hesitant to introduce it without at least a timeout interval, during which reporting could give staff the opportunity to intervene. |
| 09:13 |
jeff |
But it would also probably be important to have a means to selectively suspend the pending cancellation process, and I'm not sure what form that should take. |
| 09:14 |
csharp |
jeff: good points |
| 09:14 |
tsbere |
csharp/jeff: We have a "these holds can't be filled" report that staff poke through every so often (I hope) |
| 09:14 |
csharp |
tsbere: yeah that may be a better approach |
| 09:15 |
jeff |
similar here. they show up on our standard holds ratio report with a ratio of infinity. :-) |
| 09:16 |
bshum |
kmlussier: Agreed with csharp that hold_targeter churn does seem faster than before. |
| 09:16 |
bshum |
As far as checkin, that's trickiwr |
| 09:16 |
bshum |
*trickier for me to test right now. |
| 09:17 |
bshum |
But I'm sure it'll come up soon. |
| 09:20 |
csharp |
bshum: are you running the patches in production? |
| 09:21 |
bshum |
csharp: Maybe .... :) |
| 09:24 |
csharp |
heh |
| 16:07 |
jeff |
which isn't the longest value, but it is the largest value shared by more than one record. |
| 16:10 |
|
Claudia_Love joined #evergreen |
| 17:02 |
|
gsams joined #evergreen |
| 17:03 |
bshum |
Oops |
| 17:03 |
bshum |
Looks like Elliot is burned on osrf_control because he's not using the OpenSRF 2.3 beta |
| 17:03 |
bshum |
In conjunction with testing for Evergreen 2.6 beta1 |
| 17:04 |
bshum |
gmcharlt: Was 2.3 cut after the last dev meeting? |
| 17:04 |
bshum |
*OpenSRF 2.3 |
| 17:05 |
gmcharlt |
no, I'll get on that now |
| 17:05 |
bshum |
I'll do some explanation for the discussion on the lists. |
| 17:05 |
bshum |
Thanks gmcharlt |
| 18:41 |
|
ktomita_ joined #evergreen |
| 18:44 |
|
ningalls1 joined #evergreen |
| 18:53 |
|
ktomita joined #evergreen |
| 18:53 |
jeffdavis |
we've got a 2.6beta1 test server up and running, will start proper testing tomorrow |
| 19:37 |
|
dac joined #evergreen |
| 19:42 |
|
jeff joined #evergreen |
| 19:42 |
|
b_bonner_ joined #evergreen |
