| 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. |
| 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 |
| 05:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:03 |
|
agoben joined #evergreen |
| 07:12 |
|
rjackson_isl joined #evergreen |
| 07:50 |
|
JBoyer joined #evergreen |
| 11:15 |
Bmagic |
gmcharlt: wow! How long has it been? I can't remember that going down. |
| 11:16 |
gmcharlt |
Bmagic: a bit too long, let's just say :) |
| 11:16 |
Bmagic |
:) |
| 11:16 |
csharp |
hah |
| 11:16 |
csharp |
Bmagic: I have the same question re: adding a config.metabib_field - I'm guessing a reingest is required? |
| 11:17 |
csharp |
we're testing the field mmorgan suggested to fix the 245c display issue |
| 11:17 |
Bmagic |
The virtual index release notes and documentation make it sound like you only need to restart the services |
| 11:17 |
|
bos20k joined #evergreen |
| 11:17 |
|
collum joined #evergreen |
| 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 |
| 16:53 |
|
stephengwills left #evergreen |
| 16:56 |
jamesrf |
I am looking at some code and cstore turns {"value":"{1,2,3}"} into = '{1,2,3}' ... is there a time when it might not have added the single quotes? |
| 16:57 |
jamesrf |
see LP 1807784, just trying to figure out if this code maybe worked at one time 10 years ago and maybe there was a logical reason for dollar-quoting but subsequently single-quoting was added and broke this? |
| 16:57 |
pinesol |
Launchpad bug 1807784 in Evergreen "Booking - limiting by item attributes does not limit available resources" [Undecided,New] https://launchpad.net/bugs/1807784 |
| 17:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:08 |
|
mmorgan left #evergreen |
| 17:11 |
|
khuckins joined #evergreen |
| 17:43 |
|
jvwoolf left #evergreen |
| 03:42 |
|
jeff joined #evergreen |
| 03:44 |
|
yar joined #evergreen |
| 05:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:03 |
|
agoben joined #evergreen |
| 07:07 |
|
rjackson_isl joined #evergreen |
| 07:44 |
|
tlittle joined #evergreen |
| 09:33 |
* csharp |
has mixed feelings too |
| 09:33 |
* JBoyer |
would like the ability to design attrative html mails, but only if there's a usable plaintext alt-part for the plaintexters. |
| 09:33 |
csharp |
+1 |
| 09:35 |
* Dyrcona |
is going to try websocketd 0.3.1 on his test vm. |
| 09:35 |
JBoyer |
my understanding is that it's perfectly possible even now, but you've got to insert the multipart delimiter yourself and write both segments manually, yes? I'm not expecting our SendEmail reactor to pull out the plaintext as part of the process. |
| 09:35 |
mmorgan |
JBoyer: Yes, I can get you more detail. There were issues with the punctuation around those fields, too, which we (not me personally ;-)) addressed in tt2 files. |
| 09:35 |
JBoyer |
mmorgan++ |
| 14:54 |
Dyrcona |
I seem to recall Lp not liking certain characters in tags. |
| 15:09 |
Dyrcona |
And, Email::MIME and friends allow you to make nonconforming email messages, according to RFC 2822. |
| 15:14 |
Dyrcona |
If you pass a list to $email->header_set and family, you get multiple header entries. |
| 15:15 |
Dyrcona |
The address headers are only allowed to appear once per message, though my limited testing indicates multiple To: fields "works" even though the message is strictly illegal..... |
| 15:15 |
Dyrcona |
It's never as simple as you think. :) |
| 15:16 |
Dyrcona |
It's email. How complicated could it be? :) |
| 15:16 |
* jeff |
laughs |
| 15:23 |
Dyrcona |
maybe that's i may fault... |
| 15:23 |
Bmagic |
nfBurton: ansible for restarting services post boot: https://github.com/mcoia/eg-docker/blob/master/docker_builds/generic-dockerhub/restart_post_boot.yml |
| 15:24 |
Dyrcona |
So, it was... |
| 15:24 |
Dyrcona |
My test script wasn't decoding the message, first. SendEmail.pm is already doing that, so that's why it worked in one place but not the other. |
| 15:26 |
Dyrcona |
So, looks like I have a fix for bug 1801163. |
| 15:26 |
pinesol |
Launchpad bug 1801163 in Evergreen "SendEmail A/T reactor broken for recent version of Encode::MIME::Header" [High,In progress] https://launchpad.net/bugs/1801163 - Assigned to Jason Stephenson (jstephenson) |
| 15:31 |
Dyrcona |
And, I *think* I see a different bug.... |
| 16:45 |
Bmagic |
this is starting to make sense http://docs.evergreen-ils.org/3.1/_virtual_index_definitions_2.html |
| 16:48 |
Bmagic |
I also see a "fix me" at the top of https://wiki.evergreen-ils.org/doku.php?id=documentation:indexing |
| 16:58 |
|
bdljohn joined #evergreen |
| 17:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:02 |
|
bdljohn left #evergreen |
| 17:04 |
|
mmorgan left #evergreen |
| 17:16 |
|
jvwoolf left #evergreen |
| 00:09 |
|
eady joined #evergreen |
| 04:20 |
|
bdljohn1 joined #evergreen |
| 05:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:37 |
|
bos20k joined #evergreen |
| 07:38 |
|
agoben joined #evergreen |
| 07:56 |
|
jvwoolf joined #evergreen |
| 13:28 |
Dyrcona |
Not sure, yet, how you'd get both HTML and plain text parts out of the reactor. |
| 13:40 |
|
derekz joined #evergreen |
| 13:51 |
|
nfBurton joined #evergreen |
| 13:54 |
nfBurton |
In response to the HTML emails. I did get them working and am currently testing (successfully) HTML emails for new patrons. Likely to be expanded after. |
| 13:54 |
Bmagic |
Dyrcona: We've got the plain and html working with the patch |
| 13:55 |
Dyrcona |
"The patch..." Which patch? |
| 13:55 |
Bmagic |
bug 1532236 |
| 13:56 |
nfBurton |
I can confirm the same patch worked for me on 3.1.5 |
| 13:57 |
Bmagic |
The sample AT template on the bug shows how to do it |
| 13:59 |
Dyrcona |
Yes. That looks straightforward enough. We'll have to see if it still works with Email::Stuffer. |
| 14:06 |
csharp |
jeffdavis: testing privacy waiver branch - when I "purge" the patron via the UI, the actor.usr_privacy_waiver rows are retained - is that what you intended? |
| 14:06 |
csharp |
I realized that they would be deleted with an actual row deletion via cascade |
| 14:06 |
csharp |
s/realized/realize/ |
| 14:08 |
* csharp |
thinks we should add a DELETE to actor.usr_purge_data to handle it |
| 14:08 |
jeffdavis |
csharp: that's an oversight, the purge function should clear out that data |
| 14:08 |
csharp |
and I'm happy to do that |
| 14:08 |
jeffdavis |
yeah, that :) |
| 14:09 |
csharp |
do you want to do it? |
| 14:09 |
jeffdavis |
sure, will do |
| 14:09 |
csharp |
awesome |
| 14:09 |
csharp |
feature works great otherwise - tested from the staff and opac view |
| 14:09 |
csharp |
once we clear the policy hurdle (possibly in May) we'll probably implement it |
| 14:10 |
csharp |
it's a commonsense thing to be able to do with the software |
| 14:10 |
jeffdavis |
thanks for testing! |
| 14:13 |
Dyrcona |
Y'know, someone from CW MARS should open another bug on actor.user_delete, because the alternate names are not touched by that function, either. |
| 14:14 |
csharp |
jeffdavis: happy to do it |
| 14:20 |
* Dyrcona |
curses Lp and the infamous "Timeout Error." |
| 15:07 |
|
jvwoolf joined #evergreen |
| 16:55 |
csharp |
relevant: https://www.reddit.com/r/ProgrammerHumor/comments/ao4opn/10yearchallenge/ |
| 16:57 |
|
jvwoolf joined #evergreen |
| 17:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:09 |
|
mmorgan left #evergreen |
| 17:33 |
csharp |
calling 1144, 1145, & 1146 |
| 17:34 |
berick |
yeehaw |
| 17:42 |
pinesol |
[evergreen|Chris Sharp] LP#1715767 - stamping upgrade scripts - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6ae2427> |
| 17:44 |
csharp |
I guess the 10-year challenge meme is timely for our community since our first conference was in 2009 :-) |
| 17:59 |
|
bdljohn1 left #evergreen |
| 18:56 |
jeffdavis |
csharp++ # thanks for testing and commit! |
| 19:35 |
|
jamesrf joined #evergreen |
| 20:18 |
|
sandbergja joined #evergreen |
| 22:52 |
|
jamesrf joined #evergreen |
| 09:14 |
|
bdljohn left #evergreen |
| 09:14 |
|
jamesrf joined #evergreen |
| 09:37 |
|
terran joined #evergreen |
| 09:50 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-02-06T09:48:51,496761679-0500 -0> |
| 09:52 |
|
yboston joined #evergreen |
| 09:58 |
|
jvwoolf joined #evergreen |
| 10:13 |
|
Stompro joined #evergreen |
| 13:46 |
|
yboston joined #evergreen |
| 13:58 |
dbwells |
jeffdavis: I think you are right, and I can see it either way. It just felt a little more on the side of "let's make this better" rather than "let's fix what's broken", especially given that the current behavior has existed for quite a while. |
| 14:05 |
jeffdavis |
I was assuming that the current behavior is unintended and it just hadn't been noticed. |
| 14:06 |
csharp |
jeffdavis: I'm interested in testing patron privacy waivers, but I'm seeing several file conflicts with master. I'm fixing them locally, but you might want to rebase with master. |
| 14:07 |
jeffdavis |
csharp: ah, branch drift. Will do, thanks. :) |
| 14:08 |
csharp |
:-) |
| 14:13 |
* csharp |
is going to have to miss the dev meeting - 3:00 is always kid-pickup hour :-/ |
| 15:08 |
gmcharlt |
berick, JBoyer, csharp: where do we stand with a Hatch release? |
| 15:08 |
JBoyer |
It lives. |
| 15:08 |
berick |
indeed |
| 15:08 |
JBoyer |
Thanks to gsams testing |
| 15:08 |
JBoyer |
gsams++ |
| 15:08 |
gmcharlt |
gsams++ |
| 15:09 |
gmcharlt |
#info New Hatch release has been made |
| 15:09 |
gmcharlt |
berick, Bmagic: where stands the Dymo branch? |
| 15:09 |
berick |
I hope to spend some time on that this and next week, in fact |
| 15:10 |
gmcharlt |
great |
| 15:10 |
gsams |
I've been testing that as well this week |
| 15:10 |
gmcharlt |
I'll just carry the action item forward then |
| 15:10 |
gmcharlt |
#action Bmagic, berick, gsams et al will poke more on the Dymo branch |
| 15:10 |
berick |
gsams++ great |
| 15:11 |
gmcharlt |
#info OpenSRF 3.1.0 was released on 2019-01-17 |
| 15:11 |
gmcharlt |
anybody seeing issues running it (and not just the websocketd stuff) in production? |
| 15:11 |
miker |
no me! :) |
| 15:12 |
csharp |
we're running it in a test environment that's pretty well-used - no complaints yet |
| 15:12 |
Dyrcona |
I haven't used it in production, but it seems to work fine on my VMs, even with Evergreen 3.0. |
| 15:12 |
csharp |
(OpenSRF 3.1.0 + websocketd) |
| 15:12 |
gmcharlt |
ok |
| 15:34 |
csharp |
+1 to de-XUL-ification |
| 15:34 |
berick |
no strong preference, but will be good to reach some consensus there, since XUL is technically usable in 3.2. Is 3.3 where it fully stops working, i guess is the question. |
| 15:34 |
JBoyer |
+1 |
| 15:34 |
* csharp |
is happy to help (at least with testing) |
| 15:34 |
Dyrcona |
Did we ever set a release for removal of XUL? |
| 15:34 |
csharp |
PINES is running 3.2 without XUL (so far) - I think that's a good indicator that we can leave it behind |
| 15:34 |
* Dyrcona |
doesn't remember. |
| 15:40 |
miker |
s/page/branch |
| 15:40 |
berick |
miker++ |
| 15:40 |
sandbergja |
jeffdavis: not sure yet; I'll do some exploration this afternoon |
| 15:41 |
jeffdavis |
Sitka was hoping to test the bookings daily schedule this week and looking forward to having it in 3.3 |
| 15:41 |
berick |
i'd say at this stage there's some flexibility |
| 15:41 |
berick |
i mean if the code is already written... |
| 15:41 |
sandbergja |
yeah, I just barely missed 3.2 :-( |
| 15:52 |
gmcharlt |
#topic Should we update or remove Python libs from OpenSRF and Evergreen? |
| 15:52 |
|
Topic for #evergreen is now Should we update or remove Python libs from OpenSRF and Evergreen? (Meeting topic: Evergreen Development Meeting, 6 February 2019) |
| 15:53 |
Dyrcona |
It's a different situation from Java, in that it builds and srfsh.py works on Ubuntu 18.04, but not Ubuntu 16.04, and IIRC, Syrup uses it, but Syrup is abandonware. |
| 15:53 |
Dyrcona |
I haven't tested it on Debian since Debian 7, so I don't know if Python works on Stretch or Jessie. |
| 15:53 |
stephengwills |
I just used marc_convert.py for an on-boarding last week. Does that require any Osrf or Eg libs? or is it stand alone? |
| 15:54 |
Dyrcona |
And, then, there's another wrinkle. Our Python libs are version 2.7 compatible, and Python 2.7 is EOL on Jan 1, 2020. |
| 15:54 |
berick |
i'm pretty sure it's not 100% with perl/c osrf, but I also have not looked at it in a long time |
| 16:05 |
JBoyer |
gmcharlt++ |
| 16:05 |
Dyrcona |
gmcharlt++ |
| 16:05 |
rhamby |
gmcharlt++ |
| 16:06 |
gsams |
berick: On testing the DYMO hatch fix, the prints are diverting to an alternate printer other than the target. This is on Windows 10, I haven't tried elsewhere. |
| 16:07 |
berick |
gsams: *nod* |
| 16:07 |
gsams |
I had a small back and forth with Bmagic about it, and he got similar results. |
| 16:11 |
|
stephengwills left #evergreen |
| 16:11 |
|
jamesrf joined #evergreen |
| 16:59 |
|
mdriscoll left #evergreen |
| 17:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:06 |
|
jvwoolf left #evergreen |
| 17:12 |
|
mmorgan left #evergreen |
| 17:20 |
|
beanjammin joined #evergreen |
| 15:00 |
Dyrcona |
Hmm. Twenty-five open bugs with both the pullrequest and signedoff tags. Something to bring up tomorrow? |
| 15:07 |
* csharp |
has been planning to get to some of those |
| 15:10 |
|
mmorgan1 joined #evergreen |
| 15:10 |
Dyrcona |
Well, I'm testing an easy one right now. |
| 15:11 |
Dyrcona |
Running 2 VMs on the laptop. Who would have dreamed of that a few years ago? |
| 15:21 |
JBoyer |
If you'd like to re-live those days you could try running one inside the other, heh. |
| 15:23 |
bshum |
JBoyer: I'm not entirely sure it would allow you to do that. I know some hypervisors dont' like it when the guests try to use the same procs that are already being used by the host |
| 15:24 |
JBoyer |
bshum, oh, you don't get to use the nice hardware bits on the inside. That's what brings back that authentic feeling to running a VM on a laptop. Frames per second becomes seconds per frame, etc. :) |
| 15:24 |
Dyrcona |
heh. |
| 15:25 |
Dyrcona |
The branch needs a release note, but I'll write it then push it. |
| 15:26 |
* JBoyer |
needs to work on his LP saved search game to better help with testing, etc. |
| 15:38 |
* Dyrcona |
scratches his head at some git weirdness |
| 15:39 |
Dyrcona |
Oh! Duh! |
| 15:40 |
Dyrcona |
I forgot to rebase --continue. :) |
| 15:26 |
Dyrcona |
jammin: If you've installed Evergreen, you'll need to upgrade to Evergreen 3.0, also. |
| 15:26 |
csharp |
so is OpenSRF 3.1 good for EG 3.2? |
| 15:27 |
* Dyrcona |
has been using master, but I think so, csharp. |
| 15:27 |
Dyrcona |
i.e. in my testing of 3.2 |
| 15:28 |
jammin |
Dyrcona: at one point I was doing LD_DEBUG and saw it looking right at the right lib file, but it skipped right on to the next path... I said "whaaa?" :) |
| 15:28 |
Dyrcona |
jammin: It's because of changes in GCC 6. |
| 15:28 |
gsams |
csharp: Supposedly we are running OpenSRF 3.1 on EG 3.2.3 right now. |
| 15:28 |
Dyrcona |
Rereading the bug history refreshed my memory. |
| 15:30 |
jammin |
Dyrcona: got it, thanks. my actual target here is EG 3.1.2, so yeah will be doing that |
| 15:31 |
Dyrcona |
jammin: I think OpenSRF 3.1 should work for you, too. Might as well go with the latest and greatest. :) |
| 15:31 |
jammin |
Dyrcona: was testing upgrade to stretch before upgrading to 3.1.2. I guess the result is "don't" |
| 15:31 |
Dyrcona |
:) |
| 15:32 |
jammin |
Dyrcona: so opensrf 3.1 good to go for eg 3.1.2, then? |
| 15:33 |
Dyrcona |
I don't know of any incompatibilities. |
| 15:33 |
Dyrcona |
I've kind of skipped Evergreen 3.1 in my testing, though, so take that with a teaspoon of salt. |
| 15:34 |
* csharp |
chokes down a teaspoon of salt |
| 15:34 |
Dyrcona |
I think 3.1 works with 3.0 also.... At least parts of it do, because I backported some patches to our production servers. |
| 15:34 |
jammin |
Will know in a bit, gonna take a break, roll the vm back, and give it a go |
| 15:36 |
gsams |
csharp, Dyrcona: having literally just updated this week it's been incredibly smooth. |
| 15:36 |
Dyrcona |
Our members are making use of the web client in 3.0. |
| 15:36 |
csharp |
gsams: awesome |
| 15:36 |
jammin |
Our production is 3.1.2 on opensrf 3.0.1, I'm messing around with the test server while bringing it up to speed |
| 15:36 |
Dyrcona |
My testing looks like the upgrade will be straightforward. |
| 15:36 |
gsams |
If I can get the dymo hatch printer fix in place I'll be all set I think. |
| 15:36 |
csharp |
we expected more outcry from libraries who hadn't made the transition from circ yet |
| 15:37 |
jammin |
I need to get our RFID stuff playing nicely with the web client before can move up to 3.2 |
| 15:37 |
* csharp |
has to run pick up the teenager |
| 15:37 |
Dyrcona |
jammin: When it comes to upgrading the O/S on VMs, I usually don't. I just build a new VM, but I assume you wanted to test because you plan to upgrade production hardware? |
| 15:40 |
jammin |
Dyrcona: Not sure which way I'm going to go about it yet... rebuild VMs and fresh install, or dist-upgrade and EG upgrade. Figured either way, I should figure out how to "make it work". |
| 15:41 |
jammin |
Dyrcona: If I can fix a worst case, the easy cases will be that much easier. :) |
| 15:41 |
Dyrcona |
Yes. :) |
| 15:51 |
jammin |
I'm interested in moving up to debian-buster. Am I inviting similar library insanity? |
| 15:51 |
Dyrcona |
Probably not, but I don't think anyone has worked out the prerequisites for buster, yet. |
| 15:53 |
Dyrcona |
jammin: If you'd like to do that, feel free. Patches welcome! :) |
| 15:53 |
jeff |
Do not use unreleased testing versions of Linux distributions for production. :-) |
| 15:54 |
jammin |
I'm thinking I'll finish getting this thing going on stretch & 3.1.2 like I'm supposed to. Then take another snapshot, then see how buster goes... just because. |
| 15:55 |
Dyrcona |
It should be OK to start testing with buster, soon. The full freeze is supposed to happen in March. |
| 15:55 |
jeff |
Testing with buster and reporting issues is a useful thing, and appreciated. |
| 15:55 |
jeff |
But don't run it in production. :-) |
| 15:55 |
jammin |
No, not on production! But hey, Debian testing (in soft freeze, or close to it) isn't your average unreleased testing version. :) |
| 15:56 |
* jeff |
nods |
| 16:26 |
sandbergja |
Quick indexing question: In this doc, it says that it's required to do a "service restart" after making changes to Administration > Server > MARC Search/Facet Fields (metabib fields): http://docs.evergreen-ils.org/dev/_virtual_index_definitions.html |
| 16:26 |
sandbergja |
Which services exactly need to be restarted? |
| 16:49 |
Bmagic |
I've got a sample set of commands around somewhere |
| 16:50 |
pastebot |
"Bmagic" at 64.57.241.14 pasted "restarting services" (32 lines) at http://paste.evergreen-ils.org/14398 |
| 16:51 |
sandbergja |
Oh, cool! Thanks! |
| 17:00 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-02-01T16:58:45,062820692-0500 -0> |
| 17:14 |
csharp |
opensrf 3.1.0 and websocketd are now running on our 3.2.3 test server |
| 17:14 |
csharp |
all seems fine so far |
| 17:18 |
|
mmorgan left #evergreen |
| 17:23 |
Bmagic |
csharp++ |
| 18:58 |
|
beanjammin joined #evergreen |
