| Time |
Nick |
Message |
| 00:17 |
|
sandbergja joined #evergreen |
| 01:09 |
|
annagoben joined #evergreen |
| 01:11 |
dbs |
bshum++ # fedora 29 success! |
| 02:49 |
|
beanjammin joined #evergreen |
| 03:03 |
|
mnsri joined #evergreen |
| 07:16 |
|
rjackson_isl joined #evergreen |
| 07:29 |
|
bdljohn joined #evergreen |
| 08:16 |
|
bos20k joined #evergreen |
| 08:17 |
|
agoben joined #evergreen |
| 08:33 |
csharp |
bshum++ |
| 08:33 |
csharp |
last time I looked at getting EG running on RHEL/CentOS, ejabberd wasn't packaged and I wasn't sure how to proceed |
| 08:34 |
csharp |
haven't tried fedora in a while |
| 08:34 |
csharp |
the build servers for fedora/ubuntu died a quiet death as we moved out of our office :-/ |
| 08:42 |
|
collum joined #evergreen |
| 08:46 |
|
mmorgan joined #evergreen |
| 08:52 |
|
JBoyer joined #evergreen |
| 08:57 |
|
mdriscoll joined #evergreen |
| 09:02 |
bshum |
dbs: csharp: Well the prereqs haven't been updated for Fedora since 16, so there's alot of tweaking we still have to do to make sure all the packages are up-to-date |
| 09:02 |
bshum |
But just having a working OpenSRF with ejabberd is a good first sign. |
| 09:03 |
bshum |
I got stumped on the httpd configs, because of the different installation paths between apache on Debian/Ubuntu vs. Fedora |
| 09:03 |
bshum |
And the fact that I guess we've never made a Fedora httpd config for Apache 2.4 either. |
| 09:03 |
bshum |
So lots more tweaking to go |
| 09:04 |
bshum |
But it'd be an amusing little pet project. |
| 09:04 |
bshum |
I keep meaning to sign up and get a copy of RHEL to experiment on. |
| 09:04 |
bshum |
Baby stpes |
| 09:04 |
bshum |
*steps |
| 09:05 |
bshum |
csharp: Poor build servers :( But clearly we need to look at rebuilding all our test infrastructure for the community at large all the same |
| 09:08 |
csharp |
yeppers |
| 09:08 |
csharp |
it shouldn't be a problem to host build testing VMs in our new cloud-ish environment |
| 09:09 |
csharp |
but that all depends on whether we move to a git solution with built-in CI |
| 09:24 |
|
nfburton joined #evergreen |
| 09:29 |
|
jonadab joined #evergreen |
| 09:35 |
|
yboston joined #evergreen |
| 09:55 |
|
sandbergja joined #evergreen |
| 10:04 |
|
mmorgan1 joined #evergreen |
| 10:11 |
JBoyer |
mmorgan++ # contributing |
| 10:12 |
|
kmlussier joined #evergreen |
| 10:34 |
pinesol |
[evergreen|Garry Collum] LP#1761242 Z39.50 Marc View Usability with Mobile Repsonsiveness - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=eedb5ef> |
| 10:39 |
|
khuckins joined #evergreen |
| 10:44 |
|
soda__hobart_ joined #evergreen |
| 10:49 |
|
mmorgan joined #evergreen |
| 10:56 |
|
khuckins_ joined #evergreen |
| 11:01 |
|
khuckins joined #evergreen |
| 11:15 |
pinesol |
[evergreen|Jason Boyer] LP1801156: Add missing assets to 3.2 Offline mode - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d3a5455> |
| 11:25 |
|
khuckins_ joined #evergreen |
| 11:35 |
|
bos20k_ joined #evergreen |
| 12:13 |
|
jihpringle joined #evergreen |
| 12:16 |
|
beanjammin joined #evergreen |
| 12:51 |
csharp |
so in the web client, do dojo-ish things also use websockets? |
| 12:53 |
|
sandbergja joined #evergreen |
| 12:54 |
JBoyer |
csharp, no, that would have required enough of a rewrite that they'd just be in Angular by now. :) |
| 12:55 |
JBoyer |
That said, the rest of the staff client frame around them *does*, so they still need to be working. |
| 13:04 |
|
jvwoolf joined #evergreen |
| 13:04 |
|
jvwoolf left #evergreen |
| 13:21 |
kmlussier |
JBoyer++ # Bug 1804038 |
| 13:21 |
pinesol |
Launchpad bug 1804038 in Evergreen "Password Reset results in Internal Server Error" [High,Confirmed] https://launchpad.net/bugs/1804038 |
| 13:21 |
kmlussier |
I was trying to enable password reset on a test VM recently and kept coming across that bug. Since I never enable password resets, I thought the problem was me. |
| 13:24 |
JBoyer |
a basic grep of that function name shows that most calls are fully specified but Booking may have another potential issue. Since I'm still waiting for things to install for a proper test I'll probably go ahead and cover that one too. |
| 13:51 |
csharp |
seeing some acq failures to create volumes/copies and wanted to rule that out - thanks, JBoyer |
| 13:52 |
csharp |
the angular acq rewrite can't come quickly enough :-/ |
| 13:52 |
csharp |
current situation: press activate and pray |
| 13:53 |
csharp |
and forensic searching for the cause of a failure later is not easy either |
| 13:53 |
csharp |
</rant> |
| 13:53 |
JBoyer |
csharp, any blank call numbers on the failing POs? I've seen things get grumpy about that here. |
| 13:53 |
|
mmorgan1 joined #evergreen |
| 13:53 |
csharp |
yes - that sounds like what we're seeing |
| 13:53 |
csharp |
I haven' |
| 13:54 |
csharp |
t done much analysis yet, but my guess is a drone dying off somewhere |
| 13:55 |
csharp |
my websockets question was "what if I'm killing off legitimately long-running acq things when I kill the spinning WS processes?"" |
| 13:59 |
* kmlussier |
agrees that angular acq rewrite can't come quickly enough. |
| 13:59 |
kmlussier |
Unfortunately, the funding isn't coming quickly enough. Of course, putting calls out for funding right before Thanksgiving probably isn't great timing. |
| 15:07 |
|
khuckins_ joined #evergreen |
| 15:46 |
kmlussier |
@quote random |
| 15:46 |
pinesol |
kmlussier: Quote #12: "<pinesol_green> There are 10 quotes in my database." (added by Dyrcona at 05:26 PM, June 07, 2011) |
| 15:47 |
kmlussier |
One would think that would be quote #11, not #12. |
| 15:48 |
jeff |
@quote stats |
| 15:48 |
pinesol |
jeff: There are 187 quotes in my database. |
| 15:48 |
jeff |
@quote 191 |
| 15:48 |
pinesol |
jeff: What we have here is a failure to communicate. |
| 15:48 |
jeff |
@quote get 191 |
| 15:48 |
pinesol |
jeff: Quote #191: "<rhamby> it takes a village to build a MARC record." (added by csharp at 11:11 AM, October 19, 2018) |
| 15:49 |
csharp |
@dunno add "you have exposed a flaw in the Internet and will be reported" |
| 15:49 |
pinesol |
csharp: The operation succeeded. Dunno #60 added. |
| 15:50 |
jeff |
@dunno stats |
| 15:50 |
pinesol |
jeff: There are 57 dunnos in my database. |
| 15:55 |
csharp |
pinesol: why, though? |
| 15:55 |
pinesol |
csharp: What we have here is a failure to communicate. |
| 15:55 |
csharp |
pinesol: but for what reason? |
| 15:55 |
pinesol |
csharp: Have you tried taking it apart and putting it back together again? |
| 15:55 |
csharp |
pinesol: WHY AM I HERE?! |
| 15:55 |
pinesol |
csharp: http://www.firstpersontetris.com/ |
| 15:58 |
csharp |
the acq issue we're seeing is all of a sudden being reported from multiple sites - nothing at all has changed that I'm aware of |
| 15:58 |
csharp |
acq-- |
| 15:59 |
csharp |
I'll know more once I do some log diving |
| 16:03 |
Bmagic |
Do we have a wishlist bug for auto renewals? |
| 16:07 |
kmlussier |
Bmagic: It's available in 3.2, so it would be a Wishlist bug with a Fix Released status. |
| 16:07 |
mmorgan |
Bmagic: Granted! bug 1779920 |
| 16:07 |
pinesol |
Launchpad bug 1779920 in Evergreen "wishlist: Add Auto Renewal functionality" [Wishlist,Fix released] https://launchpad.net/bugs/1779920 |
| 16:07 |
Bmagic |
oh sweet! |
| 16:08 |
Bmagic |
How did I miss that in the release notes! |
| 16:21 |
kmlussier |
@coin |
| 16:21 |
pinesol |
kmlussier: tails |
| 16:21 |
kmlussier |
hmmm...should I trust pinesol? |
| 16:22 |
bshum |
@roulette |
| 16:22 |
pinesol |
bshum: *click* |
| 16:22 |
bshum |
Seems trustworthy to me :) |
| 16:37 |
|
khuckins joined #evergreen |
| 16:50 |
|
khuckins joined #evergreen |
| 16:57 |
|
khuckins_ joined #evergreen |
| 17:13 |
|
mmorgan left #evergreen |
| 17:36 |
|
abneiman_ joined #evergreen |
| 17:36 |
|
jgoodson_ joined #evergreen |
| 17:37 |
|
cesardv_ joined #evergreen |
| 17:38 |
|
gsams__ joined #evergreen |
| 17:40 |
|
mnsri joined #evergreen |
| 18:25 |
|
khuckins joined #evergreen |
| 19:21 |
csharp |
@roulette |
| 19:21 |
pinesol |
csharp: *click* |
| 20:42 |
bshum |
Hmm |
| 20:42 |
bshum |
Blah |
| 20:43 |
bshum |
More array_to_string(array_agg()) to fix up |
| 20:45 |
bshum |
So here's some thoughts... if we're backporting a database change, where the function is different in 3.1 vs. 3.2 (and master) due to a new feature being implemented in 3.2 |
| 20:45 |
bshum |
Then I think that means I should reserve two upgrade script IDs |
| 20:46 |
bshum |
And use the first one for 3.1 only, using it to replace the function there in that branch |
| 20:46 |
bshum |
And for master, commit that upgrade script ID with no changes |
| 20:46 |
bshum |
And then make the other upgrade script for 3.2/master with the current version of the function |
| 20:46 |
bshum |
And not backport that one to the maintenance branch? |
| 20:47 |
bshum |
Cause otherwise, if I were to use the same upgrade script number |
| 20:47 |
bshum |
Someone coming from 3.1.next upgrading in the future to 3.2.whatnot might end up thinking they've already run the upgrade script when they haven't gotten the latest version they need for their supported version? |
| 20:47 |
bshum |
Or... |
| 20:48 |
bshum |
I just choose *not* to backport it at all. |
| 20:48 |
bshum |
And say the fix exists only for 3.2, upgrade to that. |
| 20:49 |
csharp |
what was the change the broke? |
| 20:51 |
bshum |
Oh sorry okay |
| 20:52 |
bshum |
So bug 1643709 touches actor.usr_merge |
| 20:52 |
pinesol |
Launchpad bug 1643709 in Evergreen ""Purge" deleted user records (actor.usr) which result from a patron merge operation" [High,Confirmed] https://launchpad.net/bugs/1643709 |
| 20:52 |
bshum |
But bug 1776020 is a new feature in 3.2 that also touched actor.usr_merge |
| 20:52 |
pinesol |
Launchpad bug 1776020 in Evergreen "Wishlist: Patron Alternate/Preferred Names" [Wishlist,Fix released] https://launchpad.net/bugs/1776020 |
| 20:52 |
bshum |
So if I backport the upgrade script, it'll contain the new feature too, and that wouldn't be good I think. |
| 20:52 |
bshum |
If I create a separate version of the same script |
| 20:52 |
bshum |
I want to make sure nobody runs that on 3.2 or master |
| 20:53 |
bshum |
To avoid them getting the 3.1 version of the function |
| 20:53 |
bshum |
And losing the new feature |
| 20:53 |
bshum |
Upgrades are the worst, it's been awhile since I had to deal with a function discrepancy like this. Trying to decide on best practice moving forward |
| 20:59 |
csharp |
hmmm |
| 20:59 |
bshum |
Yep |
| 21:00 |
bshum |
The bug isn't targeted as a bug fix, but to me it probably should be |
| 21:00 |
bshum |
So I started making sure that it wouldn't break stuff but actually it would if I straight backported it |
| 21:00 |
bshum |
Without checking |
| 21:01 |
bshum |
I feel like we've done purely placeholder upgrade scripts before across branches |
| 21:01 |
bshum |
But it's been awhile, so I was just checking to make sure my logic was sound before attempting to construct it |
