| 10:13 |
|
Dyrcona joined #evergreen |
| 10:40 |
csharp |
Bmagic: were you able to resolve your issue? |
| 10:40 |
Bmagic |
my issue was resolved by uncommenting the remote IP business in eg_vhost.conf |
| 10:40 |
csharp |
(yes, I do have a couple of production-ish test clusters) |
| 10:40 |
csharp |
ok cool |
| 10:41 |
Bmagic |
Not the same as your issue though |
| 10:41 |
Bmagic |
(We've not tried the org unit editor on our new production environment though, we may have the same issue) |
| 10:42 |
Bmagic |
berick++ # remote IP |
| 12:58 |
sandbergja |
RMiller: no problem! FWIW, this can be super helpful for questions like that: http://docs.evergreen-ils.org/3.2_schema/ |
| 13:00 |
Dyrcona |
I'd do something more complicated for the org_units. |
| 13:02 |
RMiller |
My org units are really really simple at the moment, so I think this does the trick for now, unless there's something else I should know? |
| 13:05 |
Dyrcona |
Yeah, I was just testing the SQL before sharing it. The work firewall doesn't always play nice. |
| 13:05 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "Rmiller: Getting org_units that can have users" (5 lines) at http://paste.evergreen-ils.org/10236 |
| 13:06 |
RMiller |
Oh, gotcha. I can see how that would be handy. |
| 13:10 |
sandbergja |
Dyrcona++ |
| 16:53 |
gsams |
Bmagic: I'd be all for that. |
| 16:54 |
Bmagic |
seems like a simple solution |
| 16:54 |
Bmagic |
replacing \n with <br /> |
| 17:01 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-03-14T17:00:39,182624603-0400 -0> |
| 17:08 |
|
bdljohn left #evergreen |
| 17:10 |
Dyrcona |
For every problem, there is a solution that is simple, obvious and wrong. :) |
| 17:17 |
|
AMM_ joined #evergreen |
| 05:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 08:15 |
|
jamesrf joined #evergreen |
| 11:00 |
|
gsams_ joined #evergreen |
| 11:21 |
|
darkybinlio joined #evergreen |
| 11:21 |
darkybinlio |
hi the install intrusions seem to be 404? |
| 11:40 |
jeff |
usually there are install instructions in the tar archive once you extract it. |
| 11:40 |
jeff |
that daid, what link is 404 and what document linked to that url? |
| 12:25 |
bshum |
Uh |
| 12:26 |
bshum |
downloads is gone, so is docs, etc. |
| 12:28 |
bshum |
Basically all links are pointing to nonexistent directories |
| 12:38 |
* bshum |
typed up an email for the team |
| 12:38 |
bshum |
Time to test if we have backups... |
| 13:23 |
|
darkdrgn2k joined #evergreen |
| 13:23 |
|
darkdrgn2k joined #evergreen |
| 13:23 |
|
darkdrgn2k joined #evergreen |
| 16:48 |
csharp |
thankfully we have a good backup strategy and restoring was possible/easyu |
| 16:48 |
csharp |
easy |
| 16:48 |
rhamby |
eh, it happens, thanks for the restore |
| 17:01 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-03-09T16:58:50,722593620-0500 -0> |
| 18:05 |
|
beanjammin joined #evergreen |
| 18:36 |
jeff |
csharp++ |
| 23:19 |
|
darkdrgn2k3 joined #evergreen |
| 00:39 |
|
sandbergja joined #evergreen |
| 02:09 |
|
yar joined #evergreen |
| 05:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:55 |
|
Dyrcona joined #evergreen |
| 06:59 |
|
agoben joined #evergreen |
| 07:05 |
|
jamesrf joined #evergreen |
| 11:53 |
berick |
miker: I feel like a dummy. Anyway, I like how your branch adds smarts to FormatService (plus grid additions), so it can be used in grid and non-grid contexts and I like how mine adds the logic to pcrud so it's not limited to admin pages. I'd like to merge the two if that works for you. |
| 11:53 |
berick |
s/the logic/the link-fleshing logic/ |
| 11:54 |
terran |
berick++ for commits! |
| 11:55 |
miker |
berick: +1. one thought, instead of using virtual=true, should we use reltype={has_a|might_have} instead? (though we may have to be careful of map=$something) |
| 11:56 |
miker |
so that we can do might_have, that is |
| 11:56 |
miker |
or... are those not virtual... gah, going to go confirm |
| 11:57 |
miker |
might_have is virtual, so we'd need to test reltype for that |
| 11:58 |
miker |
(we could make map=$something cases work, of course, by jumping through the remote link) |
| 12:00 |
miker |
FTR, there are only 2 instances of might_have with a map |
| 12:00 |
miker |
they're on bre: metarecord and language |
| 12:00 |
berick |
miker: so instead of this: filter(f => f.datatype === 'link' && !f.virtual) |
| 12:00 |
berick |
something like: filter(f => f.datatype === 'link' && (f.rel_type === 'has_a' || f.rel_type === 'might_have')) |
| 12:01 |
miker |
right, that's my thought. though I'm not sure if we surface the map attr in idl2JS |
| 12:03 |
miker |
we ... don't seem to: {name:"metarecord",label:"Metarecord",virtual:true,type:"link",key:"source","class":"mmrsm",reltype:"might_have",datatype:"link"} |
| 12:04 |
miker |
berick: but ... we don't show non-virt fields in grids via * in any case, do we? |
| 12:04 |
berick |
miker: that's true, it filters those out when auto-generating fields |
| 12:05 |
miker |
however, I'd still advocate for testing reltype='has_a' rather than virtual='false' |
| 12:06 |
miker |
because if we do expand to showing might-have's (or even doing something smarter with has_many's, like counts or something) then it's more obvious. |
| 12:06 |
miker |
IOW |
| 12:07 |
miker |
filter up front via virtual now, and work on the result based on the more direct description (reltype). that feels like a better separation of concerns to me |
| 12:07 |
berick |
+1 |
| 12:08 |
miker |
awesome, thanks berick! |
| 12:08 |
miker |
berick++ |
| 13:39 |
pinesol |
[evergreen|Chris Sharp] LP#1709698 - stamping upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c20bfea> |
| 13:48 |
Dyrcona |
Calling 1157 |
| 14:02 |
|
terran joined #evergreen |
| 14:03 |
pinesol |
[evergreen|Bill Erickson] LP#712490 Vandelay merge-based field replacement - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=23293c7> |
| 14:03 |
pinesol |
[evergreen|Bill Erickson] LP#712490 Vandelay replace/merge PGTAP tests - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=99b75e0> |
| 14:03 |
pinesol |
[evergreen|Jason Stephenson] Lp 712490: Stamping UPgrade Script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f098f38> |
| 14:16 |
terran |
abneiman++ for hitting 100 tag/bug updates! |
| 14:17 |
csharp |
calling 1158 |
| 14:17 |
abneiman |
:-D I knew I was close but thanks for the shoutout! |
| 16:37 |
abneiman |
yeah, I'm looking at the oldest ones still marked "new" |
| 16:44 |
|
jamesrf joined #evergreen |
| 17:01 |
|
jvwoolf1 left #evergreen |
| 17:01 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-03-08T16:58:14,635466859-0500 -0> |
| 17:06 |
|
mmorgan left #evergreen |
| 17:12 |
terran |
Wrapping up my day, but on Monday I will update the Bug Squashing Week chart with everything that comes in through midnight :D (Like, you'll all be working on this on a Friday night) |
| 17:50 |
|
yboston joined #evergreen |
| 02:33 |
|
beanjammin joined #evergreen |
| 05:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:06 |
|
agoben joined #evergreen |
| 07:07 |
|
rjackson_isl joined #evergreen |
| 07:35 |
|
bos20k joined #evergreen |
| 09:35 |
|
sandbergja joined #evergreen |
| 09:46 |
|
yboston joined #evergreen |
| 10:13 |
|
Christineb joined #evergreen |
| 10:19 |
pinesol |
[evergreen|Jane Sandberg] Docs: Fixing broken link - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7f7919e> |
| 10:20 |
|
beanjammin joined #evergreen |
| 10:42 |
|
jvwoolf joined #evergreen |
| 10:43 |
terran |
mmorgan++ for finding the link to my patch when I forgot to include it :D |
| 11:48 |
Bmagic |
vs |
| 11:48 |
Bmagic |
https://missourievergreen.org/eg/opac/results?query=dog&qtype=keyword&fi%3Asearch_format=&locg=1&detail_record_view=1&sort= |
| 11:49 |
Bmagic |
26 seconds for gapines, 14 seconds on missourievergreen |
| 11:51 |
Bmagic |
It's not quite apples to apples of course, due to the db's not having the exact same data. The test machine with the exact same data is here http://104.155.152.239/eg/opac/home |
| 11:53 |
csharp |
Bmagic: maybe a comparison of queries and explain data would help? |
| 11:53 |
Bmagic |
yeah, good point |
| 11:54 |
Bmagic |
I've been here before, and the two versions of evergreen are fundamentally different in the search strategy. No conclusion |
| 12:48 |
Bmagic |
ty |
| 12:48 |
csharp |
if it weren't for the move from QTS -> ITS, we would have already moved to Ubuntu 18.04/PG 10 |
| 12:49 |
csharp |
probably do that over Labor Day |
| 12:50 |
Dyrcona |
Someone (me?) should start testing with Pg 11. We only started looking at Pg 10 when 11 was released. :) |
| 12:55 |
|
jvwoolf joined #evergreen |
| 13:06 |
Bmagic |
fresh reboot, same cats query 190 seconds! |
| 13:06 |
Bmagic |
collapsable join was at 10 |
| 13:18 |
Bmagic |
yeah, but that was the point of rebooting |
| 13:18 |
Bmagic |
restarting postgres wasn't enough |
| 13:18 |
Bmagic |
what's the command to warm up the cache after reboot? |
| 13:19 |
jeffdavis |
You don't want your test query in cache, but you want indexes etc to be cached so that performance is normal (or else test on two different cold-cache servers I guess) |
| 13:21 |
jeffdavis |
doing some other searches or typical queries and/or vacuuming metabib index tables might help, I'm not actually sure what's best beyond letting the server get used a bit |
| 13:23 |
jeffdavis |
you could ask in #postgres for advice on benchmarking and cache issues |
| 13:25 |
Bmagic |
yeah, it's hard to get a good test after changing those config points |
| 13:25 |
Bmagic |
to know whether or not the change made a difference |
| 13:26 |
|
sandbergja_ joined #evergreen |
| 13:35 |
Dyrcona |
Bmagic: Find your database's oid: select oid from pg_database where datname = 'evergreen'; -- Assuming your database is named evergreen and you run that query in the postgres database. |
| 14:30 |
|
littlet_ joined #evergreen |
| 14:31 |
terran |
Okay, thanks |
| 14:32 |
terran |
I've been removing some of the unofficial tags if there is a better existing term already in place |
| 14:32 |
abneiman |
another one I've been wondering about but haven't looked into -- test-writing-day-1 |
| 14:32 |
abneiman |
https://bugs.launchpad.net/evergreen/+bugs?field.tag=test-writing-day-1 |
| 14:34 |
abneiman |
All file by Liam Whalen, 3 years ago, seemingly about things that need tests written. We typically use needstest to flag new code that needs a unit/pgtap tests, so I'm not sure that applies here, but it seems like a bit of a one-off |
| 14:35 |
abneiman |
oh, mmorgan does have one with that tag too, my mistake. mmorgan please chime in if you have thoughts on this. |
| 14:38 |
terran |
I'm unsure about that one as well |
| 14:39 |
mmorgan |
abneiman: Looks like Liam added the tag to bug 1331174, I have no strong feelings about that tag. |
| 14:39 |
terran |
Was it flagging things that needed end user test instructions added? |
| 14:39 |
pinesol |
Launchpad bug 1331174 in Evergreen "Long Overdue processing needs org unit settings separate from Lost Processing" [Wishlist,Confirmed] https://launchpad.net/bugs/1331174 |
| 14:39 |
abneiman |
http://libmail.georgialibraries.org/pipermail/open-ils-dev/2015-November/009998.html |
| 14:41 |
abneiman |
and here https://wiki.evergreen-ils.org/doku.php?id=dev:test_writing_day |
| 16:22 |
|
yboston joined #evergreen |
| 16:32 |
* csharp |
plans to work on committing more tomorrow too |
| 16:56 |
|
afterl left #evergreen |
| 17:01 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-03-07T16:59:16,091764708-0500 -0> |
| 17:07 |
|
mmorgan left #evergreen |
| 17:13 |
|
jamesrf joined #evergreen |
| 17:14 |
|
jvwoolf left #evergreen |
| 00:12 |
|
sandbergja joined #evergreen |
| 04:13 |
|
beanjammin joined #evergreen |
| 05:00 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-03-05T04:58:06,059464870-0500 -0> |
| 07:03 |
|
agoben joined #evergreen |
| 07:12 |
|
rjackson_isl joined #evergreen |
| 07:29 |
|
book` joined #evergreen |
| 10:12 |
terran |
littlet++ for getting over 100 Bug Squashing Week updates on the chart already! |
| 10:17 |
mmorgan |
littlet++ |
| 10:31 |
tlittle |
:) |
| 10:44 |
terran |
There are 7 new patches ready for testing if anyone wants to take a stab at them: https://docs.google.com/spreadsheets/d/1x_sZcEaP62J42KcB03AUn1I1MSZQpPI5mF9r0Zrmhgo/edit?usp=sharing |
| 11:19 |
csharp |
where does the new ng stuff get installed? |
| 11:20 |
csharp |
if I want to rebuild on a live server, where do I do that? |
| 11:20 |
|
khuckins joined #evergreen |
| 14:14 |
sandbergja |
for an added dash of mystery |
| 14:15 |
csharp |
argh - still seeing it |
| 14:15 |
csharp |
yeah, I'm in FF |
| 14:15 |
dbwells |
csharp: yes, I only tested in Chrome, and it also worked for me there. |
| 14:16 |
csharp |
same behavior in Chrome for me |
| 14:16 |
berick |
and I'm not seeing it in FF |
| 14:16 |
berick |
csharp: just to confirm, the page doesn't render or it's an error in the console? |
| 16:48 |
terran |
berick: thanks, I'll open a bug report |
| 16:58 |
terran |
berick: never mind, there's already a bug report and gmcharlt already has a fix and rhamby has already signed off :) gmcharlt++ rhamby++ |
| 16:58 |
terran |
https://bugs.launchpad.net/evergreen/+bug/1812389 |
| 16:58 |
pinesol |
Launchpad bug 1812389 in Evergreen "Group Penalty Threshold link does not work" [Medium,Confirmed] |
| 17:00 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-03-05T16:58:45,793808627-0500 -0> |
| 17:05 |
berick |
terran: clearly you have magical powers |
| 17:05 |
terran |
I can control space and time. Everybody knows that. |
| 17:09 |
|
mmorgan left #evergreen |
| 17:38 |
rhamby |
abneiman++ for getting rid of cruft, the more invalid/won'tfix bug we mark out the better we can identify ones we actually need to work on |
| 17:41 |
littlet |
abneiman++ for tag updating and updating the official tag list! I also love the controlled vocab :D |
| 17:48 |
gsams |
Bmagic: We are running 3.1 in production. |
| 17:50 |
makohund |
I've gone through every single line in osrfsys.log for my last test import (roughly 1000 lines), and haven't found anything wrong there. Yet. |
| 17:52 |
gsams |
abneiman++ #Didn't even know I was still on a list for notification on some of these! |
| 17:56 |
Bmagic |
gasms++ |
| 17:56 |
Bmagic |
gsams++ #even |
| 18:04 |
Bmagic |
that's very very close now |
| 18:05 |
Bmagic |
my patch works but the real answer is upgrading to the absolute latest version of java fx |
| 18:07 |
Bmagic |
berick figured that out berick++ |
| 18:07 |
gsams |
berick++ |
| 18:08 |
gsams |
Well, if you need someone to test/signoff I will happily jump at it, it'd resolve the biggest issue we currently have. |
| 18:08 |
berick |
need to get a little more broad resposne to my proposal of packaing jre in the installer |
| 18:08 |
berick |
once we're thumbs-up there, we can update the Hatch installer |
| 18:08 |
gsams |
Awesome |
| 03:10 |
|
beanjammin joined #evergreen |
| 03:42 |
|
jamesrf joined #evergreen |
| 05:00 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-03-04T04:57:50,470383187-0500 -0> |
| 07:05 |
|
JBoyer joined #evergreen |
| 07:13 |
|
agoben joined #evergreen |
| 07:14 |
|
rjackson_isl joined #evergreen |
| 10:36 |
terran |
StomproJosh++ extra karma anyhoo |
| 10:38 |
jeff |
launchpad-- |
| 10:39 |
jeff |
terran: are you working on bug 1777677? you're currently assigned. |
| 10:39 |
pinesol |
Launchpad bug 1777677 in Evergreen "Test notification method" [Wishlist,New] https://launchpad.net/bugs/1777677 - Assigned to Terran McCanna (tmccanna) |
| 10:39 |
Dyrcona |
StomproJosh++ |
| 10:41 |
|
terran_ joined #evergreen |
| 10:41 |
terran_ |
@jeff - nope, sorry, forgot to take my name off |
| 12:02 |
Dyrcona |
littlet: Just ask and if anyone can answer, they will. |
| 12:03 |
* Dyrcona |
uses iptable to combat "Bobby Tables." :) |
| 12:03 |
* Dyrcona |
can't type. :( |
| 12:04 |
littlet |
Thanks :) So, I'm trying to play around with the new Angular stuff, and just to change something simple, like a label or something to see the change show on my test server. But nothing I do changes anything--even if I change a label to say 'Cancel Reasons TESTING', it doesn't change. |
| 12:04 |
littlet |
I've cleared cache and cookies, and Googled, and I don't know if I'm just not Googling well... |
| 12:05 |
Dyrcona |
littlet: Did you just copy the file into place or edit in place, or did you the ng build --prod step, and then do make install? |
| 12:06 |
littlet |
I just edited in place |
| 12:09 |
Dyrcona |
I think you should edit it in the source code, then do the ng build --prod and make install steps. |
| 13:27 |
mmorgan |
One less bug needing squashing! |
| 13:27 |
Bmagic |
Now that I'm on a roll: Record bucket searching by ISBN doesn't seem to use the same methods as an OPAC search. Specifically the 10/13 normalizer is not taken into account. Is that a bug? |
| 13:34 |
jihpringle |
Bmagic: my vote would be searching for the ISBN should work the same throughout the OPAC/staff client |
| 13:35 |
Bmagic |
yeah, agreed. Not sure what the underlying record bucket search uses, but based upon some test examples, it's not using the same methods as OPAC search |
| 13:36 |
* mmorgan |
would agree also, but wonders how it worked in the xul client |
| 13:40 |
mmorgan |
Bmagic: xul client record bucket search on isbn also does not employ the isbn 10/13 normalizer. So it was always broken :-( |
| 13:40 |
jihpringle |
I suspect buckets weren't the same as the OPAC in the xul client which might make this more of a new feature (change of existing behaviour) than a bug |
| 14:25 |
Dyrcona |
jeff: Are you working on bug 1519879? |
| 14:25 |
pinesol |
Launchpad bug 1519879 in Evergreen "SIP Precedence Warning, possible logic issue" [Undecided,Confirmed] https://launchpad.net/bugs/1519879 - Assigned to Jeff Godin (jgodin) |
| 14:26 |
jeff |
I wasn't, but I can be. Dusting off memories... |
| 14:27 |
Dyrcona |
The fix is exactly as mentioned in the description, use && instead of and. I've verified it with a test script. |
| 14:28 |
Dyrcona |
As long as circ is not blocked, it always returns true the was it is written. |
| 14:28 |
Dyrcona |
So, I can post a branch if you don't have the time. |
| 14:29 |
jeff |
go ahead, if you beat me to the branch i can signoff/merge. i think there was something more subtle (and the reason i grabbed and was going to comment on it), but as you can see, there's no comment. |
| 16:45 |
makohund |
though I'm not sure I ever tried it back on jessie on this machine either, so it may have been broken all along |
| 16:53 |
|
Bmagic joined #evergreen |
| 16:56 |
|
mnsri_away joined #evergreen |
| 17:00 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-03-04T16:58:41,171347372-0500 -0> |
| 17:03 |
|
mmorgan left #evergreen |
| 17:39 |
makohund |
I'm not outta the woods yet... inspecting my import queue, none of the descriptive fields show anything at all (Title, Author, ISBN, etc). Even though the fields are there if I view MARC. (Or look at it in vandelay.queued_record, or vandelay.queued_bib_record.) And if I import the same file again, expecting matches to be found... nope. |
| 17:40 |
makohund |
I import the same test file on our production system... no such problems. Fields are fleshed out, second import matches on all records, etc. |
| 19:12 |
|
dickreckard joined #evergreen |
| 19:30 |
|
beanjammin joined #evergreen |
| 19:34 |
|
jvwoolf joined #evergreen |
| 19:39 |
|
jvwoolf left #evergreen |
| 19:53 |
makohund |
I've just confirmed that my import problem predates my buster upgrade test... I jumped back to a vm snapshot on old evergreen version on jessie... importing was fine. Jumped forward to stretch, and no import, until changing it from /tmp to somewhere else. Now records import, but no matching and no data in the fields on the inspect queue screen. Hmm. |
| 20:33 |
|
beanjammin joined #evergreen |
| 21:28 |
|
sandbergja joined #evergreen |
| 22:07 |
|
sandbergja joined #evergreen |
| 01:09 |
|
jamesrf joined #evergreen |
| 05:02 |
pinesol |
News from qatests: Failed Installing some build essentials <http://testing.evergreen-ils.org/~live/test.4.html#2019-02-27T04:55:21,162334599-0500 -0> |
| 05:02 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-02-27T04:55:21,191140280-0500 -2> |
| 05:02 |
pinesol |
News from qatests: Failed Running pgTAP live tests <http://testing.evergreen-ils.org/~live/test.47.html#2019-02-27T04:55:21,220190182-0500 -4> |
| 06:39 |
|
stephengwills joined #evergreen |
| 07:09 |
|
agoben joined #evergreen |
| 07:13 |
|
rjackson_isl joined #evergreen |
| 15:44 |
Dyrcona |
If it doesn't do this already, it should detect the language of the browser and switch automatically. |
| 15:46 |
Bmagic |
"That's like, your opinion man" -The Dude |
| 15:47 |
Dyrcona |
It's an informed opinion. |
| 15:48 |
jihpringle |
Bmagic: I've seen the same thing on the 3.2 server we set up to test French on, it doesn't like to switch back to English |
| 15:50 |
Bmagic |
oh good, glad it's not just me |
| 15:51 |
jihpringle |
it's on my list to test further and report to launchpad |
| 15:59 |
bshum |
jihpringle: Bmagic: Yeah the switcher is touchy for sure. I've found it's easier to use TPAC to change my language cookie setting, and then use that with my staff client |
| 16:00 |
bshum |
And also, because of how the i18n PO files are broken up, sometimes you get colliding values where the TPAC translated string doesn't match the staff client version of something |
| 16:00 |
bshum |
"name" is a bad example" |
| 16:39 |
JTaylor_ |
or if, that is. |
| 16:59 |
JTaylor_ |
Guess not :-) Will try again sometime. |
| 16:59 |
|
JTaylor_ left #evergreen |
| 17:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 21:43 |
|
sandbergja joined #evergreen |
| 04:30 |
|
phasefx joined #evergreen |
| 04:30 |
|
maryj joined #evergreen |
| 04:35 |
|
dbs_ joined #evergreen |
| 05:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:14 |
|
Dyrcona joined #evergreen |
| 06:15 |
Dyrcona |
So, our fine generator got stuck twice last night. Nothing in the logs, literally, after 9 seconds from its start time. |
| 06:16 |
Dyrcona |
Well, nothing from the fine generator or the storage service. |
| 15:28 |
jeff |
Ah. *nod* |
| 15:28 |
jeff |
Less flat. |
| 15:28 |
csharp |
we've chased our tail more than once trying to add carriers for some of these off-brand cellular companies (and some more well-known ones) |
| 15:29 |
jeff |
More "not without official documentation from the carrier in question" and perhaps even "a patron willin to test" :-) |
| 15:29 |
jeff |
Which in some cases reduces/simplifies to "No." |
| 15:30 |
csharp |
I guess that's the other nuance that de-flattens my "no" - the patron is welcome to request that information of the carrier :-) |
| 15:31 |
jeff |
I'm pretty sure I've made my strong feelings about this known, but in case anyone's interested in trying the "eliminate the email to text gateways" approach, I'd be interested in helping / collaborating. :-) |
| 15:31 |
jeff |
I think that Stompro is on that short list. |
| 16:25 |
csharp |
jeff: I don't remember right this moment, but I'm pretty sure we group them so it's not an insane number of texts per patron |
| 16:31 |
|
yboston joined #evergreen |
| 16:40 |
|
makohund joined #evergreen |
| 16:47 |
makohund |
A while back I mentioned wanting to try out evergreen on debian buster. (Was upgrading our test server from jessie to stretch, and kept going.) And I'm happy to report that it is done, and working just fine. :) |
| 16:48 |
bshum |
Buster? Lol, awesome |
| 16:48 |
Dyrcona |
makohund: Do you have a git branch to update the prerequisite installers? |
| 16:49 |
Bmagic |
makohund++ |
| 16:52 |
makohund |
Biggest prob was ejabberd... change to default internal hostname. Eventually just reinstalled & configured it from scratch. |
| 16:53 |
|
khuckins joined #evergreen |
| 16:59 |
makohund |
Found the message about it... the release note for 17.08-1... https://github.com/jabber-at/ejabberd/blob/master/debian/NEWS |
| 17:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:05 |
|
sandbergja_ joined #evergreen |
| 17:05 |
makohund |
Instead of the ejabberd config notes for stretch, follow the ones for ubuntu bionic. Except can't just uncomment mod_legacy_auth, have to add it. |
| 17:08 |
|
mmorgan left #evergreen |
| 17:26 |
Bmagic |
oh! |
| 17:26 |
Bmagic |
the "default" printer bug? |
| 17:26 |
berick |
Bmagic: i wanted to see if we could avoid the big fork in the code |
| 17:27 |
makohund |
sandbergja_: I'm finally done monkeying around with the test server |
| 17:27 |
berick |
Bmagic: https://bugs.openjdk.java.net/browse/JDK-8088918 |
| 17:27 |
Bmagic |
berick: so the work around using JEditorPane isn't needed? |
| 17:28 |
berick |
the fix was a side effect of this bug, a toss-away comment basically that got some love |
| 17:30 |
berick |
Bmagic: that was part of my concern, thinking it might be brittle over time |
| 17:30 |
* berick |
will document findings |
| 17:30 |
Bmagic |
berick++ |
| 17:31 |
berick |
I have a tine return address label here now that just says "test" |
| 17:31 |
berick |
s/tine/tiny/ |
| 17:31 |
Bmagic |
oh man! The feeling of seeing that printer spit anything out for the first time is euphoric |
| 17:32 |
Bmagic |
RE: brittle over time - I did write in my comments "well, crap" |
| 17:32 |
Bmagic |
:) |
| 05:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:04 |
|
littlet joined #evergreen |
| 07:18 |
|
agoben joined #evergreen |
| 07:21 |
|
pinesol` joined #evergreen |
| 14:33 |
JBoyer |
Speaking as one of the 3 most recently elected (and potentially only returning!) members, I would love to see some folks with experience cme back. |
| 14:34 |
hbrennan |
JBoyer: Agreed. I can't step up to serve any more than a seat filler, unfortunately |
| 14:37 |
JBoyer |
:) |
| 14:39 |
* csharp |
cheers on pg_basebackup to move a bit faster restoring on a test server |
| 14:39 |
csharp |
go! go! go! |
| 14:45 |
* Dyrcona |
uses pg_restore, but has used pg_basebackup, and the latter is probably faster. |
| 14:47 |
JBoyer |
pg_restore -j $BIG_NUM is really nice. |
| 14:58 |
csharp |
pg_basebackup is basically rsync with WAL streaming on the side |
| 15:00 |
Dyrcona |
I usually use -j 8 with pg_restore. |
| 15:00 |
Dyrcona |
There's always that one index that takes forever. :) |
| 15:01 |
csharp |
yeah |
| 15:01 |
JBoyer |
csharp, well, if the db is going to be hooked up to streaming rep afterword pg_basebackup is by far the best way to go, but for a testing server I figure it's quicker to let the metabib.real_full_rec index rebuild than transfer every byte of data. :) |
| 15:02 |
csharp |
you may be right |
| 15:03 |
csharp |
I've done it different ways over the years - pg_basebackup is nice because it has a progress meter and when you're done, it just starts up and you're good |
| 15:03 |
Dyrcona |
Well, that's how you set up the rep server: pg_basebackup, then fire it up. |
| 15:03 |
csharp |
right |
| 15:04 |
Dyrcona |
That's the couple of times I've used pg_basebackup. For our test/development db server, I just restore a dump every Sunday morning. |
| 15:04 |
JBoyer |
There's certainly appeal there, just waiting for pg_restore to go away without knowing where it's at is a little annoying (other than peeking at pg_stat_activity, which is no replacement for a progress bar) |
| 15:09 |
Dyrcona |
pgrep -af postgres |
| 15:19 |
JBoyer |
That's a handy one. Calling pgrep -af postgres | wc -l in a loop will give you a countdown, which is sort of like progress. :) |
| 16:49 |
jvwoolf |
We had a library report that an advanced search limiter gets wiped out after they add volumes to an item |
| 16:51 |
csharp |
@who would like to play bug or feature? |
| 16:51 |
pinesol |
phasefx_ would like to play bug or feature. |
| 16:51 |
jvwoolf |
I tested and it looks like the catalog will hold onto the filter if you stay on the results screen, but if you click on a record, it gets wiped out, even if you go back to the results |
| 16:52 |
mmorgan |
@decide bug or feature |
| 16:52 |
pinesol |
mmorgan: go with feature |
| 16:52 |
* mmorgan |
doesn't agree |
| 16:53 |
sandbergja |
jvwoolf: do you have an OPAC link you could share? |
| 16:54 |
sandbergja |
or is this in the staff client? |
| 16:55 |
mmorgan |
If you're getting back to the results screen that came from the filter, it sounds like a bug that the filter doesn't carry back there. |
| 17:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:05 |
|
mmorgan left #evergreen |
| 17:07 |
jvwoolf |
sandbergja: Both places |
| 17:08 |
jvwoolf |
Just realized the time though and need to get going. I think I have my answer, though. Will file a bug report tomorrow. |
| 00:22 |
|
jamesrf joined #evergreen |
| 03:39 |
|
felicia joined #evergreen |
| 04:08 |
|
jamesrf joined #evergreen |
| 05:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:12 |
|
rjackson_isl joined #evergreen |
| 07:36 |
|
bdljohn joined #evergreen |
| 07:47 |
|
jamesrf joined #evergreen |
| 13:07 |
|
jvwoolf joined #evergreen |
| 13:18 |
|
seymour joined #evergreen |
| 13:21 |
|
yboston joined #evergreen |
| 13:27 |
abneiman |
JBoyer / Dyrcona -- thanks for testing & rebasing -- as miker is out this week it looks like (barring a Hail Mary) this will have to fall back to 3.4 |
| 13:27 |
JBoyer |
+! |
| 13:27 |
JBoyer |
+1 |
| 13:28 |
JBoyer |
I also had enough issues rebasing when I loaded it that I'm not putting a hand on that football today. |
| 15:53 |
|
jamesrf joined #evergreen |
| 15:57 |
|
beanjammin joined #evergreen |
| 16:03 |
|
jvwoolf1 joined #evergreen |
| 16:33 |
sandbergja |
Christineb: jeffdavis: dbwells: bug 1797934 should be ready for more testing |
| 16:33 |
pinesol |
Launchpad bug 1797934 in Evergreen "Ability to view booking reservations (reserved, captured, and out) in My Account in the OPAC" [Wishlist,Confirmed] https://launchpad.net/bugs/1797934 |
| 16:36 |
dbwells |
sandbergja: thanks, I am going to ask remingtron to look it over |
| 16:36 |
sandbergja |
dbwells++ |
| 16:36 |
sandbergja |
remingtron++ |
| 16:37 |
dbwells |
berick: I've been testing and am interested in pushing in bug #1806087 , and have a couple questions. |
| 16:37 |
pinesol |
Launchpad bug 1806087 in Evergreen "Angular staff catalog continued (cira 3.2)" [Wishlist,New] https://launchpad.net/bugs/1806087 - Assigned to Dan Wells (dbw2) |
| 16:38 |
berick |
dbwells: *nod* |
| 16:40 |
dbwells |
berick: It has rough edges, which seems find to me at this "experiemental" stage. I am wondering if it might be best to leave the bug open and treat it as potentially an integration/collab point rather than add little bugs which get out of sync. Do you think that makes sense? |
| 16:51 |
dbwells |
okay, will push and comment on the existing bug. Thank you, berick |
| 16:51 |
berick |
dbwells++ |
| 17:00 |
dbwells |
grabbing 1152 |
| 17:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:03 |
sandbergja |
Bugging any core committers who have the time: Christineb was kind enough to test and sign off on bug 1790727 |
| 17:03 |
pinesol |
Launchpad bug 1790727 in Evergreen "New feature: add a daily schedule view of existing bookings" [Wishlist,Confirmed] https://launchpad.net/bugs/1790727 |
| 17:04 |
sandbergja |
Does anybody have the time/energy to take a look at getting it into 3.3? |
| 17:06 |
|
mmorgan left #evergreen |
| 01:35 |
|
jamesrf joined #evergreen |
| 03:56 |
|
book` joined #evergreen |
| 04:15 |
|
book` joined #evergreen |
| 05:00 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-02-13T04:57:40,631260384-0500 -0> |
| 07:03 |
|
agoben joined #evergreen |
| 07:07 |
|
rjackson_isl joined #evergreen |
| 07:40 |
|
littlet joined #evergreen |
| 13:06 |
|
abowling joined #evergreen |
| 13:07 |
JBoyer |
anyone else actively looking at bug 1749475 |
| 13:07 |
pinesol |
Launchpad bug 1749475 in Evergreen "wishlist: Improved email and printing from the OPAC" [Wishlist,New] https://launchpad.net/bugs/1749475 |
| 13:07 |
JBoyer |
csharp, I know it's on some of your test machines but since terran's not in channel I didn't know if you were aware of any issues she's still seeing? |
| 13:09 |
* csharp |
tries to summon terran |
| 13:12 |
|
terran joined #evergreen |
| 13:14 |
berick |
it worked! |
| 17:02 |
|
jvwoolf1 left #evergreen |
| 17:07 |
|
mmorgan left #evergreen |
| 19:08 |
|
makohund joined #evergreen |
| 19:19 |
makohund |
Are there any obvious/common causes for the web staff client to fail to operate? Login prompt there, but won't login or do anything? I have websockets supposedly proxied by nginx so I don't think it's as simple as connectivity, but who knows. |
| 19:20 |
makohund |
Test server, not production. EG 3.1.2. |
| 19:25 |
devted |
makohund: Check if memcached and ejabberd are running |
| 19:26 |
devted |
Check logs: tail -f /var/log/apache2/*log /openils/var/log/*log /var/log/syslog /var/log/nginx/*log |
| 19:26 |
makohund |
yes to both services, the rest of EG is working fine |
| 11:23 |
|
jvwoolf joined #evergreen |
| 11:26 |
|
khuckins joined #evergreen |
| 11:30 |
Bmagic |
mmorgan: post upgrade to 3.1, the default virtual index on title is blank. Which (I think) means that the search method will continue to function the old way. But when introducing a single entry for "Main Title" - it should switch to using the virtual index method when searching? |
| 11:32 |
Bmagic |
Dyrcona: what would we lose if we switched to github? Working repo linkage? Automatic tests? Or maybe nothing? We would just have to do a bunch of work to make the transition? |
| 11:33 |
Dyrcona |
Bmagic the automated tests have nothing to do with gitolite, i.e. they're scripted outside of git. |
| 11:34 |
Dyrcona |
We'd have to change how we work with branches, and I'd recommend losing the working repository in favor of everyone having their own. I'd make the same recommendation switching to gitlab. |
| 11:35 |
Dyrcona |
Free github accounts for users and the organization look like our best option. |
| 11:35 |
Bmagic |
github seems like it will be around for awhile |
| 11:37 |
Dyrcona |
Yes it is, and DIG uses github though not exclusively. |
| 11:40 |
mmorgan |
Bmagic: In 3.1, the only virtual index configured by default is for keyword. Did you add an entry for a title virtual index in config.metabib_field? |
| 11:42 |
Bmagic |
hmm, I need to insert into that table manually? |
| 11:47 |
mmorgan |
Hmm. Maybe not. We've tested a lot with the keyword virtual index, but haven't looked at adding title virtual indexes yet. It looks like you can configure them in the client. |
| 11:58 |
|
aabbee joined #evergreen |
| 11:59 |
Bmagic |
mmorgan: It seems that an entry in config.metabib_field might be required to "look" like the entry for "All searchable fields" - Main Title has an xpath with it, and "All searchable fields" does not |
| 12:03 |
mmorgan |
Bmagic: Yes, I made that assumption, but the documentation suggests that you can add virtual maps to existing indexes, too. http://docs.evergreen-ils.org/3.1/_virtual_index_definitions_2.html |
