| 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 |
| 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: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. :-) |
