| 00:08 |
bshum |
We haven't finished the juggling for all that yet... |
| 00:09 |
* bshum |
strongly wants to see https://bugs.launchpad.net/opensrf/+bug/1579219 merged for OpenSRF 2.5.0 and also for Evergreen 2.12 then. |
| 00:09 |
pinesol_green |
Launchpad bug 1579219 in OpenSRF "don't require mod_perl as an OpenSRF dependency" [Wishlist,Triaged] |
| 00:09 |
* bshum |
updates targets accordingly |
| 00:09 |
bshum |
Well, for Evergreen. Looks like we don't have an OpenSRF 2.5.0 final yet. |
| 00:09 |
bshum |
For bug milestone |
| 00:12 |
bshum |
Guess I haven't built on Ubuntu 14.04 in awhile. I totally forgot about mod_perl oddness till now. |
| 00:13 |
bshum |
And huzzah, working Ubuntu 14.04 with PG 9.4 and OpenSRF master and Evergreen master (with the working branch changes) |
| 00:13 |
bshum |
Whee |
| 00:13 |
bshum |
Tests pass, and webclient functions. Good enough. |
| 00:15 |
* bshum |
starts Fedora 25 download and goes to bed |
| 04:28 |
|
NawJo joined #evergreen |
| 05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:21 |
|
rjackson_isl joined #evergreen |
| 07:25 |
|
agoben joined #evergreen |
| 08:00 |
|
remingtron_ joined #evergreen |
| 10:34 |
* dbs |
sees mention of PostgreSQL 9.1 in Evergreen README in master, ugh |
| 10:34 |
bshum |
dbs: Yeah, we're working on changing all that |
| 10:35 |
dbs |
bshum: right, I saw the discussion yesterday, but seeing the minimum of 9.3 and then "but Trusty comes with 9.1 so you're all good" a few paragraphs later o.0 |
| 10:35 |
pinesol_green |
[opensrf|Dan Scott] Remove Fedora as a well-tested target - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=b397106> |
| 10:36 |
dbs |
okay, I'll limit my edits to just getting rid of Fedora mentions and leave the postgresql-related updates to someone else |
| 10:39 |
bshum |
dbs: Fwiw, I started updates for that language in the collab for PG 9.4 support |
| 10:39 |
Dyrcona |
Trusty comes with 9.3. |
| 10:39 |
bshum |
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/bshum/PG94-testing has the latest |
| 10:40 |
Dyrcona |
I think that was a typo. :) |
| 10:40 |
Dyrcona |
I'm testing that branch with Trusty, now. |
| 10:41 |
Dyrcona |
We have it so 9.4 gets installed automagically from apt.postgresql.org. |
| 10:45 |
pinesol_green |
[evergreen|Dan Scott] Remove Fedora from install documentation - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9389188> |
| 10:46 |
miker |
berick / csharp: and to stick a fork in it, yes, the old targetter would move the hold to a new target upon (prev_check_time-exceeded) retargetting. line ~1390 of Storage/Publisher/action.pm ... |
| 11:24 |
|
brahmina joined #evergreen |
| 11:29 |
Bmagic |
berick: but yeah, we are running that branch in production. Why do you ask? |
| 11:30 |
berick |
csharp: ^-- |
| 11:30 |
csharp |
Bmagic: I asked :-) - because I'd love to see some payment/billing linkages |
| 11:30 |
csharp |
I'll add that to my testing for 2.12 once we get it running on our staging servers |
| 11:31 |
Bmagic |
so far so good. Our libraries seem to enjoy it |
| 11:31 |
csharp |
I bet |
| 11:32 |
Bmagic |
count(csharp) == count(berick) = glance cross confuse, lol |
| 16:27 |
Dyrcona |
Thanks, anyway. |
| 16:29 |
Dyrcona |
Oh, wait! Copying mine down and doing a diff shows that I'm looking for is there! |
| 16:30 |
Dyrcona |
And, it looks like I didn't copy berick's stuff correctly, possibly. |
| 16:30 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 16:30 |
kmlussier |
uh oh |
| 16:31 |
bshum |
Ho hum |
| 16:32 |
bshum |
Guess lsb-release isn't on the test server |
| 16:32 |
kmlussier |
The new Postgres stuff? |
| 16:33 |
bshum |
kmlussier: Yeah, it's dying on the first try to use lsb-release to detect what linux distro the server is running |
| 16:33 |
bshum |
The command isn't found, so that tool isn't installed |
| 16:33 |
kmlussier |
Well, I guess it wouldn't be Bug Squashing week if we didn't have a failed test or two. |
| 16:34 |
kmlussier |
or three or four |
| 16:36 |
Dyrcona |
Hah! |
| 16:36 |
Dyrcona |
I had the right version. I copied it to the wrong place in a rush last week. |
| 16:39 |
Dyrcona |
jeffdavis++ # one more time. If I hadn't looked at your branch, this would have taken me longer to figure out. |
| 16:42 |
Dyrcona |
Might not be in the user's path. |
| 16:42 |
Dyrcona |
Or, yeah, options changed. |
| 16:42 |
Dyrcona |
I hate when they do that. |
| 16:42 |
Dyrcona |
What does the test server run? |
| 16:43 |
bshum |
It's Debian Wheezy |
| 16:43 |
bshum |
I think |
| 16:43 |
bshum |
phasefx would know best |
| 16:44 |
phasefx |
it's wheezy |
| 16:44 |
bshum |
But yeah, it's choking on checking for the lsb_release command and that's passing an empty value to the pgdg apt source, and that results in a 404 error and boom, the rest dies |
| 16:45 |
bshum |
On my debian wheezy test vm, running "lsb_release -cs" gives me "wheezy" in reply, so I'm not sure |
| 16:45 |
Dyrcona |
Same here. |
| 16:45 |
Dyrcona |
Tests could be running in a chroot with limited utilities available. |
| 16:46 |
phasefx |
lsb_release not found |
| 16:47 |
Dyrcona |
phasefx: Is there a chroot? |
| 16:48 |
phasefx |
Dyrcona: yes, coming from package coreutils |
| 16:48 |
Bmagic |
because I gotta be honest, I am a Michael Bolton fan. For my money it doesnt get better than when he sings..... |
| 16:48 |
Dyrcona |
I mean are tests run in a chroot. |
| 16:49 |
phasefx |
Dyrcona: oh, no |
| 16:49 |
phasefx |
apt-get update is failing on that machine too |
| 16:49 |
phasefx |
Err http://apt.postgresql.org -pgdg/main amd64 Packages |
| 03:58 |
|
NawJo joined #evergreen |
| 04:20 |
|
NawJo joined #evergreen |
| 05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 05:52 |
|
genpaku joined #evergreen |
| 06:20 |
|
genpaku joined #evergreen |
| 07:14 |
|
kmlussier joined #evergreen |
| 07:16 |
|
rjackson_isl joined #evergreen |
| 07:22 |
|
agoben joined #evergreen |
| 07:46 |
pinesol_green |
[evergreen|Galen Charlton] LP#1517596: add missing template file for webstaff patron merge - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=512dd0c> |
| 08:41 |
|
abowling1 joined #evergreen |
| 08:45 |
|
mmorgan joined #evergreen |
| 08:54 |
|
genpaku joined #evergreen |
| 10:06 |
rjackson_isl |
it was good for visiting the local eagle's nest Sunday AM with the frozen temps (mud was also frozen for the hike) |
| 10:09 |
pinesol_green |
[evergreen|Jeff Davis] LP#1668816: Prevent Internal Server Error in OPAC when logged-in user has no card - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d2ff144> |
| 10:12 |
|
abowling joined #evergreen |
| 10:46 |
terran |
FYI, bug squashing is going great this week: https://docs.google.com/spreadsheets/d/1RPR5gIL02EiIvsg5vDKLs40rgw0Daqy4_TRWPlqU0WY/edit?usp=sharing |
| 10:46 |
terran |
bugtesters++ |
| 10:47 |
terran |
The bottom-right list on that spreadsheet has new or updated patches that are ready to test |
| 10:49 |
kmlussier |
I would like to load remingtron's new patch on mlnc3, but I don't know when I'll get to it. |
| 10:51 |
pinesol_green |
[opensrf|Bill Erickson] LP#1667091 Remove non-SSL websockets sample configs - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=2fc52cf> |
| 10:52 |
gmcharlt |
now cutting the OpenSRF 2.5 RC |
| 12:13 |
Dyrcona |
@quote get 5 |
| 12:13 |
pinesol_green |
Dyrcona: Quote #5: "<senator> the armenian regression sounds like a spy novel" (added by bshum at 03:44 PM, February 22, 2011) |
| 12:13 |
Dyrcona |
heh. that was a real bug. |
| 12:13 |
dbs |
Bmagic: iirc some of the inputs might not work as expected for things like money or date/time values -- you'll want to test those |
| 12:14 |
Bmagic |
good to know |
| 12:14 |
Bmagic |
good thing this experiment was for bug squashing week :) |
| 12:20 |
|
jihpringle joined #evergreen |
| 13:26 |
|
rlefaive joined #evergreen |
| 13:28 |
jeff |
apparently despite their interface's calendar coloring the days as "available", Friday is not actually available at the conference hotel. |
| 13:52 |
|
maryj joined #evergreen |
| 14:09 |
* dbs |
offers up bug 1584891 as low-hanging i18n-friendly fruit for testing |
| 14:09 |
pinesol_green |
Launchpad bug 1584891 in Evergreen "marc_export -i gives incorrect record length in the leader when call numbers include UTF8 characters" [Undecided,Confirmed] https://launchpad.net/bugs/1584891 |
| 14:13 |
Dyrcona |
UTF-8 in call numbers... I've seen it. All I can say is, "Yuck." |
| 14:14 |
terran |
jeff: apparently we hit the contract numbers for the Friday room block, but we are trying to get more - you might want to contact joe gtownlibrary.net for followup |
| 15:09 |
* gmcharlt |
commissions a recipe ;) |
| 15:10 |
gmcharlt |
if we want to go with a compressed agenda, I have a suggestion |
| 15:10 |
berick |
#info berick Bill Erickson |
| 15:10 |
gmcharlt |
namely, what are the top priorities for testing for the upcoming releases? |
| 15:12 |
kmlussier |
OK, well the agenda is fairly short as it is, so let's note that the one action item is deferred and move on to updates where we can talk about testing for 2.12. |
| 15:12 |
gmcharlt |
#link https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2017-03-01#new_business |
| 15:12 |
kmlussier |
Thanks, I was just about to do that! It's been a while since I took the meeting controls. |
| 15:12 |
kmlussier |
#topic Action items from last meeting |
| 15:13 |
kmlussier |
I should have a little more time on my hands in a couple of weeks. |
| 15:13 |
kmlussier |
#topic OpenSRF 2.5 updates |
| 15:14 |
kmlussier |
gmcharlt? |
| 15:14 |
gmcharlt |
#info OpenSRF 2.5.0-rc released today |
| 15:14 |
gmcharlt |
#info OpenSRF 2.5.0 will be released on 14 March |
| 15:14 |
gmcharlt |
#info Testing requested, in particular for installation issues on supported platforms |
| 15:14 |
gmcharlt |
and that's it, unless there are questions. |
| 15:16 |
kmlussier |
Any questions for gmcharlt? |
| 15:16 |
* gmcharlt |
answers in advance: 42 |
| 15:16 |
kmlussier |
:) |
| 15:17 |
kmlussier |
#topic Evergreen 2.12 updates |
| 15:17 |
kmlussier |
#info 2.12 beta was released last week |
| 15:18 |
kmlussier |
Thanks to everyone who helped get the release out and to those who helped with the issues with the automated tests. |
| 15:18 |
kmlussier |
We're getting a lot of bug fixing activity done this week with Bug Squashing Week. |
| 15:18 |
kmlussier |
terran++ |
| 15:20 |
kmlussier |
One thing I would like to do for the end of bug squashing week is to see if there are any volunteers in the community who might want to go through some of the use cases we have on the wiki just to make sure the release is in good shape. |
| 15:20 |
kmlussier |
I think I tried something similar for the 2.10 release without much luck, but maybe we'll get some takers. |
| 15:21 |
kmlussier |
I do have a question regarding translations. Eva had contacted me a while ago to see if we might be able to do the translation dance again at the .1 release to give translators more time to get their translations in. |
| 15:21 |
kmlussier |
Is that something that would be doable? |
| 15:22 |
bshum |
kmlussier: As long as we don't merge any new string changes or run any POT updates for the templates, then the PO files won't drift any further than what's in Launchpad |
| 15:22 |
bshum |
So that is doable, until we start merging new features or syncing the templates again |
| 15:23 |
bshum |
Or like how gmcharlt and others fixed some typos in the git branch and touched the change in all the templates too |
| 16:11 |
Dyrcona |
On the Pg 9.3 front on wheezy, we get the apt.postgresql.org repo to add easily, but libdbi won't build with libpq-dev from the community repo. |
| 16:11 |
Dyrcona |
That's as far as I got before climbing up the ladder. |
| 16:12 |
Dyrcona |
I have not had this problem on the production vms I've made with wheezy, but then, I've stuck with the 9.1 client from Debian. |
| 16:14 |
Dyrcona |
I *think* bshum and I are both using working/collab/dyrcona/wheezy-pg93-testing which is based on working/user/bshum/wheezy-pg93-testing which he said has stuff he lifted from csharp. :) |
| 16:16 |
Dyrcona |
The error, for anyone still paying attention, is configure: error: Invalid PostgreSQL directory - libraries not found. |
| 16:17 |
csharp |
hmm |
| 16:19 |
csharp |
so why still on wheezy? (not judging, just askin' ;-) ) |
| 16:56 |
berick |
csharp: ok, the only time it should target somewhere else when there is a copy at the pickup library, is if there is only 1 copy at the pickup library and that copy is currently targeted, so a new copy is selected (from the next "closest" location) |
| 16:57 |
berick |
csharp: anyway, yeah, keep me posted |
| 17:00 |
csharp |
berick: thanks for the pointers! |
| 17:02 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:02 |
kmlussier |
csharp / berick: Is it a case where the opportunistic capture happens before the person in library A has a chance to pull it off the shelf? Do you have holds stalling in place? |
| 17:03 |
kmlussier |
Oh, I think berick was already suggesting that above. :) |
| 17:03 |
csharp |
kmlussier: we have 5 days of stalling in place, but I'm sure it's not that - our staff is pretty savvy about that feature |
| 17:04 |
csharp |
at least I can say that about the 2 staff that independently reported the issue :-) |
| 17:04 |
kmlussier |
OK, then, so it shouldn't be an opportunistic capture. |
| 17:04 |
* kmlussier |
tried out a bunch of different use cases with the new holds targeter, but did not test out holds stalling. |
| 17:06 |
csharp |
I figured we were good after a month and a half, but you can trust PINES libraries to find every single corner case :-) |
| 17:07 |
|
mmorgan left #evergreen |
| 17:09 |
* kmlussier |
never knows what status to give a bug that was addressed through one of the big web client merges. |
| 18:51 |
Dyrcona |
And, Pg 9.4 server installs nicely. So, I'm signing out. |
| 19:28 |
jeff |
Dyrcona++ |
| 19:47 |
|
Jillianne joined #evergreen |
| 21:23 |
bshum |
@later tell Dyrcona Saw the branch work for PG 9.4, looks great. I'll test the latest on fresh Wheezy and also apply changes for Trusty too. See: https://bugs.launchpad.net/evergreen/+bug/1493824 |
| 21:23 |
pinesol_green |
bshum: The operation succeeded. |
| 21:23 |
pinesol_green |
Launchpad bug 1493824 in Evergreen "Evergreen/PostgreSQL 9.4 support" [Wishlist,Triaged] |
| 21:26 |
bshum |
Dyrcona++ |
| 04:57 |
|
gk-1wm-su joined #evergreen |
| 05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:10 |
|
rjackson_isl joined #evergreen |
| 07:31 |
|
agoben joined #evergreen |
| 07:33 |
|
kmlussier joined #evergreen |
| 11:31 |
|
khuckins joined #evergreen |
| 11:46 |
bshum |
Hmmmm, https://github.com/phhusson/quassel-irssi |
| 11:49 |
Stompro |
When changing the bib source on a title, is a reingest needed for visibility changes to be seen, or is it a memcache results cache of some sort that I need to wait to time out? |
| 11:51 |
berick |
Stompro: catalog searches are temporarily cached |
| 11:51 |
berick |
you can bypass the cache with minor search tweaks, though, to test |
| 11:51 |
berick |
like foo -zzzzzz |
| 11:54 |
Stompro |
berick, thanks. |
| 12:02 |
|
brahmina joined #evergreen |
| 12:10 |
|
mmorgan joined #evergreen |
| 16:46 |
bshum |
The fun part for the committer is making sure that if they add your code with id 54 let's say, that we don't accidentally merge someone else's code where they also decide to use 54, etc. |
| 16:46 |
bshum |
If there were multiple people touching it at the same time |
| 16:46 |
terran |
exactly |
| 16:46 |
kmlussier |
That's why we should test the upgrade scripts before we merge. |
| 16:46 |
bshum |
First come, first serve. Next person has to update and rebase. |
| 16:47 |
bshum |
But this is all new stuff for 2.next / 3.0 right? :D |
| 16:47 |
bshum |
So we got time to figure it out too |
| 16:49 |
bshum |
Just one of those, oh by the way, watch out for this in your upgrade experience |
| 16:49 |
bshum |
aka, write a good release note about it |
| 16:49 |
terran |
I shall do my best |
| 16:49 |
bshum |
And maybe put some -- comments in your upgrade script about it |
| 16:49 |
bshum |
So that if/when we merge it for testing, we can put it in hopefully safer places |
| 16:49 |
terran |
good idea |
| 16:51 |
bshum |
Maybe someday when we're on PG 9.5 for more folk, we can use https://wiki.postgresql.org/wiki/UPSERT |
| 16:51 |
bshum |
Or we could probably do some smarter upgrade scripting to think through the problem too... hmm |
| 16:57 |
Bmagic |
I got the xul staff client recompiled from these instructions https://wiki.evergreen-ils.org/doku.php?id=backend-devel:i18n |
| 16:59 |
Bmagic |
but now, on the login box, I can choose my new language, I click "apply locale" and I get xml parsing error: chrome://open_ils_staff_client/content/main/main.xul. Line 21, <window id="main_win" |
| 16:59 |
Bmagic |
XML Parsing Error: undefined entity |
| 17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:03 |
bshum |
Bmagic: Just a guess based on some old threads, but maybe try a fresh profile |
| 17:03 |
bshum |
http://markmail.org/message/vatzumzzq74w3uay |
| 17:03 |
Bmagic |
ah, I'll try a fresh one |
| 00:35 |
|
boson joined #evergreen |
| 03:29 |
|
Jillianne joined #evergreen |
| 05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:13 |
|
rjackson_isl joined #evergreen |
| 07:30 |
|
agoben joined #evergreen |
| 08:17 |
* csharp |
wonders how many other gmail users end up on the Italian Linux Society's website when clicking git.evergreen-ils.org links that break across mulitple lines |
| 08:30 |
jeff |
it's a combination of Launchpad breaking the URL across multiple lines, and some mail clients (including gmail) turning url-looking strings in text messages into links. |
| 08:31 |
csharp |
ah - that makes sense |
| 08:32 |
jeff |
so the first part of the url gets linked beause it starts with http://, and the second part gets linked presumably because it starts with a domain-looking string and in all other ways looks like a url where someone didn't include the leading "http://" |
| 08:38 |
JBoyer |
miker, good call on the TT fixes on lp 1274999, but now I'm stuck on something else; the Next link isn't appearing anymore. I tested this thing multiple times (it was annoying looking for titles with exactly 10 copies, etc...) can you see anything obviously wrong? |
| 08:38 |
pinesol_green |
Launchpad bug 1274999 in Evergreen "Next 10 Link erroneously available at the end of holdings in OPAC, intermittent " [Undecided,Confirmed] https://launchpad.net/bugs/1274999 |
| 08:39 |
JBoyer |
Or anyone else that would like to poke at templates! Feel free to tell me how I've err'd, because this is maddening. :/ |
| 08:40 |
|
mmorgan joined #evergreen |
| 08:42 |
JBoyer |
D: The worst! Works as expected on a migration server, falls over on dev and production. Sparta? This is madness! |
| 08:44 |
csharp |
JBoyer: is there a good concerto record to test on? |
| 08:45 |
csharp |
nevermind - I found one |
| 08:46 |
JBoyer |
You need a couple, one with exactly copy_limit (usually 10) copies, and one with more than that |
| 08:48 |
Stompro |
jeffdavis, is the Sitka new items carousel for wordpress plugin available for others to use? |
| 08:52 |
csharp |
JBoyer: with miker's branch I'm not seeing the "Next X" link either, if that helps |
| 08:55 |
JBoyer |
csharp, miker, even with my branch they're not working correctly on 2/3 servers here. For instance: http://evergreen.lib.in.us/eg/opac/record/8205944 has no link, but 15 copies. Put mig. in from of evergreen and it does work. :( |
| 08:55 |
csharp |
actually, I'm not seeing it with your branch either |
| 08:55 |
JBoyer |
Same changes! |
| 08:55 |
csharp |
yeah - I can confirm that behavior on my master test server |
| 08:56 |
csharp |
if I revert both commits, it works |
| 08:56 |
JBoyer |
Well, "works," that's where you need a record with total copies == copy_limit. |
| 08:57 |
csharp |
well, I mean that the link reappears |
| 09:00 |
JBoyer |
Well that's embarrassing... The mig server where I monkey patched this to test has ctx.copy_offset + ctx.copy_limit < total_copies, but my patch has ctx.copy_offset + ctx.copy_limit > total_copies which is completely backward... |
| 09:00 |
JBoyer |
csharp++ for looking. |
| 09:01 |
* JBoyer |
goes to fix the branch, and our servers. |
| 09:02 |
csharp |
JBoyer: happy to help! |
| 09:05 |
miker |
JBoyer: sorry for not testing the branch, I just wanted to clean up the syntax. feel free to squash my commit into yours if you keep it |
| 09:06 |
JBoyer |
I'm definitely making your changes also. And it's evident *I* didn't fully test the branch either, so no harm there. :/ |
| 09:07 |
JBoyer |
I'll probably force update my branch to have a single commit that matches your changes (AND work), but if you'd like to sign off on it after that that would be great. |
| 09:21 |
|
yboston joined #evergreen |
| 09:28 |
|
kmlussier joined #evergreen |
| 13:19 |
mmorgan |
I do know about that "Request Item" function, and that it does not set notifications. AFAIK, these holds were not placed that way. |
| 13:29 |
rjackson_isl |
There is still an open bug where SMS carrier can be left blank and have Hold Notification Format set to SMS with a Defalt SMS/Text Number entered - bug 1098685 |
| 13:29 |
pinesol_green |
Launchpad bug 1098685 in Evergreen "User can select SMS notify without providing a valid address" [Undecided,Confirmed] https://launchpad.net/bugs/1098685 |
| 14:16 |
bshum |
well, for giggles, Debian Stretch (9.0) testing has not yielded a working OpenSRF. It blows up with the libraries and can't find the stuff to start up opensrf.math or dbmath processes. So I guess that's changed somewhere, somehow. |
| 14:20 |
bshum |
On the plus side, the ejabberd 16.x stuff we wrote for Xenial seemed to work, along with the basic packages from xenial too for defining what to install. |
| 14:47 |
Stompro |
rjackson_isl, I hate that bug. |
| 15:16 |
|
bmills joined #evergreen |
| 16:08 |
kmlussier |
@dessert [someone] |
| 16:42 |
|
dkyle1 joined #evergreen |
| 16:43 |
|
_bott_1 joined #evergreen |
| 16:53 |
|
Jillianne joined #evergreen |
| 17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:05 |
|
mmorgan left #evergreen |
| 17:05 |
Bmagic |
I just received a feature request where the staff would like to be able to place a copy level hold on a copy from the item status screen. Any thoughts on that idea? |
| 17:29 |
Stompro |
Bmagic, I think you can already do that, right click -> request item. |
| 00:34 |
|
eady joined #evergreen |
| 04:42 |
|
Guest25107 joined #evergreen |
| 05:00 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 06:56 |
|
kmlussier joined #evergreen |
| 07:01 |
kmlussier |
Good morning #evergreen! |
| 07:01 |
kmlussier |
@coffee [someone] |
| 10:27 |
pinesol_green |
[evergreen|Galen Charlton] LP#1666933: note that the minimum supported Pg version is 9.3 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=215bb67> |
| 10:39 |
pinesol_green |
[evergreen|Kathy Lussier] Docs: Some corrections to hatch information in 2.12 release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1a631f8> |
| 10:44 |
berick |
kmlussier: hatch doc changes look good |
| 10:44 |
bshum |
"Evergreen 2.8 has been tested on..." (it's said 2.8 since forever. Should we just make it just say "Evergreen" and omit the specific version number?) |
| 10:44 |
bshum |
In the README for Linux distro support |
| 10:44 |
kmlussier |
Well, I can say with confidence that 2.8 has been tested on all those distros. |
| 10:45 |
kmlussier |
2.12? Not so sure. |
| 10:45 |
bshum |
Fair... but kind of meaningless in all these current README docs |
| 10:45 |
bshum |
For newer versions anyways |
| 10:45 |
bshum |
So maybe it shouldn't say that either |
| 10:48 |
kmlussier |
Sounds good to me |
| 10:48 |
Bmagic |
Anyone created a report that shows an "average age" of groups of items, on a shelf for example? |
| 10:49 |
csharp |
Bmagic: interesting that you bring that up because we had a similar request this week (it was for a meeting that passed before I got to it, though, so I didn't create it) |
| 10:49 |
gmcharlt |
Pg t/ tests pass on both newly seeded and upgraded-from-2.11.3 databases |
| 10:49 |
csharp |
our request was "what is the average life of audiobooks in PINES" |
| 10:49 |
Bmagic |
csharp: I am working on it, but I don't think its possible with the report engine |
| 10:50 |
csharp |
it might be view-worthy |
| 10:52 |
bshum |
csharp: I'll take that approach in mind as I toy with wording (and other stuff) in the README. I'm getting ISOs for Wheezy, Jessie, and the new thing (Stretch) to try some stuff out |
| 10:53 |
bshum |
With Stretch frozen, I figure it's time to play with Debian 9.0 and start finding out what fun adventures await... |
| 10:54 |
gmcharlt |
OK, active pull request for bug 1666928 for review ASAP, please |
| 10:54 |
pinesol_green |
Launchpad bug 1666928 in Evergreen "Build tests are failing for Overdrive and OneClickdigital modules" [Low,Confirmed] https://launchpad.net/bugs/1666928 |
| 10:54 |
gmcharlt |
or rather, would be if Launchpad DID NOT KEEP TIMING OUT |
| 10:54 |
gmcharlt |
so, I'd like to request review and merge of user/gmcharlt/lp1666928_deal_with_failing_tests |
| 11:03 |
kmlussier |
gmcharlt: works for me. I'll merge it in a sec |
| 11:05 |
|
mmorgan joined #evergreen |
| 11:05 |
berick |
not an issue for Hatch, but certainly put pressure on localStorage for non-hatch users |
| 11:07 |
kmlussier |
gmcharlt: done |
| 11:08 |
pinesol_green |
[evergreen|Galen Charlton] LP#1666928: fix build tests for ebook API Perl modules - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8dce9e6> |
| 11:25 |
|
khuckins_ joined #evergreen |
| 11:35 |
jeffdavis |
bah, thanks for that fix gmcharlt |
| 11:36 |
gmcharlt |
jeffdavis: you're weclome! |
| 11:38 |
dbs |
gmcharlt: nice find on relator maps, id.loc.gov would be a good way to go. |
| 11:39 |
* dbs |
throws bug 1584891 onto the heap, but it should have a test :/ |
| 11:39 |
pinesol_green |
Launchpad bug 1584891 in Evergreen "marc_export -i gives incorrect record length in the leader when call numbers include UTF8 characters" [Undecided,Confirmed] https://launchpad.net/bugs/1584891 |
| 11:57 |
|
sandbergja joined #evergreen |
| 12:06 |
* dbs |
is pretty sure he fixed that problem last year but can't find the bug or branch so... |
| 15:44 |
kmlussier |
Would be nice if the only known web client issue was that surveys are inaccessible from the patron account. |
| 15:44 |
berick |
you don't /have/ to update it ;) |
| 15:45 |
tsbere |
kmlussier: Define all other web client issues as "features" and hope nobody notices? ;) |
| 15:45 |
kmlussier |
heh |
| 15:46 |
kmlussier |
We might get more libraries willing to test it in production. |
| 15:48 |
* kmlussier |
starts to write 'the ability to delete patrons via the web client is missing.' Quickly corrects it to say 'the ability to delete patron accounts...' |
| 15:48 |
|
khuckins__ joined #evergreen |
| 15:49 |
mmorgan |
Heh. That former might be pretty popular... |
| 15:49 |
kmlussier |
bug 1517595 |
| 16:50 |
csharp |
gmcharlt++ # ha! |
| 16:54 |
* kmlussier |
thinks bug 1437106 has been resolved, but hasn't tried keyboard shortcuts in the web client in months. |
| 16:54 |
pinesol_green |
Launchpad bug 1437106 in Evergreen "keyboard shortcuts in the web staff client" [Undecided,Confirmed] https://launchpad.net/bugs/1437106 |
| 16:54 |
kmlussier |
It might be a good thing for somebody tot test during Bug Squashing week to see if it's still an issue. |
| 16:55 |
berick |
Stompro++ # bug 1667115 -- I keep meaning to do something about that.. |
| 16:55 |
pinesol_green |
Launchpad bug 1667115 in Evergreen "Log Noise - retrieve config.hard_due_date called with no ID..." [Undecided,New] https://launchpad.net/bugs/1667115 |
| 17:00 |
kmlussier |
berick: bug 1472316 was covered by the Hatch Omnibus bug, right? |
| 17:00 |
pinesol_green |
Launchpad bug 1472316 in Evergreen "Enabling/Disabling Hatch in browser client causes loss of settings" [Undecided,New] https://launchpad.net/bugs/1472316 |
| 17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:02 |
berick |
kmlussier: yeah, i'd say so. the "copy settings to hatch" and "copy settings to local storage" actions provide a manual solution to the problem. |
| 17:02 |
berick |
we may eventually want to automate that, but it's at least work-around-able now |
| 17:02 |
kmlussier |
Hooray for successful tests! |
| 17:05 |
mmorgan |
Yay!! |
| 17:06 |
gmcharlt |
berick: heh, although "copy settings to Evergreen server" also looks attractive :) |
| 17:06 |
gmcharlt |
though just for actual workstatino settings, not cases like the tag table where we're just using local storage as a fast cache |
| 01:32 |
|
Jillianne joined #evergreen |
| 05:00 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 07:12 |
|
rjackson_isl joined #evergreen |
| 07:29 |
|
agoben joined #evergreen |
| 07:29 |
|
Dyrcona joined #evergreen |
| 07:42 |
csharp |
c0c60f45 |
| 07:42 |
pinesol_green |
csharp: [evergreen|erickson] use the event def template for the bill note (thanks, miker) instead of using a param. Created a system billing type of Notification Fee, also so none is needed via event param. Added first billing type const (yay). - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c0c60f4> |
| 08:43 |
|
mmorgan joined #evergreen |
| 08:47 |
rhamby |
there's a strange moment when you're going through the stock test data and find a Goodread review you wrote in a 520 tag of a bib |
| 08:57 |
Dyrcona |
Callender_++ gmcharlt++ # They know why. :) |
| 08:57 |
Dyrcona |
rhamby++ # That's funky. :) |
| 08:58 |
* Dyrcona |
is about to let staff back into the client... |
| 09:33 |
|
kmlussier joined #evergreen |
| 09:35 |
kmlussier |
Good morning #evergreen! |
| 09:38 |
mmorgan |
kmlussier: Good Morning! |
| 09:39 |
kmlussier |
bshum and I spent a bit of time last night looking into perl live test failures resulting from new records added to the test dataset. |
| 09:40 |
kmlussier |
bshum has a branch he posted at https://bugs.launchpad.net/evergreen/+bug/1541559/comments/19 that addresses the current perl live test failures that came from the new ebook records, but doesn't address the PgTAP test that had previously been failing. |
| 09:40 |
pinesol_green |
Launchpad bug 1541559 in Evergreen "OneClickdigital API integration" [Wishlist,Fix committed] |
| 09:41 |
kmlussier |
I'm wondering if anyone has other ideas for loading new records to the dataset so that it doesn't move copy numbers around in a way that breaks our tests. I'm not sure bshum's branch is the best long-term solution. |
| 09:52 |
tsbere |
kmlussier: I have ideas....that may not work at all for what I am assuming the problem may be. :/ |
| 09:55 |
* tsbere |
isn't actually 100% positive what the issue is |
| 09:55 |
kmlussier |
tsbere: Well, I'm hoping for a long-term solution that might allow us to add bib records to the test data in a way that puts them to the back in the line so that they don't disrupt the ids for the existing test records. |
| 09:56 |
kmlussier |
tsbere: The issue is that when we add new bib records to the test dataset, it shifts the copy ids around in such a way that the tests are no longer pointing to the correct data. |
| 09:56 |
kmlussier |
I don't know that the ideal, long-term solution is something we can put in place for today's beta release. |
| 09:57 |
bshum |
tsbere: http://testing.evergreen-ils.org/~live/test.24.html <-- it shows up here in the recent live test runs. Test 2 dies, so does 3, 4, 9 (yikes neg balances), and 14. |
| 09:57 |
bshum |
Due to the shifted copies as kmlussier says |
| 09:57 |
* tsbere |
takes a quick look at things and throws his previous ideas out the window |
| 10:00 |
kmlussier |
@coffee |
| 10:00 |
* pinesol_green |
brews and pours a cup of Panama Gesha 2011, and sends it sliding down the bar to kmlussier |
| 10:03 |
tsbere |
I have another idea, but I want to check something first before I elaborate |
| 10:08 |
dbs |
hmm, I'm not surprised checking for a specific database ID (like in 02_simple_circ.t) isn't robust. bshum's approach is expedient, but we should pursue a better longer-term fix post-beta? |
| 10:10 |
tsbere |
I actually wonder why the extra bibs being moved further down is fixing things. Or is this a "the call numbers got moved around due to located URIs" issue? |
| 10:10 |
bshum |
dbs: I've been wondering if we shouldn't consider either adapting the test data to always create specific copies that are intended for passing the tests properly, and leave the rest random, or if we need to make the whole thing less randomly generated to begin with. and do X bibs random, Y bibs more specifically, and Z bibs exactly one way |
| 10:10 |
dbs |
tsbere: it's how we create copies |
| 10:11 |
dbs |
tsbere: when we had one set of bib records, it was easy enough to say "Create a batch of call numbers, and then a batch of copies, based on this set of MARC" |
| 10:11 |
bshum |
but then I worry about curbing the helpfulness of the tests |
| 10:11 |
JBoyer |
I don't actually see any benefit to the random generation and think that a fully hard coded test set would make things a lot simpler in the long run. (Especially in those instances where someone resets a server every day, say, and goes to some lengths to make sure everything ends up the same... ;) ) |
| 10:12 |
dbs |
bshum: well, looking at 02-simple_circ.t, I'm not convinced it's a great test either |
| 10:12 |
bshum |
dbs: That too crossed my mind :) |
| 10:12 |
JBoyer |
Then ids in failed tests also become a lot more useful. |
| 10:12 |
dbs |
JBoyer: here's the thing, the call numbers and barcodes are already unique |
| 10:13 |
dbs |
so using the database IDs in the tests is probably not a great practice |
| 10:13 |
dbs |
JBoyer: they're not randomly generated, they have a very specific pattern |
| 10:13 |
JBoyer |
That's also true. |
| 10:14 |
* csharp |
votes for *not* relying on DB serial IDs for tests |
| 10:14 |
bshum |
Given that the generated call numbers and barcodes are based on the bib ID numbers right? Isn't it safe to assume to they'll usually generate out the same way as long as the bib order loading proceeds as expected? |
| 10:14 |
bshum |
Well maybe not, it is a little random I guess |
| 10:14 |
* bshum |
stops talking and runs to his next meeting |
| 10:15 |
dbs |
bshum: yeah, database doesn't guarantee specific ids when it hands out serial types, it just ends up that way |
| 10:15 |
tsbere |
So, looking at things *very* quickly, I suspect that just skipping the marcxml_import table (insert directly like the auth_concerto.sql file does) and putting the various "assets" lines after the appropriate "bibs" line in load_all would be at least a little more robust to future changes. |
| 10:15 |
JBoyer |
Agreed on not depending on ids, that's not why I'd like a more static sample. We've considered putting together a small static set for training purposes and have been (ab?)using concerto for that through the years. |
| 10:20 |
kmlussier |
For today, I'm thinking we can use bshum's approach to make the tests temporarily happy. rhamby is also working to take a similar approach with the records from bug 1665626. |
| 10:20 |
pinesol_green |
Launchpad bug 1665626 in Evergreen "Need more metarecord groups in sample dataset" [Undecided,New] https://launchpad.net/bugs/1665626 |
| 10:21 |
kmlussier |
And then we can consider other options for better loading of test data / better tests in the near-term future? |
| 10:21 |
dbs |
sounds good |
| 10:21 |
* kmlussier |
can try out tsbere's suggestion to see how it works. But not today. |
| 10:23 |
kmlussier |
As I told bshum in a pm, the good news is the fact we are seeing so many test failures speaks to the fact that we've gotten very good about adding live tests since the last time new records were added to the dataset. |
| 10:23 |
kmlussier |
We just need to robust-ify them. |
| 10:25 |
|
tspindler joined #evergreen |
| 10:29 |
dbs |
+1 |
| 10:30 |
|
Jillianne joined #evergreen |
| 10:50 |
JBoyer |
csharp, I pulled up some buckets at various sizes, the only one that was really miserable had around 4000 items in it, though even the 75 and 100-ish ones I wouldn't call "fast." :/ |
| 10:50 |
csharp |
JBoyer: hmm - weird |
| 10:50 |
rhamby |
"just when things look darkest, they go black." - John Newman |
| 10:50 |
csharp |
thanks for testing after me |
| 10:50 |
JBoyer |
Given that they're supposed to only pull details about the 30-ish or so you can see does make that seem odd. |
| 10:51 |
berick |
csharp: i don't remember if the tpac references any IDL strings, but if I had to guess, i'd say it doesn't. |
| 10:51 |
csharp |
berick: k - thanks |
| 11:46 |
Dyrcona |
"Take your hat off, boy, when you're talking to me." ;) |
| 11:47 |
kmlussier |
bshum++ |
| 11:49 |
dbs |
And then Tanya and Kim Deal got together to create The Breeders which blew my mind as a Throwing Muses/Belly/Pixies fan |
| 11:49 |
pinesol_green |
[evergreen|Ben Shum] LP#1541559: Change order of test bib loading - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1a9b812> |
| 11:50 |
rhamby |
dbs: The Breeders were awesome. Iliked Belly and Pixies too but never got into Throwing Muses. |
| 12:01 |
dbs |
I was hooked when I got Garoux des Larmes on a mixtape from a girl I didn't know in California :) |
| 12:06 |
Dyrcona |
dbs: There's a Monty Python retort in there somewhere, but I'm too busy. |
| 12:27 |
csharp |
JBoyer: with one of the 100+ buckets, could you try clicking "Show Status"? |
| 12:28 |
tspindler |
Dyrcona: "And now for something completely different" |
| 12:31 |
JBoyer |
csharp, Intense unhappiness. A tiny window with no contents opened in the middle of the screen and everything is frozen. I expect it to time out soon. |
| 12:32 |
csharp |
ok - that's the complaint |
| 12:32 |
csharp |
I'm about to fire up a 2.9.1 client to see if it happens on our old test server |
| 12:32 |
JBoyer |
Or, you could click the X on the little window to make it go away, though it doesn't seem to do much. |
| 12:32 |
csharp |
actually, I'm not seeing the window - just nothing happening and frozen client |
| 12:36 |
Dyrcona |
tspindler: More like "farsical aquatic ceremonies." |
| 13:07 |
mmorgan |
Hmm. Just killed my client. Clicked Show Status while viewing the copy bucket, THEN tried to scroll down the list of items. |
| 13:07 |
csharp |
yeah - that's what we're hearing from the wild |
| 13:11 |
Bmagic |
I have not received a report about this issue but it sure sounds like it's a real issiue |
| 13:14 |
kmlussier |
OK, I've squashed rhamby |
| 13:14 |
kmlussier |
Ugh. Didn't mean to hit <enter>. I didn't really squash Rogan. |
| 13:15 |
kmlussier |
I've squashed rhamby's commit and added my own commit to http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/kmlussier/lp1665626-fix-metarecord-test-rebase |
| 13:15 |
rhamby |
I assumed I was being abused as normal /shrug |
| 13:15 |
JBoyer |
Sometimes I don |
| 13:15 |
JBoyer |
t like the single quote being right next to Enter. |
| 13:15 |
kmlussier |
But it isn't working for me. When I load the new bibs, I'm getting a bunch of perl live test failures. I'm putting it out there for additional eyes. |
| 13:19 |
csharp |
@who squashed rhamby? |
| 13:19 |
pinesol_green |
phasefx_ squashed rhamby. |
| 13:21 |
* kmlussier |
has a theory. |
| 13:21 |
kmlussier |
Unfortunately, it takes many minutes to test out my theories. |
| 13:42 |
|
collum joined #evergreen |
| 14:31 |
kmlussier |
All tests successful. |
| 14:32 |
kmlussier |
Now I just need to squash some commits and update the metarecord test. I should have something for somebody to merge in the next 15 minutes. |
| 14:38 |
|
collum joined #evergreen |
| 14:45 |
mmorgan |
kmlussier++ |
| 14:56 |
kmlussier |
working/user/kmlussier/lp1665626-fix-metarecord-test-rebase is ready for testing and, hopefully, signoff and merging. |
| 14:56 |
kmlussier |
Once that fix gets into master, we'll close off new code for 2.12beta and hand things over to gmcharlt to perform his magic. |
| 14:57 |
gmcharlt |
speaking of which |
| 14:57 |
gmcharlt |
the OpenSRF beta tarball will definitely be available today |
| 14:57 |
gmcharlt |
but the Evergreen one may not be until tomorrow |
| 14:58 |
kmlussier |
Works for me! gmcharlt++ |
| 14:58 |
kmlussier |
Also, bshum++ rhamby++ # Helping with tests. |
| 15:02 |
Dyrcona |
Chtulhu Fhtagn! |
| 15:03 |
Dyrcona |
At least, I can end today with most things working, thanks in part to gmcharlt and Callender_. |
| 15:03 |
kmlussier |
gmcharlt++ Callender++ |
| 16:27 |
JBoyer |
(spoiler alert: any time the total number of copies mod copy_limit == 0 you get a Next link, even if there are only copy_limit copies total.) |
| 16:27 |
kmlussier |
Speaking of release notes, I just remembered there are still some stray entries from 2.11 that need to be cleared out. |
| 16:27 |
JBoyer |
kmlussier, That's how I was leaning, miiiiight be able to squeeze it in today yet in that case. :) |
| 16:29 |
kmlussier |
JBoyer: Might be a nice thing to test during Bug Squashing week. :) |
| 16:30 |
JBoyer |
kmlussier++ |
| 16:46 |
|
hbrennan joined #evergreen |
| 16:48 |
bshum |
All tests pass for me in the branch |
| 16:48 |
bshum |
Anyone else testing and signing off to push? |
| 16:48 |
* bshum |
will go ahead and get it in otherwise |
| 16:50 |
* bshum |
whistles a happy tune |
| 16:52 |
pinesol_green |
[evergreen|Rogan Hamby] LP#1665626: adding new records to the meta group and breaking into new file - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7ecb690> |
| 16:52 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1665626: Change order of test bib loading - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=44644b4> |
| 16:52 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1665626: Update metarecord_constituent_result_reroute.pg test - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=02a62c2> |
| 17:00 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 17:01 |
bshum |
Aw, not fast enough. Didn't get the latest commits in that test run. Have to wait till tomorrow I guess. |
| 17:02 |
* phasefx |
can force another run |
| 17:02 |
bshum |
The build test failure though, hmm |
| 17:02 |
bshum |
That's something else |
| 17:02 |
phasefx |
oh, in that case, no need for me to force it |
| 17:03 |
bshum |
Yeah, best to figure out what that one is about too and then fix all the things |
| 17:03 |
bshum |
But later |
| 18:11 |
Dyrcona |
hm... The line where filename is set suddenly looks wrong, there's a space: $self-> ftp_get. I think that should be all right, but I'll verify. |
| 18:13 |
Dyrcona |
yeah, a space there should not be a problem. |
| 18:14 |
Dyrcona |
oh, duh. it's _ my block cursor on the line below obscured it. |
| 18:14 |
Dyrcona |
Even so, a space still seems to work from a quick test. |
| 18:14 |
* Dyrcona |
calls it a day. |
| 19:07 |
|
brahmina joined #evergreen |
| 19:43 |
bshum |
Hmm, confirmed that the make check fails on the build test with 23-OpenILS-Application-EbookAPI.t |
| 19:43 |
bshum |
At least, confirmed for me on my own VM, not just the builder test |
| 20:37 |
pinesol_green |
[evergreen|Galen Charlton] Translation updates - newpot - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a67e294> |
| 21:54 |
|
denials_exile joined #evergreen |
| 21:55 |
denials_exile |
In case anyone is looking for the Planet, it will be down until this is fixed: https://status.linode.com/incidents/2ns3cw1dsymf (hopefully soon, sigh) |
| 19:09 |
* bshum |
can try that too |
| 19:10 |
bshum |
The perl live tests seem unhappier |
| 19:11 |
kmlussier |
Yes, sorry, it's the pgTap test that has been failing. |
| 19:11 |
bshum |
But maybe it's something I did wrong in my testing run |
| 19:11 |
bshum |
Or maybe it's the new bibs doing something |
| 19:11 |
kmlussier |
The perl live tests have been doing okay in the twice-daily test runs. |
| 19:17 |
bshum |
Fwiw, it passes pg tests successfully now |
| 19:17 |
bshum |
Let me try the live tests both ways to be sure and then I'll go ahead and commit it |
| 19:17 |
bshum |
But probably after I eat dinner |
| 19:21 |
bshum |
Or you know, right now |
| 19:21 |
bshum |
Cause I'm super curious... |
| 19:22 |
bshum |
Okay, so reverting the new bib change from rhamby, and the perl live test succeeds, except for something with the hold targeter. Probably a bad install on my end |
| 19:22 |
bshum |
I'll double check all my install configs to be sure the hold targeter stuff is setup right |
| 19:22 |
bshum |
This is a reinstalled system so maybe I need to update something |
| 19:23 |
bshum |
When i ran the live tests against the new test bibs, things blew up for stuff all the way down to some of the early tests with bills and circs |
| 19:24 |
bshum |
So maybe we moved a bib assignment or something for an early test |
| 19:24 |
* bshum |
goes to get dinner first now |
| 19:24 |
Dyrcona |
dinner would be nice, but the family is not home, yet. |
| 19:24 |
Dyrcona |
the wife wants to make pasta or hambugers or something. |
| 19:24 |
Dyrcona |
I hinted that she should get pizza and chicken wings on the way home. |
| 19:25 |
kmlussier |
bshum: Which tests are failing? |
| 19:26 |
Dyrcona |
What's not failing would be a shorter list for me.... |
| 19:26 |
kmlussier |
I had been thinking Rogan's new bibs got later ids, but I see they jumped ahead of a few records in the dataset. |
| 19:26 |
|
dcook left #evergreen |
| 19:28 |
kmlussier |
So, generally, when people add new records to the test dataset, I think they add a new sql file, rather than appending it to an existing sql file. Maybe we need to do that with these records to make sure it doesn't bump anything being used by the tests. |
| 19:29 |
Dyrcona |
And, they get home while I'm trying to concentrate on writing an email and the dog goes nuts barking. |
| 19:32 |
* kmlussier |
can try to make that happen while she waits for her VM to fire up. |
| 19:43 |
jeffdavis |
kmlussier: I will write release notes for the ebook API stuff, hopefully tomorrow |
| 21:00 |
bshum |
I think it's still unstamped |
| 21:01 |
kmlussier |
I didn't push those? |
| 21:01 |
kmlussier |
Huh, I know I did those. |
| 21:02 |
bshum |
I'm circling back to finishing testing the test stuff |
| 21:02 |
kmlussier |
I'm still working on that. I just fixed an issue with a missing comma. |
| 21:03 |
bshum |
Oh okay |
| 21:03 |
bshum |
:) |
| 21:30 |
Dyrcona |
I did build new clients on the replacement. |
| 21:31 |
Dyrcona |
but of course, the upgrade files are missing. |
| 21:33 |
Dyrcona |
bshum: That's what I'll do, I'll rename the xul version directory temporarily and I'll delete the old ones still hanging around on some of the servers. |
| 22:08 |
kmlussier |
To follow up on fixing our tests, bshum and I have found that the addition of any new bib records to the test dataset is busting our perl live tests. See my comment at https://bugs.launchpad.net/evergreen/+bug/1665626/comments/4 |
| 22:08 |
pinesol_green |
Launchpad bug 1665626 in Evergreen "Need more metarecord groups in sample dataset" [Undecided,New] |
| 22:09 |
Dyrcona |
Yay! more f'd up legacy server configuration that only manifests when you try to restart stuff. |
| 22:09 |
bshum |
kmlussier++ # trying to fix tests with me |
| 22:09 |
kmlussier |
I would like to hold off on merging that code until we can see if there is a way we can add bibs to the dataset without shifting the existing data. Or, maybe, we just need to accept that we have to fix up a bunch of perl live tests every time we add bibs. |
| 22:10 |
Dyrcona |
This and hardware failure is why a "simple" upgrade has taken 12 hours so far. |
| 22:10 |
kmlussier |
bshum++ |
| 22:12 |
kmlussier |
@swill Dyrcona |
| 22:12 |
* pinesol_green |
grabs a forty of Jeremiah Weed and sends it sliding down the bar to Dyrcona |
| 22:39 |
bshum |
kmlussier: This is a really terrible hack |
| 22:39 |
bshum |
But hey, it works: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/bshum/move-test-ebook-bibs |
| 22:40 |
bshum |
And all live tests succeed for me after I move the ebook bibs out of the way of being loaded the first time around |
| 22:40 |
Dyrcona |
yay. at least something works for somebody. |
| 22:40 |
Dyrcona |
Simple day of installing o/s and security updates, turns into a 3-hour tour on the SS Minnow. |
| 22:41 |
bshum |
"Those poor people..." |
