| Time |
Nick |
Message |
| 07:29 |
|
collum joined #evergreen |
| 07:58 |
|
rfrasur joined #evergreen |
| 08:04 |
|
BDorsey joined #evergreen |
| 08:31 |
|
Dyrcona joined #evergreen |
| 08:35 |
|
mmorgan joined #evergreen |
| 08:37 |
|
mantis1 joined #evergreen |
| 08:48 |
|
dguarrac joined #evergreen |
| 08:53 |
Dyrcona |
Looks like B&T are "at it" again. I'm going to set a timeout of 10 or 15 seconds in OpenILS::Utils::RemoteAccount::_ftp. |
| 08:54 |
Dyrcona |
According to perldoc Net::FTP the default timeout is 120 seconds, i.e. 2 minutes, which I can verify by my logs. |
| 09:09 |
Dyrcona |
And, an oversimplified patch is working. It should be made configurable. |
| 09:35 |
Dyrcona |
Ha! OK: "2>&1 > /dev/null | grep -v 'already retrieved'" |
| 09:56 |
Dyrcona |
Now, today's problem: OCLC search returned 0 hits on production. However, it works from training, and they are running the same release of Evergreen, but production had recent updates installed. The OCLC search not working sounds familiar. |
| 10:05 |
Dyrcona |
Trying to search the IRC logs with Google turned up nothing. |
| 10:15 |
Dyrcona |
And, it's working today, but was busted yesterday.... |
| 10:19 |
collum |
Dyrcona: Maybe this? At 11:02 - http://irc.evergreen-ils.org/evergreen/2022-01-27 |
| 10:24 |
Dyrcona |
collum: Nope. Not that this time. Other outside things were working. |
| 10:25 |
Dyrcona |
Also, if click on the time, or copy the time URL from the web logs, you'll get an anchor to that point in the log. (For the logs, and those who don't know.) |
| 10:25 |
Dyrcona |
Also, I've made sure the firewall rules are persitent. :) |
| 10:26 |
Dyrcona |
And, it mysteriously fixed itself this morning..... |
| 10:26 |
collum |
Ah! I didn't even try clicking on the time. :-) |
| 10:27 |
Dyrcona |
Must be something beyond my control... :) |
| 10:40 |
Dyrcona |
For those having issues with EDI and B&T, i.e. the fetcher keeps running for hours, here's a patch: https://bugs.launchpad.net/evergreen/+bug/1836908/comments/1 |
| 10:40 |
pinesol |
Launchpad bug 1836908 in Evergreen "EDI File Transfer Needs to be Smarter" [Undecided,Confirmed] |
| 10:40 |
csharp_ |
I'm struggling with getting a couple of columns I've added to the fieldmapper to show in the AngularJS patron holds interface - I see them in reports... |
| 10:41 |
csharp_ |
(working on bug 1963541 ) |
| 10:41 |
pinesol |
Launchpad bug 1963541 in Evergreen "Staff-forced Hold cancelation leaves no trace of staff who did it " [Undecided,Confirmed] https://launchpad.net/bugs/1963541 |
| 10:42 |
mmorgan |
csharp_++ |
| 10:43 |
csharp_ |
not showing up in Angular either |
| 10:43 |
csharp_ |
regular culprits: reports fm_IDL.xml is updated correctly, autogen.sh has been run |
| 10:44 |
Dyrcona |
You reocmpiled AngularJS after? |
| 10:44 |
csharp_ |
yes, I did |
| 10:44 |
Dyrcona |
What table? |
| 10:44 |
Dyrcona |
ahr? |
| 10:44 |
csharp_ |
ahr |
| 10:44 |
csharp_ |
https://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=2478eaddd31a2d20c9086c43e3a9d239ba7513af - WIP |
| 10:46 |
csharp_ |
my latter half of the year's resolution is to get more fluent in Angular(JS) and JavaScript generally |
| 10:46 |
Dyrcona |
Ah, well, you did the first thing that I was going to suggest: Add them to CDBI/action.pm. |
| 10:46 |
Dyrcona |
csharp_++ |
| 10:48 |
Dyrcona |
fm_IDL.xml passes xmllint? |
| 10:50 |
csharp_ |
yes, it does |
| 10:52 |
Dyrcona |
I thought the columns would just show up in the picker, at for AngularJS, but I suppose I am wrong. I should look into that more myself. |
| 10:53 |
csharp_ |
I'll look for other examples where a column was added to a grid |
| 10:56 |
Dyrcona |
Is autofields set to true on the grid in question? |
| 10:57 |
csharp_ |
uhhh |
| 11:00 |
Dyrcona |
OK... The issue might be the fetch wide holds function. |
| 11:02 |
csharp_ |
oh - hmm |
| 11:04 |
Dyrcona |
Yeah... Looks like you'll want to add your new fields to Storage/Publisher/action.pm around line 2208. |
| 11:04 |
Dyrcona |
It looks like the AngularJS egHolds services uses the wide holds interface. |
| 11:05 |
Dyrcona |
Wow! That's a crazy query. :) |
| 11:07 |
Dyrcona |
Hopefully nothing is relying on the order of the fields from the function. It looks like AngularJS uses a hash. |
| 11:07 |
csharp_ |
Dyrcona: thanks for the tip - I'll give it a shot |
| 11:08 |
|
jvwoolf joined #evergreen |
| 11:08 |
Dyrcona |
Hope it helps! |
| 11:08 |
mmorgan |
Dyrcona++ |
| 11:09 |
csharp_ |
holy crap, you're not kidding |
| 11:10 |
* csharp_ |
gets nervous when seeing monolithic code like that |
| 11:14 |
Dyrcona |
I'd probably add the new fields on a new line below h.hopeless_date at line 2208 or above or below the is staff hold check at line 2224. |
| 11:15 |
Dyrcona |
The former is probably the better choice, given that the columns below that line are either from other tables or calculated. |
| 11:22 |
collum |
ccharp_: look at src/templates/staff/circ/patron/t_holds_list.tt2. |
| 11:22 |
collum |
I added this line underneath the Cancel Cause line in <eg-grid-field label="[% l('Canceled By') %]" path='hold.canceled_by' hidden></eg-grid-field> afterwards it displayed the user id of the canceller. |
| 11:23 |
collum |
In the patron's canceled holds. |
| 11:25 |
berick |
wide holds has a ton of useful columns. adding new ones is pretty easy too. |
| 11:25 |
mmorgan |
Does the patron's canceled holds list also use wide holds? |
| 11:26 |
csharp_ |
collum: that works! thanks - when I get my branch closer to publishing condition I'll ask that you contribute that |
| 11:27 |
Dyrcona |
csharp_: I'd still add them to the wide holds query just to make sure. |
| 11:27 |
csharp_ |
Dyrcona: yes, I've done that |
| 11:28 |
berick |
mmorgan: no, not until we migrate to the Angular patron interfaces. |
| 11:28 |
|
jihpringle joined #evergreen |
| 11:28 |
Dyrcona |
Cool! csharp_++ collum++ |
| 11:28 |
collum |
csharp_: you can just add it, if you want. I was just playing. |
| 11:28 |
mmorgan |
collum++ |
| 11:29 |
mmorgan |
berick++ |
| 11:30 |
csharp_ |
collum: thanks! - look for your name in the commit when I get to that point :-) |
| 11:30 |
csharp_ |
lunch will make things way better - back in a bit :-) |
| 11:31 |
Dyrcona |
lunch++ |
| 11:31 |
Dyrcona |
csharp_: I might as well join you for lunch. |
| 11:31 |
Bmagic |
where y'all going? |
| 11:32 |
berick |
spies not welcome |
| 11:32 |
Bmagic |
lol, of course you are |
| 11:32 |
berick |
heh |
| 11:41 |
Dyrcona |
I'm going to my kitchen for leftovers. |
| 11:45 |
mmorgan |
Lunch time already?? Morning flew by! |
| 12:34 |
|
collum joined #evergreen |
| 12:39 |
|
collum joined #evergreen |
| 12:48 |
|
jvwoolf left #evergreen |
| 13:31 |
|
jihpringle joined #evergreen |
| 13:42 |
|
mixo joined #evergreen |
| 13:42 |
mixo |
hello |
| 13:42 |
mixo |
I am run Open-ILS/src/support-scripts/settings-tester.pl |
| 13:43 |
mixo |
get this error |
| 13:43 |
mixo |
libdbi PostgreSQL driver not found in shared library path; |
| 13:46 |
Dyrcona |
Does Evergreen work, or are you trying to diagnose a problem with settings-tester.pl? |
| 13:46 |
mixo |
staff client does not work |
| 13:48 |
mixo |
when I am trying to login and adding workstation, It saves, but browser web console says there is no workstation |
| 13:48 |
Dyrcona |
mixo: I get that message and many more on a system that does work. settings-tester.pl is likley out of date. |
| 13:49 |
Dyrcona |
mixo: What happens when you add the workstation? Do you click use now and get redirected to the login page? |
| 13:51 |
mixo |
I have this error in chrome console |
| 13:51 |
mixo |
main.3fe318102e967afcb3ee.js:1 No such workstation "" |
| 13:51 |
Dyrcona |
Did you log out and log back in with the workstation? The client won't actually be able to use it until you do so. |
| 13:56 |
mixo |
yes, I log out and login again, it asks for registering workstation, then it says "Workstation "CONS-mmm" already exists. Use it anyway?" |
| 13:56 |
mixo |
and I agree with this |
| 13:57 |
mixo |
but every time asks for registration workstation |
| 13:58 |
Dyrcona |
Are you using Incognito or Private windows? |
| 13:58 |
mixo |
and chrome console says No such workstation "" |
| 13:59 |
mixo |
when I am trying use this workstation |
| 14:00 |
Dyrcona |
If you use Incognito Mode in Chrome it will ask you to register the workstation every time because the browser can't save it. |
| 14:01 |
mixo |
no I do not use incognito |
| 14:01 |
Dyrcona |
The same might happen if you have a very restrictive set up and it won't save browser state between sessions or your computer user account cannot write to where Chrome stores user data. |
| 14:01 |
mixo |
there is this error also |
| 14:01 |
mixo |
RROR Error: Uncaught (in promise): Error: Cannot match any routes. URL Segment: 'staff/admin/workstation/workstations/remove' |
| 14:01 |
mixo |
Error: Cannot match any routes. URL Segment: 'staff/admin/workstation/workstations/remove' |
| 14:02 |
jeff |
Anyone here running their database server(s) on ARM CPUs? |
| 14:03 |
Dyrcona |
mixo: I don't know that part of the system very well. I was hoping you had something easy going on. :) |
| 14:03 |
Dyrcona |
jeff: I'm not, but I considered it. |
| 14:04 |
mmorgan |
mixo: Have you tried clearing cookies? Also, have you used hatch? |
| 14:04 |
mixo |
yes I used hatch |
| 14:05 |
mixo |
what this mean "DevTools failed to load source map: Could not load content for https://evergreen1.tsu.ge/upup.sw.min.js.map: HTTP error: status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE" |
| 14:05 |
Dyrcona |
mixo: That last one is normal. You can ignore it. There are a number of "errors" like that. |
| 14:06 |
mmorgan |
mixo: Are you able to register a workstation with a name you have not used before? |
| 14:07 |
jeff |
That specific class of errors (failure to retrieve a file ending in .js.map) is due to the browser's Dev Tools attempting to load an optional file that can make debugging minified JavaScript code easier. As Dyrcona mentioned, those specific errors can be ignored. |
| 14:09 |
Dyrcona |
jeff: Any particular reason you're asking about ARM? |
| 14:16 |
jeff |
Budget season approaches! |
| 14:17 |
jeff |
AWS has a number of ARM-based instance types. |
| 14:18 |
jeff |
...and GCP has some in preview / pre-GA |
| 14:18 |
mixo |
I tried now add workstation in windows and it was succesfull |
| 14:19 |
mixo |
and I have one question, thank you for help |
| 14:19 |
mixo |
WARNING Error parsing JSON message on STDIN org.json.JSONException: A JSONObject text must begin with '{' at 3 [character 1 line 2] : |
| 14:20 |
mixo |
this appears during hatch test |
| 14:20 |
mixo |
is this problem? |
| 14:20 |
Dyrcona |
jeff: I imagine that ARM would as well as x86. |
| 14:21 |
Dyrcona |
...would work as well as x86. |
| 14:26 |
Dyrcona |
mixo: I don't have any experience with Hatch. Maybe someone else knows? |
| 14:30 |
JBoyer |
jeff, ARM is interesting, but I don't know much about the performance of server-based ARM processors. I assume they (have to) be better in comparison to Xeons than Qualcom's laptop chips compare to mobile x86? |
| 14:36 |
* Dyrcona |
uses an ARM laptop. |
| 14:44 |
JBoyer |
All of the reviews of Windows ARM laptops sound horrible, though I suppose Linux may not suffer from some of the same issues. (A big issue on Windows apparently being that everything not installed from the factory is emulated x86.) |
| 14:50 |
Dyrcona |
I have a Pinebook Pro (https://www.pine64.org/pinebook-pro/). It's not as fast as my Dell XPS13 but it's definitely usable. And everything is compiled for ARM. |
| 14:50 |
collum |
Just checking all of our AWS instances, they are all x86. I also checked RDS. It doesn't look like you have options for architecture. |
| 14:50 |
Dyrcona |
I suspect that JavaScript in FF and Chromium are not as well optimized. |
| 17:09 |
|
mmorgan left #evergreen |
| 17:41 |
|
jihpringle joined #evergreen |
| 17:47 |
|
Stompro joined #evergreen |
