| Time |
Nick |
Message |
| 00:16 |
|
sandbergja joined #evergreen |
| 01:06 |
|
sandbergja joined #evergreen |
| 01:46 |
|
sandbergja joined #evergreen |
| 05:59 |
|
cmalm joined #evergreen |
| 07:01 |
|
agoben joined #evergreen |
| 07:10 |
|
rfrasur joined #evergreen |
| 07:11 |
|
rjackson_isl joined #evergreen |
| 07:14 |
|
Dyrcona joined #evergreen |
| 07:15 |
|
collum joined #evergreen |
| 07:50 |
pinesol |
[evergreen|Terran McCanna] LP#1843637 MARC View Display Issues - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9bf50ce> |
| 08:10 |
|
tlittle joined #evergreen |
| 08:15 |
|
bos20k joined #evergreen |
| 08:47 |
|
mmorgan joined #evergreen |
| 08:59 |
Dyrcona |
Grr. Trying to convert a do block that uses exception/when into a function and Pg keeps saying syntax error at or near END for the END closing the function's begin. Doesn't matter if I add a semicolon or remove it. |
| 09:01 |
Dyrcona |
OIC.... I need another BEGIN... |
| 09:04 |
Dyrcona |
Thanks, ducky! :) |
| 09:15 |
Dyrcona |
Whee! Nothing like call number labels to contain garbage, well, after MARC.... :P |
| 09:17 |
|
aabbee joined #evergreen |
| 09:32 |
|
jvwoolf joined #evergreen |
| 09:33 |
rhamby |
Dyrcona: you forget addresses :) |
| 09:34 |
Dyrcona |
:) |
| 09:35 |
Dyrcona |
During MVLC's migration, I found phone numbers entered as "The number in the field above is the student ID." I guess because phone number was below the ID field in the old ILS. :) |
| 09:36 |
Dyrcona |
Today, I've been asked to regularize some call number labels. Something I've done a number of times before. It really exercises one's regex fu. |
| 09:38 |
* Dyrcona |
considers "cheating" by dumping the rows to a CSV, mangling them manually, and generating a SQL update script from the CSV. |
| 09:46 |
Dyrcona |
On the plus side, production and test data are the same for a change. |
| 09:48 |
|
mmorgan1 joined #evergreen |
| 09:54 |
|
sandbergja joined #evergreen |
| 09:55 |
|
yboston joined #evergreen |
| 10:01 |
|
gsams joined #evergreen |
| 10:06 |
Dyrcona |
Eh... Bummer.... unique violation.... Back to the mess.... |
| 10:10 |
Dyrcona |
Some things are more easily done in Perl.... |
| 10:11 |
|
tlittle60 joined #evergreen |
| 10:14 |
Dyrcona |
PgAdmin-- # Too crashy.... |
| 10:14 |
Stompro |
postgres 12 rc1 released - postgresql++ Someday we will upgrade from 9.4 |
| 10:19 |
Dyrcona |
Stompro: You'll have to for 3.4. |
| 10:19 |
Dyrcona |
Stompro: Try Pg 10 and let me know how it goes. :) |
| 10:19 |
|
jvwoolf1 joined #evergreen |
| 10:20 |
berick |
heh, i felt so bleeding edge on 9.6. i'm already crusty. |
| 10:21 |
Dyrcona |
Maybe we'll skip 11 and go straight to 12? |
| 10:22 |
Dyrcona |
Heh. Nigels' may go to 11. Mine go to 12. :) |
| 10:22 |
csharp |
I'm testing 11 right now - but I might chicken out and go from 9.5 to 9.6 :-/ |
| 10:22 |
berick |
Dyrcona++ |
| 10:23 |
csharp |
@ana none more black |
| 10:23 |
pinesol |
csharp: Noblemen croak |
| 10:23 |
Dyrcona |
csharp: We need more testing on 10, really. No one has really put it through its paces. |
| 10:23 |
Dyrcona |
A propos nothing: gnu.org seems to be really slow today. |
| 10:23 |
csharp |
10 probably makes more sense since it's the default in 18.04 |
| 10:26 |
Dyrcona |
We also "support" it in master/3.4. |
| 10:27 |
csharp |
I think you just convinced me :-) |
| 10:46 |
|
tlittle42 joined #evergreen |
| 11:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 11:07 |
Dyrcona |
Grrr.... "unexpected EOF while parsing" and I don't see the syntax error.... |
| 11:07 |
|
yboston joined #evergreen |
| 11:08 |
|
berick joined #evergreen |
| 11:10 |
|
sandbergja joined #evergreen |
| 11:14 |
Dyrcona |
Retyping a couple of lines fixed it.... |
| 11:35 |
rjackson_isl |
trying to push security patches to our various servers and thanks to JBoyer I now have our dev, migration and production servers patched |
| 11:36 |
rjackson_isl |
However, our training server (ubuntu 14.04) is stuck in limbo not allowing /sbin/initctl start opensrf or stop to execute |
| 11:37 |
rjackson_isl |
any ideas why those commands would get stuck? (where to look for issues?) |
| 11:39 |
* phasefx |
is not familiar with initctl |
| 11:40 |
Dyrcona |
I'd look at your init script for opensrf. And, these are not standard, so not supported by the community. |
| 11:40 |
Dyrcona |
Also, you should upgrade to Ubuntu 16.04. |
| 11:40 |
rjackson_isl |
yeah - if only I were a sys admin... :( |
| 11:42 |
Dyrcona |
Well, you can always kill the running processes. |
| 11:42 |
rjackson_isl |
Dyrcona - yeah that is true but it results in the ansible software running on our admin server dying |
| 11:43 |
rjackson_isl |
so the update aborts and around and around I go :( |
| 11:43 |
Dyrcona |
Well, that's another thing we don't support: ansible. :) |
| 11:43 |
rjackson_isl |
++ or -- or not sure! |
| 11:43 |
Dyrcona |
:) |
| 11:43 |
Dyrcona |
@decide ++ or -- |
| 11:43 |
pinesol |
Dyrcona: go with -- |
| 11:44 |
rjackson_isl |
that was my inclination as well |
| 11:44 |
Dyrcona |
I'm going to guess that the start and stop mechanism on the 14.04 server is out of date vis a vis the other servers and what ansible and/or initctl expect. Or you simply don't have init scripts there. |
| 11:45 |
Dyrcona |
JBoyer, berick, and bshum are the culprits behind the ansible scripts, IIRC. |
| 11:47 |
berick |
I assume rjackson_isl is using local ansible stuff that most of us never seen. |
| 11:48 |
rjackson_isl |
berick this was all recently inherited and unfortunately my understanding of the entire process is limited |
| 11:49 |
berick |
*have never seen* -- I sound like a total hillbilly |
| 11:50 |
Dyrcona |
:) |
| 11:50 |
JBoyer |
Yeah, parts of the stuff in use at EI has been shared in the 12.04 or 14.04 timeframe. |
| 11:51 |
JBoyer |
But upstart and systemd scripts haven't really been pursued in depth. (the ship has sailed on upstart anyway.) |
| 11:52 |
JBoyer |
rjackson_isl, I'd recommend looking at other examples that have something like ignore_errors: ok or something like that, applying that to all of the service lines that touch opensrf, and see if docs.ansible.com references a timeout that can be applied to modules in general, or the service module specifically. |
| 12:03 |
|
jihpringle joined #evergreen |
| 12:21 |
|
rfrasur joined #evergreen |
| 12:24 |
|
mmorgan joined #evergreen |
| 12:28 |
|
sandbergja joined #evergreen |
| 12:46 |
|
collum joined #evergreen |
| 12:48 |
|
jvwoolf joined #evergreen |
| 12:50 |
|
jvwoolf1 joined #evergreen |
| 13:00 |
|
yboston joined #evergreen |
| 13:03 |
|
khuckins joined #evergreen |
| 13:05 |
dbs |
Another bonus of migrating docs.evergreen-ils.org to project-owned servers: for https://docs.evergreen-ils.org/ "The certificate is only valid for the following names: *.mohawkcollege.ca, mohawkcollege.ca" :/ |
| 13:11 |
jeffdavis |
Is there a filter function for Angular admin pages? (aside from the org unit filter) |
| 13:12 |
jeffdavis |
or maybe I should say a filter widget, comparable to the filter option in Dojo UIs |
| 13:13 |
sandbergja |
jeffdavis: you ask such a good question. We could theoretically just add [filterable]="true" to the basic admin page component |
| 13:13 |
sandbergja |
which would add filters to every column |
| 13:14 |
sandbergja |
thanks to the work that Equinox did for the acquisitions angular-ization |
| 13:14 |
sandbergja |
However, when I tried fiddling around with that, it got really cluttered really fast |
| 13:14 |
sandbergja |
So I think we'd need to prioritize which columns should get filters, and which don't need them |
| 13:17 |
berick |
agreed re: prioritizing columns |
| 13:18 |
berick |
could also support making columns filterable as a grid-level preference |
| 13:18 |
jeffdavis |
Does the Dojo filter exclude columns? I had the impression you could filter on pretty much anything. |
| 13:18 |
berick |
jeffdavis: you can, but the Angular version of the filter UI displays inline in the grid and it gets very cluttered |
| 13:19 |
jeffdavis |
Could we just make a similar widget and avoid the clutter? |
| 13:19 |
berick |
the Dojo one is a separate dialog, so it's not a big deal there |
| 13:19 |
berick |
jeffdavis: maybe, but then you lose some of the utility of the Angular filter -- being able to see the filters inline and tweak them w/ just a click, that kind of stuff |
| 13:20 |
berick |
i imagine there's a middle ground though.. |
| 13:20 |
khuckins |
I wonder if the prioritized columns idea would work well in the current implementation as an array instead of a boolean, so you get the filter boxes only on the columns specified? Or a condensed mode |
| 13:21 |
jeffdavis |
Where would it be specified? For the autogenerated pages I have the impression it would need to be in the fieldmapper. |
| 13:22 |
sandbergja |
Low hanging fruit decision would be not to include a filter for the context org unit, since there's already a filter for that up top. :-) |
| 13:24 |
sandbergja |
Didn't jihpringle report a bug recently about an angular admin page that *really* needed filters? |
| 13:25 |
jeffdavis |
you may be thinking of bug 1843970 |
| 13:25 |
pinesol |
Launchpad bug 1843970 in Evergreen "MARC Coded Value Maps Filter Missing" [Undecided,New] https://launchpad.net/bugs/1843970 |
| 13:25 |
jeffdavis |
but there are a number of others - booking admin > resources is another good example |
| 13:26 |
sandbergja |
yes! that's the one I was thinking of |
| 13:27 |
jeffdavis |
On the subject of admin-page-specific configurability, I've been stymied by lack of that ability on bug 1834687 - can't see a way to link to secondary admin pages (e.g. Z39.50 source -> Z39.50 attributes) short of defining the relationship in the fieldmapper somehow. |
| 13:27 |
pinesol |
Launchpad bug 1834687 in Evergreen 3.3 "Z39.50 Servers Attributes page missing" [Medium,Confirmed] https://launchpad.net/bugs/1834687 |
| 13:32 |
jeffdavis |
looks like bug 1831788 for the "filterable" option (thanks Christineb) |
| 13:32 |
pinesol |
Launchpad bug 1831788 in Evergreen "angular: add filtering, sticky headers, and other improvements to eg-grid" [Wishlist,Fix released] https://launchpad.net/bugs/1831788 |
| 13:38 |
sandbergja |
To get really philosophical: what makes a column good for filtering? |
| 13:38 |
sandbergja |
vs. another column that is not so helpful as a filter? |
| 13:42 |
jeffdavis |
looking at admin/booking/resource as an example, I can imagine wanting to filter on any of the columns except possibly Overbook |
| 13:45 |
jeffdavis |
for SVF Record Attribute Coded Value Map I want to be able to filter on Value, Search Label, SVF Attribute, maybe Code, maybe OPAC Visible, but probably not the primary key or other fields |
| 13:46 |
jeffdavis |
I don't know if there is a general rule for "do we want to filter on this" |
| 13:52 |
jeffdavis |
A filter widget that exploits the gridFilters param is looking pretty appealing to me right now, although there's probably a more Angular-ish way to do it |
| 14:06 |
|
jvwoolf joined #evergreen |
| 14:21 |
|
sandbergja_ joined #evergreen |
| 14:28 |
|
yboston joined #evergreen |
| 14:32 |
rjackson_isl |
JBoyer++ to infinity and beyond! |
| 15:03 |
|
mmorgan1 joined #evergreen |
| 15:03 |
csharp |
dbs: the server is provisioned for docs migration - we just need to coordinate the bofh team with mohawk for the changeover |
| 15:55 |
|
yboston joined #evergreen |
| 16:04 |
|
nfBurton joined #evergreen |
| 16:06 |
|
jihpringle joined #evergreen |
| 16:15 |
Bmagic |
Anyone seen this? Open chrome and hit the offline interface. It doesn't load completely, and about 10 seconds later THE WHOLE BROWSER CLOSES. It's the weirdest thing. Crashes Chrome with no error report. |
| 16:19 |
jeffdavis |
I've seen offline crash the browser on Download Block List, don't think I've seen it just on loading offline. |
| 16:21 |
Bmagic |
hmmm, I am starting to wonder if the reason is: first having the block list downloaded. Then going into offline mode, and the browser code for loading that block list in offline mode is causing the issue |
| 16:23 |
|
jvwoolf left #evergreen |
| 16:53 |
|
mmorgan joined #evergreen |
| 17:09 |
|
mmorgan left #evergreen |
| 17:20 |
jeffdavis |
3.4beta2 AngJS build is failing for me with "SyntaxError: Expected an identifier but found 'lead' instead at cat/bucket/record/app.js:702" |
| 17:20 |
jeffdavis |
or at least giving the above error |
| 17:21 |
jeffdavis |
PhantomJS 2.1.1, Ubuntu 16.04 |
| 17:22 |
berick |
s/let/var/ |
| 17:23 |
|
khuckins joined #evergreen |
| 17:25 |
Dyrcona |
jeffdavis: I might try later. Are you using git or the tarball? I'm assuming git because that step is already done for the tarball. |
| 17:25 |
jeffdavis |
yeah, tarball seems ok |
| 17:26 |
Dyrcona |
Have you tried master? |
| 17:27 |
Dyrcona |
I haven't built much lately other than 3.2.9 and 3.2.8. |
| 17:27 |
csharp |
jeffdavis: I saw the same thing installing master yesterday - definitely not just you |
| 17:27 |
berick |
confirmed, phantomjs does not like 'let' |
| 17:28 |
jeffdavis |
also getting an "integrity checksum failed" error, just rebuilding to see where that is happening |
| 17:29 |
|
jihpringle joined #evergreen |
| 17:31 |
Bmagic |
jeffdavis: guess what? It was the block list. The current block list is weighing in at 36MB and 2,269,926 lines. This apparently introduces a bug into Evergreen causing Chrome to crash and browser to exist without a trace |
| 17:31 |
jeffdavis |
aha |
| 17:31 |
Bmagic |
exist/exit |
| 17:32 |
jeffdavis |
"exist without a trace" kinda works too |
| 17:32 |
Bmagic |
:) |
| 17:32 |
jeffdavis |
bug 1727557 |
| 17:32 |
pinesol |
Launchpad bug 1727557 in Evergreen 3.3 "Web Client: Download Block List causes unresponsive page with large file" [High,Confirmed] https://launchpad.net/bugs/1727557 |
| 17:32 |
Bmagic |
I was just looking at that bug. It's not exactly the same bug |
| 17:32 |
Bmagic |
The download works fine |
| 17:33 |
Bmagic |
It takes ~5 minutes but it finishes and the page continues working fine |
| 17:33 |
Dyrcona |
jeffdavis: I'll say what I always say when someone mentions PhantomJS: The main github repo is archived. We need to ditch for something else. |
| 17:34 |
Dyrcona |
Bmagic: Yeah, browsers don't like dealing with "large" files. Don't think I'll repeat myself from 2012.... |
| 17:34 |
Bmagic |
I wonder if a possible solution is Hatch |
| 17:35 |
Dyrcona |
No, a possible solution is a stand-alone client. |
| 17:35 |
jeffdavis |
Bmagic: I think the issue is not the file download but pulling its contents into local storage, which it's probably doing from your already-downloaded block list |
| 17:35 |
Bmagic |
yep |
| 17:35 |
Bmagic |
Dyrcona: :) |
| 17:36 |
Bmagic |
I guess I can "head -n 100000 list.txt > list.txt" |
| 17:36 |
Dyrcona |
You can, but you'll be missing a number of entries. |
| 17:36 |
Bmagic |
lol, oh really? |
| 17:37 |
Dyrcona |
:) |
| 17:37 |
Dyrcona |
Actually, you'll end up with an empty file. |
| 17:37 |
jeffdavis |
So, looks like `npm install` for eg2 is also failing currently, separate from the above issue. |
| 17:37 |
jeffdavis |
npm ERR! code EINTEGRITY |
| 17:37 |
jeffdavis |
npm ERR! sha1-mnHEh0chjrylHlGmbaaCA4zct78= integrity checksum failed when using sha1: wanted sha1-mnHEh0chjrylHlGmbaaCA4zct78= but got sha1-0javwSQJyHOlXIo1EmipnceQPXE=. (10980065 bytes) |
| 17:37 |
Bmagic |
Not sure if it's better to have nothing or just make it smaller so we don't have to advise everyone to "DON'T TOUCH THE DOWNLOAD BUTTON" |
| 17:37 |
Dyrcona |
Redirecting stdout to the file you're reading usually gives you nothing. |
| 17:38 |
Dyrcona |
Well, don't generate the blocklist in the first place, then the download button does nothing. :) |
| 17:38 |
Dyrcona |
jeffdavis: npm sucks, too. |
| 17:38 |
Bmagic |
right, or that |
| 17:38 |
* Dyrcona |
is just full of joy this evening. :) |
| 17:38 |
jeffdavis |
well yes, but I still need to install EG on this server |
| 17:39 |
Dyrcona |
Well, you can't, apparently, not until someone fixes their package on npm. |
| 17:54 |
csharp |
Bmagic: yeah, we just stopped creating the download - we also hid the button |
| 17:55 |
csharp |
https://git.evergreen-ils.org/?p=evergreen/pines.git;a=commit;h=a8155c449c40c0926d7dfb8f7ab379911207e3c4 |
| 17:57 |
jeffdavis |
I actually have the necessary node_modules folders for earlier versions stashed in a git repo to avoid npm problems during custom builds, I just don't have it for 3.4beta2 |
| 18:06 |
|
sandbergja_ joined #evergreen |
| 19:06 |
|
cmalm joined #evergreen |
| 21:54 |
|
sandbergja joined #evergreen |
| 22:06 |
|
sandbergja joined #evergreen |
| 23:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 23:35 |
|
sandbergja joined #evergreen |
