| 10:01 |
yboston |
bshum: ¡gracias! https://www.youtube.com/watch?v=0jnv0ejmLlY |
| 10:14 |
|
timf joined #evergreen |
| 10:18 |
pinesol_green |
[evergreen|Jason Stephenson] LP1297435: Make 0872 upgrade require less hand holding. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2d2e504> |
| 10:24 |
egbuilder |
build #573 of evergreen-master-ubuntu-12.04-x86 is complete: Success [build successful] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-ubuntu-12.04-x86/builds/573 |
| 10:25 |
bshum |
Yay! |
| 10:25 |
bshum |
:) |
| 10:25 |
bshum |
(unrelated) |
| 10:56 |
eeevil |
Bmagic: have a heart and at least add /system to make it bootable ;) |
| 10:57 |
Bmagic |
eeevil: lol - yeah bootable suuuure |
| 10:58 |
phasefx |
new meaning to DOS |
| 10:58 |
jeffdavis |
rangi: what is the state of the NCIPServer code? I see it's being actively developed (which is great!), wondering how far it is from being ready for testing/release. |
| 11:01 |
Dyrcona |
jeffdavis: My understanding is testing is started for the Koha side of things. The Evergreen side has gone nowhere because I was going to do it and have been too busy with other projects. |
| 11:01 |
jeff |
jeffdavis: what are you looking to do with NCIP? |
| 11:02 |
Dyrcona |
jeffdavis: The Evergreen side of things should start moving within a few weeks or months. |
| 11:09 |
jl- |
I'm reporting on the conference later today, anyone else want to chime in why migrating from a legacy ILS -> evergreen is such a big deal? so far I have: 1) marc records are shit 2) there are a lot of custom scripts involved but no clear documentation that fits all for batch importing formatting, adjusting (utilizing and perl, python) and there are several layers to be aware of (bibs, authorities, holds, books in circulation, charactor en |
| 11:51 |
rfrasur |
Dyrcona: why? because of conference calls? Oh, that's good...although conference calls do evoke a little bit of hari kari in me. |
| 11:55 |
rfrasur |
:-| |
| 11:55 |
* rfrasur |
just died a little, too. |
| 11:59 |
dreuther |
Is there a public facing server running master that I can use to test a couple things? |
| 12:01 |
rfrasur |
dreuther: I'm really not sure. You might want to ping bshum or jeff or csharp or eeevil |
| 12:01 |
* rfrasur |
pings them for you. |
| 12:01 |
dreuther |
rfrasur: Thanks |
| 12:03 |
bshum |
And actually master-like |
| 12:03 |
Dyrcona |
oops. bet that's in the logs now. :) |
| 12:04 |
rfrasur |
Dyrcona: no context so it's okay |
| 12:04 |
bshum |
dreuther: I'd generally recommend putting together your own test system though. Trusting the rest of us might not be the best thing if you want to check or poke at things :) |
| 12:04 |
* bshum |
wanders off to lunch |
| 12:05 |
dreuther |
bshum: Thanks I think that will be close enough. Just need a few basic tests. |
| 12:06 |
jeff |
Syndetics Plus adds an additional 13KB of Javascript that rarely if ever changes, yet is loaded with a cache-busting t=Date().getTime() |
| 12:08 |
Dyrcona |
Working for libraries: The crazy that keeps on giving! |
| 12:08 |
jeff |
also, while the http URL is backed by a CDN (which we already know has certain availability issues), the https URL appears to be backed by a single server at proquest. |
| 12:12 |
rfrasur |
Dyrcona++ #I'm particularly fond of the "Ten reasons not to read this list of ten reasons not to read this list." |
| 12:19 |
jeff |
<br /> nbsp;<br /> |
| 12:19 |
rfrasur |
lol, nice. |
| 12:23 |
Dyrcona |
rfrasur: I think we need buttons: "I passed the secret test!" |
| 12:23 |
rfrasur |
hehe, I'll make it happen. |
| 12:50 |
* rfrasur |
plays with Awesome Box. |
| 12:56 |
jcamins |
rfrasur: how is it? |
| 16:09 |
|
lchenry joined #evergreen |
| 16:09 |
rfrasur |
so, I bought them croissants. |
| 16:10 |
* rfrasur |
mutters something about being an enabler. |
| 16:14 |
lchenry |
Hi, y'all - is there a way to force Evergreen to send an email to a patron for testing purposes? |
| 16:14 |
rfrasur |
lchenry: what are you testing? |
| 16:14 |
rfrasur |
the validity of the email address or something else? |
| 16:15 |
lchenry |
We have a patron whose hold notifications are dated 12/31/1969 |
| 16:15 |
lchenry |
I read that this could be a problem with some phones, and I wanted to see if it displayed the same way on a laptop or desktop |
| 16:15 |
lchenry |
and she's already deleted the notifications she had |
| 16:22 |
lchenry |
No |
| 16:22 |
lchenry |
Just something I found when Googling |
| 16:22 |
* bshum |
looks for stock |
| 16:23 |
lchenry |
But my original question: Is there a way to force a test email? That would be handy, not just for this but for other email problems. |
| 16:23 |
bshum |
Okay, that date thing must be custom somewhere, I'm not seeing anything like that in the stock A/T definitions at least. |
| 16:24 |
lchenry |
Fair enough. Thanks for looking. |
| 16:24 |
csharp |
lchenry: your sys admin can use mutt or something to send an email from the server, if that's what you want |
| 16:24 |
bshum |
I think in the A/T admin interface there's a test area |
| 16:24 |
bshum |
But I don't know if/how it works |
| 16:24 |
* csharp |
doubts it does that level of testing |
| 16:24 |
bshum |
csharp's suggestion is probably best to determine if there's any wacky config issues on the server in question. |
| 16:26 |
* Dyrcona |
thinks it is more likely to be the template and not the server. |
| 16:26 |
lchenry |
Yeah, I don't have access to the back end of it, and the EG admin is home sick. I was hoping not to bug him. :) |
| 16:34 |
lchenry |
Haha, any knowledge is good knowledge. |
| 16:34 |
csharp |
lchenry++ |
| 16:34 |
bshum |
trivia++ |
| 16:34 |
remingtron |
berick: what's required to get a test instance of your web staff client code running? |
| 16:36 |
bshum |
For myself, I grabbed one of berick's working branches |
| 16:36 |
bshum |
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/berick/web-staff-proto |
| 16:36 |
bshum |
And installed that branch of code alongside other things in our test system. |
| 16:37 |
bshum |
There's a few branches floating around though, so berick might know which ones he wants people to poke with more specifically. |
| 16:37 |
bshum |
But I had the most luck with that. |
| 16:37 |
jeff |
a surprising number of things are tolerant of a mis-permissioned metabib.full_rec view. |
| 16:37 |
jeff |
but added content is not one of those things. |
| 16:38 |
jeff |
(owner/permissions on metabib.full_rec in a dev test db was wrong) |
| 16:38 |
remingtron |
bshum: do you think a normal install is necessary, or could I just drop his template and js folders in place? |
| 16:39 |
bshum |
remingtron: So what I actually did in the end was squashed all of berick's changes into a single commit and tacking that onto our custom blends we build. |
| 16:40 |
bshum |
remingtron: From that squash, I can see changes to fm_IDL.xml, eg_vhost, and a perl module |
| 16:42 |
remingtron |
sounds like a fresh build is best. thanks |
| 16:42 |
berick |
remingtron: what bshum said, but beware the latest code requires websockets opensrf. change t_base_js.tt2 to avoid websockets (the opensrf_xhr.js bits and the comment out OpenSRF.Session.transport should do it).[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C |
| 16:43 |
* berick |
curses this connection |
| 16:43 |
bshum |
Ahh, didn't notice that in the newest branch |
| 16:43 |
bshum |
My test build didn't include that fun stuff :) |
| 16:43 |
bshum |
I pulled early |
| 16:43 |
jeff |
kmlussier: the wifi at the evergreen conference this year was quite decent, especially in comparison to what i'm heading from code4lib 2014 :-) |
| 16:44 |
* rfrasur |
concurs |
| 16:44 |
* dbs |
nods vigorously |
| 04:19 |
|
remingtron joined #evergreen |
| 04:19 |
|
dbwells joined #evergreen |
| 04:43 |
|
remingtron_ 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:13 |
|
timf joined #evergreen |
| 07:32 |
csharp |
@quote random |
| 07:32 |
pinesol_green |
csharp: Quote #24: "<denials> when git doesn't kill you, it makes you smarter" (added by gmcharlt at 03:58 PM, May 03, 2012) |
| 09:24 |
jeff |
tsbere++ |
| 09:24 |
jeff |
(for the code and bug, not for having the same opinion as i) :-) |
| 09:31 |
|
yboston joined #evergreen |
| 09:36 |
tsbere |
jeff: As an FYI, in testing I saw *massive* improvements in response time, though I also did things like "put a hold on every bib in the concerto database" as part of testing. Not 100% realistic, IMO, but meh. ;) |
| 09:38 |
tsbere |
(fun doing things like "insert into action.hold_request(blah blah) select blah blah, id, blah blah from biblio.record_entry where not deleted" during testing, I think I did the same with asset.copy at one point too.... |
| 09:40 |
|
alynn26 joined #evergreen |
| 09:48 |
jeff |
tsbere: You and I have talked before, but I have ~40 holds on my account on a normal day due to my use of suspended holds, and I expect I would see several seconds shaved off of my account retrieval at a SIP client |
| 09:58 |
|
BigRig_ joined #evergreen |
| 10:09 |
|
denishpatel joined #evergreen |
| 10:11 |
csharp |
unforking_sip_server++ |
| 10:14 |
|
rjackson-isl joined #evergreen |
| 10:15 |
egbuilder |
build #539 of evergreen-master-fedora-18 is complete: Success [build successful] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-fedora-18/builds/539 |
| 10:16 |
phasefx |
huzzah |
| 10:17 |
|
tspindler joined #evergreen |
| 10:35 |
tsbere |
eeevil: The parameter in question was, in fact, an internal evergreen parameter, not one that SIPServer used directly. <_< |
| 14:21 |
pinesol_green |
Launchpad bug 1290496 in Evergreen "Import z3950 - using local catalog search option results in network error" (affected: 2, heat: 10) [High,Confirmed] https://launchpad.net/bugs/1290496 |
| 14:21 |
bshum |
Dyrcona: Cool, if you feel like pushing it, go ahead. |
| 14:21 |
bshum |
It worked fine for me too when we were hammering at it |
| 14:22 |
Dyrcona |
bshum: Well, I wonder if it needs more testing, and is it really related to Sitka's issue with acquisitions? |
| 14:24 |
Dyrcona |
heh.. Syndetics.... |
| 14:24 |
Dyrcona |
My first test search was Aleph by Paulo Coelho, and the first copy gets a cover of Frankenstein by Mary Shelley. |
| 14:37 |
Dyrcona |
After some more looking, I guess we should push the branch. I don't think either of the more permanent fixes are going to happen before release. |
| 14:41 |
jl- |
do people still use these tools: http://coffeecode.net/egdocs/1.6/draft/html/migrating_records_using_migration_tools.html I recall someone saying that the pg_loader is slow and not recommended |
| 14:42 |
Dyrcona |
jl-: I certainly hope no one still uses those tools. |
| 15:38 |
|
remingtron joined #evergreen |
| 15:39 |
eeevil |
related, for later, we need to gut 80%+ of Publisher/metabib.pm, methinks |
| 15:41 |
bshum |
Dyrcona++ # thanks, I was distracted talking to Bmagic about git usage. |
| 15:41 |
jihpringle |
bshum: I've done some more acq testing and I think what we were seeing was related to Vandelay and queues rather than Z39.50 |
| 15:42 |
jihpringle |
and can be avoided by chosing the right options in vandelay |
| 15:42 |
bshum |
jihpringle: That's what we were suspecting based on what berick was trying to tell me I think. |
| 15:42 |
bshum |
jihpringle: Glad to hear you're looking into it though. |
| 15:44 |
jihpringle |
I can confirm that the MARC Federated Search is broken for the local catalogue by the z39.50 issue which will be what dbwells saw for creating picklists |
| 15:45 |
jihpringle |
I'm hoping to get the fix applied to our test server later today to confirm that the MARC Federated Search gets fixed by it, unless someone else has already tested that piece |
| 15:45 |
eeevil |
bshum: on https://bugs.launchpad.net/evergreen/+bug/1249480 did you push that to 2.5 also, or were there merge problems there? |
| 15:45 |
pinesol_green |
Launchpad bug 1249480 in Evergreen 2.5 "staff client localstore.rdf can grow too large" (affected: 2, heat: 10) [Undecided,New] |
| 15:46 |
bshum |
eeevil: I believe I only pushed it to master because I got distracted |
| 15:48 |
bshum |
Agreed, it would for rel_2_5 |
| 15:48 |
bshum |
I probably just got distracted when I was working on it and stopped :\ |
| 15:49 |
Dyrcona |
I can push it unless someone else wants to. |
| 15:49 |
bshum |
jihpringle: That'd be great to test if you can apply the patch for the z3950 one to see if it's similarly affected. |
| 15:49 |
bshum |
I'll try to carve some time to look at the MARC federated search in acq later on our end too. Maybe. If I ever go home from conferences :) |
| 15:56 |
berick |
for ref, the acq/vandelay issue (one of them) was about not picking a queue during import, which is required. |
| 15:59 |
eeevil |
bshum: arg ... so, there's enough drift that it's far from clear that I won't break things with a simple pick-and-fix |
| 16:00 |
bshum |
eeevil: Yeah I think that's why I skipped it. Sorry. (tell people to upgrade!) |
| 10:44 |
gsams |
I wasn't able to attend your session and Sys Admin interest group at the same time |
| 10:45 |
krvmga |
Dyrcona++ |
| 10:46 |
|
kbutler joined #evergreen |
| 10:46 |
phasefx |
jeff: I believe it was you asked about up'ing the live tests frequency. I'm going to make it happen twice a day |
| 10:47 |
phasefx |
would folks here be okay with two RSS messages a day from qatests? |
| 10:47 |
jeff |
sounds like a reasonable next step :-) |
| 10:47 |
* jeff |
has no objection |
| 10:47 |
phasefx |
my original goal was to only see the RSS message when the status actually changed (from Failed to Passed or vice versa); not sure what I did wrong there, but others are welcome to poke if they like that behavior better |
| 10:52 |
phasefx |
probably something to do with when the file was last modified; could reset that timestamp or not overwrite the file unless it changes |
| 10:55 |
phasefx |
well no, it looks I tried to do just that (the latter), but am still doing something wrong. I'm going to stop rubberducking and move on :) that code is at the bottom of test_output_webifier.pl if anyone has the itch; referenced through the "git" link at http://testing.evergreen-ils.org/~live/ |
| 11:02 |
|
akilsdonk joined #evergreen |
| 11:03 |
dbs |
speaking of testing, we need to add Business::Stripe to the slaves (per phasefx's presentation) |
| 11:03 |
|
kbeswick joined #evergreen |
| 11:05 |
* jeff |
nods |
| 11:05 |
jeff |
two GPLS slaves (csharp is at code4lib con, right?) and one UPEI? |
| 11:54 |
jeff |
dbs: if the -y caused aptitude to remove those packages without user interaction, that does make me wonder if we can turn off prompting without disabling safeties (like "is it okay if i go this odd route on fixing what looks broken?") |
| 11:55 |
jeff |
dbs: ah, the shotgun approach. :-) |
| 11:58 |
* dbs |
is locked and loaded |
| 12:01 |
egbuilder |
build #566 of evergreen-master-debian-6.00-x86_64 is complete: Success [build successful] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-debian-6.00-x86_64/builds/566 |
| 12:02 |
jeff |
yay! \o/ |
| 12:02 |
dbs |
phasefx: BOOM! See, testbot is still announcing in-channel (I didn't touch anything, honest) |
| 12:03 |
dbs |
testbot, buildbot, potato, poutine |
| 12:03 |
jeff |
buildbot++ |
| 12:03 |
jeff |
poutine++ |
| 12:05 |
phasefx |
it announced to me in private message too, go egbuilder :) |
| 12:11 |
mceraso |
gmcharlt: I tested the release candidate for OpenSRF 2.3.0 and encountered no issues whatsoever |
| 12:11 |
gmcharlt |
mceraso++ |
| 12:33 |
|
bmills joined #evergreen |
| 12:44 |
kmlussier |
The CREATE_PICKLIST permission. In this context, picklist is acq selection list? Is that right? |
| 14:54 |
|
ktomita_ joined #evergreen |
| 14:57 |
|
_bott_ joined #evergreen |
| 15:05 |
csharp |
jeff: correct two GPLS buildslaves, one Fedora 19, one Ubuntu 12.04 |
| 15:05 |
jeff |
robbat2: are you making that statement based on observation and testing, or something in the 9.3 changelogs, or? |
| 15:05 |
csharp |
s/correct/correct -/ |
| 15:05 |
jeff |
csharp: cool. are you in a position to get Business::Stripe installed on both, or are you distracted by code4lib? :-) |
| 15:05 |
csharp |
distracted at the moment, but I can do it later ;-) |
| 04:43 |
|
alynn26 joined #evergreen |
| 04:58 |
|
alynn26 joined #evergreen |
| 05:12 |
|
alynn26 joined #evergreen |
| 05:24 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:27 |
|
alynn26 joined #evergreen |
| 05:27 |
|
mmorgan1 joined #evergreen |
| 05:41 |
|
alynn26 joined #evergreen |
| 10:31 |
hbrennan |
oh gross... or not |
| 10:31 |
jeff |
@who thinks @who will work now? |
| 10:31 |
pinesol_green |
jeff: An error has occurred and has been logged. Please contact this bot's administrator for more information. |
| 10:31 |
jeff |
double drat. |
| 10:32 |
jeff |
@who thinks jeff should stop cluttering up the channel with his testing |
| 10:32 |
pinesol_green |
jeff: An error has occurred and has been logged. Please contact this bot's administrator for more information. |
| 10:34 |
jeff |
@who thinks that it'll work now? |
| 10:34 |
pinesol_green |
phasefx thinks that it'll work now. |
| 11:08 |
pinesol_green |
gsams: <shaggy>We're, like, doomed.</shaggy> |
| 11:09 |
|
zaimma joined #evergreen |
| 11:09 |
hbrennan |
berick: Ha. Love that. |
| 11:10 |
jeff |
@ana This is a test |
| 11:10 |
pinesol_green |
jeff: Its hastiest |
| 11:10 |
jeff |
@who [ana stole the cookie from the cookie jar]? |
| 11:10 |
pinesol_green |
egbuilder Cheekier of to toothsome lock. |
| 11:19 |
berick |
gmcharlt: aware of any changes to git.evergreen-ils.org? getting publickey / permission denied errors today |
| 11:19 |
eeevil |
kmlussier: everyone hosted by ESI (to be clear) ... we heartily recommend SSD |
| 11:20 |
jeff |
berick: i was just able to fetch security without issue. sure you have the right key loaded? |
| 11:20 |
berick |
jeff: hm, yeah, it must be me. just tested another server. |
| 11:21 |
berick |
@who logged onto my dev server and broke things |
| 11:21 |
pinesol_green |
Bmagic logged onto your dev server and broke things. |
| 11:21 |
bwiens |
lol |
| 11:22 |
jeff |
sitting in the Mutually Assured QA talk and looking at http://www.postgresql.org/docs/9.2/static/runtime-config-logging.html |
| 12:08 |
StephenGWills |
hanging in 'Discovery' Room at Marriot with Dev while Galen asks for a new release mgr. And….. Ben Shum steps up! |
| 12:09 |
kayals |
Hi. Could anyone help why my search in OPAC gives zero result found but I can get results from staff-client |
| 12:09 |
StephenGWills |
version? |
| 12:09 |
kayals |
2.4.6 |
| 12:09 |
kayals |
its a standalone testing server |
| 12:10 |
StephenGWills |
I ran into the recently and found that I had to reinvest my records to get my 901c field updated |
| 12:10 |
StephenGWills |
and then it showed up in both the opac and the staff client. maybe that would help you? |
| 12:11 |
kayals |
thanks |
| 12:14 |
kayals |
make sense |
| 12:16 |
RoganH |
I think while ben is talking we should volunteer him for more tasks, like writing all 2.7 documentation. |
| 12:17 |
tsbere |
irc side-votes? ;) |
| 12:18 |
StephenGWills |
and build the test platform? and QA test scripts? |
| 12:23 |
mrpeters |
tsbere is most likely correct. staff sees all undeleted bibs in search results, patrons only see bibs with items, or e-resource type bibs with proper holdings info in them |
| 12:23 |
tsbere |
mrpeters: Or "trancendant" bibs regardless of all of the rest |
| 12:24 |
mrpeters |
^^ forgot about those suckers |
| 13:53 |
jeffdavis |
heh |
| 13:54 |
gsams |
csharp++ |
| 13:55 |
|
jihpringle joined #evergreen |
| 13:58 |
jeff |
I can't tell if I just broke my charger or if this powerstrip lacks power. |
| 13:58 |
* jeff |
grabs a paperclip and tests |
| 13:58 |
* berick |
plays taps |
| 13:58 |
* bottotr |
doesn't smell smoke |
| 14:00 |
jboyer-laptaupe |
Is someone making bacon in the next room? |
| 15:00 |
dbs |
ah bug fd3703ad |
| 15:00 |
pinesol_green |
[evergreen|Ben Shum] Revert "Eliminate an annoying and useless warning in the JavaScript Console." - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fd3703a> |
| 15:00 |
jeff |
it was a bit too RFC 1178 for my tastes |
| 15:00 |
bshum |
But it is just the usual "marc_export" just substantially faster. At least in my testing. |
| 15:01 |
csharp |
we could rename pinesol_green "marque" |
| 15:01 |
bshum |
I keep meaning to think about dropping the _green part |
| 15:01 |
jeff |
csharp: alas, someone already has that nick registered |
| 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 |
| 12:48 |
_bott_ |
bshum: I've run into both 1 and 2 of your noted issues on my test install. Unfortunately, after a big set of metabib.reingest_record_attributes(), I still have a few that don't get searched, and I can't explain |
| 12:49 |
_bott_ |
...and I agree on the "somehow". The noted function didn't seem to be getting called unless I did so directly. |
| 12:49 |
bshum |
_bott_: What we found is that some of our bibs had weird encodings on them. Like a DVD that was encoded as a laserdisc in OCLC. |
| 12:50 |
_bott_ |
yep, found a few of those too. But I have a couple that seem to "fit", but aren't getting the expected vlist entries |
| 12:50 |
|
Wyuli joined #evergreen |
| 13:35 |
eeevil |
so when we reingest a record's attributes, first we do the controlled, non-composite ones, then the uncontrolled ones (no ccvm entry), then the composite attrs |
| 13:37 |
bshum |
I'm looking for another example book that's missing from our searches to go see what the vlist entries are. |
| 13:37 |
bshum |
And see if it has anything obviously missing |
| 13:37 |
eeevil |
to do the composite attr tests (which can /also/ be multi-valued), we look at the vlist after the controlled non-composite portion is updated (basically the positive numbers in the array) and see which, if any, of the composite attr defs for each composite attribute matches the record's data |
| 13:39 |
bshum |
The query that was suggested previously included reingests on sr_format instead of search_format, so I initially thought that's where things went wrong for me, but doing the reingest for search_format didn't make the record appear in my searches either (reset memcache too, just in case it was just remembering bad results). |
| 13:41 |
bshum |
But now I want to verify that the right coded values are where I expect them to be. Or not. |
| 13:41 |
bshum |
I do know that a full reingest took the vlist from one list of numbers to a much longer list of numbers. |
| 14:00 |
bshum |
That does look different. I will see what that does. |
| 14:00 |
dbwells |
right, without specifying the attrs you want |
| 14:00 |
bshum |
On one bib first |
| 14:01 |
dbwells |
Yes, iterative testing with hour+ waits can be a drag :) |
| 14:02 |
bshum |
Especially when reloading the fresh DB to then re-run all the upgrade scripts for it :) |
| 14:05 |
bshum |
Well, the vlist entries changed slightly doing that on the sample bib |
| 14:05 |
bshum |
Resetting the memcache and trying a fresh search next |
| 14:05 |
dbwells |
bshum: what is the record being tested, at this point? |
| 14:05 |
bshum |
Just one of the many "the help" books that didn't show up in search |
| 14:06 |
bshum |
When I search for it in production I can find 19300 hits, but in the test server, I can only find 9640 hits |
| 14:06 |
bshum |
So I have plenty to choose from |
| 14:06 |
bshum |
If I go direct to the record ID the bib lives, so there is that |
| 14:07 |
dbwells |
bshum: with such nice roundish numbers, are you sure that isn't a superpage setting difference? |
| 14:07 |
bshum |
There might be some. |
| 14:07 |
bshum |
But the book still isn't showing up in search |
| 14:07 |
bshum |
I'm going to do a full reingest now on that bib and seeing what the vlist says next |
| 14:07 |
bshum |
And yes, it is superpage, good call dbwells :D |
| 14:08 |
* bshum |
curses his test server |
| 14:08 |
bshum |
Well, it looks exactly the same. |
| 14:08 |
bshum |
Wth |
| 14:10 |
bshum |
And yet doing the full reingest action makes the bib show up in searches now. |
| 14:10 |
bshum |
The vlist entries didn't change though from what it looked like after doing the non-specific reingest |
| 14:10 |
bshum |
So maybe it's not that preventing the bibs from showing up in search |
| 14:11 |
dbwells |
If we're dealing with different search internal limits, reingesting could cause it to be included just by "chance". |
| 14:12 |
|
mmorgan left #evergreen |
| 14:12 |
dbwells |
The records at the tale will have increasingly similar relevance (in the initial built-in sorting), so you might just be excluding different ones. |
| 14:13 |
bshum |
Or am I misunderstanding what you're suggesting? |
| 14:14 |
dbwells |
Unfortunately, some of the ranking you see happens late in the process. |
| 14:14 |
dbwells |
So if a record doesn't make the first cut, it won't be there, even if further adjustments might have put it at #1. |
| 14:14 |
bshum |
Keyword for "the help stockett" (title + author) and I get 16 hits in production vs. 8 hits in test. |
| 14:16 |
dbwells |
Can you adjust your internal search limits on the test server, or is that out of the question? |
| 14:17 |
dbwells |
but yes, that more specific test should be a better one overall for ruling more things out. |
| 14:17 |
bshum |
I can probably do that. You mean just changing the opensrf.xml settings? |
| 14:17 |
dbwells |
right |
| 14:19 |
bshum |
I can make that the same. Just for parity. |
| 14:29 |
bshum |
Alrighty, tweaked and trying another search test. |
| 14:29 |
|
Wyuli joined #evergreen |
| 14:30 |
bshum |
I'm still not seeing half the books or audiobooks that should have retrieved in the test. |
| 14:31 |
dbwells |
bshum: well, at least the broad search isn't off by 10,000 any more, but yeah, not seeing what we should when adding "stockett" |
| 14:31 |
bshum |
Given that the vlist entries aren't changing between those reingests, I guess maybe it's not whatever we're doing there, but something else that a full reingest does that would cause things to suddenly become findable through search again. |
| 14:32 |
dbwells |
bshum: just to triple check that, can you do this: SELECT metabib.reingest_record_attributes(2895210,NULL::TEXT[],marc,false) |
| 14:37 |
bshum |
Nope. |
| 14:37 |
bshum |
No limits on the search |
| 14:38 |
bshum |
Though limiting on the format doesn't help either cause the bib just doesn't show up |
| 14:38 |
eeevil |
bshum: then attrs are not involved. sorry, I assumed you were testing that |
| 14:38 |
eeevil |
right. your bibs are not properly ingested at this point in some other way |
| 14:38 |
dbwells |
bshum: Should we just start walking through the various tables and see what's missing? |
| 14:38 |
bshum |
dbwells: I guess that's what I should start thinking through. |
| 14:39 |
eeevil |
are there entries for the missing records in metabib.metarecord_source_map? |
| 15:03 |
eeevil |
dbwells: agreed, and upgraders can adjust to their taste if they so desire |
| 15:03 |
_bott_ |
dbwells++ that's what I ended up doing, and other than a few issues I've found, I think it worked well |
| 15:09 |
_bott_ |
I should note. The "few issues" have turned out to be MARC issues, not software issues |
| 15:09 |
bshum |
I think I can agree with that now that this last hurdle is solved. And I'm +1 to doing more reingesting. |
| 15:14 |
bshum |
I have to ask folks to resume testing now. |
| 15:17 |
eeevil |
FWIW, I do see how, previous to 5f03068 and in the face of a disabled ingest.metarecord_mapping.preserve_on_delete flag, bshum's situation could be created and go unnoticed |
| 15:18 |
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> |
| 15:21 |
dbwells |
eeevil: Can you elaborate? |
| 15:34 |
eeevil |
ever, to be exact ;) |
| 15:34 |
dbwells |
:) |
| 15:38 |
dbwells |
It might be time to just let this shake out a bit more. Whatever the circumstances that caused it, they certainly might well not exist any more. |
| 15:39 |
eeevil |
the cause must be local to bshum's test server, then. either some intermediate state, or the forced anti-leakage run (though I can't see how, personally) ... right, what you typed faster ;) |
| 15:42 |
dbwells |
bshum: If you are up for any more inquiry, are you missing metarecord_source_map entries in production? On the other hand, maybe we can look at it together later this week. |
| 15:45 |
bshum |
dbwells: I can take a closer look again in a bit. Or yeah, there's always some time soon enough. |
| 15:45 |
bshum |
It's certainly possible it's some weird intermediate step on my end. I really want to blow the whole thing away and try again now :) |
| 18:10 |
phasefx |
hrmm, we don't have an obvious link to Launchpad from the website do we? ah, found it, Community Links at the bottom. and on the downloads page |
| 18:13 |
bshum |
I think in the old days, it used to be in one of the sidebars too. For the PHP site, pre-wordpress. |
| 18:14 |
bshum |
If you have suggestions on making that more visible somehow, I'd be happy to help point you in the direction of the wordpress login page, phasefx :) |
| 18:23 |
phasefx |
mulling it over :) |
| 18:45 |
phasefx |
bshum: do we have a dev version of the site where we can test ideas, etc? |
| 18:55 |
kmlussier |
phasefx: I don't think we do. We like to live on the wild side. |
| 18:55 |
phasefx |
roger that :) |
| 19:39 |
bshum |
phasefx: Yeah kmlussier is right about the wild side. Long term I'd like to see looking at our hosting infrastructure to see what might be possible. I think poor lupin could use some retasking certain functions. |
| 21:16 |
jeff |
kmlussier: indeed i am in Cambridge. Flew in this evening. |
| 21:17 |
phasefx |
maybe I needed to have followed the advice in 0855 about re-running example.reporter-extension.sql |
| 21:17 |
bshum |
phasefx: I just committed a fix for 0864 last night. |
| 21:18 |
phasefx |
bshum: roger doger |
| 21:19 |
phasefx |
now for smoke testing :) |
| 21:20 |
|
bbqben joined #evergreen |
| 21:20 |
* phasefx |
chokes on smoke; probably something else wrong he did |
| 21:23 |
phasefx |
yay, all working |
| 21:27 |
bshum |
Whee, cool. |
| 21:37 |
eeevil |
phasefx: remember to reinjest :) |
| 21:37 |
phasefx |
is that needed when going from 2.5.3 to 2.6-beta1? |
| 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 |
| 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! |
