| Time |
Nick |
Message |
| 00:31 |
|
sandbergja joined #evergreen |
| 06:58 |
|
agoben joined #evergreen |
| 08:15 |
|
Dyrcona joined #evergreen |
| 08:45 |
|
rfrasur joined #evergreen |
| 08:46 |
|
mdriscoll joined #evergreen |
| 09:07 |
|
aabbee joined #evergreen |
| 09:08 |
|
yboston joined #evergreen |
| 09:32 |
|
Dyrcona joined #evergreen |
| 09:51 |
|
jvwoolf joined #evergreen |
| 10:12 |
|
sandbergja joined #evergreen |
| 10:59 |
csharp |
berick: curious as to whether your work on bug 1846806 should be considered "deprecated" since we're moving to Angular for everything else? We have a library interested in some selfcheck improvements and was about to take a look before I realized it was in AngJS |
| 10:59 |
pinesol |
Launchpad bug 1846806 in Evergreen "Web Based Self Check - Angular version" [Undecided,New] https://launchpad.net/bugs/1846806 |
| 10:59 |
berick |
csharp: hm, there's another version of that bug that is deprecated |
| 11:00 |
berick |
https://bugs.launchpad.net/evergreen/+bug/1710299 |
| 11:00 |
pinesol |
Launchpad bug 1710299 in Evergreen "Port the self-checkout interface to AngularJS" [Wishlist,Won't fix] |
| 11:00 |
berick |
https://bugs.launchpad.net/evergreen/+bug/1840773 |
| 11:00 |
pinesol |
Launchpad bug 1840773 in Evergreen "Angularize the Self-Check Interface" [Wishlist,New] |
| 11:01 |
|
aabbee left #evergreen |
| 11:01 |
|
aabbee joined #evergreen |
| 11:01 |
* berick |
updates 1846806 |
| 11:02 |
csharp |
berick++ |
| 11:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 11:04 |
|
tlittle joined #evergreen |
| 11:45 |
|
jihpringle joined #evergreen |
| 12:00 |
|
sandbergja joined #evergreen |
| 12:27 |
|
yboston joined #evergreen |
| 12:32 |
|
sandbergja_ joined #evergreen |
| 12:36 |
|
khuckins joined #evergreen |
| 12:38 |
Bmagic |
berick: I've got the elasticsearch branch up and running and indexing (thanks to your sweet techref) - Indexed about 5.4 GB worth of data into the elasticsearch service. I am working through the code changes to see where exactly Evergreen forks to use the ES service instead of PG. I am not certain it's using it |
| 12:40 |
jeff |
if you have nginx in front of elasticsearch you should be able to see access log entries correlated with searches. |
| 12:40 |
Bmagic |
lemme check |
| 12:41 |
jeff |
(if you don't, you could always packet capture) |
| 12:41 |
Bmagic |
I would expect the elasticsearch logs would spit something |
| 12:42 |
jeff |
queries are not logged without additional configuration |
| 12:42 |
jeff |
elasticsearch has a "slow queries log" like postgres does. |
| 12:42 |
Bmagic |
hmmmm, tricky tricky |
| 12:43 |
Bmagic |
eg2/en-US/staff/catalog/search?org=1&limit=20&query=goblet%20fire&fieldClass=keyword&joinOp=&matchOp=contains&dateOp=is&ridx=5 |
| 12:46 |
Bmagic |
gateway.log open-ils.search open-ils.search.elastic.bib_search.staff {"size":20,"from":0,"sort":[{"_score":"desc"}],"query":{"bool":{"must":{"multi_match":{"query":"potter fire","fields":["keyword.text*"],"operator":"and","type":"most_fields"}}}}}, {"search_org":1} |
| 12:46 |
Bmagic |
if it's working then I am amazed |
| 12:51 |
* berick |
reads up |
| 12:51 |
Bmagic |
perhaps it's only working within the staff client's Experimental catalog search? |
| 12:51 |
berick |
Bmagic: yes it only works in Ang catalog for now |
| 12:51 |
berick |
and those are the expected console logs |
| 12:51 |
Bmagic |
and it's turned "on" by default to use ES? |
| 12:52 |
berick |
Bmagic: grep "ES " in osrfsys logs |
| 12:52 |
berick |
Bmagic: yes, the branch turns it on by default |
| 12:52 |
berick |
(i'm pretty sure -- osrfsys logs will confirm) |
| 12:53 |
Bmagic |
I just would have expected to have to fiddle with it more |
| 12:53 |
Bmagic |
lol |
| 12:54 |
Bmagic |
it seems like it's working - ES search found 73 results in 0.235 seconds. |
| 12:54 |
|
nfBurton joined #evergreen |
| 12:54 |
berick |
Bmagic++ # woot |
| 12:54 |
Bmagic |
berick++ |
| 12:54 |
Bmagic |
jeff++ |
| 12:54 |
berick |
jeff++ # indeed, much inspiration |
| 12:55 |
* berick |
pushed a bit more and rebased the branch yesterday, fyi |
| 12:55 |
Bmagic |
yep, just soaked that up and running it now |
| 12:55 |
Bmagic |
like 20 minutes ago |
| 12:55 |
nfBurton |
nice! |
| 12:58 |
|
Christineb joined #evergreen |
| 13:08 |
Bmagic |
The fateful "dog" keyword search is pretty fast! |
| 13:09 |
Bmagic |
berick: I want to help. If I were to add code, do we have a logistic issue with git/branch/user/collab? |
| 13:11 |
berick |
Bmagic: collab branch is fine. anything in particular you're looking at? |
| 13:11 |
Bmagic |
I would like to add configuration to make it OPAC optionally enabled. Perhaps library setting per branch/system etc |
| 13:11 |
berick |
one thing on my list is moving more of the index config in the db so it's not all hard-coded in the Perl |
| 13:11 |
berick |
Bmagic: cool! |
| 13:14 |
Bmagic |
I'm not sure I have collab branch creation powers |
| 13:14 |
jeff |
anyone does using the path of your git username in the branch name |
| 13:15 |
jeff |
and anyone can push to them (hence the collab) |
| 13:15 |
jeff |
but only the "owner" (the username in the branch name) can force push / delete |
| 13:15 |
jeff |
(iirc) |
| 13:15 |
Bmagic |
sweet! Good to know. It'll be my first time |
| 13:15 |
jeff |
hopefully that's in the wiki somewhere. if not, now it's at least in recent logs. |
| 13:15 |
Bmagic |
lol |
| 13:19 |
berick |
Bmagic: collab/berick/lp1844418-elastic |
| 13:19 |
Bmagic |
ha |
| 13:19 |
Bmagic |
ty |
| 13:24 |
|
khuckins joined #evergreen |
| 13:26 |
Dyrcona |
The wiki only mentions user branches, and then only in an example. |
| 13:28 |
Dyrcona |
collab is used in some examples further down the dev:gt page. |
| 13:28 |
Dyrcona |
https://wiki.evergreen-ils.org/doku.php?id=dev:git |
| 13:29 |
Dyrcona |
Down in the Working Repos section. |
| 13:32 |
Bmagic |
Dyrcona++ |
| 13:32 |
Bmagic |
While we are at it. I was reviewing: https://wiki.evergreen-ils.org/doku.php?id=eg_developer_overview and found the top section a little "out of date" on numeric 3 |
| 13:33 |
Bmagic |
berick: made my first push, merge conflict resolution |
| 13:33 |
Dyrcona |
Yeah, a lot of things on the wiki are out of date. |
| 13:34 |
csharp |
@who is supposed to be keeping the wiki up-to-date? |
| 13:34 |
pinesol |
remingtron is supposed to be keeping the wiki up-to-date. |
| 13:34 |
|
collum joined #evergreen |
| 13:35 |
Dyrcona |
Sounds about right to me. :) |
| 13:35 |
Bmagic |
lol |
| 13:39 |
Dyrcona |
Bmagic: Did you merge into rel_3_4? |
| 13:40 |
Bmagic |
tags/rel_3_4_0 |
| 13:40 |
Bmagic |
should have been tracking rel_3_4, doh |
| 13:41 |
Dyrcona |
That's what it looks like. Well, I'm not sure what berick does, but I usually tracking master in my working branches. |
| 13:41 |
Dyrcona |
I can English... :) |
| 13:41 |
Bmagic |
rel_3_4 makes more sense |
| 13:42 |
Dyrcona |
Maybe. I'll let berick take it from here. Doesn't look like anything that a force push can't resolve. :) |
| 13:43 |
Bmagic |
I was going to try to correct it by stacking a fix on top |
| 13:43 |
Bmagic |
I am slightly confused though. Should the branch have or NOT have the line from -- remington/mmorgan/jpringle/gmcharlt ? |
| 13:44 |
Dyrcona |
OK. For the logs, we usually leave just the highest numbered update in the config.upgrade_log insert. |
| 13:45 |
Dyrcona |
I'd delete the 1192 and 3.4.0 lines. |
| 13:45 |
Bmagic |
cool, done |
| 13:45 |
Dyrcona |
So, yeah, it should have the line that you asked about. |
| 13:45 |
Dyrcona |
We only put the X.Y.Z lines in tag branches for releases. |
| 13:46 |
Dyrcona |
The make upgrade script does it. |
| 13:47 |
Bmagic |
pushed |
| 13:48 |
Dyrcona |
conflict resolution can be tricky. |
| 13:49 |
JBoyer |
There are some serious benefits to basing new features on master rather than a release branch. If it's accepted into core master is the branch you have to worry about merge conflicts with, for one. (if it backports, great, but if not you don't want something to only apply cleanly to an "older" release...) |
| 13:50 |
Dyrcona |
That, and I will put _X_Y on the end of pushed branches if they're not based on master. |
| 13:50 |
JBoyer |
Dyrcona++ # handy way to show that. |
| 13:51 |
Dyrcona |
I know a neat trick for rebasing on a different branch. |
| 13:52 |
Dyrcona |
Say your branch is based on rel_3_2 and you want to rebase on master. If you do git rebase origin/master, you're bound to get conflicts with code that isn't your changes. |
| 13:52 |
Dyrcona |
But, if you say "git rebase -X theirs origin/master" those conflicts get resolved by pulling the code from master. |
| 13:55 |
Dyrcona |
Works with merge, too. |
| 13:59 |
Bmagic |
Dyrcona++ |
| 13:59 |
JBoyer |
Dyrcona++ # I think I have cause to use that one already. |
| 14:00 |
Bmagic |
Dyrcona: going to make the hack-away this year? |
| 14:01 |
Dyrcona |
I use it with our customization branches. |
| 14:01 |
Dyrcona |
Bmagic: Nope. Not gonna make it this year. It was going to be too close to an upgrade that got postponed, and we've had a lot of things going on. |
| 14:02 |
Dyrcona |
I feel I should share a little more work flow on the rebase trick. |
| 14:03 |
Dyrcona |
I have a branch called custom_3_2 that has our customization for rel_3_2 in it, and I want to rebase it on rel_3_4. |
| 14:03 |
berick |
Bmagic: hm, that branch should be based on master, is it not? |
| 14:04 |
Dyrcona |
I would checkout custom_3_2, and then checkout a copy named custom_3_4: git checkout -b custom_3_4 custom_3_2 |
| 14:04 |
Dyrcona |
Then, in custom_3_4, I do the following rebase: git rebase -X theirs origin/rel_3_4 |
| 14:04 |
Bmagic |
lol, it started with rel_3_4_0 - and after Dyrcona powowed with me, I changed to rel_3_4, and now I need to switch again? Whee, learning from mistakes is the best |
| 14:04 |
Dyrcona |
This way, the original branch doesn't get hosed. |
| 14:05 |
Dyrcona |
*some clever statement about mistakes and learning* :) |
| 14:06 |
Dyrcona |
Honestly, I've probably learned more from mistakes than from successes. |
| 14:06 |
Bmagic |
Here Here! |
| 14:09 |
berick |
Bmagic: i'm unclear on what's going on.. do I need to force-push anything to collab/berick/lp1844418-elastic ? |
| 14:11 |
* berick |
could just reset it |
| 14:11 |
|
jvwoolf left #evergreen |
| 14:11 |
Dyrcona |
berick: That's probably safest, but I don't think you can lose anything in a collab branch from another user. |
| 14:12 |
Dyrcona |
I think all that's happened here is commit noise was added. |
| 14:20 |
berick |
k, will wait for thumbs up from Bmagic in case there's something I'm missing |
| 14:24 |
|
bos20k joined #evergreen |
| 14:35 |
|
stephengwills joined #evergreen |
| 14:58 |
|
stephengwills left #evergreen |
| 14:58 |
|
stephengwills joined #evergreen |
| 14:59 |
csharp |
@blame hungry hungry pcrud drones |
| 14:59 |
pinesol |
csharp: hungry hungry pcrud drones is really just another name for autogen |
| 15:00 |
csharp |
so thanks to agoben's awesomeness, I will be staying in the Harrison House this year - looking forward to some Real-World-esque roommate relationships! |
| 15:01 |
berick |
true story |
| 15:01 |
csharp |
holy crap, that show's still on |
| 15:01 |
csharp |
wait - ended in 2017, but still |
| 15:03 |
agoben |
The suites are really pretty nice (and private), but the ground floor is where the party is at, so there's that... |
| 15:03 |
csharp |
supercool |
| 15:05 |
|
yboston joined #evergreen |
| 15:10 |
stephengwills |
is there a new dev working group meeting today? I didn’t see any emails about such a thing but it’s on my calendar. |
| 15:11 |
csharp |
stephengwills: Terran just mentioned that it was going on - let me see what I can find out |
| 15:13 |
JBoyer |
stephengwills, This is all I've seen about it: https://wiki.evergreen-ils.org/doku.php?id=newdevs:start |
| 15:13 |
csharp |
https://wiki.evergreen-ils.org/doku.php?id=newdevs:meetings:agenda-2019-10 |
| 15:14 |
JBoyer |
csharp++ |
| 15:14 |
stephengwills |
i’m there, thanks |
| 15:35 |
|
jvwoolf joined #evergreen |
| 16:03 |
|
sandbergja_ joined #evergreen |
| 16:13 |
dbs |
stupid question: does the "forgot my password" process still work with the move to actor.passwd for storing passwords? |
| 16:13 |
dbs |
I guess I can peek at the code... |
| 16:16 |
|
yboston joined #evergreen |
| 16:23 |
|
jvwoolf1 joined #evergreen |
| 16:24 |
Bmagic |
berick: yes - reset |
| 16:24 |
berick |
Bmagic: k, on it |
| 16:24 |
Bmagic |
sorry |
| 16:24 |
berick |
meh |
| 16:25 |
berick |
easy peasy |
| 16:25 |
Bmagic |
Thanks - tracking master now |
| 16:26 |
dbs |
yay, modify_migrated_user_password does the right thing in the password reset flow: https://gitlab.com/evergreen-library-system/evergreen-library-system/blob/rel_3_4/Open-ILS/src/perlmods/lib/OpenILS/Application/Actor.pm#L1491 |
| 16:44 |
Bmagic |
Anyone know if there is an LP entry for patron self registration notification AT to staff? Seems pretty straightforward in terms of implementing. Almost could be implemented solely in the database AT definition |
| 16:49 |
Bmagic |
but bug 1821093 might need to be solved first, otherwise, let the email/texts rip |
| 16:49 |
pinesol |
Launchpad bug 1821093 in Evergreen "Patron Self Registration form needs captcha" [Undecided,Confirmed] https://launchpad.net/bugs/1821093 |
| 17:16 |
|
Stompro joined #evergreen |
| 17:38 |
|
aabbee joined #evergreen |
| 19:17 |
|
jihpringle joined #evergreen |
| 20:11 |
|
cmalm joined #evergreen |
| 21:42 |
|
sandbergja joined #evergreen |
| 22:41 |
|
sandbergja joined #evergreen |
| 23:03 |
pinesol |
News from qatests: Failed Installing Angular web client <http://testing.evergreen-ils.org/~live/test.29.html#2019-10-16T23:01:40,911865881-0400 -0> |
| 23:03 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live/test.49.html#2019-10-16T23:01:40,940294206-0400 -2> |
