| Time |
Nick |
Message |
| 07:23 |
|
redavis joined #evergreen |
| 07:33 |
|
BDorsey joined #evergreen |
| 07:49 |
|
sandbergja joined #evergreen |
| 08:11 |
|
dguarrac joined #evergreen |
| 08:32 |
|
Dyrcona joined #evergreen |
| 08:34 |
|
mmorgan joined #evergreen |
| 08:49 |
|
collum joined #evergreen |
| 08:52 |
Stompro |
JBoyer, morning. My testing of NCIP AcceptItem and RequestItem with ToAgencyID set to our system level OU seems like it works ok. As long as <PickupLocation> is set in the AcceptItem message at least. I'll send you my notes. |
| 08:54 |
JBoyer |
Stompro ++ |
| 09:03 |
|
sandbergja joined #evergreen |
| 09:04 |
|
sleary joined #evergreen |
| 09:05 |
|
mantis1 joined #evergreen |
| 09:08 |
|
kmlussier joined #evergreen |
| 09:08 |
sandbergja |
Good morning all! We are now feature slushed for 3.12. So in general, please don't target any more new features to 3.12-beta in launchpad, and instead let's focus on bringing home the features that are currently targeted (which includes some really cool stuff!). |
| 09:08 |
sandbergja |
And to keep you warm in all that slush... |
| 09:08 |
sandbergja |
@coffee [someone] |
| 09:08 |
* pinesol |
brews and pours a cup of Sumatra Aceh Pondok, and sends it sliding down the bar to scottangel |
| 09:08 |
sandbergja |
@tea [someone] |
| 09:08 |
* pinesol |
brews and pours a pot of Magic Summer Organic Tea, and sends it sliding down the bar to jeff (http://ratetea.com/tea/organic-herbie/magic-summer-organic-tea/9533/) |
| 09:08 |
kmlussier |
sandbergja++ |
| 09:09 |
Dyrcona |
Oof! Does that mean I'm a day late to target a marc_export new feature? |
| 09:11 |
sandbergja |
I think it's okay to be a bit flexible. redavis, mmorgan, collum: thoughts? |
| 09:13 |
sandbergja |
Dyrcona: what's the feature, out of curiosity? |
| 09:14 |
Dyrcona |
Lp 2015484 and looks like it is already targeted at 3.12 beta. |
| 09:14 |
pinesol |
Launchpad bug 2015484 in Evergreen "marc_export: provide way to exclude OPAC-suppressed items" [Wishlist,Confirmed] https://launchpad.net/bugs/2015484 - Assigned to Jason Stephenson (jstephenson) |
| 09:14 |
sandbergja |
Excellent! |
| 09:15 |
* mmorgan |
would be ok with that, as long as it's close. |
| 09:15 |
mmorgan |
Dyrcona: Looks like that should get a pullrequest tag, right? |
| 09:16 |
Dyrcona |
i ued it in production last night and was going to add the pullrequest tag today. |
| 09:16 |
* mmorgan |
nods |
| 09:16 |
mmorgan |
Dyrcona++ |
| 09:25 |
Dyrcona |
I updated Chrome this morning, and the interface is flickering in Gmail and Google Meet. Anyone else seen this? (I'm on Ubuntu 20.04, as that probably matters.) |
| 09:28 |
|
sandbergja joined #evergreen |
| 09:29 |
* collum |
is late to the party, but is OK with marc_export new feature. |
| 09:30 |
Bmagic |
Dyrcona++ |
| 09:32 |
Bmagic |
I'm having a heck of a time getting Evergreen to fill in biblio.record_entry.vis_attr_vector on an electronic bib (and $9's properly filled in) - I ended up manually executing UPDATE biblio.record_entry SET vis_attr_vector = biblio.calculate_bib_visibility_attribute_set(650266) |
| 09:32 |
Bmagic |
and that worked |
| 09:37 |
|
bgillap_ joined #evergreen |
| 09:43 |
Bmagic |
it's almost* like it's not executing z_opac_vis_mat_view_tgr, but I ran this explain analyze UPDATE biblio.record_entry SET marc=marc WHERE id = 650266; it's said it executed it. |
| 09:43 |
Bmagic |
my best guess is that it's not passing this else statement ELSIF TG_TABLE_NAME = 'record_entry' AND OLD.source IS DISTINCT FROM NEW.source THEN |
| 09:44 |
Bmagic |
it would seem that source needs to be non-null? In my example, it's null |
| 09:44 |
Dyrcona |
Is the triggering using the NEW row? |
| 09:45 |
Dyrcona |
Oh, bib source might be necessary, yeah. |
| 09:45 |
Bmagic |
what does this mean in English "OLD.source IS DISTINCT FROM NEW.source" |
| 09:46 |
Bmagic |
does that mean that the row is getting the source column changed? |
| 09:46 |
Dyrcona |
I think so, but that's not how I would do it. |
| 09:47 |
Dyrcona |
Oh! Yeah. old <> new would trigger if they're both null, so "is distinct from" is needed. |
| 09:48 |
Dyrcona |
null <> null is true in pg, IIRC. |
| 09:50 |
Dyrcona |
OK. What I said about 'null <> null' is not exactly right, but "null is distinct from null" returns false. The other comparisons return null. |
| 09:51 |
collum |
I didn't know this operation existed. https://wiki.postgresql.org/wiki/Is_distinct_from |
| 09:51 |
Bmagic |
but what if they are the same (as they would be most of the time) |
| 09:52 |
Bmagic |
wouldn't we want the trigger to recalculate the bib's visibility regardless of whatever source has? |
| 09:52 |
Dyrcona |
Well, that returns false. Are you saying there's a bug in the trigger? |
| 09:52 |
Dyrcona |
I would think so, yes. |
| 09:53 |
Bmagic |
so the question becomes: will "OLD.source IS DISTINCT FROM NEW.source" resolve as "TRUE" when OLD.source == NEW.source ? |
| 09:53 |
Dyrcona |
That's false. Source has to be different. |
| 09:53 |
Bmagic |
ok, I think this is a bug |
| 09:53 |
Dyrcona |
Try it yourself in your favorite pg client. |
| 09:54 |
Dyrcona |
select 'x' is distinct from 'x'; |
| 09:54 |
Dyrcona |
false. |
| 09:54 |
Bmagic |
it would seem, that Evergreen will only recalculate the vis_attr_vector when source changes |
| 09:54 |
Dyrcona |
Well, that's probably a bug. |
| 09:55 |
Bmagic |
I'm racking my brain to figure out why it's written like that in the first place |
| 09:55 |
Dyrcona |
Don't bother. Just open a bug on Lp. :) |
| 09:56 |
Bmagic |
furthermore, I find it hard to believe that no one else has hit this, which makes me think I'm not understanding it |
| 09:56 |
Dyrcona |
Maybe no one has noticed. |
| 09:57 |
Dyrcona |
Try a git blame. See how old that code is. |
| 09:57 |
|
sleary joined #evergreen |
| 09:57 |
Bmagic |
that's where I was headed. Great minds think alike |
| 09:58 |
Dyrcona |
Devious minds, too. :) |
| 09:58 |
* redavis |
is gonna read back. |
| 09:58 |
redavis |
Sorry sandbergja. Was in a meeting. |
| 09:59 |
sandbergja |
np! |
| 10:00 |
Bmagic |
Dyrcona: 2017! |
| 10:00 |
redavis |
sandbergja, yes. I think it's okay to be just a little flexible. If there are hard fought tickets that are ready to have pullrequest tags added (like Dyrcona's), so long as they're in by EOB today it should be okay. |
| 10:01 |
Dyrcona |
I have noticed it being an issue. I don't think the vis_attr_vector changes that often. |
| 10:01 |
Dyrcona |
s/have/haven't/ |
| 10:01 |
Bmagic |
there must be another place where SQL is updating that column |
| 10:02 |
Dyrcona |
One of the metabib ingest functions, maybe? |
| 10:02 |
Bmagic |
I'm diving |
| 10:04 |
Bmagic |
oh, maybe it's engineered to perform this when asset.call_number is changed. There's if statements in here looking for "##URI##" that trigger's an update to biblio.record_entry |
| 10:06 |
Dyrcona |
OK. |
| 10:08 |
Dyrcona |
I'm not entirely sure how vis_attr_vector is used, but I'm sure it's most important for records with URIs. |
| 10:13 |
sleary |
sandbergja: thank you for changing that route :) |
| 10:14 |
Bmagic |
update config.internal_flag set enabled='f' where name~'ingest.reingest.force_on_same_marc' |
| 10:15 |
Dyrcona |
Bmagic: Yeah. You may or may not want that flag enabled all the time. It depends on how much/how often your MARC actually changes. |
| 10:16 |
Dyrcona |
You might be surprised to see how often MARC gets updated when it hasn't changed. |
| 10:16 |
Bmagic |
I think that was the trick, still playing with it |
| 10:18 |
Bmagic |
confirmed, that was it |
| 10:18 |
Bmagic |
I could have swore I checked that before I started posting here |
| 10:20 |
Dyrcona |
You can set that flag during a transaction, and it will only take effect during the transaction until you COMMIT. This means you can set true, do stuff, set it back to false, then commit. That won't work if the triggers are DEFERRED however. |
| 10:20 |
Bmagic |
Dyrcona++ # always being there for a shoulder to slam my head against |
| 10:21 |
Dyrcona |
Bmagic++ |
| 10:23 |
Dyrcona |
I think the issue that I mentioned with Chrome earlier was related to Google Meet. I closed the tab after the meeting, and the flickering continued until I closed all of the Chrome tabs and restarted Chrome. It seems fine, now. |
| 10:24 |
|
sandbergja joined #evergreen |
| 10:37 |
mantis1 |
trying to work with Angular to have the exclude e resources box to be defaulted |
| 10:37 |
mantis1 |
just wanted to ask for clarification on this tag in the div class field |
| 10:37 |
mantis1 |
'*ngIf="showExcludeElectronic()"' |
| 10:38 |
mantis1 |
I'm assuming this means if the box is checked off, then show the results as true? |
| 10:39 |
berick |
mantis1: showExcludeElectronic() is true if we should show the checkbox at all |
| 10:40 |
mantis1 |
ah ok |
| 10:40 |
berick |
unrelated to the actual behavior of the checkbox |
| 10:40 |
mantis1 |
gotcha |
| 10:52 |
|
briank joined #evergreen |
| 10:53 |
* Dyrcona |
wonders if you can concatenate a variable '-v variable=value' with a string in o in psql, i.e. specify the output directory from an external source.... |
| 10:54 |
Dyrcona |
I know how to make that work in queries. |
| 10:56 |
Dyrcona |
Awesome sauce! The "obvious" approach works. |
| 10:57 |
Dyrcona |
`psql -v outputdir=output -f script`, then in the script: `\o :outputdir/outfile.dat`. |
| 10:58 |
Dyrcona |
Think I'll shorten it to 'outdir' for the actual thing, though. |
| 11:24 |
Dyrcona |
Bmagic (and berick for that matter): I'm going to run the Rust MARC exporter either later today or tonight to capture the error output. It seems to find more "bad" records than the Perl code. Just thought I'd give you a head's up. I don't expect the load to spike on the utility server, but you never know. |
| 11:25 |
Bmagic |
Dyrcona++ # you go on with your bad self |
| 11:25 |
berick |
Dyrcona: cool, be curious to see what you find |
| 11:26 |
Dyrcona |
Actually, I'll schedule it for 9:00 PM since we don't seem to have any database updates requested. I'll write something to parse the error output afterward. (It will be good practice.) |
| 11:26 |
berick |
also what Bmagic said |
| 11:26 |
Dyrcona |
:) |
| 11:27 |
Dyrcona |
I'm going to extract all of the records, and I won't bother with holdings. |
| 11:28 |
Dyrcona |
berick: Can the eg-marc-export do authorities, too? If not, that would be a useful feature. |
| 11:28 |
berick |
Dyrcona: not yet |
| 11:28 |
Dyrcona |
I'll work on a pull request, then. ;) |
| 11:28 |
berick |
awesome |
| 11:29 |
* Dyrcona |
decides to break early for lunch. |
| 11:33 |
Bmagic |
Dyrcona++ # you go on with your bad self x2 |
| 11:37 |
Dyrcona |
Hhe |
| 11:41 |
berick |
phasefx++ # comprehensive feedback on bug 1993824 |
| 11:41 |
pinesol |
Launchpad bug 1993824 in Evergreen "wishlist: Angular Link Checker Interface" [Wishlist,Confirmed] https://launchpad.net/bugs/1993824 |
| 11:46 |
csharp_ |
idea: database table with a boolean that gets set via trigger after certain org_unit fields are updated - cron script checks that table row, and if true, run autogen.sh |
| 11:47 |
Dyrcona |
csharp_: Sounds OK to me. |
| 11:47 |
Bmagic |
csharp_++ # autogen automation would be super. We usually couple that with a full restart of the stack, not sure that's needed anymore but it's so annoying when autogen is the issue |
| 11:48 |
Dyrcona |
Bmagic: Not sure that org_unit changes require a restart, but settings changes in the XML files require settings (at least) to be restarted. I usually bounce the whole thing and Apache2. |
| 11:49 |
Bmagic |
might work if it were a column on actor.org_unit, but it would need to be flipped back to false after autogen completes. The issue is multiple bricks would need to see it and react, and only after all of the bricks finished, should the column flip |
| 11:50 |
Bmagic |
new org units or old org unit visibility changes, sure seems to want apache restarted |
| 11:50 |
csharp_ |
yes, the cron-ish script would reset the flag |
| 11:50 |
Dyrcona |
Timestamp the change and the cron can keep track of the last time something changes. |
| 11:50 |
csharp_ |
yeah, noticed there's not a last update time on orgs |
| 11:51 |
Bmagic |
the database would almost need to "know" how many bricks were "there" so it would "know" when they've done the thing |
| 11:51 |
csharp_ |
I think that would all be managed client-side (thinking of a playbook, maybe?) |
| 11:51 |
csharp_ |
the thoughts, they are fluid |
| 11:51 |
Dyrcona |
Bmagic: Not if the cronjob keeps track and runs on all bricks. |
| 11:53 |
Bmagic |
the problem I'm thinking of is: when do we resolve and flip the boolean back to false. But it seems like you're offering a different idea based upon a timestamp? That would work better, so there's nothing the bricks need to do back on the DB after they've finished |
| 11:53 |
Dyrcona |
I've got a cronjob that I run on a server to check for OpenBSD updates. It hits the web page and parses it. It keeps track of the last time it checked and what the last patch number it saw was. It uses the time stamp with an 'If-Modified-Since' header so the web server can send back whatever the code is for "not changed." |
| 11:54 |
Bmagic |
it could be disruptive if bricks reacted immediately at the same time during the day, so the cron would want to be checking the timestamp only during off hours, seems doable |
| 11:55 |
Stompro |
Dyrcona++ the NCIPServer code is a joy to read through. Lots of good comments and good variable names. |
| 11:55 |
Dyrcona |
I don't think services need to be restarted. |
| 11:55 |
Dyrcona |
Stompro: Thank you. I was thinking of future me when I did it. :) |
| 11:55 |
Bmagic |
csharp_: I love it already. It seems like it could be pretty straightforward, and adding the column "edit_date" onto actor.org_unit would do it I think |
| 11:56 |
Dyrcona |
We *may* have to do some cache busting, but IIRC autogen.sh will do that unless you give a specific cache key? |
| 11:56 |
|
jihpringle joined #evergreen |
| 11:56 |
csharp_ |
agreed |
| 11:57 |
csharp_ |
Dyrcona: yeah, autogen updates the cache key when it runs |
| 11:57 |
csharp_ |
I'll work something up |
| 11:57 |
Dyrcona |
csharp_++ Bmagic++ |
| 11:57 |
csharp_ |
Bmagic++ Dyrcona++ |
| 11:57 |
Bmagic |
csharp_++ Dyrcona++ |
| 11:57 |
Bmagic |
lol |
| 11:57 |
csharp_ |
lol++ |
| 11:58 |
csharp_ |
pinesol: lol |
| 11:58 |
pinesol |
csharp_: did you finish your beer? |
| 11:58 |
csharp_ |
pinesol: I don't drink you insensitive bot |
| 11:58 |
pinesol |
csharp_: git diff origin/hamster |
| 11:58 |
Dyrcona |
pinesol: you should know better. |
| 11:58 |
pinesol |
Dyrcona: MARC still isn't dead yet, alas |
| 11:58 |
csharp_ |
pinesol: that's origin/hain to you |
| 11:58 |
pinesol |
csharp_: Go away, or I'll replace you with a very small shell script! |
| 11:58 |
* Dyrcona |
has to make "hamster" the main branch in a repo just for fun, now. |
| 11:59 |
csharp_ |
pinesol: blame pinesol |
| 11:59 |
pinesol |
csharp_: itself must eat cottage cheese! |
| 11:59 |
Dyrcona |
"Did you check the hamster branch?" |
| 11:59 |
Dyrcona |
I don't know why that is so funny to me right now, but there it is. |
| 11:59 |
csharp_ |
"pretty sure that made it into hamster" |
| 12:00 |
Dyrcona |
csharp_++ |
| 12:04 |
Dyrcona |
'git checkout hamster' |
| 12:16 |
redavis |
pinesol: blame infoexpress |
| 12:16 |
pinesol |
redavis: It really IS infoexpress's fault! |
| 12:16 |
redavis |
pinesol: blame the courier |
| 12:16 |
pinesol |
redavis: the courier must eat cottage cheese! |
| 12:17 |
redavis |
pinesol: blame people who react but don't pay attention |
| 12:17 |
pinesol |
redavis: people who react but don't pay attention typed Google into Google; broke the Internet. |
| 12:17 |
redavis |
thanks pinesol |
| 12:49 |
Dyrcona |
Heh... funny typo: "OUTPUTRID" for "OUTPURDIR" |
| 12:49 |
|
Rogan joined #evergreen |
| 12:50 |
berick |
OUTPUTRID=/dev/null |
| 12:50 |
Dyrcona |
And, I typoed my typo example....."OUTPURDIR" should be OUTPUTDIR. |
| 12:50 |
jeff |
amused also that there appear to be two typos... yeah. :-) |
| 12:50 |
Dyrcona |
yeah... all complaints to /dev/null. |
| 12:51 |
jeff |
Errors-To: Non-standard, discouraged. |
| 12:51 |
Dyrcona |
They asked for a timestamp in the file name. I hope they like this: now=$(date --iso-8601=s | sed s/-0[45]:00//) |
| 12:52 |
Dyrcona |
I was also told the timestamp "can be anything you like." |
| 12:57 |
jeff |
"anything you like" leaves room for a lot of creativity. |
| 12:57 |
jeff |
now=$(date +%s | cowsay | base64 -w0) |
| 13:00 |
Dyrcona |
Ok. I'm gonna run that, but do I have cowsay? |
| 13:01 |
Dyrcona |
Nope. Have to install it. |
| 13:01 |
Dyrcona |
Nifty! |
| 13:02 |
jeff |
it gives you a very inefficient base64 string. there's probably more efficient encodings, or simpler cows. |
| 13:02 |
jeff |
(or you could hash it, if you don't care about being able to get back to the original/meaningful value) |
| 13:02 |
Dyrcona |
Yeah... But, now, I'm thinking that I should just use `date +%s` for the timestamp. |
| 13:03 |
jeff |
...when (hashes of) (spherical) cows collide! |
| 13:03 |
jeff |
echo IF9fX19fX19fX19fXwo8IDE2OTg5NDQ0ODMgPgogLS0tLS0tLS0tLS0tCiAgICAgICAgXCAgIF5fX14KICAgICAgICAgXCAgKG9vKVxfX19fX19fCiAgICAgICAgICAgIChfXylcICAgICAgIClcL1wKICAgICAgICAgICAgICAgIHx8LS0tLXcgfAogICAgICAgICAgICAgICAgfHwgICAgIHx8Cg== | base64 -d |
| 13:04 |
jeff |
gzip cuts it almost in half... ;-) |
| 13:04 |
Dyrcona |
:) |
| 13:05 |
Dyrcona |
I don't think the binary data would work so well in a file name. :) |
| 13:05 |
jeff |
(also, base64 isn't filename-safe, so further reason to use a different encoding, if we were going to take this rather ridiculous exercise any further.) |
| 13:06 |
Dyrcona |
sha512, maybe? |
| 13:06 |
jeff |
Dyrcona: oh, i was gzipping before the base64. |
| 13:06 |
jeff |
echo H4sIAAAAAAAAA1OIRwJcNgqGZpYWliYmZiYmCnZcCrpIgEsBCmKAOC4+Pg4uABLRyM/XjIEZo4AENOLjNWOgbM0Y/RgUSRCoqQGZXq5Qg0UGSnEBAF4X4lumAAAA | base64 -d | gunzip -c |
| 13:06 |
Dyrcona |
Oh, right. That makes more sense. |
| 13:06 |
jeff |
shorter, no binary, but still wildly impractical! |
| 13:07 |
Dyrcona |
I think I'll stick with what I've got, thought I am considering '-u' for UTC and changing the sed part appropriately. |
| 13:07 |
Dyrcona |
s/thought/though/ |
| 13:09 |
Dyrcona |
Yeah, I'll use UTC. Our servers are set to America/New_York, but that might not always be the case. I think I'll just strip the "minutes" off the timezone. |
| 13:09 |
Dyrcona |
jeff++ |
| 13:11 |
Dyrcona |
now=$(date --iso-8601=s -u | sed s/:[0-9][0-9]$//) |
| 13:12 |
Dyrcona |
Let's hope that they aren't transferring this to a filesystem that has a problem with ':' in the filename and that they're using MTP, which also seems to have an issue with ':' in a filename. |
| 13:13 |
Dyrcona |
should be "that they're not using MTP." |
| 13:17 |
Dyrcona |
What I find more interesting is that this actually works in psql: `\o :outdir/incremental_changes_:mdate.ids`. |
| 13:17 |
Dyrcona |
Where mdate is set to the timestamp. |
| 13:31 |
Dyrcona |
hmm. don't want to get emailed every 10 minutes about a successful upload.... '> /dev/null' |
| 13:59 |
|
sleary joined #evergreen |
| 14:07 |
Dyrcona |
oof... Looks like sftp send the "Connected to <host>" to stderr. |
| 14:09 |
jeff |
-q is probably going to be helpful there. |
| 14:13 |
Dyrcona |
jeff++ |
| 14:13 |
Dyrcona |
That's what I'm starting to think. Filtering 2 hasn't worked so far. |
| 14:16 |
Dyrcona |
Oh. I think I'm doing it in the wrong order. I think you have to do 2 before the redirect on 1, unless you use numbers for both.... That sounds like something I've run into before. |
| 14:16 |
Dyrcona |
Yeahp... That's it. But -q is less to type, so I'll use that "for real." |
| 14:22 |
Dyrcona |
Bash "programming" is "fun!" |
| 14:50 |
|
mantis1 left #evergreen |
| 15:08 |
Stompro |
Dyrcona, is there an easy way to get logging in NCIPServer... I'm trying to troubleshoot why "User Privilege" isn't being included in lookupuser, but I cannot figure out how to get debugging messages. |
| 15:08 |
Dyrcona |
Stompro: No, there isn't. There's a bug about that in the NCIPServer Launchpad. There's no logging at all. |
| 15:09 |
Dyrcona |
One of the things I've been meaning to get to. There are times that I'd have liked it. |
| 15:10 |
Stompro |
I tried the Dancer logging... but I must not be able to use them in Evergreen.pm, info, debug, ... |
| 15:11 |
Dyrcona |
Yeah, I'd like to eliminate Dancer, too. That's a legacy of trying to be compatible with Koha. |
| 15:11 |
Dyrcona |
@blame rangi |
| 15:11 |
pinesol |
Dyrcona: rangi forgot to give the gerbils their chocolate-frosted sugar bombs |
| 15:11 |
Dyrcona |
@praise rangi |
| 15:11 |
* pinesol |
rangi is the very model of a modern major hacker |
| 15:11 |
Dyrcona |
That second one if probably true. |
| 15:11 |
Dyrcona |
s/if/is/ |
| 15:17 |
Dyrcona |
It's 8:16 AM. Maybe rangi is over in #koha on oftc.net? |
| 15:18 |
* csharp_ |
at the next hackaway https://www.instagram.com/reel/CzEYhY1oWwO/?igshid=MTc4MmM1YmI2Ng%3D%3D |
| 15:21 |
berick |
that would be ideal for the 2-hackers-on-the-same-keyboard setup |
| 15:21 |
berick |
just slappin keys |
| 15:28 |
Stompro |
Can't just add "use OpenSRF::Utils::Logger;" "Bareword "OpenSRF::Utils::Logger" not allowed while "strict subs" " |
| 15:39 |
JBoyer |
Stompro, when I've wanted this I just used the raw perl syslog module, hard-code the various params, and just dropped a log line with the whole incoming and outgoing xml messages for testing. I don't use it in prod because SHAREit does send passwords even though we don't check them. |
| 15:39 |
Dyrcona |
JBoyer++ |
| 15:42 |
Stompro |
JBoyer, thanks, I just want to add some print statements to figure out why certain code isn't working correctly. I don't actually need the messages right now. |
| 15:43 |
JBoyer |
Ah, fair. But the end result is the same, sprinkle syslog() calls wherever you want to shine a light. |
| 15:44 |
Stompro |
Thanks, I'll give it a try. |
| 15:47 |
Dyrcona |
Stompro: I'm not sure why you get the error message when trying to use OpenSRF::Utils::Logger. Something has to be wrong there. |
| 15:50 |
Stompro |
I'll give it another try next week. I off to vacation land. |
| 17:13 |
|
mmorgan left #evergreen |
| 17:57 |
|
kmlussier left #evergreen |
| 18:28 |
|
sandbergja joined #evergreen |
| 19:16 |
|
bgillap__ joined #evergreen |
| 20:36 |
|
sleary joined #evergreen |
