| 00:25 |
|
jamesrf joined #evergreen |
| 00:42 |
|
sandbergja joined #evergreen |
| 05:00 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-03-25T04:57:33,988624201-0400 -0> |
| 05:53 |
|
jamesrf joined #evergreen |
| 06:43 |
|
JBoyer joined #evergreen |
| 06:56 |
|
jamesrf joined #evergreen |
| 10:17 |
krvmga |
the key text element in the error refers to where the ISBN typically is and the UPC should be if no ISBN |
| 10:30 |
bshum |
krvmga: That sounds similar to https://bugs.launchpad.net/evergreen/+bug/1549393 |
| 10:30 |
pinesol |
Launchpad bug 1549393 in Evergreen 2.9 "AddedContent: Invalid ISBN's are sent to Content Cafe as blank string" [Medium,Fix released] |
| 10:30 |
bshum |
Which is an ancient and closed bug |
| 10:31 |
bshum |
Are you sure it's a valid UPC and no ISBN on the bib record you're checking? |
| 10:31 |
|
Christineb joined #evergreen |
| 10:32 |
bshum |
Interesting |
| 10:32 |
bshum |
That fix that Stompro provided in that bug only applied to ISBN/ISSN |
| 10:33 |
bshum |
So maybe it's an undef UPC value |
| 10:33 |
bshum |
https://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=15890219867ea44524a36b8becfaa12594984927 |
| 10:34 |
bshum |
See around line 184 of AddedContent.pm where it yanks out bad isbn/issn, maybe we need to add upc there |
| 10:37 |
bshum |
Yeah that seems logical. I don't have ContentCafe to test, but the symptoms and code seem to read out the way |
| 10:38 |
bshum |
So maybe try adding @upcs = grep {defined} @upcs; |
| 10:39 |
bshum |
Like the other ones there |
| 10:39 |
bshum |
Stompro++ |
| 10:40 |
bshum |
krvmga++ |
| 11:33 |
dbs |
bshum++ |
| 12:02 |
|
khuckins joined #evergreen |
| 12:09 |
|
jihpringle joined #evergreen |
| 14:44 |
csharp |
looks like this is some corner case with metarecord hold cancellation that I'm going to have to dig into in a week where I'm not under this much pressure |
| 14:44 |
csharp |
(migrating PINES to new colo in 2 weeks and I'm off next week) |
| 14:45 |
JBoyer |
csharp++ # good vibes! |
| 14:55 |
jeff |
Good reason to test "unusual" reingest methods. Passing a list of display fields to metabib.reingest_metabib_field_entries() means that only those display fields will be present after it completes. |
| 14:56 |
jeff |
i.e., if there were other display fields present for that record before, they will be removed if they are not in the supplied list of fields to reingest. |
| 14:56 |
jeff |
(at least in 3.1) |
| 14:56 |
jeff |
(mild surprise, not outright shock) |
| 15:09 |
csharp |
JBoyer: thanks! |
| 15:21 |
|
khuckins joined #evergreen |
| 16:19 |
pastebot |
"phasefx" at 64.57.241.14 pasted "user/berick/lp1811288-fm-editor-combobox" (78 lines) at http://paste.evergreen-ils.org/10823 |
| 16:30 |
berick |
bit of an edge case, where we pass in hard-coded values |
| 16:31 |
phasefx |
edge case is my name.. or maybe that was head case |
| 16:32 |
berick |
chaos-powers++ |
| 16:33 |
phasefx |
testing. I can probably streamline my build process.. it's a sledgehammer |
| 16:34 |
phasefx |
berick: all good, new and chaos resistant |
| 16:35 |
pinesol |
[evergreen|Jane Sandberg] LP1797934: follow-up: make the reservations tab in MyOpac optional - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5046ced> |
| 16:36 |
berick |
phasefx++ |
| 16:39 |
phasefx |
berick: minor one, tanget. got an ERROR Error: Uncaught (in promise): Object: {"dismissed":true,"message":"cross_click"} clicking the X to close the fm editor dialog |
| 16:49 |
berick |
may as well make the sandbox examples as useful as possible... |
| 16:53 |
phasefx |
berick: looks good! |
| 16:54 |
phasefx |
berick: though I must confess, I didn't expec to really create an entry in config.marc_field just now :D |
| 16:56 |
berick |
oh yeah, it's testing the actual plumbing |
| 16:57 |
pinesol |
[evergreen|Bill Erickson] LP1821409 Ang admin editor clears fields on new - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=29b100c> |
| 17:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:03 |
pinesol |
Showing latest 5 of 6 commits to Evergreen... |
| 17:03 |
pinesol |
[evergreen|Bill Erickson] LP1811288 Angular fm-editor uses combobox - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d63c7c3> |
| 17:03 |
pinesol |
[evergreen|Bill Erickson] LP1811288 Basic admin page readonlyFields repair - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=00de314> |
| 17:03 |
pinesol |
[evergreen|Bill Erickson] LP1811288 Admin grids preload combobox values - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9e69671> |
| 17:03 |
pinesol |
[evergreen|Bill Erickson] LP1811288 Allow Combobox to default to field id - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a3731c9> |
| 17:03 |
pinesol |
[evergreen|Bill Erickson] LP1811288 Sandbox editor handles dismissals - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fc8bd35> |
| 17:05 |
Bmagic |
When something is a direct charge - it doesn't seem to have any rows in acq.lineitem_detail. Is there any way to connect those fund_debit's to anything? The invoice_entry is null |
| 17:07 |
|
mmorgan left #evergreen |
| 17:15 |
berick |
Bmagic: acq.po_item |
| 05:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 08:02 |
|
collum joined #evergreen |
| 08:07 |
|
troy____ joined #evergreen |
| 08:08 |
|
bshum_ joined #evergreen |
| 15:13 |
berick |
ok it's fixed in the branch for bug 1811288 |
| 15:13 |
pinesol |
Launchpad bug 1811288 in Evergreen "Angular Fieldmapper Editor should use combobox for linked fields" [Medium,New] https://launchpad.net/bugs/1811288 |
| 15:13 |
berick |
https://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=e9d2882b79816ba52e1db55a6cc96990b3526b68 |
| 15:13 |
sandbergja |
Oh, great! |
| 15:13 |
sandbergja |
berick++ |
| 15:17 |
sandbergja |
dbwells: what are the chances that bug 1811288 could get into the release candidate, if I could test it and sign off on it within the next few hours? |
| 15:17 |
pinesol |
Launchpad bug 1811288 in Evergreen "Angular Fieldmapper Editor should use combobox for linked fields" [Medium,New] https://launchpad.net/bugs/1811288 |
| 15:17 |
sandbergja |
it would be really nice to save users and servers from dropdown menus that are populated with every single bib record in the catalog! |
| 15:24 |
dbwells |
It's a pretty big change at this late hour, and the diffs are a little hard for me to read. |
| 15:33 |
berick |
ok, so I rebased user/berick/lp1811288-fm-editor-combobox to master |
| 15:33 |
berick |
retested and confirmed it fixes the booking issue |
| 15:34 |
berick |
and that it behaves as expected for creating booking resources, etc. |
| 15:47 |
dbwells |
sandbergja: My brain is getting a little leaky with all the various eg2 branches, so I am starting to test a few to hopefully push in as well. Just a heads up in case some merge conflicts result. |
| 15:48 |
berick |
dbwells: holler if I can be of assistance |
| 15:48 |
dbwells |
will do |
| 16:07 |
dbwells |
berick: Testing #1807461, I see a bug, but I think it is unrelated. If you edit a row, you can no longer create new rows. The old edit data is still there, so I am guessing it might be an ID collision, as the old ID is there, and you can't delete it. Does that sound familiar? |
| 16:08 |
dbwells |
"old edit data is still there" meaning the editor form is still populated with all data from the edit, even when creating new. |
| 16:11 |
* berick |
looks |
| 16:12 |
dbwells |
This was in the "Claim Type" editor, since that is what was referenced on the bug, but it probably manifests elsewhere as well. |
| 16:14 |
pinesol |
[evergreen|Bill Erickson] LP#1807458 Angular admin grid Edit Selected option - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=89948f5> |
| 16:47 |
sandbergja |
in case of really big lists? |
| 16:51 |
berick |
sandbergja: exactly. that's how the dojo widget handled it, so i tried to keep it consisten |
| 16:55 |
sandbergja |
berick: thanks! |
| 17:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:03 |
pinesol |
[evergreen|Bill Erickson] LP1812670 Angular grid shows selector labels - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8480ca2> |
| 17:03 |
pinesol |
[evergreen|Bill Erickson] LP#1819179: Angular value formatter gets link smarts - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2fe4212> |
| 17:03 |
pinesol |
[evergreen|Bill Erickson] LP1819179 IDL2js includes 'map' attribute data - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d26ece2> |
| 17:03 |
pinesol |
[evergreen|Bill Erickson] LP1819179 PCRUD selector fleshing handles maps - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1db81cf> |
| 17:08 |
|
mmorgan left #evergreen |
| 17:12 |
berick |
dbwells++ |
| 17:16 |
sandbergja |
berick: I like all the comboboxes, but I'm a little hesitant about how many interfaces that used to preload those values (both in dojo, and of course under the current ng client) now would not. I suspect that -- in some of those cases -- users rely on being able to see a complete list of possible values. |
| 05:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:01 |
|
agoben joined #evergreen |
| 07:15 |
|
rjackson_isl joined #evergreen |
| 07:34 |
|
bdljohn joined #evergreen |
| 08:40 |
|
bos20k joined #evergreen |
| 08:53 |
|
mmorgan joined #evergreen |
| 08:54 |
Dyrcona |
So, I think my issues with the fine generator and open-ils.storage are memory issues. |
| 08:57 |
Dyrcona |
Because, I started running the fine generator on a test VM yesterday and today, I see that is has used swap, and there's a decent amount of RAM in the O/S cache: 4GB. |
| 08:57 |
Dyrcona |
I'm working on getting the rss sizes of the drones, the listener is not presently all that big. |
| 08:59 |
|
aabbee joined #evergreen |
| 09:07 |
Dyrcona |
Interesting... All of the storage processes, including the listener have had 15,000+ minor page faults while running. That's no big deal, right, because that's accessing stuff that's in RAM already. |
| 09:44 |
|
nfBurton joined #evergreen |
| 09:55 |
|
tlittle joined #evergreen |
| 10:01 |
|
tlittle joined #evergreen |
| 10:05 |
Dyrcona |
So, our storage drones seem to use around 260MB of RAM apiece and I'm cycling through them rather quickly, at least on this test machine. |
| 10:06 |
Dyrcona |
Perhaps, I should up the connection count settings on the machine that runs the fine generator? |
| 10:22 |
jeff |
I wouldn't focus on the swap usage too much, especially that amount. If vm.swappiness is at the default of 60, swap usage isn't something that indicates "we're running out of physical memory". |
| 10:25 |
Dyrcona |
jeff: I know that it normally doesn't. It can, though if your swap usage gets really high and you have a large number of swap ins and swap outs....When swap usage is 100%, you've got real problems. :) |
| 10:26 |
Dyrcona |
I also think that bumping the connection count for storage on the utility server will help, as I'll cycle through drones less quickly that way. |
| 10:27 |
jeff |
Sure, just trying to talk you down from chasing "why did my system use 1.6 megabytes of swap" :-) |
| 10:27 |
Dyrcona |
Yeah, and it dropped to 160K rather soon after. |
| 10:28 |
Dyrcona |
The fine generator has been running for the past 1.5 hours on my test vm, and it is still doing something as I'm tailing syslog. |
| 10:29 |
Dyrcona |
The test db is also busy with other things. |
| 10:29 |
Dyrcona |
when this stops. I'll up the connection count by a factor of 10. |
| 10:34 |
|
collum joined #evergreen |
| 10:36 |
Dyrcona |
Looks like drones are being recycled at a rate of about 1 every 3 minutes. |
| 10:47 |
Dyrcona |
Seems to be going through cstore drones at a similar clip, too. That must be some of the storage calls using cstore. |
| 10:48 |
Dyrcona |
Think I'll up the max requests on cstore for the next test. |
| 11:22 |
phasefx |
@later tell sandbergja re: LP1721109, I noticed a syntax error in line 430 of cat/item/app.js, with var all_items = itemSvc.copies.map((item) => {return item.id}); |
| 11:22 |
pinesol |
phasefx: The operation succeeded. |
| 11:32 |
jeff |
certificate expired on https://yeti.esilibrary.com |
| 11:36 |
|
sandbergja joined #evergreen |
| 11:37 |
Dyrcona |
Lp 1721109 |
| 11:37 |
pinesol |
Launchpad bug 1721109 in Evergreen 3.2 "Web client: Editing item information from the item status screen does not automatically update item status display" [Medium,Fix committed] https://launchpad.net/bugs/1721109 |
| 11:37 |
phasefx |
also, I only saw the syntax error with npm, haven't tested it in a real browser. Could be a version issue on my end given that the functionality tested out |
| 11:38 |
phasefx |
npm and rhino |
| 11:38 |
berick |
that would be interesting if browsers supported arrow functions |
| 11:38 |
berick |
not impossible |
| 11:39 |
Dyrcona |
rhino? Really? |
| 11:45 |
Dyrcona |
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions#Browser_compatibility |
| 11:45 |
berick |
Dyrcona: neat |
| 11:45 |
|
khuckins joined #evergreen |
| 11:45 |
phasefx |
fwiw, the live tester behaves the same (reports a syntax error) but doesn't flag a warning/error with the QA tests |
| 11:46 |
Dyrcona |
phasefx: You're getting the syntax from npm run test ? |
| 11:46 |
phasefx |
Dyrcona: yeap |
| 11:47 |
phasefx |
http://testing.evergreen-ils.org/~live/cronoutput.txt |
| 11:47 |
* Dyrcona |
usually skips that. |
| 11:48 |
berick |
probably best to de-arrow-ify for now |
| 11:48 |
|
sandbergja_ joined #evergreen |
| 11:49 |
Dyrcona |
So, PhantomJS doesn't like it. |
| 11:49 |
phasefx |
Dyrcona: I tried to make the installer match the instructions on the website as closely as possible; we call for npm run test there |
| 11:49 |
Dyrcona |
phasefx: Yeah, it definitely makes sense to run the test on the QA testing server. :) |
| 11:49 |
phasefx |
:D |
| 11:50 |
Dyrcona |
I usually skip it on my own installations because it usually passes and I'm lazy. :) |
| 11:50 |
Dyrcona |
I do run it for new stuff that I'm doing, though. |
| 11:51 |
phasefx |
so the actual shell level return value from npm run test is 0, which is why the tests didn't sound an alarm |
| 11:51 |
phasefx |
though I could start looking for it explicitly |
| 11:51 |
phasefx |
http://testing.evergreen-ils.org/~live/test.28.html |
| 11:53 |
* Dyrcona |
agrees with berick that it is probably best to de-arrowify it for now. |
| 11:53 |
Dyrcona |
Shame to miss out on language features from the 1950s, though. :) |
| 11:54 |
JBoyer |
Oh, and as for the arrow func, it's probably complaining because what that really says is "return return item.id;" -- The only contents of an arrow function are "return (your text here)" |
| 11:57 |
jeff |
so that's unlikely to happen anytime soon. |
| 11:58 |
sandbergja |
JBoyer: hahaha, that's what I thought. :-) |
| 11:58 |
JBoyer |
Is it still used by node, or only the version of node that builds the AngularJS parts of the client? |
| 11:59 |
berick |
JBoyer: it's used for headless unit tests |
| 11:59 |
berick |
node doesn't use it |
| 11:59 |
JBoyer |
Ah, that's where I was getting confused. |
| 11:59 |
JBoyer |
berick++ |
| 12:02 |
|
jeff_ joined #evergreen |
| 12:30 |
nfBurton |
sandbergja++ |
| 12:32 |
|
afterl joined #evergreen |
| 13:04 |
|
krvmga joined #evergreen |
| 13:21 |
Dyrcona |
Doing another fine_generator.pl run while monitoring drone memory usage. Looks like I was right, the first drone that gets the list of overdue circs is the biggest, but not by much in this test run. |
| 13:23 |
berick |
3043651 |
| 13:23 |
pinesol |
berick: [opensrf|Bill Erickson] LP#1706147 Perl Force-Recycle drone option - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=3043651> |
| 13:23 |
berick |
Dyrcona: ^-- may be of interest |
| 13:24 |
berick |
if a drone gobbles up a lot of ram, the API in question can be modified to exit after a single call of said API. |
| 13:25 |
Dyrcona |
Might be handy, but for this run it's only using about 13MB more than the others. |
| 13:30 |
Dyrcona |
I'll test that patch later, as in tomorrow or after next week. |
| 13:31 |
Dyrcona |
As expected, after upping max requests for both storage and cstore, drones are sticking around longer. It also took longer to spawn a 6th cstore drone, though that may not be related to the setting change. |
| 13:38 |
|
Christineb joined #evergreen |
| 13:38 |
Dyrcona |
I expected storage drones to start dying off by now, but they haven't. |
| 14:22 |
miker |
#topic Release Manager (Dan Wells) |
| 14:23 |
|
Topic for #evergreen is now Release Manager (Dan Wells) (Meeting topic: EOB meeting for 2019-03-21, agenda: https://wiki.evergreen-ils.org/doku.php?id=governance:minutes:2019-03-21) |
| 14:23 |
miker |
dbwells: sir, have you anything for us? |
| 14:23 |
dbwells |
Not too much to report. I'll be building and testing the RC over the next couple days. |
| 14:23 |
dbwells |
We also need to still sort out some of the new translation bits, but we're getting there. |
| 14:23 |
dbwells |
It's been a pretty quiet and routine release cycle, which I think is as expected. |
| 14:23 |
dbwells |
Any questions? |
| 14:24 |
terran |
dbwells++ |
| 14:24 |
collum |
dbwells++ |
| 14:24 |
miker |
dbwells: one -- should we be avoiding angular7 infrastructure pushes in 3.3? |
| 15:29 |
JBoyer |
collum++ |
| 15:30 |
agoben |
collum++ |
| 15:35 |
|
afterl left #evergreen |
| 17:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:04 |
|
mmorgan left #evergreen |
| 17:25 |
|
yboston joined #evergreen |
| 18:04 |
|
dbwells_ joined #evergreen |
| 01:21 |
|
sandbergja_ joined #evergreen |
| 05:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:48 |
|
agoben joined #evergreen |
| 07:11 |
|
rjackson_isl joined #evergreen |
| 07:36 |
|
bdljohn joined #evergreen |
| 15:32 |
berick |
dbwells++ |
| 15:32 |
berick |
thanks |
| 15:40 |
phasefx |
Stompro: Dyrcona: the call number pull list fix (lp1749502), for me, if you do Print Full List twice in a row, it renders the affix id's and not the labels |
| 15:41 |
csharp |
ok, so the next step, I think, is to implement cross-domain registration in a test environment. Does anyone out there have docs or examples I could use for this? I have a high-level understanding of what needs to happen, but I'm not sure how to actually do it |
| 15:42 |
* csharp |
steps away for a bit but will be back soon |
| 15:49 |
|
sandbergja_ joined #evergreen |
| 15:50 |
berick |
csharp: take w/ grain of salt cuz I'm not using it, but IIRC you just have to add public and private <router> entries in opensrf_core.xml per each host |
| 15:50 |
berick |
that's assuming the bricks can already route to each other and jabber is using non-localhost domains (e.g. private.brick01, public.brick01, etc.) |
| 15:52 |
Dyrcona |
phasefx: I see that one some rows but not others. I'm getting -1 on some prefixes. |
| 15:52 |
Dyrcona |
Also, doing it a third time, everything looks OK. |
| 15:53 |
Stompro |
phasefx, Interesting, I'll test that out. |
| 15:55 |
phasefx |
I imagine most folks will only invoke it once per page load, but my chaos powers are compulsive |
| 15:55 |
Dyrcona |
Doesn't seem to be much rhyme nor reason when it happens and if it it is prefix, suffix, or both. |
| 15:55 |
Dyrcona |
Well, if you do it again and again you get different results each time, at least I seem to. |
| 16:09 |
phasefx |
Stompro: sure, it's back up, but with an extra commit beyond master |
| 16:09 |
phasefx |
in the pull list grid UI, no less :) but shouldn't affect the bug |
| 16:10 |
Dyrcona |
Stompro: I saw the same thing as phasefx. I could open it, look at it, close, then open it again. |
| 16:12 |
Stompro |
phasefx, yep, I see it too on your test system. Hmm, I'll check to see what I missed when creating the commit. |
| 16:15 |
Dyrcona |
I'm only seeing it with affixes of -1. phasefx did you see it with others? |
| 16:15 |
phasefx |
Dyrcona: yes, the REF one from concerto |
| 16:16 |
Dyrcona |
OK. Could be that the list I was looking at had no actual affixes. |
| 16:16 |
Dyrcona |
I was using production data with a small library. |
| 16:16 |
phasefx |
I created a pull list in concerto by hitting up 3 bibs with copy level holds, and specifically modifying the item for the 2nd hold to have a prefix and suffix |
| 16:17 |
Dyrcona |
Good way to test it. I just logged in and brought up the pull list. :) |
| 16:17 |
phasefx |
I also played with location affixes too, because I forgot those were just for label printing |
| 16:19 |
* phasefx |
is poking at lp1779316 and wanted to see what changes were made recently |
| 16:19 |
Dyrcona |
I wonder if fleshing the affixes would be better than going back and retrieving them? We seem to do a lot of pcrud lookups in the web staff client for that sort of thing. |
| 16:57 |
|
sandbergja__ joined #evergreen |
| 17:00 |
sandbergja__ |
Hey all -- I've got Evergreen running on localhost, using docker. But Firefox doesn't like weird ports like 7682 under a self-signed certificate. Does anybody know if there's a way I can adjust about:config so that Firefox isn't so picky about that? |
| 17:00 |
sandbergja__ |
FWIW, I can use Chromium just fine. |
| 17:02 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-03-20T16:59:00,937625555-0400 -0> |
| 17:03 |
sandbergja__ |
I tried setting network.security.ports.banned.override to 7682, but that didn't help :-( |
| 17:05 |
|
mmorgan left #evergreen |
| 17:13 |
berick |
sandbergja__: try navigating to https://HOST:7682/osrf-websocket-translator |
| 00:02 |
|
sandbergja joined #evergreen |
| 05:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:15 |
|
rjackson_isl joined #evergreen |
| 07:31 |
|
agoben joined #evergreen |
| 07:41 |
|
bdljohn joined #evergreen |
| 11:26 |
Dyrcona |
Ok. I take that back. Of the two that are active, one has a custom granularity that works out to daily, the other doesn't. |
| 11:27 |
Dyrcona |
Ours are working, but we're on 3.0.13. |
| 11:28 |
pastebot |
"Bmagic" at 64.57.241.14 pasted "Trigger logs" (7 lines) at http://paste.evergreen-ils.org/10507 |
| 11:28 |
Dyrcona |
They seem to be working on our 3.2 test machine. |
| 11:29 |
Dyrcona |
To answer your question, no. If that's the main trigger that marks items lost it goes by checkout.due. |
| 11:30 |
Dyrcona |
The notices and extra triggers that play off something going lost should have lost.auto. |
| 11:30 |
Bmagic |
yep, that's what I've got |
| 16:45 |
|
nfBurton joined #evergreen |
| 16:45 |
csharp |
okay - websocketd is back in place - no significant difference between now and before with apache2-websockets |
| 16:45 |
csharp |
also looks like restarting services staves off the issue for a while |
| 16:46 |
nfBurton |
Quick Q: Running an update on my test server and keep getting " duplicate key value violates unique constraint "upgrade_log_pkey"". Is there something wrong with my DB or the upgrade script? |
| 16:46 |
nfBurton |
The DB upgrades are not my friend today |
| 16:47 |
csharp |
nfBurton: sounds like you're trying to apply an upgrade you already have? |
| 16:47 |
nfBurton |
I'm not though... |
| 16:52 |
nfBurton |
I've been commenting those out since they aren't Combo Breakers |
| 16:53 |
csharp |
it only happens if you apply upgrade scripts outside normal "version" upgrades |
| 16:53 |
csharp |
which I think all of us do from time to time |
| 16:54 |
nfBurton |
Yeah. This is just my test which I thought was in line with my production site but may have pushed some updates along at some point |
| 16:55 |
nfBurton |
Is there a generally accepted reinjest script for the whole catalog as well? While I am here |
| 16:55 |
nfBurton |
I should run that too |
| 16:56 |
csharp |
nfBurton: Open-ILS/src/support-scripts/pingest.pl is nice if you have a large database |
| 17:01 |
csharp |
hmm |
| 17:01 |
nfBurton |
Yeah |
| 17:01 |
nfBurton |
I have set up 3 new collections and they all do the same thing |
| 17:01 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-03-19T16:57:59,497208919-0400 -0> |
| 17:01 |
nfBurton |
I feel like a CRON job must clean them up if it randomly happens |
| 17:03 |
csharp |
might need to look directly at the metabib data for the records where it's not changing |
| 17:04 |
csharp |
that's getting into territory I'm less familiar with day-to-day, but have had to troubleshoot before |
| 00:46 |
|
sandbergja joined #evergreen |
| 04:37 |
|
jamesrf joined #evergreen |
| 05:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:00 |
|
JBoyer joined #evergreen |
| 07:02 |
|
agoben joined #evergreen |
| 07:10 |
|
rjackson_isl joined #evergreen |
| 09:59 |
Dyrcona |
berick: I think csharp was referring to the fact that apache2-websocket processes would go ballistic from time to time, not that it made a difference in drone usage. |
| 09:59 |
Dyrcona |
At least, that's what I meant about websocketd making a difference. |
| 10:04 |
csharp |
berick: so the idle timeout with websocketd is set in the nginx config, right? (as opposed to the apache config for apache2-websockets where we left the nginx timeouts higher) |
| 10:04 |
berick |
csharp: correct |
| 10:05 |
berick |
as a test, maybe knock it down to 1 minute |
| 10:05 |
miker |
csharp: opensrf is already able to distribute load. you can create a single xmpp domain, as Dyrcona suggests, or just tell the services about all the existing domains (which requires they have non-localhost addresses and unique names) |
| 10:05 |
csharp |
berick: thanks |
| 10:05 |
* Dyrcona |
uses non-localhost addresses anyway, but doesn't do cross-brick communication, yet. |
| 15:40 |
miker |
gmcharlt: will look, sec |
| 15:44 |
berick |
forgot all about that stuff |
| 15:45 |
berick |
gmcharlt: i trust your research there. |
| 15:48 |
miker |
gmcharlt: hrm. it looks to me like we still eval it into place if no added content provider is defined in opensrf.xml, no? I haven't looked past the named commit yet |
| 15:49 |
miker |
gmcharlt: we don't in master... ok, it does look dead to me, indeed |
| 15:51 |
miker |
looks like we can drop a test! :) |
| 15:52 |
miker |
Open-ILS/src/perlmods/t/06-OpenILS-Application-Search.t specifically |
| 15:52 |
miker |
or, one in there |
| 15:53 |
|
bdljohn joined #evergreen |
| 16:25 |
csharp |
...and we're back to drone saturation |
| 16:25 |
csharp |
might have to revert to apache2-websockets |
| 16:58 |
csharp |
sounds more like the album name than the band name though |
| 17:00 |
bshum |
jeff++ berick++ csharp++ # I miss production issues (not really) |
| 17:00 |
csharp |
it's a mixed bag - the soul-crushing lows are often followed by dizzying highs |
| 17:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:01 |
* bshum |
now wants pumpkin pie |
| 17:01 |
bshum |
It's too early for this. |
| 17:02 |
* bshum |
wanders off, but will read the rest of this adventure story later |
| 17:41 |
csharp |
this feels like something that could be fixed with tuning configs though |
| 17:42 |
csharp |
at this very moment, everything is pretty balanced across (after restarting opensrf to reactivate backlog queuing) |
| 17:42 |
csharp |
also just generally calmer |
| 17:43 |
berick |
yeah, probably over the hump |
| 17:44 |
berick |
well, keep us posted, especially if you decide to revert websocketd to test. |
| 17:44 |
csharp |
thanks! |
| 17:44 |
berick |
guessing tests now won't prove much |
| 17:45 |
csharp |
agreed |
| 19:33 |
|
Dyrcona joined #evergreen |
| 20:26 |
|
gryffonophenomen joined #evergreen |
| 05:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 05:17 |
|
RBecker joined #evergreen |
| 06:59 |
|
agoben joined #evergreen |
| 07:14 |
|
rjackson_isl joined #evergreen |
| 13:05 |
Dyrcona |
Bmagic 00:00:06, 00:00:08, and one is 5 minutes. |
| 13:05 |
Dyrcona |
RMiller_ I'm working on a complete insert SQL for you. |
| 13:06 |
RMiller_ |
Thank you! I'm starting to figure out SQL stuff a little, but I don't want to make a bigger mess |
| 13:08 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "RMiller_ Should work. I have not tested it." (9 lines) at http://paste.evergreen-ils.org/10296 |
| 13:08 |
mmorgan |
Dyrcona++ |
| 13:12 |
RMiller_ |
That fixed it! Check in is working now! |
| 13:12 |
RMiller_ |
Thank you so much! |
| 13:12 |
Dyrcona |
You're welcome. |
| 13:29 |
* Dyrcona |
is going to reboot the laptop. |
| 13:38 |
|
Dyrcona joined #evergreen |
| 14:24 |
Stompro |
Dyrcona, about splitting the code up. Does each commit need to be fully independent of each other for a situation like this, or can they build off of each other, seperate commits in the same branch that should be tested together? |
| 14:26 |
Dyrcona |
Stompro: Either way, could also all be in one commit. It depends on the tickets, etc. |
| 14:26 |
Dyrcona |
I prefer to split things up into logical chunks and prefer not to have branches that cover multiple Lp bugs, but I sometimes do the latter. |
| 14:27 |
* Dyrcona |
is not a huge fan of omnibus branches or bugs, but deals with 'em when they happen. |
| 14:29 |
Dyrcona |
More specifically, I was offering to help if you had a single commit, say, that you wanted to split into multiple commits. |
| 14:44 |
|
stephengwills joined #evergreen |
| 14:52 |
|
yboston joined #evergreen |
| 17:01 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-03-15T16:58:14,560346605-0400 -0> |
| 17:05 |
|
mmorgan left #evergreen |
| 17:44 |
|
mcgriff joined #evergreen |
| 18:42 |
|
stephengwills joined #evergreen |
| 00:23 |
|
sandbergja joined #evergreen |
| 05:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:32 |
|
JBoyer_alt joined #evergreen |
| 06:37 |
|
bos20k joined #evergreen |
| 06:55 |
|
agoben joined #evergreen |
| 09:49 |
|
sandbergja joined #evergreen |
| 10:03 |
pinesol |
[evergreen|Bill Erickson] LP1739293 Record merge horizontal; optional holdings - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=29882b4> |
| 10:03 |
pinesol |
[evergreen|Bill Erickson] LP1739293 Record merge fits container - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d2ad575> |
| 10:03 |
Bmagic |
csharp: Do you have a machine seperate from the production cluster that you can test on? Things started becoming more clear once I did that |
| 10:03 |
pinesol |
[evergreen|Bill Erickson] LP1739293 Record merged edit-in-place avoid wrap - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=df8973b> |
| 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 |
| 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 |
| 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 |
