| Time |
Nick |
Message |
| 02:00 |
|
dbs joined #evergreen |
| 07:30 |
|
collum joined #evergreen |
| 07:57 |
|
BDorsey joined #evergreen |
| 08:32 |
|
kworstell-isl joined #evergreen |
| 08:37 |
|
mmorgan joined #evergreen |
| 09:09 |
|
rfrasur joined #evergreen |
| 09:29 |
|
dguarrac joined #evergreen |
| 09:37 |
|
Dyrcona joined #evergreen |
| 10:01 |
|
mmorgan1 joined #evergreen |
| 10:15 |
Dyrcona |
Well, something isn't right. I'm looking at reporter templates and I don't get the same hash values as in the table when I do what I think is the way to calculate the hash. I obviously don't still don't understand something. |
| 10:22 |
Dyrcona |
Hmm... Dunno why I'm getting different results... I doubt either of the md5 functions is bugged. |
| 10:29 |
Dyrcona |
So, my results with Python and Emacs Lisp are consistent, but don't match what I get in the database. |
| 10:31 |
Dyrcona |
This full path "ahr-expire_time" shows relation of "3b0d7d05c65006de7b2ca20f5fe39690" in the database. |
| 10:31 |
Dyrcona |
When I hash just the relpath "ahr" I get "35b605f929209fc6cba65789d1f6b61c" with Python and with Emacs. |
| 10:33 |
Dyrcona |
With the Python, I went through the steps of split and join, etc., as well just to see if that made a difference. It didn't. |
| 10:36 |
|
mmorgan joined #evergreen |
| 10:42 |
Dyrcona |
I love that this is the only test for the hex_md5 function in our library: return hex_md5("abc") == "900150983cd24fb0d6963f7d28e17f72"; |
| 10:43 |
Dyrcona |
Python, Emacs, and our JS library all agree on that one, just not on other strings. |
| 10:44 |
Dyrcona |
Oops. Spoke too soon. They don't agree. The beginning and ends are the same. |
| 10:44 |
Dyrcona |
So, I suspect a bug in md5.js.... |
| 10:46 |
Dyrcona |
Grr.. I'm having one of those mornings... They do agree on "abc" after all. |
| 10:47 |
Dyrcona |
But, they don't agree on "ahr" apparently. |
| 10:51 |
Dyrcona |
Does anyone know how to run JavaScript from the Linux command line without install Node? I don't want to pollute my laptop with that garbage. |
| 10:53 |
JBoyer |
Dyrcona, you could install rhino. Though then you get to ask yourself if you'd rather install node or a JRE. |
| 10:55 |
Dyrcona |
JBoyer: I've used rhino in the past. |
| 10:55 |
Dyrcona |
I have a JRE installed already, there is also jsc from the libjavascriptcoregtk-4.0-bin package. |
| 10:56 |
Dyrcona |
I'm not sure that the latter can do "include" or library files. I'm trying to find out. |
| 10:57 |
JBoyer |
Ah yeah, jsc is another one I saw reference to (and is available out of the box on macOS, so handy for me) |
| 10:57 |
Dyrcona |
Heh. |
| 10:57 |
JBoyer |
I'd probably lean that way since I don't know how up to date rhino is. (may be fine, dunno) |
| 10:57 |
Dyrcona |
Turns out I've also used javax.script.* with nashorn in the past. |
| 10:58 |
Dyrcona |
Yeah, jsc claims to be interactive, too. I need to find more documentation. |
| 10:59 |
Dyrcona |
There's a JavaScript plugin for LibreOffice, too, but it's aimed at writing macros. |
| 11:05 |
Dyrcona |
Looks like I might be able to us jsc. It has a load(filename) function. |
| 11:05 |
Dyrcona |
gmchartl++ Bmagic++ JBoyer++ abneman++ mmorgan++ # Did I forget anyone? |
| 11:05 |
Dyrcona |
gmcharlt++ even.... |
| 11:06 |
Dyrcona |
abneiman++ |
| 11:06 |
mmorgan |
Dyrcona++ |
| 11:06 |
* Dyrcona |
should just used autocomplete ... :) |
| 11:06 |
mmorgan |
gmcharlt++ |
| 11:07 |
* gmcharlt |
randomly whines about autocomplete in Slack - do it on the nick, please and dagnabbit, not the name! |
| 11:07 |
mmorgan |
Bmagic++ |
| 11:07 |
mmorgan |
JBoyer++ |
| 11:07 |
Bmagic |
mmorgan++ gmcharlt++ JBoyer++ abneman++ Dyrcona++ # Go go gadget Evergreen! |
| 11:07 |
mmorgan |
abneiman++ |
| 11:09 |
Dyrcona |
Aight.... So, when I load md5.js and run hex_md5('ahr'); I get the same value as from Python and Emacs, but it doesn't match the value in this reporter template..... |
| 11:10 |
Dyrcona |
The breakage is elsewhere, or I'm looking at the wrong code. |
| 11:40 |
gmcharlt |
https://evergreen-ils.org/security-release-evergreen-3-8-3-3-9-2-and-3-10-1/ |
| 11:44 |
berick |
gmcharlt++ |
| 11:46 |
pinesol |
News from commits: fix title of the 3.10 release notes document <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=b1fbd441a60bf2dfa99f4c0b21122bc58d7f4121> |
| 11:46 |
pinesol |
News from commits: Docs: 3.10.1 release notes - edited <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=6fd1bd1f76b261d61b41a1f796dbaf01a9ad5611> |
| 11:46 |
pinesol |
News from commits: Docs: 3.9.2 release notes - edited <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=1595e1b867917717657d9ae0eadbaaabfc9f3664> |
| 11:46 |
pinesol |
News from commits: update 3.8.3 release notes to include security fix information <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=05d86d16495a6ef867e82a6dd923200aabdcb746> |
| 11:46 |
pinesol |
News from commits: update 3.9.2 release notes to include security fix information <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=6f846c7725119ac6b1d1f591730c129f6f279db7> |
| 11:46 |
pinesol |
News from commits: update 3.10.1 release notes to include security fix <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=d5b401aa45bdeb55564b491e153458ad3e236c6c> |
| 11:46 |
pinesol |
News from commits: Docs: 3.10.1 release notes <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=fdccc0707e62e577123d4c2fbd23c83bde6577a5> |
| 11:46 |
pinesol |
News from commits: Docs: 3.9.2 release notes <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=f89c9f8aef6a4692d3beb4a8ae80471c0c204a11> |
| 11:47 |
pinesol |
News from commits: Docs: 3.8.3 release notes <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=c5b468ecbc5f4a05c93e844c1616ed595f511989> |
| 11:47 |
pinesol |
News from commits: LP#1361782: (follow-up) fix the default search limit in seed data <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=d50e68e0f01e7bacf0ade169890843b83a4c4e51> |
| 11:47 |
pinesol |
News from commits: LP#1361782: stamp DB update <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=21e9855ce07369d90c2f159100fcf904a67d02ac> |
| 11:47 |
pinesol |
News from commits: DoS protection release notes <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=ac87e869cc1c0c6ab2c06f2eecfbfaaa45624258> |
| 11:47 |
pinesol |
News from commits: LP#1361782: Add DoS protection <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=c88cdba786981fbab3a8a933634cc4096f5c9cb7> |
| 11:47 |
pinesol |
News from commits: qtype CGI param protection release notes <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=2b9f993842ec272434bbef961ac17ddd90718652> |
| 11:47 |
pinesol |
News from commits: LP#1811685: qtype CGI parameter checking <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=a8efc39d4569362d6ee232e75e19a35dba2faa9a> |
| 11:52 |
gmcharlt |
the master, rel_3_10, rel_3_9, and rel_3_8 branches are now unfrozen |
| 11:54 |
csharp_ |
gmcharlt++ |
| 11:54 |
csharp_ |
@decide the master or the main |
| 11:54 |
pinesol |
csharp_: That's a tough one... |
| 11:57 |
|
Christineb joined #evergreen |
| 11:59 |
Bmagic |
when Evergreen builds itself, perl in particular, it creates a blib folder and then copies the folder tree over to /usr/local/share/perl/5.34.0/OpenILS? Like this "cp -R Open-ILS/src/perlmods/blib/OpenILS /usr/local/share/perl/5.34.0/" |
| 12:00 |
Bmagic |
Is there any reason I can't sym link If I wanted to hack on the perl stuff, can I just symlink /usr/local/share/perl/5.34.0/OpenILS -> Evergreen/Open-ILS/src/perlmods/lib/OpenILS ? |
| 12:01 |
|
jihpringle joined #evergreen |
| 12:03 |
Bmagic |
(skipping blib and preferring lib) |
| 12:04 |
JBoyer |
gmcharlt++ |
| 12:04 |
JBoyer |
Bmagic, I suspect that would work, so long as you restart everything after putting the symlink in place. |
| 12:04 |
Bmagic |
right |
| 12:10 |
|
dguarrac joined #evergreen |
| 12:16 |
pinesol |
News from commits: remove release notes entries made moot by security point releases <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=5919d176c9b2ad39a879c7f4c6669d9da868c0e4> |
| 12:16 |
pinesol |
News from commits: forward-port 3.10 upgrade scripts <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=fbb850e75527e0076baddf43e7451f3ac9cc11c3> |
| 12:16 |
pinesol |
News from commits: forward-port version upgrade scripts <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=4dca04cad741ae0876a8963060d47367d1dcb637> |
| 12:16 |
gmcharlt |
Bmagic: note that lib/OpenILS/Utils/Cronscript.pm.in is a minor exception |
| 12:17 |
Bmagic |
that can't be symlinked? |
| 12:17 |
gmcharlt |
no, that the resulting lib/OpenILS/Utils/Cronscript.pm might not actually exist |
| 12:18 |
Bmagic |
and only exists in blib? |
| 12:18 |
gmcharlt |
(though 99% of the time it would, since there's little reason to have not done a configure/make in your Git checkout) |
| 12:18 |
gmcharlt |
more likelike to bite one is making changes to Cronscript.pm and forgeting that Cronscript.pm.in is the file that's acdtually under version control |
| 12:18 |
gmcharlt |
*likely |
| 12:20 |
Bmagic |
I see. So in almost all of the Perl file cases, you can edit the *.pm files in the repository, and with the symlink, they would be "live" (after a service restart) - whereas, Cronscript.pm.in is not "live" and I would need to copy my changes from Cronscript.pm -> Cronscript.pm.in once tested |
| 12:21 |
gmcharlt |
yep |
| 12:21 |
Bmagic |
gmcharlt++ |
| 12:21 |
gmcharlt |
(though in practice, that file does not get touched all that often) |
| 12:22 |
Bmagic |
I'm working on publishing a "dev" container for the community. Once that just "works" with all this business setup ahead of time |
| 12:22 |
Bmagic |
Once/one |
| 12:24 |
gmcharlt |
yeah, the Cronscript.pm.in => Cronscript.pm during the make of perlmods is a wart that is best removed in favor of some other mechanism for passing the default OpenSRF config path in |
| 12:24 |
Bmagic |
seems doable |
| 12:28 |
Dyrcona |
Bmagic: blib is part of the way Perl builds its libraries. It's not specific to Evergreen. |
| 12:28 |
Bmagic |
When I was working on the enhanced concerto set, I learned about this little gem: eg_config.in |
| 12:28 |
Dyrcona |
At least, I'm pretty sure its is. Who knows? I've been wrong a lot lately. |
| 12:29 |
Dyrcona |
All of the *.in files bet mangled during installation. Most of them are modified with sed. There's a better way to do it with make targets to have AC_SUBST run on them. |
| 12:29 |
Dyrcona |
s/bet/get/ |
| 12:30 |
Dyrcona |
Well, I guess we'd add them to a list in configure.ac. |
| 12:33 |
Dyrcona |
You can copy the files from lib over to the installation location after you've modified them, then restart services. That's what I do if I'm testing a change in one or two files. |
| 12:34 |
|
collum joined #evergreen |
| 12:38 |
Dyrcona |
So, when I load the report utils functions and the md5 functions in jsc, I do NOT get the same relation values that I'm seeing in this one reports template. I'm going to check another template with the same tables. |
| 12:44 |
* Dyrcona |
must be missing something in the composition of path, but I'm using the path that appears in the report template itself, which is what the JS code appears to use. |
| 12:45 |
jeff |
it might be instructive to add some console.log to the md5_hex function so that you can see its inputs and outputs. also, it's possible/likely that the exact inputs to the md5 are different for templates created in xul vs web, and that probably doesn't cause any issues, but might be contributing to your confusion if that's actually the case. |
| 12:48 |
Dyrcona |
jeff: Thing is hex_md5 isn't broken. It agrees with Python and Emacs Lisp. I see what you're saying about the inputs, however. |
| 12:48 |
Dyrcona |
I've tried throwing quotation marks in the strings, but those don't add up either. |
| 12:50 |
Dyrcona |
rlwrap++ |
| 12:51 |
jeff |
I don't think that hex_md5 is broken, no. |
| 12:53 |
csharp_ |
the memcache token issue I was troubleshooting from last week was the same issue as bug 2006749 and subsequent bug 2007880 - applying those fixes allowed the staff logins to correctly apply the auth.staff_timeout setting to the auth token |
| 12:53 |
pinesol |
Launchpad bug 2006749 in Evergreen "Angular Library Settings Editor view perms check is broken" [High,Fix released] https://launchpad.net/bugs/2006749 |
| 12:53 |
pinesol |
Launchpad bug 2007880 in Evergreen " open-ils.actor.ou_setting.ancestor_default broken" [High,Fix released] https://launchpad.net/bugs/2007880 |
| 12:53 |
|
collum joined #evergreen |
| 12:54 |
csharp_ |
as they say, when you come at AppUtils.pm, you best not miss |
| 12:54 |
Dyrcona |
Ha! |
| 12:55 |
jeff |
csharp_: ah, meaning you weren't dealing with early eviction, but an incorrect TTL to begin with? |
| 12:58 |
Dyrcona |
jeff: What I'm trying to do is figure out a way to modify report templates outside of the client. We've got a couple dozen templates that we want to apply the same changes to, and it's more complicated than a regexp_replace in the database can handle. |
| 12:59 |
Dyrcona |
I want to calculate the same relation hashes, but since I'm not adding new relations, really, I could just copy existing hashes and stop worrying about it. However, that isn't my style. I like to know what's going on. |
| 13:06 |
Dyrcona |
Ah ha! I'm using the wrong path for relation.... |
| 13:14 |
Dyrcona |
Nope. I'm still stuck. |
| 13:15 |
Dyrcona |
The Dojo code in Open-ILS/web/report is still used, right? |
| 13:26 |
Dyrcona |
The same thing happens with alias. It is supposed to be the hex md5 of path. I have this path: "ahtc-source-aou" with this alias: "891dbcc665e507af890240c25dd9b0b6". However, hex_md5("ahtc-source-aou") is "b36835813c2685f6e79974b2d5e6531b" |
| 13:34 |
Dyrcona |
Apparently, I have been looking in the wrong place.... |
| 13:41 |
Dyrcona |
Dunno. Still working out correctly... |
| 13:42 |
Dyrcona |
Still not working out correctly.... |
| 13:52 |
Dyrcona |
I got it, and I don't like it. |
| 13:52 |
Dyrcona |
It's using the label not the class path. |
| 13:59 |
Dyrcona |
And, links are more complicated still. |
| 14:05 |
csharp_ |
jeff: right - it was falling back to 7200 seconds (default in our opensrf.xml) |
| 14:59 |
|
mmorgan1 joined #evergreen |
| 15:07 |
* Dyrcona |
gives up. |
| 15:47 |
pinesol |
News from commits: LP#1369345: de-duplicate ILS events and clean up whitespace <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=d045f7bfa5ba1465d75ecc47e22d6ff0fb1c4bc6> |
| 15:53 |
* gmcharlt |
claims 1362 |
| 16:17 |
pinesol |
News from commits: LP#1972738: stamp schema update <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=36b06264874bd1d7f014e34d12dd6e88cb2f2461> |
| 16:17 |
pinesol |
News from commits: LP#1972738: add an ANALYZE after the index gets created <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=21befeda1c4a70e912a315cabb147232e186322b> |
| 16:17 |
pinesol |
News from commits: LP1972738: Add index on hopeless date <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=71df266db6b8ba782ef2d4b00032974c44713ce8> |
| 17:11 |
|
mmorgan left #evergreen |
| 17:19 |
|
dtmoore joined #evergreen |
| 17:37 |
|
kmlussier joined #evergreen |
