13:29 |
|
Ryan_LGPL joined #evergreen |
13:30 |
Ryan_LGPL |
Hi! I have a question about automatic opening cash drawers, and Evergreen! |
13:31 |
Ryan_LGPL |
We just got a new cash drawer at my library, because the old one's latch was broken, and wouldn't stay closed anymore, without extreme effort. |
13:32 |
Ryan_LGPL |
The replacement drawer does not (Though it didn't state this in the advertisement) have a manual open button...it only opens with the key. It's an EOM-POS cash drawer. It does plug into our printer, and DOES respond to the test button in the printer settings for testing whether our printer can trigger the latch. |
13:33 |
Ryan_LGPL |
How can I get Evergreen to send the signal to the printer to trigger the cash drawer? Also, is it possible to get it to only do so when printing receipts for actual financial transactions, and NOT when printing due date slips? |
13:33 |
jeff |
A few options here. |
13:34 |
jeff |
Depending on the printer and the print driver, you should be able to configure it so that it does a "drawer kick" after every print job. |
13:34 |
Ryan_LGPL |
Printer is a TSP100u. I can't find any settings in it's settings for the printer/cashdrawer interaction, aside from the test button that confirms that it CAN send the code to open the drawer |
13:36 |
jeff |
If you'd like to only "kick" the drawer open for certain kinds of receipts, you might be able to do this by creating a second windows printer object for the same device, and configuring only that printer to send the drawer kick at the end of jobs, and then using Evergreen printer contexts to send certain receipt templates to that printer that kicks. |
13:37 |
jeff |
Some printers support a "control font" and certain characters printed with that control font do certain things. Older (much older) printers only supported escape codes, which required certain hex values to make their way from the app to the printer without being transformed along the way. That's not likely to work these days. |
13:37 |
jeff |
But if the printer supports a control font you might be able to configure a "drawer kick" command in a receipt template that way. |
14:07 |
pinesol |
csharp: vacuum full; strong opinions; data; Data from TNG; simple fixes to scary-looking problems; and all the things |
14:08 |
|
jihpringle joined #evergreen |
14:08 |
csharp |
@hates |
14:08 |
pinesol |
csharp hates dojo_hold_policies_interface; SIP; when libraries purchase third party products without testing and blame Evergreen for it not working; reports; the fact that the Base Filters is unnecessarily greyed out when applying an Aggregate Filter and vice versa; evil; reports more; reports even moar; details; reports even more; the fact that the Base Filters is unnecessarily greyed out when (2 more messages) |
14:08 |
csharp |
@more |
14:08 |
pinesol |
csharp: applying an Aggregate Filter and vice versa even more; having to teach SIP2 client vendors about the SIP2 specification; troubleshooting reports; money reports; marc; reports even more than before; the EDI ruby bits; acquisitions; <quote>fun<unquote>; edi; sip2; sip too; sip two; acq; acq more; acq way more than before; omg I hate acq; omg I love acq; hate hate hate; comcast; action_triggers; (1 more message) |
14:08 |
csharp |
@more |
16:11 |
Bmagic |
probably more like 4 years ago... geez |
16:11 |
bshum |
I'm reading off old emails from 2014/15 era |
16:12 |
bshum |
So yeah |
16:15 |
Bmagic |
thanks yall, off to the test server for many hours |
16:46 |
Bmagic |
I just printed to a Dymo printer from the web client using Hatch |
17:09 |
|
mmorgan left #evergreen |
17:11 |
jeff |
Bmagic++ |
17:17 |
Bmagic |
Anyone here have a Dymo printer? |
17:18 |
rhamby |
heh, probably in a box somewhere in the garage |
17:19 |
sandbergja |
Bmagic: we've got one! We don't use Hatch, though |
17:19 |
Bmagic |
Looking for someone to test drive this code with Webby/Hatch/Dymo |
17:19 |
Bmagic |
It might be a matter of adjusting the template to get the label to print in the upper left corner or something like that |
17:20 |
Bmagic |
(I don't have the physical printer, just the driver installed. Not getting errors now. Had a library on the phone and got it to print out a blank label but they had to go) |
17:27 |
alynn26 |
I have a dymo let me try, which server do you want me to use? |
17:55 |
alynn26 |
Ok |
17:57 |
alynn26 |
set it as the default, same thing. I have a Dymo LabeWriter 450 Duo. |
17:58 |
Bmagic |
alynn26: thanks for trying! I am hacking more on it next week. |
17:58 |
alynn26 |
Ok, if you want me to do some testing, let me know. Just email me. |
17:58 |
Bmagic |
right on! Thanks |
17:58 |
alynn26 |
good night. |
18:08 |
|
jvwoolf joined #evergreen |
11:04 |
Dyrcona |
Only thing you can do is setup a proxy and drop duplicate requests. |
11:05 |
* Dyrcona |
has looked into the general problem of double form submissions. |
11:05 |
Dyrcona |
I should say, the proxy is the only thing you can do that would be 100% effective. |
11:07 |
JBoyer |
Sure, it can't really stop anyone determined, or multiple people actually submitting the same search, I don't mind that. But I just did a simple test where I held down enter until I it looked like the screen was about to change and got 108 identical searches. |
11:08 |
Dyrcona |
JBoyer: Sounds about right. |
11:10 |
JBoyer |
Interesting thing about doing that though, you can get a rough idea of how well your load balancer spreads things around. ;) |
11:10 |
Dyrcona |
Or doesn't spread things around. :) |
11:46 |
rhamby |
kmlussier: ok, I might as well cancel the karoake rental then.... |
11:46 |
kmlussier |
rhamby: There's no reason you can't do karoake! I'm sure somebody will post the video so that I can enjoy it. |
11:50 |
Dyrcona |
:) |
11:51 |
kmlussier |
If anyone is looking for a quick and easy patch to test, there's bug 1783602 |
11:51 |
pinesol |
Launchpad bug 1783602 in Evergreen "Copy counts should be removed from metarecord search results page" [Medium,New] https://launchpad.net/bugs/1783602 |
11:56 |
plux |
cqqqqq |
11:58 |
|
mmorgan1 joined #evergreen |
12:26 |
JBoyer |
We remove age protection the day it "expires" and also automatically roll some 'blah blah new' circ mods to regular old 'blah blah' |
12:27 |
JBoyer |
An automated script is really the only way to do it. It could be made into a srfsh script, or something that uses the CronScript perl modules, but the end result is the same. |
12:27 |
jwoodard |
We remove ours monthly from new items |
12:27 |
mmorgan |
Also, I have not tested this, but I remember discussion about the ability to set up a hold policy that consults an age hold protection rule based on other selections in the hold policy. |
12:29 |
jwoodard |
as we have grown we are encountering more special cases where age protection would be nice |
12:29 |
jwoodard |
but we do not want to increase the workload |
12:30 |
jwoodard |
how does the "item age<" field function? |
14:01 |
jeffdavis |
cool, thanks |
14:16 |
gmcharlt |
kmlussier: ping |
14:16 |
kmlussier |
gmcharlt: Yes? |
14:17 |
gmcharlt |
kmlussier: I'm wrapping up testing of the branch for bug 1746536 |
14:17 |
pinesol |
Launchpad bug 1746536 in Evergreen "web client: cannot edit vol/call number in item status" [Medium,Confirmed] https://launchpad.net/bugs/1746536 - Assigned to Galen Charlton (gmc) |
14:17 |
gmcharlt |
I've verified that Janet's testing in commit 27 also works for me in the current branch |
14:17 |
gmcharlt |
and I"m no longer seeing the issues reported in comments 23 and 24 |
14:18 |
gmcharlt |
before I merge, was there anything else you're aware of holding up that one? |
14:18 |
kmlussier |
gmcharlt: I'm confident that the previous bug fix has addressed the issues I found. Those were the only two issues. |
14:18 |
gmcharlt |
ok, great |
14:18 |
gmcharlt |
merging now |
14:24 |
pinesol |
[evergreen|Mike Rylander] LP#1746536: Restrict CN addition but allow CN edits... - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6cd17f1> |
14:24 |
pinesol |
[evergreen|Kathy Lussier] LP#1746536: Remove input-group-addon class from Add Call Number button - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f6d7999> |
14:25 |
|
khuckins joined #evergreen |
14:25 |
berick |
if anyone's feeling adventurous, I've found the patch for bug #1797923 to be helpful in my webstaff testing |
14:25 |
pinesol |
Launchpad bug 1797923 in Evergreen 3.1 "Browser client iframe (catalog, etc.) loading page" [Undecided,New] https://launchpad.net/bugs/1797923 |
14:25 |
berick |
before tomrrow's release cut, i mean |
14:26 |
|
yboston joined #evergreen |
17:31 |
|
khuckins joined #evergreen |
17:35 |
dbwells |
berick: I think it is mentioned in the tangle of bugs listed on #1731272, but I might be mistaken. It seems your branch fixes some things on that bug, so maybe it deserves to be separated out to a new bug for clarity anyway. |
17:36 |
berick |
dbwells: ok, just making sure the patch didn't introduce a bug |
17:37 |
dbwells |
berick: No, sorry if I implied that. In my testing your branch made 'default view' go from majorly broken to considerably less broken. |
17:38 |
dbwells |
in my experience |
17:39 |
jihpringle |
default view is fixed in the patches on LP 1724348 and LP 1731272 but neither have made it into a release yet |
17:39 |
pinesol |
Launchpad bug 1724348 in Evergreen 3.1 "Web client: set default view not sticky" [Undecided,Confirmed] https://launchpad.net/bugs/1724348 |
17:39 |
pinesol |
Launchpad bug 1731272 in Evergreen 3.1 "web client: "Set default view" breaks record page loading" [High,Confirmed] https://launchpad.net/bugs/1731272 |
09:01 |
* pinesol |
grabs some Shamrock Shakes for _bott_ |
09:03 |
_bott_ |
I do like the Shamrock Shake |
09:03 |
* kmlussier |
has never had a Shamrock Shake. :( |
09:04 |
Dyrcona |
Ah ha! That test that fails on 3.0.13 but succeded on master last night is broken on 3.0.13. It's looking for the wrong number. I guess I'll fix that. |
09:07 |
Bmagic |
Wrong number, please hang up and try again. If you feel that you have reached this recording in error...... |
09:13 |
Dyrcona |
tests+- |
09:14 |
JBoyer |
berick, kmlussier, re: copy notes post-3.1, in addition to skipping the migration script I went as far as putting the field back in the copy editor since we have so many libraries on both sides of the xul/web line. There are a large number of local commits I'm looking forward to throwing away once we upgrade next month... |
09:14 |
cesardv |
Bmagic: https://www.youtube.com/watch?v=NI_wyiY4vyk |
09:14 |
cesardv |
lol |
09:16 |
Bmagic |
cesardv: this is the one I was thinking of: https://www.youtube.com/watch?v=37aHq3WDe-w |
09:17 |
cesardv |
Bmagic: ah yeah, I've heard that variation before... |
09:17 |
Bmagic |
It's a bygone era |
09:29 |
JBoyer |
sooo, who has a test install of the latest 3.2? I'm getting failures to load item status with this error: vendor.bundle.js:6 TypeError: Cannot read property 'filter' of null at item.js 162 |
09:30 |
pinesol |
[evergreen|Dan Wells] LP#1796971 Wait for call number and copy before loading locations - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=193f06d> |
09:30 |
pinesol |
[evergreen|Dan Wells] LP#1796978 Realign working copy refresh with proper condition - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f64ec2e> |
09:30 |
JBoyer |
That line is filtering on copy alerts to only display the count of non-ack'd alerts attached to the item and it's failing for copies with and without alerts. |
14:09 |
pinesol |
Launchpad bug 1795906 in Evergreen "Bring parity to the estimated queue position in OPAC and Record -> View Holds UIs" [Medium,New] https://launchpad.net/bugs/1795906 |
14:51 |
|
abowling joined #evergreen |
14:53 |
Dyrcona |
jeffdavis: Just run master. It isn't as scary as it sounds. :) |
14:53 |
jeffdavis |
heh |
14:56 |
|
khuckins_ joined #evergreen |
15:01 |
jeffdavis |
Dyrcona: the amount of testing we do before an upgrade means we usually only do one big upgrade per year - usually shortly after a major version release, at which point there's not much difference from master. Then we backport fixes as required. |
15:02 |
Dyrcona |
jeffdavis: Perfect candidate for running master in that case. |
15:02 |
jeffdavis |
This year with the switch to the web client we have more backports than usual. We did a minor upgrade from 3.1.0 to 3.1.4 and will probably do another minor release upgrade next month. |
15:02 |
Dyrcona |
We just upgraded from 3.0.8 to 3.0.12 and I installed the patches for 3.0.13 last night. |
15:14 |
JBoyer |
berick++ |
15:14 |
JBoyer |
berick++ |
15:15 |
JBoyer |
I've been looking at things on and off; very glad you had time to knock it out. |
15:18 |
JBoyer |
I'll test that branch out, but something that occured to me when I was looking earlier is that applyControlFunctions will always only look at the default columns since it's called before the columns are loaded. |
15:19 |
JBoyer |
Not really knowing where those are used I'm not sure how to even verify that at the moment. |
15:20 |
berick |
JBoyer: that should be OK |
15:20 |
berick |
that's most setup for future actions |
15:20 |
berick |
*mostly |
15:21 |
JBoyer |
Sounds good then. I didn't figure it would affect this, but wondered if it would matter later. |
15:30 |
|
khuckins joined #evergreen |
16:15 |
JBoyer |
bug 1798170 is tested, signed, etc. and all around happier with the order of operations. |
16:15 |
pinesol |
Launchpad bug 1798170 in Evergreen "Custom grid columns fail to display on initial load" [Undecided,New] https://launchpad.net/bugs/1798170 |
16:31 |
* kmlussier |
shakes her head at JBoyer's Carly Rae Jepsen impersonation on bug 1798170. |
16:31 |
pinesol |
Launchpad bug 1798170 in Evergreen "Custom grid columns fail to display on initial load" [Undecided,New] https://launchpad.net/bugs/1798170 |
17:03 |
Bmagic |
yeah, I am starting to learn that |
17:03 |
Bmagic |
It seems possible that xul users could make the old style alert though |
17:03 |
Bmagic |
will the web client respect the old alert? |
17:04 |
jeff |
and it isn't sufficient to just hold off on using the feature in new ways. the upgrade script migrated legacy copy alerts in a way that made them at least no longer visible / editable by the xul client, even if they continued to fire. |
17:05 |
jeff |
i do not think we've yet tested if the code supports the legacy copy alert message in the web client, or if we need to revert/change some things there until we're off xul. |
17:05 |
|
mmorgan left #evergreen |
17:05 |
jeff |
it was a late discovery in pre-upgrade planning process for us when we jumped from 2.10 to 3.1. |
17:06 |
Dyrcona |
The test server isn't testing, or is it just not posting to the channel? |
17:06 |
berick |
jeff: are you just using the browser client for all copy-alert related stuff? |
17:07 |
jeff |
berick: no, we skipped the migration of copy alerts in the relevant upgrade script, so our legacy alerts remain in-table. |
17:07 |
|
stephengwills left #evergreen |
17:22 |
jeff |
I have a local todo to look into it. I have a suspicion that it might be messy. The web client probably sees the alerts at checkin/checkout but probably can't successfully modify them, at least not in a way that doesn't lead to alert message bifurcation. :-) |
17:31 |
|
cesardv joined #evergreen |
17:43 |
|
khuckins_ joined #evergreen |
17:57 |
bshum |
Dyrcona: I'm pretty sure the test server isn't posting to channel because phasefx has to rebuild it out of Wheezy and into Stretch or some other supported distro |
17:57 |
bshum |
So yeah, no telling how long it's been since the last successful test run :\ |
17:58 |
bshum |
I haven't run one in awhile myself. |
18:00 |
|
khuckins joined #evergreen |
18:36 |
|
nfburton joined #evergreen |
18:47 |
Dyrcona |
bshum: I'm just curious if it is having failures. On rel_3_0, I'm getting live_t/20-hold-targeter.t failing, on master on Ubuntu 18, live_t/09-lp1198465_neg_balances.t fails for me. |
18:48 |
Dyrcona |
tests+- |
19:15 |
Dyrcona |
OK. Tests are working for me on master after reloading concerto. |
21:51 |
Bmagic |
What does it mean when OpenSRF::Transport /usr/local/share/perl/5.22.1/OpenSRF/Transport.pm:83 Session Error: routerprivate.localhost/open-ils.serial IS NOT CONNECTED TO THE NETWORK!!! ? Ejabberd is messed up? Which config should I tweak do you think? |
22:14 |
|
beanjammin joined #evergreen |
09:02 |
Dyrcona |
Was the 3.2.0 release announced? |
09:03 |
|
stephengwills joined #evergreen |
09:03 |
Dyrcona |
Indeed, it was. |
09:05 |
* Dyrcona |
waits on lost a/t to finish on test server... |
09:05 |
|
remingtron joined #evergreen |
09:09 |
|
sallyf joined #evergreen |
09:11 |
Dyrcona |
Yeahp. It's definitely the parallel settings for open-ils.trigger causing the lost print notices not group properly. The question is now why does this one a/t have the problem and our others don't? |
10:33 |
csharp |
there was a bug sometime in the last 1.5 years where the group field could be null but the perl assumed it wasn't and would choke, but that's not what your issue sounds like |
10:34 |
csharp |
and that should be fixed upstream (not just in PINES) |
10:45 |
Dyrcona |
Right, and that's not my problem. There's something about our lost-print trigger that doesn't like being run parallel. |
10:46 |
Dyrcona |
I'm waiting on another test run to finish... |
11:05 |
|
jvwoolf joined #evergreen |
11:09 |
|
Christineb joined #evergreen |
11:20 |
|
khuckins joined #evergreen |
11:35 |
Bmagic |
windows_file_explorer++ |
11:35 |
Bmagic |
windows_task_manager++ |
11:36 |
* mmorgan |
wonders what's so great about file explorer and task manager |
11:36 |
aabbee |
"windows 10 october 2018 update no longer deletes your data" https://arstechnica.com/gadgets/2018/10/microsoft-fixes-october-update-file-deleting-bug-resumes-insider-testing/, so they got that going for them, which is nice. |
11:39 |
kmlussier |
@karma microsoft |
11:39 |
pinesol |
kmlussier: Karma for "microsoft" has been increased 0 times and decreased 1 time for a total karma of -1. |
11:39 |
kmlussier |
microsoft-- |
11:52 |
Bmagic |
Right now, I am favoring fedora with KDE (if someone made me switch today) |
11:53 |
bshum |
berick: Oooo pretty :D |
11:53 |
* Dyrcona |
used to work on KDE and wouldn't recommend it. They broke everything in KDE 4 and decided to release it half-finished. |
11:53 |
Bmagic |
I've heard that too but in testing, everything seems to work for me |
11:53 |
Dyrcona |
Well, they've had time to finish more stuff since then. :) |
11:54 |
Bmagic |
Starcraft 2 doesn't work so well in wine on my GPU on Gnome or KDE... so there's that |
11:54 |
Dyrcona |
I left about the time 2.0 was done because my daughter was born and no more time. |
12:32 |
mmorgan |
s/bit/but |
12:36 |
Dyrcona |
mmorgan: Thanks. All of our print notices are sort on usr. |
12:37 |
Dyrcona |
Our lost print notice has an extra loop to sort by target_copy.call_number.owning_lib, and before I started running these in parallel it worked. |
12:38 |
Dyrcona |
The other od print notices work, so I assume the failure is related to this second sort, but I'm still waiting on test results. |
12:56 |
* Dyrcona |
thinks we're going back to the old settings... |
13:22 |
|
jvwoolf joined #evergreen |
13:58 |
jeff |
Just a few short days after the LoC MARC site outage, and I'm getting bibs from OCLC with no 245. |
13:26 |
JBoyer |
That database seems... sickly. |
13:27 |
jeff |
looks like the upgrade script may have relied upon assertions that do not hold true with our database. |
13:29 |
JBoyer |
I do remember undertaking a "Great Realignment" here at some point years ago. Without that I suspect we'd be in the same boat. |
13:30 |
JBoyer |
(though I did just go check our 3.2 test db just to be sure we're not actually knee deep in said boat.) |
13:42 |
jeff |
during your "Great Realignment", did you dig into how you had diverged? |
13:43 |
jeff |
And, did you encounter any serious gotchas? |
13:49 |
JBoyer |
I suspect that one or more new fields were added manually without necessarily using the same ids as the upgrade scripts (or worse, the upgrade scripts disagree(d) with the seed data) but it was long enough ago and I was fresh enough at the job that I didn't go very far down that road. |
15:11 |
kmlussier |
#action gmcharlt will open and work on bugs for documentation changes for better ejabberd configuration during installation of OpenSRF |
15:12 |
kmlussier |
#info berick has reviewed miker's ejabberd changes for bug 1703411 |
15:12 |
pinesol |
Launchpad bug 1703411 in OpenSRF "OpenSRF: XMPP Non-SASL auth is being phased out" [Medium,Confirmed] https://launchpad.net/bugs/1703411 |
15:12 |
kmlussier |
#info gmcharlt and Dyrcona to tested the ang6 branch |
15:12 |
kmlussier |
Is there anything else to say about the action items from the previous meeting? |
15:13 |
kmlussier |
#topic OpenSRF 3.1 beta release |
15:13 |
|
Topic for #evergreen is now OpenSRF 3.1 beta release (Meeting topic: 2018-10-10 Evergreen developers meeting) |
15:13 |
kmlussier |
gmcharlt? |
15:13 |
Dyrcona |
I think that bug 1703411 should actually be bug 1793356. |
15:13 |
pinesol |
Launchpad bug 1703411 in OpenSRF "OpenSRF: XMPP Non-SASL auth is being phased out" [Medium,Confirmed] https://launchpad.net/bugs/1703411 |
15:13 |
pinesol |
Launchpad bug 1793356 in OpenSRF "Ejabberd strips custom XML attributes" [Medium,Fix committed] https://launchpad.net/bugs/1793356 |
15:16 |
kmlussier |
gmcharlt: Are there any OpenSRF bugs that need to be reviewed to help with the release? |
15:18 |
gmcharlt |
for the beta, as many eyes as possible on the websocketd patch woudl be great |
15:18 |
JBoyer |
I'm hoping to throw some tuits in that direction soon. |
15:18 |
* berick |
is running it on a large test cluster as of 2 weeks ago |
15:19 |
JBoyer |
berick++ |
15:19 |
kmlussier |
#help websocketd patch needs review from as many people as possible. |
15:19 |
Dyrcona |
I'm running websocketd in production with OpenSRF 3.0.1 if that means anything. |
15:07 |
alynn26 |
Its a JSON File. There is one issue with the pocket label, we print the Circulating library on the pocket. In the templates they left out the short code for circulating library but had the ID. In the JSON, I use the ID, and have it print the approiate Short code for the Library. |
15:07 |
|
Dyrcona joined #evergreen |
15:09 |
sandbergja |
alynn26++ #can't wait to try these out! |
15:15 |
alynn26 |
I have a quick question about Vandelay. My staff have been trying to export the Item Import list as a CSV, and it is not working. I have them a work around, but would rather see this fixed. I tested it on Nobles test server and you can not export it there either. |
15:21 |
alynn26 |
sandbergja, here are the instructions I gave our staff on printing labels. https://drive.google.com/drive/folders/1zVo5B01n4SfR8FIuBE1cxDxhkruNDcxu?usp=sharing |
15:32 |
|
khuckins_ joined #evergreen |
15:33 |
|
alynn26 joined #evergreen |
15:35 |
|
aabbee joined #evergreen |
17:37 |
jeffdavis |
I filed bug 1794884 about non-OPAC-visible holdings in Z39.50 output but it looks like a similar issue exists with, e.g, /opac/extras/supercat/retrieve/marcxml-full/record/$id |
17:37 |
pinesol |
Launchpad bug 1794884 in Evergreen "SRU/Z39.50 results can include non-OPAC-visible holdings" [Undecided,New] https://launchpad.net/bugs/1794884 |
18:00 |
|
berick joined #evergreen |
18:08 |
jeffdavis |
looking at the no-longer-used _cp_is_visible() function in Application/SuperCat.pm, seems like only opac-visible items should be included |
18:09 |
jeffdavis |
which I think means the new_record_holdings() function in Application/SuperCat.pm ought to be updated to test for opac visibility |
18:10 |
* jeffdavis |
files a bug report |
18:35 |
jeffdavis |
for the logs: bug 1796201 |
18:35 |
pinesol |
Launchpad bug 1796201 in Evergreen "SuperCat output can include non-OPAC-visible holdings" [Undecided,New] https://launchpad.net/bugs/1796201 |
18:47 |
|
jaswinder joined #evergreen |
20:04 |
|
badzerglingyQ joined #evergreen |
14:46 |
pinesol |
[evergreen|Galen Charlton] LP#1789442: restore column allocation for barcode input - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=110624b> |
14:46 |
pinesol |
[evergreen|Galen Charlton] LP#1789442: turn of Perl taint-checking on 14-OpenILS-Utils.t - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6c0e0d5> |
14:48 |
Dyrcona |
remingtron++ |
14:49 |
dbwells |
berick, gmcharlt, et al: I noticed now the extra chatter on the checkout display problems on bug #1552778. I had also noticed this bug and am trying to track it down, but I also stand ready to test any proposed fixes should others also be looking at it right now. |
14:49 |
pinesol |
Launchpad bug 1552778 in Evergreen 3.1 "Web client check-out "specific due date" should also include times" [Medium,Confirmed] https://launchpad.net/bugs/1552778 |
14:50 |
gmcharlt |
dbwells: I will look at that one in a bit, but not for another hour or so due to other calls on my tuits |
14:52 |
dbwells |
gmcharlt: Okay, thanks for the update. I'll keep poking, but I don't have a good view of the big picture yet, so we'll see if I get anywhere useful. |
16:29 |
berick |
fix pushed for bug 1794176 |
16:29 |
pinesol |
Launchpad bug 1794176 in Evergreen "Webstaff: Lines added to checkout grid blank on checkout" [High,Confirmed] https://launchpad.net/bugs/1794176 |
16:30 |
berick |
hm, looks like tooltips were backported too, so this fix will need backporting as well |
16:31 |
dbwells |
testing now... |
16:32 |
dbwells |
berick++ |
16:38 |
|
jihpringle joined #evergreen |
16:42 |
kmlussier |
@blame tooltips |
16:42 |
pinesol |
kmlussier: I come to bury tooltips, not to praise them. |
10:46 |
Dyrcona |
Lp 1514085 |
10:46 |
pinesol |
Launchpad bug 1514085 in Evergreen "Feature Request: Make Vandelay Asynchronous/Stateless" [Wishlist,Fix released] https://launchpad.net/bugs/1514085 |
10:46 |
|
beanjammin joined #evergreen |
10:47 |
csharp |
no, I know I didn't |
10:47 |
csharp |
not on production - we were testing it and I'm not sure where Tiffany left off |
10:47 |
Dyrcona |
Must be something else, then. Carry on. :) |
10:47 |
csharp |
thanks for thinking of it |
10:48 |
Dyrcona |
Might be worth trying with that branch on a test system, though. There's a chance it might resolve your issue. |
10:50 |
cesardv |
JBoyer: hey! Sorry I was in the zone... what's up? |
10:51 |
JBoyer |
No problem, I was just curious why bug 1691263 added select-on-focus, since some of our catalogers are unhappy about it. |
10:51 |
pinesol |
Launchpad bug 1691263 in Evergreen 3.0 "webclient wishlist: wrap long fields in MARC editor" [Medium,Fix released] https://launchpad.net/bugs/1691263 |
15:33 |
pinesol |
Launchpad bug 1552778 in Evergreen 3.1 "Web client check-in "effective date" and check-out "specific due date" should also include times" [Medium,Confirmed] https://launchpad.net/bugs/1552778 |
15:33 |
pinesol |
Launchpad bug 1789442 in Evergreen 3.1 "Web client: When editing an hourly due date the time is automatically changed to 12:00 am" [Medium,Confirmed] https://launchpad.net/bugs/1789442 |
15:34 |
Dyrcona |
gmcharlt expects us to work.... :) |
15:34 |
* Dyrcona |
is testing bshum's branch for Ubuntu 18 support in Evergreen, and it is going well so far. |
15:35 |
gmcharlt |
of particular note: that branch establishes a clean_ISO8601 in Evergreen, copied and fixed from cleanse_ISO8601 in OpenSRF; other time-manipulation functions are brought over as well, particularly interval_to_seconds() and seconds_to_interval() |
15:35 |
gmcharlt |
so... not only do I want you all to work... I want you to work hard! ;) |
15:35 |
Dyrcona |
:) |
15:35 |
bshum |
Speaking of Ubuntu 18, should we wait till the .1 to put that through? It wouldn't be the first time we ported distro support in a future release if we wanted to give more time to test things around |
15:36 |
bshum |
Though we've also just pushed stuff like that before, and called it "initial support" :D |
15:36 |
bshum |
With more to come later |
15:36 |
gmcharlt |
bshum: works for me if it works for y'all; distro support need not be strictly tied to Evergreen .0 releases |
15:36 |
Dyrcona |
Well, it's not much use without OpenSRF released also. The -RC is Monday, and that's really up to berick. |
15:36 |
bshum |
That's true, OpenSRF is important |
15:36 |
gmcharlt |
and on my plate for next week now that the webstafblockers (I think) all have patches at this point |
15:36 |
Dyrcona |
Anyway, time to run the tests and then kick the tires on the web staff client. |
15:37 |
bshum |
gmcharlt: That's cool, definitely doesn't hurt to test stuff more thoroughly all around, especially since we're going back to CPAN for some of the dependencies again. And new perl, etc. |
15:38 |
Dyrcona |
Tests are failing, but I kind of expected that. :( |
15:38 |
bshum |
Bah humbug :) |
15:38 |
kmlussier |
gmcharlt: If nobody else gets to it, I'll try to take a look at webstaffblocker patches over the next couple of days. |
15:38 |
gmcharlt |
kmlussier++ |
15:40 |
bshum |
Dyrcona: Err, not for a few days :( |
15:40 |
bshum |
Well not since last week |
15:40 |
bshum |
When we were doing the bug week |
15:41 |
Dyrcona |
Well, it might be a problem with newer Perl versions and something odd that we're doing: Failed test 'use OpenILS::Application::Circ::HoldNotify;' |
15:42 |
Dyrcona |
Yeahp, that's what it looks like: Unescaped left brace in regex is illegal here in regex; marked by <-- HERE in m/\${ <-- HERE EMAIL_SENDER}/ at /usr/local/share/perl/5.26.1/OpenILS/Application/Circ/HoldNotify.pm line 358. |
15:42 |
Dyrcona |
I think that used to just raise a warning. |
15:45 |
Dyrcona |
Yeahp, in perl 5.22 it says that construction is deprecated, not illegal. |
15:50 |
|
spont4e4 joined #evergreen |
15:57 |
berick |
can we delete HoldNotify yet? |
15:58 |
Dyrcona |
No idea, but the fix isn't too hard. However, I get some nice warnings including a vulnerability from CGI.pm. |
16:00 |
bshum |
Dyrcona: fwiw, all live tests pass clean for current master as of this writing on my new ubuntu 16.04 box. So guess it's a unique issue to 18.04's new perl. |
16:01 |
Dyrcona |
It's something that was deprecated and then became illegal, i.e. it throws a warning on ubuntu 16.04. bshum: Did you also run make check or just make live-check? |
16:02 |
bshum |
Dyrcona: I just ran livecheck first |
16:02 |
bshum |
I can go back and do the other |
16:02 |
bshum |
make check passes, though I do see all those deprecation warnings you speak of |
16:03 |
Dyrcona |
live tests are also blowing up, but I'm about to call it a day. |
16:08 |
Dyrcona |
We're definitely not ready for Ubuntu 18.04 and Perl 5.26.1. |
16:20 |
|
kmlussier joined #evergreen |
16:49 |
pinesol |
[evergreen|Dan Wells] LP#1791340 Webstaff: Don't backdate when we're not - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c09dd9a> |
10:26 |
berick |
bshum: oh, going for PG 10.. bold |
10:26 |
bshum |
berick: But hey, on the plus side, npm ran happily enough |
10:27 |
berick |
;) |
10:27 |
bshum |
berick: PG10 is the default for Ubuntu 18 |
10:27 |
bshum |
We could add the PG apt repo and only install up to 9.6 I guess |
10:27 |
bshum |
To match what we're doing with Stretch |
10:27 |
* bshum |
will consider that as an option to get a working system proceeding so that we can test the rest of it |
10:28 |
pinesol |
[evergreen|Jason Boyer] LP1792371: Fix De-select Whole Page Action - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5f4b487> |
10:29 |
bshum |
Oh for randomness, now that eg_startup is in apache_24 folder, we need to add it to the .gitignore too |
10:30 |
berick |
bshum: well, pg10 prep is certainly appreciated. if that's a pre-req for adopting the 18.04 install target, though, it will push it back. |
10:42 |
bshum |
Where they tell you that 9.6 is obsolete, and you should install 10 instead |
10:43 |
bshum |
Must be a package thing with the repo |
10:43 |
berick |
that was fast |
10:43 |
* bshum |
clicks OK and proceeds anyways |
10:43 |
bshum |
:D |
10:44 |
bshum |
Well their site says it's still supported through 2021 |
10:45 |
bshum |
I don't know why this warning popped up |
10:45 |
* bshum |
will test that further the next installs |
10:47 |
bshum |
And concerto DB created with PG 9.6 on Ubuntu 18.04. Moment of truth, firing up open-ils services... |
10:48 |
bshum |
And search works in tpac |
10:49 |
bshum |
Whee |
10:49 |
bshum |
Now to setup my websockets and see if the web client can open... lol |
10:49 |
berick |
woohoo |
10:49 |
bshum |
berick++ |
10:50 |
JBoyer |
bshum++ # What does this button do... |
10:52 |
Dyrcona |
bshum++ |
10:52 |
* Dyrcona |
is still working on getting OpenSRF to work with a clean Ubuntu 18 vm. |
10:54 |
bshum |
Staff client logs in for me too. |
10:54 |
bshum |
I'll test more of the parts later on |
10:54 |
bshum |
And get all the changes I recommend for OpenSRF and Evergreen into some branches for further testing |
10:56 |
bshum |
Unrelated, there are "ads" in my Ubuntu 18 terminal screen |
10:56 |
bshum |
"here's how to make a kiosk, look at this tutorial URL" |
10:56 |
bshum |
"here's entertainment tips to use with Ubuntu" |
10:56 |
Dyrcona |
Yes, I've seen those. |
10:56 |
bshum |
That's just weird |
10:56 |
Dyrcona |
No, just stupid. |
15:35 |
Dyrcona |
Lp 1793356 |
15:35 |
pinesol |
Launchpad bug 1793356 in OpenSRF "Ejabberd strips custom XML attributes" [Medium,Confirmed] https://launchpad.net/bugs/1793356 |
15:35 |
Dyrcona |
1 "5" not 2. |
15:38 |
berick |
Dyrcona: ah, thanks for checking that. test likely needs a poke |
15:39 |
Dyrcona |
Yeah, I suspect it is looking for things in attributes. |
15:40 |
Dyrcona |
Yeah, looks like the sample message needs updating on line 114. |
15:43 |
Dyrcona |
And, looks like line 202 is also blowing up. |
15:46 |
|
computertechie9 joined #evergreen |
15:47 |
Dyrcona |
berick: Would you like me to update the bug with the test failure details? |
15:53 |
berick |
Dyrcona: oh, yeah, or just a comment that it's happening so it's not lost |
15:53 |
Dyrcona |
Will doo. |
15:53 |
Dyrcona |
do. |
10:49 |
|
bdljohn joined #evergreen |
11:15 |
berick |
note to self, running 'prove' on a pgtap file produces confusing results. |
11:16 |
Dyrcona |
heh. |
11:34 |
berick |
would be great to get bug 1787274 merged before the RC - review/test volunteers needed |
11:34 |
pinesol |
Launchpad bug 1787274 in Evergreen "Web Client: Transits Don't Always Clear" [Critical,Confirmed] https://launchpad.net/bugs/1787274 |
11:37 |
miker |
berick: I have a few to toss in that boat, too. once I'm at a computer I'll list them here of that might be helpful |
11:38 |
berick |
miker: great |
11:38 |
* berick |
adds a test note to the LP |
11:39 |
kmlussier |
berick: I'm about to load some patches on a VM. I can add that one to the pile. |
11:39 |
berick |
kmlussier++ |
11:39 |
berick |
kmlussier: well, maybe wait for miker's input -- not sure what he's got in mind |
13:28 |
BAMkubasa |
hello good people. can anyone tell me in which of the data tables I can find details about secondary permission group(s) that a user is in? actor.usr has profile for the primary permission group, but I'm trying to find out other instances where staff have multiple permission groups |
13:29 |
jeff |
BAMkubasa: I believe that would be in permission.usr_grp_map |
13:29 |
jeff |
yep, just double checked my memory. you'll find a mapping in that table of usr (actor.usr.id) to grp (permission.grp_tree.id) |
13:34 |
BAMkubasa |
ok, gotcha Jeff. that worked with my test case. Thanks! |
13:34 |
jeff |
BAMkubasa: you're welcome! |
13:36 |
|
pihlstro7 joined #evergreen |
13:36 |
|
pihlstro7 was kicked by jeff: spam |
14:25 |
|
jvwoolf joined #evergreen |
14:25 |
kmlussier |
Nope. Looks like I added eg.circ.checkin.do_inventory_update. Sigh... |
14:27 |
kmlussier |
Actually, eg.circ.checkin.do_inventory_update is the correct setting that's tied to that checkin modifier. I don't know what that other one is. |
14:30 |
pinesol |
[evergreen|Jane Sandberg] Docs: LP1793184 adding to the 3.2 release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cbdc776> |
14:44 |
|
TheLugal18 joined #evergreen |
14:45 |
|
TheLugal18 was kicked by jeff: spam |
14:46 |
|
beanjammin joined #evergreen |
14:50 |
pinesol |
[evergreen|Bill Erickson] LP#1787274 Prevent multiple active copy checkins - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a03994f> |
14:50 |
pinesol |
[evergreen|Bill Erickson] LP#1787274 Active copy transit unique constraint - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=87bc5e5> |
14:50 |
pinesol |
[evergreen|Bill Erickson] LP#1787274 One active transit pgtap tests - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2b72119> |
14:50 |
kmlussier |
Gah! Forgot about the upgrade script. |
14:51 |
kmlussier |
Calling 1133 |
14:56 |
pinesol |
[evergreen|Kathy Lussier] LP#1787274: Stamping upgrade script for no dupe transits - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=af72b32> |
10:07 |
* csharp |
is looking at bug 1773434 |
10:07 |
pinesol |
Launchpad bug 1773434 in Evergreen "Item Status - missing option to "Show in Catalogue"" [Undecided,Confirmed] https://launchpad.net/bugs/1773434 |
10:08 |
|
jwoodard joined #evergreen |
10:08 |
csharp |
looks like we have working code there with a semi-signoff from kmlussier, but it ends with a question about menus |
10:09 |
csharp |
wondering if we shouldn't accept the fix as-is and let kmlussier open a new bug if she thinks it makes sense to change it - thoughts? |
10:09 |
* csharp |
was about to test and sign off |
10:10 |
pinesol |
[evergreen|Galen Charlton] LP#1786534: ensure that changes don't regress - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4894212> |
10:11 |
gmcharlt |
csharp: yeah, I think it makes sense to either leave that for a follow-up bug or just do a quick follow-up patch |
10:12 |
gmcharlt |
either way, so long as it doesn't block /something/ getting in for 3.2 |
11:02 |
Dyrcona |
The CStoreEditor generates search_ delete_ create_ and update_ functions for the objects from the IDL. It uses the oils_obj:fieldmapper attribute with the :: converted to an underscore. |
11:03 |
Dyrcona |
It also requires a transaction for delete, create, and update. |
11:03 |
Dyrcona |
If you have any specific questions, please ask. |
11:05 |
csharp |
jeffdavis: FYI, PINES staff are about to test bug 1715767 - hopefully we'll see a signoff so it can make it to 3.2 |
11:05 |
pinesol |
Launchpad bug 1715767 in Evergreen "Allow others to use my account (privacy waiver)" [Wishlist,New] https://launchpad.net/bugs/1715767 |
11:06 |
csharp |
(unless it's too late for getting that done) |
11:07 |
berick |
csharp: too late on that one for 3.2, but a sign-off now so we can merge as soon as rel_3_2 is branched would be great. |
12:38 |
|
plux left #evergreen |
12:38 |
|
plux joined #evergreen |
12:39 |
JBoyer |
git --amend --notary |
12:44 |
plux |
working on an upgrade from 3.0.3 to 3.2 beta on a test box - hit issues with the reingest at 1103.data.virtual_index_defs.sql - tried running with just one valid biblio.record_entry id and it just hangs - ditto for other records |
12:45 |
plux |
anyone else seeing issues with that? |
12:46 |
|
beanjammin joined #evergreen |
12:47 |
JBoyer |
plux, is postgresql completely crashing on you? depending on your database you might be running into bug 1764542 |
12:47 |
pinesol |
Launchpad bug 1764542 in Evergreen "Incorrect format on config.metabib_field insert results in segmentation fault" [High,Confirmed] https://launchpad.net/bugs/1764542 |
13:15 |
csharp |
hmm - that's interesting :-/ :https://pastebin.com/nrrRPgrX |
13:16 |
|
yboston joined #evergreen |
13:16 |
berick |
would have been more interesting had it returned a result ;) |
13:32 |
csharp |
trying to ferret out an issue where I register a workstation, log in with it, then am brought back to workstation (though it sees the one I registered) and when I click "Use Now" it goes back to the login page with "egAuth found no valid authtoken" in an endless loop |
13:33 |
csharp |
this is on FF and Chrome and cache/cookie clears have all happened |
13:34 |
csharp |
I've applied several patches at the behest of my colleagues for testing bugs, so I don't know what broke it :-/ |
13:36 |
Dyrcona |
charp: Have you tried doing the npm, make, and make install steps again? |
13:36 |
Dyrcona |
csharp, that is. |
13:36 |
csharp |
no, I haven't |
11:28 |
berick |
bshum++ |
11:29 |
bshum |
berick++ Dyrcona++ jeffdavis++ # trailblazers |
11:29 |
berick |
then i can merge the ansible branch |
11:30 |
pinesol |
[opensrf|Bill Erickson] LP#1777180 Websocketd gateway and test scripts - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=21c9c76> |
11:30 |
pinesol |
[opensrf|Jason Stephenson] LP#1777180 Update README for websocketd - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=d1c33b4> |
11:31 |
csharp |
okay for bug 1735816, after applying the patch, we're not seeing already-entered copy notes when we click copy notes - I can confirm they are created in the DB |
11:31 |
pinesol |
Launchpad bug 1735816 in Evergreen "Cannot Delete Existing Copy Notes" [Medium,Confirmed] https://launchpad.net/bugs/1735816 |
11:31 |
csharp |
gathering console output now |
11:35 |
JBoyer |
:/ Have you done all of the clear cache/hard reload voodoo that Chrome wants you too doo? |
11:37 |
csharp |
yeppers |
11:38 |
|
blongwell joined #evergreen |
11:40 |
bshum |
sandbergja++ # your testing notes are great! |
11:42 |
sandbergja |
Thanks! |
11:43 |
JBoyer |
Well that's fabulous, it looks like that patch has fallen off of production here... and all of our other machines. woo. |
11:43 |
JBoyer |
One moment. |
13:14 |
|
beanjammin joined #evergreen |
13:18 |
pinesol |
[opensrf|Ben Shum] LP#1777180: Add zip/unzip to prerequisites - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=da7e927> |
13:21 |
|
dkyle1 joined #evergreen |
13:25 |
bshum |
phasefx: FYI, I'm thinking to rebase the branches to eliminate wheezy install targets |
13:25 |
bshum |
And push those through, since Wheezy is definitely EOL |
13:25 |
bshum |
I know you're in the process of building a new live test server, but I just wanted to give you a head's up before I go ahead |
13:26 |
miker |
bshum: IMO, that's kinda a version-y thing... we know that up to 3.1 works on wheezy, so I'd say remove it for master only. thoughts? |
13:26 |
bshum |
miker: Yes I was only going to push that change for master only |
13:26 |
bshum |
(for 3.2) |
13:49 |
miker |
I'm glad we don't support IE ... think of all the phantom click sounds! |
13:49 |
berick |
that means it's working! |
13:50 |
berick |
well, not functioning, of course, but putting forth effort |
13:54 |
jihpringle |
aabbee: that fix is on my list to test in a sandbox later today |
13:55 |
aabbee |
jihpringle: great news, thank you! i hope it just misplaced the line when it was merged and is an easy fix. looking forward to knowing either way. |
14:18 |
pinesol |
[opensrf|Jason Stephenson] Lp#1718459: Remove Debian 7 Wheezy installation support. - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=265aa9f> |
14:20 |
|
rlefaive joined #evergreen |
15:47 |
berick |
jeff: only for the install -g @angular/cli bit |
15:47 |
berick |
i wonder if we can get rid of that, though |
15:48 |
JBoyer |
I thought all of the stuff that needed to be done by root was in <blah>-developer? |
15:48 |
bshum |
berick: Hmm, that directory doesn't exist on my test system anymore, but the folders leading up to it seem to be owned by me |
15:48 |
JBoyer |
my entire build (after prereqs) is run by opensrf until install time. |
15:49 |
berick |
JBoyer: it is... |
15:49 |
bshum |
Would it matter that I'm using myself benjamin, rather than opensrf to run the step though? Since the user is opensrf for the Evergreen repo |
15:53 |
JBoyer |
+- oops. |
15:53 |
berick |
https://gist.github.com/berick/6a5f9f111de78f23dbfd8f17227fa534 -- for example ;) |
15:53 |
jeff |
berick: ah, yeah. looks like installing @angular/cli locally is possible, but weird. |
15:54 |
berick |
anyway, the 2 "becomes" are what I'm trying to remove |
15:54 |
* berick |
doesn't have a clean vm handy at the moment to test |
15:54 |
bshum |
I can test that out on my busted VM with the error :) |
15:55 |
bshum |
But I'll retest it on a clean VM afterwards |
15:55 |
berick |
bshum: cool, may have to do some chown'ing first |
15:55 |
bshum |
I was just going to blow away the directories and start over too, but yeah I getcha |
15:55 |
berick |
the ultimate chown |
16:44 |
bshum |
I think for majority users, we'd want that option to exist and be turned on |
16:44 |
bshum |
Or at least, I would :D |
16:45 |
berick |
yeah, +1 to that. it is an OS-specific installer and this just makes that whole thing easier |
16:49 |
bshum |
berick: I'll put all those thoughts into a branch and test everyone on fresh VMs tomorrow |
16:50 |
bshum |
Thanks! |
16:50 |
bshum |
Signing off for now, have a nice day y'all |
16:50 |
Bmagic |
lata |
16:51 |
berick |
later bshum |
16:51 |
berick |
and thanks again |
10:49 |
csharp |
it's not happening to me on Linux (Chrome or FF) |
10:49 |
csharp |
yeah, we cleared cookies, then tried again |
10:49 |
|
stephengwills left #evergreen |
10:49 |
Dyrcona |
OK. I asked not because I have answers, but I didn't see that behavior when I tested it recently. I also used FF and Chromium on Linux. |
10:50 |
Dyrcona |
I did log in with eg2/staff, first. |
10:50 |
jeff |
csharp: What version of Chrome on each? By any chance, has one recently upgraded to Chrome 69 and the other is still on an earlier version? |
10:50 |
csharp |
https://pastebin.com/xaHugXr2 - dev tools console output |
13:15 |
pinesol |
[evergreen|Dan Scott] LP#1774886 Distinguish Phys Char Wizard with an edit icon - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1d38620> |
13:21 |
|
beanjammin joined #evergreen |
13:32 |
Dyrcona |
JBoyer: Would you mind sharing the SQL you used to cancel all of your duplicate transits? I am inclined to go with your solution to that problem. |
13:33 |
JBoyer |
I'll see if I still have it around. It took a few rounds to make sure I wasn't getting rid of things we need. (and I can't exactly test a recreation since it's stopped...) |
13:34 |
Dyrcona |
I can probably figure something out, but thought that if you did the work already, I could save myself some time. :) |
13:41 |
berick |
in case it hasn't been said, +1 to the unique constraint being part of the fix for that bug |
13:46 |
|
terran joined #evergreen |
14:11 |
|
yboston joined #evergreen |
14:11 |
csharp |
maybe something local |
14:13 |
Dyrcona |
JBoyer: That looks a lot like where my thoughts were heading. You should get all of the duplicates that way. |
14:13 |
bshum |
Well the copy locations editor worked for me when I opened it on my test VM |
14:14 |
bshum |
I don't remember how to navigate to funds :) |
14:14 |
pinesol |
[evergreen|Bill Erickson] LP#1724083 Webstaff approve pending patron address - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e763bd6> |
14:14 |
bshum |
The only way I found forward was through the eg2 version of it |
14:14 |
bshum |
But let's say that I'm rusty in my Evergreen navigation |
15:57 |
phasefx |
csharp: jeff: ^ I have multi-host support worked out |
15:58 |
csharp |
phasefx: there should be some VMs for the purpose (probably long out of date) on mundungus |
15:59 |
csharp |
I created Ubuntu, Debian, and Fedora hosts IIRC, but I didn't have credentials to set up buildslaves |
15:59 |
phasefx |
csharp: main things are 1) vm's need to be refreshed from snapshot periodically and 2) they need to accept an outside ssh connection (key-based) |
15:59 |
|
bdljohn1 joined #evergreen |
16:00 |
phasefx |
(optionally from a known IP if you want to tighten it further) |
16:00 |
|
bdljohn joined #evergreen |
16:02 |
|
bdljohn1 joined #evergreen |
16:05 |
phasefx |
branched from collab/phasefx/wheezy_installer, we have http://git.evergreen-ils.org/?p=working/random.git;a=tree;h=refs/heads/collab/phasefx/eg_live_tests There's a public key in there for livetesting.evergreen-ils.org, and a config file in qa/test_runner.xml for managing remote hosts |
16:06 |
|
bdljohn joined #evergreen |
16:10 |
csharp |
which OSes need to be testing? I have Ubuntu 14.04 & 16.04 and Debian jessie hosts running |
16:10 |
csharp |
I can add others |
16:10 |
|
bdljohn1 joined #evergreen |
16:11 |
phasefx |
csharp: I think the more the merrier, but I'll likely be getting a Debian Jessie vm to replace the wheezy one we've been using |
16:14 |
phasefx |
the script will fork a process for each server being tested |
16:14 |
Dyrcona |
phasefx: I'd go for stretch so that you get a longer support lifetime. |
16:15 |
phasefx |
Dyrcona: sounds sane to me |
16:16 |
* phasefx |
needs to put together a multi-host dashboard/summary page |
16:20 |
phasefx |
we could also test branches other than master if desired |
16:32 |
Dyrcona |
JBoyer: I think we need a more thorough approach to remove "duplicate" transits. I added a query and I was able to create the index, but I still have 1,712 copies with duplicate transits since we upgraded to 3.0 using my first query from https://pastebin.com/AqZeeeh2 |
16:38 |
|
mmorgan1 joined #evergreen |
16:42 |
Dyrcona |
But, I guess all of those transits can't be open....I think the open ones where another has been sent, should probably be canceled. |
00:08 |
|
sandbergja joined #evergreen |
01:06 |
|
beanjammin joined #evergreen |
06:31 |
pinesol |
News from qatests: Failed Running Evergreen browser client build/test - Expected 6 errors but encountered 3. <http://testing.evergreen-ils.org/~live> |
06:31 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live> |
06:42 |
|
JBoyer joined #evergreen |
06:56 |
|
agoben joined #evergreen |
07:10 |
|
rjackson_isl joined #evergreen |
08:19 |
JBoyer |
Ouch. That's really bad. :( |
08:21 |
JBoyer |
Have you put that server under fairly significant load to be certain it's not hardware at all? |
08:21 |
JBoyer |
(That's much more appealing than something in the db being so broken that the entire thing dies....) |
08:22 |
csharp |
yeah, this is a tried and true test server identical to our prod servers |
08:22 |
csharp |
been using it since 2014 - all appears to be fine hw-wise |
08:22 |
JBoyer |
Guess it's a good thing I'm planning to do the same here this week. :/ |
08:23 |
csharp |
I think I'll do a single-thread reingest with some RAISE NOTICEs as you suggested |
08:24 |
JBoyer |
++ |
09:34 |
|
jvwoolf joined #evergreen |
09:35 |
|
terran joined #evergreen |
09:49 |
|
collum joined #evergreen |
09:59 |
JBoyer |
Dyrcona, I don't have a lot of great info on the duplicate transits issue, as a test I canceled all of the duplicates and added a unique index on target_copy where the cancel and recv times are null. Haven't heard of any issues since. |
10:00 |
Dyrcona |
JBoyer: Thanks! That reminds that I need to search the logs for a particular example. |
10:03 |
JBoyer |
It's clearly still being triggered, as a quick grep of the index name is pulling up 27 attempts this month to insert a dup. :/ |
10:09 |
|
rlefaive joined #evergreen |
16:11 |
terran |
Thanks, that all reinforces my thoughts :) |
16:11 |
rhamby_ |
csharp: it's a fair cop |
16:14 |
Dyrcona |
:) |
16:17 |
terran |
berick++ for first patch signed off for bug squashing week! (and thanks to Garry for testing, but I don't see him in here) |
16:32 |
berick |
woohoo |
16:32 |
berick |
Garry++ |
16:39 |
phasefx |
berick: have you tried the eg2/ work on wheezy by chance? |
16:41 |
Dyrcona |
There is/are Lp bugs with branches to remove wheezy prereqs if anyone wants to dust them off. |
16:41 |
bshum |
https://bugs.launchpad.net/evergreen/+bug/1718459 |
16:41 |
pinesol |
Launchpad bug 1718459 in OpenSRF "Remove Installation Targets for Debian Wheezy" [Undecided,New] |
16:41 |
phasefx |
it'll take me a while to get the live tests moved over to something newer |
16:45 |
|
jvwoolf left #evergreen |
16:59 |
|
khuckins_ joined #evergreen |
17:02 |
|
Christineb joined #evergreen |