Evergreen ILS Website

IRC log for #evergreen, 2016-09-02

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

Time Nick Message
00:23 gmcharlt joined #evergreen
06:40 rlefaive joined #evergreen
07:02 agoben joined #evergreen
07:09 rhamby joined #evergreen
07:09 pinesol_green joined #evergreen
07:09 dkyle joined #evergreen
07:09 phasefx joined #evergreen
07:17 rjackson_isl joined #evergreen
08:13 Dyrcona joined #evergreen
08:47 bos20k joined #evergreen
09:00 agoben joined #evergreen
09:26 kmlussier joined #evergreen
09:31 maryj joined #evergreen
09:36 collum joined #evergreen
09:41 _adb joined #evergreen
09:59 gmcharlt joined #evergreen
10:05 rlefaive_ joined #evergreen
10:06 maryj joined #evergreen
10:19 jvwoolf joined #evergreen
10:33 Stompro Good morning, could some share their auditor pruning query with me that deletes all but the x most recent versions for each id?
10:33 * berick was just working on one..
10:33 berick sec
10:34 Dyrcona Stompro: MVLC has one that deletes based on date, i.e. auditor entries older than X days. That's relatively simple to do.
10:34 * tsbere considered "keep X copies" but decided against it
10:34 jeff i do need to start running a frequent script that enumerates my editor swap files.
10:35 jeff because by the time it gets to the point where I notice, the mess is out of hand.
10:35 * Dyrcona almost never has editor swap files.
10:35 jeff and I have four swap files for a single source file.
10:35 jeff my laptop used to crash a lot. :P
10:35 tsbere ahhh
10:35 tsbere yea, was about to say "mine only stick around after a crash"
10:36 tsbere But my editor also turns around and says "hey, there is a swap file for this already...." afterwards
10:36 * jeff nods
10:36 * tsbere only has to worry about digging out swap files for "he was working on a new, unsaved file"
10:36 jeff i'm not quite sure how i managed to get this many for a single file without noticing.
10:37 Dyrcona My laptop doesn't crash much, but it's like playing Russian roulette after resume from suspend/sleep if it is going to act normal or exhibit one of two or three bugs.
10:38 * Dyrcona goes back to figuring out why some students didn't load yesterday...
10:40 Stompro Dyrcona, I just got done purging based on our migration date, lots of test load data, and batch global edits in there.
10:41 berick Stompro: we break our auditor data into 3 time categories and keep at most a certain number of entries from each grouping.  (We're only cleaning the copy auditor right now, more to follow).  the code i'm about to deploy: http://git.evergreen-ils.org/?p=worki​ng/Evergreen.git;a=commitdiff;h=f4585​7003181c8b0083c4d66e07d003d4478f29a
10:41 Stompro berick++ , thank you.
10:43 * berick notes some of the comments in there mention specific values for variables which are, in fact, variable
10:44 jeff my most recent need for content in the equivalent of a swap file involved sending a SIGSTOP to the editor and going digging for the application autosave file, since it was a not-previously-saved buffer.
10:45 * Dyrcona digs in the auditor for actor.usr to see when 6 patrons had their email addresses changed.
10:47 tsbere jeff: I have config lines in place to say "store swap files in location X if there is no filename" as if there is a filename it stores them next to the file.
10:48 * tsbere could also go with "always store them in location X" but then you run into issues with the same filename in two different folders
10:49 Dyrcona Odd... Someone deleted and readded the email address... But it looks like it was there when the update should have happened.
10:52 * Dyrcona suspects a bad script run on 8/29 for most of these... Email is there, then gone, just fractions of a second apart.
10:55 jeff or a race condition in stock code.
10:55 jeff (which i suppose qualifies for "bad script")
11:04 Dyrcona Well, these scripts are...to put it nicely...junk. Just a bunch of updates, inserts, and the occasional delete in three separate transactions.
11:05 * Dyrcona would have stopped at "it reads a file into a staging table" and written it in Perl.
11:05 Dyrcona There's also a separate script for loading the students at each college and no VCS has been used to date, so who knows where the latest, correct script is.
11:06 Dyrcona Too many hardcoded values, and in some cases that's the only reason separate scripts exist.
11:06 Dyrcona Hardcoded path to the same file, so be sure to put your file in the exact right place before running, or you'll have problems...
11:07 Dyrcona Fragile...That's what I should have said instead of "junk."
11:07 Christineb joined #evergreen
11:08 Dyrcona Oh, and hope no one else is doing it at the same time, but that's usually not the issue since only certain people are allowed to do it.
11:08 dbwells Dyrcona: Fragile still sounds negative... how about "delicate"?  ;)
11:08 Dyrcona Evergreen needs decent bulk load facilities in the staff client.
11:08 Dyrcona :)
11:09 Dyrcona Delicate.... Could be. :)
11:10 Dyrcona Oh, and a serious lack of whitespace... but that's easy enough to fix with s/;$/;\n/ or the equivalent.
11:12 Dyrcona My guess is that an outdated version of the script was run at some point. Though I have no idea why one patron hasn't had an update since March.
11:13 Dyrcona Ok. Enough of that....
11:13 Dyrcona On an unrelated note: Has anyone else noticed an uptick in spam after having a day last weekend (Saturday?) where practically none came in?
11:42 Stompro RE purging versions, I was looking for a single query version so after some googling, how does this look?
11:42 pastebot "Stompro" at 64.57.241.14 pasted "Find auditor copy entries that are over x number of versions old." (12 lines) at http://paste.evergreen-ils.org/24
11:43 bmills joined #evergreen
11:51 Stompro Oops, I shouldn't use order by audit_id, in case it wraps around in the future.  And I see that this is the exact same thing that berick's code is doing... so I'll go with it.  I should have looked more closely before posting.
11:51 brahmina joined #evergreen
11:54 * Dyrcona would order by audit_time.
11:54 berick Stompro: hm, maybe good to do a secondary sort on audit_id (after audit_time) as a tie-breaker
11:55 berick since there could be multiple rows per transaction w/ same audit_time
11:56 Dyrcona yeah...I might have seen some of those this morning, but didn't look that closely.
11:57 Stompro berick, I see that you use rank(), is that a better option that using the row_number() fuction?
11:58 bmills joined #evergreen
11:58 Stompro berick, does rank give the same number if the timestamps are the same?
11:59 berick Stompro: IIRC, if the OVER clause produces unique entries (i.e. nothing has the same rank per group), then they are effectively the same
11:59 berick Stompro: exactly...
11:59 berick why i'm going to add audit_id as a secondary sort
12:03 berick Stompro: row_number probably makes more sense here, unless you wanted to keep more rows where the ranks match, but that was not my intention.
12:10 bwicksall_ joined #evergreen
12:13 Stompro berick, do you try to reclaim the space "vacuum full" or just leave it for new inserts when you clean out your auditor tables?
12:14 berick Stompro: just going to leave it for new inserts.
12:15 berick guessing a vacuum full would require down time
12:16 berick well, unless you temporarily moved the table *shrug* -- anyway, no urgent need to clear space, so not worried about it
12:17 JBoyer I don't think a full vac requires downtime in the traditional sense where connections aren't allowed, but it's *effective* downtime since any Q that touches that table will wait until it's finished.
12:17 berick JBoyer: right, no copy edits, so.. yeah
12:17 berick s/edits/changes/
12:18 tsbere no checkins/checkouts/reshelving updates....
12:18 JBoyer "When can I check this item out?" "At this rate, I'd say 3-4 hours."
12:18 Stompro We have a tiny system compaired with most of you all, so it only takes a few seconds for a vacuum full.
12:20 tsbere JBoyer: For some our libraries the answer would be "the selfchecks are in offline mode, go use one of them" ;)
12:20 Stompro Until we absorbe all of Minnesota at least, muhahahah.
12:20 tsbere Stompro: I don't think you want that headache. ;)
12:21 JBoyer Then it depends on how much space you free up. I know >< this much about file fragmentation on ext4, so I'd say full's are only necessary if you're talking a drastic amount of space.
12:28 jihpringle joined #evergreen
12:39 kmlussier @quote random
12:39 pinesol_green kmlussier: Quote #107: "<dbs> JSPAC was almost self-aware ... <JSPAC> dbs: YES, I WAS" (added by gmcharlt at 03:42 PM, March 10, 2015)
12:39 bshum o.O
12:40 gmcharlt and that, friends, is the real reason we removed JSPAC in 2.9!
12:40 bshum gmcharlt++
12:42 Stompro Does anyone do regular action_trigger.* cleanup?  It seems like the output table should be cleaned up occasionally.
12:42 kmlussier JSPAC still lives on in some parts - http://opac.nwic.edu/opac/en-​US/skin/default/xml/index.xml
12:43 Dyrcona kmlussier: Yep, they're on 2.2 or something like that.
12:43 kmlussier I think I found another instance of it when rhamby and I were working on the annual report.
12:43 rhamby lol
12:51 berick Stompro: it's on my list.  I also want to implement a feature where certain types of output are automatically removed, like some "format" entries (HTML-ized PO's, self-check receipts, etc.) -- make it configurable
12:53 bmills joined #evergreen
13:17 yboston joined #evergreen
13:17 Bmagic csharp: I messaged you
13:22 kmlussier Wait, I'm confused. When is Evergreen's actual birthday? I saw pictures of cake from a few days ago, but that seems a little early to me.
13:22 kmlussier Oh, never mind. I now see the tweet with the explanation. September 5. :)
13:24 jeffdavis Stompro: we clean up old action_trigger.event entries periodically
13:24 jeffdavis it's a manual process in the db for us though
13:30 rlefaive joined #evergreen
13:32 csharp PINES' Evergreen go-live was Labor Day weekend 2006
13:33 * csharp didn't read what kmlussier was reading, but adds for the sake of log readers of the future
13:33 kmlussier csharp: I just logged into Twitter for the 1st time in a while and saw a post from gmcharlt with a photo of a tasty bday cake.
13:35 csharp ah
14:08 dbs "While we all know and love the XUL staff client" *coughs* (https://esilibrary.com/evergreen-2014/)
14:17 kmlussier Once we kill the XUL client, I'm sure I'll always have a special place in my heart for it.
14:17 rhamby kmlussier: are you sure that's your heart?
14:20 csharp well, the XUL client is a known quantity, which has a lot of value to sysadmins :-)
14:21 csharp stasis++
14:26 dbs csharp: there's some truth to that. stable but outdated / almost-abandoned framework with known security issues vs. modern but continually shifting tower of node.js libs eh?
14:27 jeffdavis stasis-- # surely it's inappropriate to change the karma for this word? :)
14:28 csharp heh
14:29 csharp dbs: I'm also thinking about the increased number of browsers/OS platforms/hardware devices we'll be supporting (even if we "officially" restrict what we support)
14:31 dbs jeffdavis++
14:31 dbs csharp: just give everyone a chromebook and say "there's yer damned staff client" :)
14:32 jeff apropos of absolutely nothing, anyone here have a favorite RFID reader/antenna vendor?
14:41 berick changing the subject even more.. anyone in these parts doing holds aging/anonymization?
14:45 tsbere berick: MVLC is
14:46 berick tsbere: it's fairly painless?  no unexpected issues?
14:48 tsbere berick: I don't believe we had many/any issues. The DB function runs nightly. One thing to consider is that we keep cancelled holds longer than fulfilled ones in case staff look to uncancel them.
14:48 berick going to do the same here, in fact
14:48 berick was really glad to see that's baked into the aging code
14:50 tsbere I think that was my doing, actually. Might be Dyrcona's name on the code, though....
14:50 berick tsbere++ Dyrcona++
14:52 Dyrcona Hmm....
14:53 Dyrcona I'm setting up a vm and was thinking in the past, I had either setup the public and private domains with the same IP address or just used localhost for both.
14:53 Dyrcona Anyone done something similar?
14:54 Dyrcona Eh, I may just do the typical setup to avoid "complications."
14:54 tsbere Dyrcona: Every production system MVLC has had, though I don't think you want localhost on both *names*
14:54 Dyrcona tsbere++ # thanks for the memory jog.
14:55 Dyrcona So host.private and host.public point to the same IP address, IIRC.
14:55 Dyrcona Usually, the public IP, right?
14:55 tsbere They can indeed point to the same. As for which IP, that depends.
14:55 Dyrcona By public IP, I meant not "localhost."
14:55 tsbere In a single machine setup it doesn't matter and I usually use private IPs
14:56 tsbere In a multiple machine setup you will want the public IP for obvious reasons ;)
14:56 Dyrcona Right, right.... Thanks, again.
14:56 tsbere In a production setup I generally recommend using DNS names whenever possible
14:56 tsbere Less host file management that way
14:56 Dyrcona Makes sense. Just update DNS in that case.
14:57 Dyrcona I knew I'd seen that before. :)
14:57 Dyrcona And, bummer, I don't have enough RAM to run both of my VMs at the moment.
14:58 tsbere Dyrcona: For added fun, you could set up the actual ejabberd ahead of time on the *host* (or a dedicated VM for it) and then point any/all VMs at that one instance ;)
14:59 Dyrcona Yeah. This is just a single vm for development work right now.
15:00 Dyrcona That is what I'll do when I setup VMs for production. I'll run the ejabberd on the "brick head" VM.
15:00 Dyrcona Come to think of it, the configuration at C/W MARS puts both the public and private host names on the same IP address. ;)
15:01 Dyrcona And, yeah, otherwise the machine would need two IPs for the drones to work.
15:02 tsbere Dyrcona: For more fun, set them as two different private IPs on the brick head, then point everything else at the public IP. Ejabberd won't actually care.
15:03 tsbere Just so long as you can get them all talking to the same ejabberd cluster, regardless of what IPs they are using, you are generally going to be good
15:03 Dyrcona tsbere: I don't guess you've ever been able to experiment with actually using a cluster of ejabber daemons? Might be neat to run a giant brick talking to multiple jabber instances.
15:04 tsbere I did try that once. The results were inconclusive.
15:04 tsbere In part because the cluster kept falling apart, and in part because I was using a pile of crap machines that couldn't handle a load on the system either way. <_<
15:07 Dyrcona I recall.
15:08 * tsbere actually suspects the cluster kept falling apart partially due to the machines not being able to handle much
15:30 * Dyrcona takes another look at Lp 1485374
15:30 pinesol_green Launchpad bug 1485374 in Evergreen "Use client TZ in the database when supplied to the server" [Wishlist,New] https://launchpad.net/bugs/1485374
15:32 Dyrcona Fun thing about making the working repo your origin: git checkout collab/miker/lp1485374-always-use-client-tz-rebase  just works.
15:40 Stompro jeffdavis, can I see your action_trigger cleanup queries?  Here is what I've come up with https://gist.github.com/stompro/​4b6c135a01e40f587d70a843f0476ef3 , I would like to see if there is a better way to go about it.
15:42 tsbere Stompro: From my playing with things in the past I think you need to watch out for things that the system will just try and put *back*
15:44 Stompro tsbere, I think I know what you mean, if there is no max event validity delay value set for the event def, or if it overlaps with items you delete.
15:44 Stompro But for things like the various receipts and reports, that shouldn't be a problem.
15:45 * Dyrcona gets a lot of deprecations warnings on npm install.
15:48 Dyrcona bshum berick: grunt all just worked. Did you two do anything to fix that issue or has npm fixed it?
15:49 jeff are you talking about the test failure fixed in commit 6bc0bc2?
15:49 pinesol_green jeff: [evergreen|Jeff Godin] LP#1618136 Fix webstaff IDL2js.js test failures - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=6bc0bc2>
15:49 jeff (that was unrelated to npm, so i'm not sure if that's what you mean)
15:50 Dyrcona jeff: I think that is it. My memory ain't what it used to be.
15:50 Dyrcona jeff++ bshum++ dbwells++
15:51 Dyrcona I rebased the tz branch.
15:51 Dyrcona To build a staff client or not.... Guess I will.
15:53 Dyrcona jeff: Now, my clock on my VM is set to EDT and not UTC because I installed from an ISO and it guessed my timezone.
15:53 Dyrcona IIRC, some of the bugs that this branch is supposed to address happen even when the time zones are the same.
15:54 Dyrcona I can always change my TZ on the server if I have to.
15:58 Dyrcona Nice time for the wifi to go out and come back....In the middle of downloading xulrunner.
16:03 Dyrcona Oh, yeah. I need dojo.tgz...
16:05 Dyrcona Plain old dojo 1.3.3 works, doesn't it?
16:08 * Dyrcona answers his own question: Yes.
16:08 Bmagic wifi--
16:09 kmlussier Why is it not 5 p.m. yet?
16:11 miker Dyrcona: the point testing of that branch is not to change the server tz -- that should be whatever it should be -- but to change the /client/ tz and confirm that times are 1) recorded in the client tz 2) show up in the client tz. that is, a client in central time should see times in central, even if they were written in eastern and the server is in eastern. and that those times should be the /real point in time/ not the same string. does that make
16:11 miker sense?
16:12 Dyrcona miker: Yes. I could just change my server to UTC and get a similar effect, no?
16:12 miker eg, if someone checks out an item at 1pm EST, a client in CST will see the circ happened at noon CST
16:12 miker um, no
16:13 Dyrcona OK.
16:13 miker the branch uses /the client timezone/ everywhere (or, tries to)
16:13 Dyrcona I'll monkey with my client's time zone.
16:13 berick kmlussier: it is somewhere. *cracks open a jug of Schlitz*
16:13 miker it does /not/ use the server time zone (or, tries not to)
16:14 jeff But if you have a US/Detroit client and your server is UTC, you should see different behavior with that branch than without that branch, right?
16:14 kmlussier miker: I'm going to try to make time to get the Release Notes acknowledgements done soon. I should still be making updates in the RELEASE_NOTES_NEXT directory, right?
16:14 miker jeff: doesn't matter what the server timezone is. if you apply that branch (and the opensrf one) then you should see all times in YOUR time zone
16:14 kmlussier I can't remember when we stop generating the release notes document from that directory.
16:15 jeff miker: I think we're saying the same thing.
16:15 jeff or at least, not disagreeing.
16:15 kmlussier berick: Brazil! Hopefully, they have no Schlitz there.
16:15 miker perhpas
16:15 Dyrcona Well, if I do some transactions in EDT and change my timezone to CST to view them later, that should work.
16:16 miker I guess my point is, the real world test of the branch is about "do times displayed in the client and opac use the client TZ?"
16:16 miker Dyrcona: right
16:16 jeff miker: agreed!
16:16 miker jeff: but, in the real world, one wouldn't be changing the server's system TZ
16:17 jeff miker: it doesn't matter which one has changed, just that they are different.
16:17 miker so, while that might aproximate the effect, I wouldn't trust it, necessarily. too many things (like database settings) could (in a real world setup) get in the way
16:18 miker anyway, testing++
16:18 miker Dyrcona++
16:18 miker jeff++
16:18 * miker steps away from all keyboards for a bit
16:32 Dyrcona Heh. Doesn't work if you start services before configuring the database in opensrf.xml....
16:43 Dyrcona Hmm.. /eg/staf/ leads to a login, but /eg/opach/home leads to an internal server error.
16:43 * tsbere would expect both of those to be 404s, honestly ;)
16:44 Dyrcona Sep  2 16:42:50 xenial apache2[13936]: [perl:error] [pid 13936] [client 192.168.122.1:44826] egweb: Context Loader error: Can't locate object method "retrieve_config_global_flag" via package "OpenILS::Utils::CStoreEditor" at /usr/local/share/perl/5.22.1​/OpenILS/WWW/EGCatLoader.pm line 266.
16:44 Dyrcona Well, that's not good. I musta botched something.
16:44 yboston phasefx: can you PM for a quick work question?
16:45 Dyrcona Eh, no. cstore is running.
16:48 Dyrcona Oddly enough, I can login via staff client and I can do a search.
16:48 Dyrcona web staff client that is.
16:48 tsbere Dyrcona: I have gotten errors like that when the IDL didn't initialize properly. Did apache come up too soon or something?
16:49 Dyrcona Yeah, my next thought after cstore not running was the idl. I ran autogen, and started apache. I'll restart apache and see if that helps.
16:50 Dyrcona tsbere++ # A restart helped.
16:50 Dyrcona Well, now that it seems to be working. I'll shut it down and do the testing tomorrow.
16:54 Dyrcona Well, have a nice weekend, everybody!
17:23 jvwoolf left #evergreen
17:32 Bmagic I'm trying to login to my new test server via SIP. I am getting an error about workstation not found. Anybody have something off the top of their head before I dive in?
17:34 berick Bmagic: it's ringing a bell w/ a recent bug...
17:34 berick Bmagic: bug #1259196
17:34 pinesol_green Launchpad bug 1259196 in Evergreen "SIP support workstation option at login" [Wishlist,Fix committed] https://launchpad.net/bugs/1259196
17:35 Bmagic oh good!
17:35 Bmagic berick++
17:36 Bmagic I am running master on this test machine though
17:37 gmcharlt joined #evergreen
17:38 Bmagic my login message contains the CP for the insitution, now it's workstation?
17:40 Bmagic oh boy, this is going to break some stuff in the wild for sure
17:43 berick AO field normally carries the institution id.
17:44 Bmagic I see, I will need to alert our libraries, and grep the logs for all the 93 messages to see how they are coming in currently
17:44 berick but, yeah.. the code should be more forgiving...
17:44 berick it should not prevent the server from working
17:44 Bmagic if there is something in the CP field, and it's not a workstation name, we have breakage
17:45 berick optionally a config option to turn on force-valid-login-CP or some such
17:45 Bmagic The code would be improved to go ahead and ignore the CP if it doesn't match anything in the DB
17:53 bmills joined #evergreen
17:55 _adb left #evergreen
18:14 kmlussier joined #evergreen
18:15 kmlussier Now sure if anyone is still around, but, while I was working on Release Note acknowledgements, I realized we never acknowledge people who contribute translations. Is there a good place to find that information for each release?
18:16 kmlussier The final release note entry regarding translations made me think those people should be getting some kind of credit in the notes.
18:21 dbs I think we've discussed it before, it's hard because Launchpad enables almost drive-by translations
18:22 kmlussier dbs: I was just looking in Launchpad, and I was thinking I could give an acknowledgement to anyone who updated a string with a last edited date that falls after the date of the 2.10.0 release?
18:23 dbs huh. do you get a string-by-string list of translators?
18:25 kmlussier No, apparently I don't. Let me reword that. :)
18:26 kmlussier So here - https://translations.launchpad​.net/evergreen/master/+lang/cs - I can see the last time a certain area was edited for a particular language. I was thinking I could grab those translators for the release notes.
18:27 dbs It's certainly better than nothing at all. You could have multiple contributors per file (we do in French for tpac for example) but in most cases it's probably one or two people
18:30 kmlussier Maybe only do it for the 'official' list of languages, as was defined in that e-mail thread from a couple of months ago.
18:33 dbs sounds reasonable!
18:33 kmlussier French: last edited 39 seconds ago by dbs. :)
18:35 kmlussier Of course, the other problem is we then have people whose names I don't recognize.
18:35 kmlussier And who may be missing last names.
18:35 * kmlussier will think about this more when it's not a Friday night.
18:35 kmlussier Have a nice weekend!
21:23 jeff Bmagic: yeah, that's one of my planned bugfixes for that feature. :-)
21:38 jeff there are a few concerns:
21:39 jeff 1. don't require everyone upgrading to create new workstations or reconfigure every sip client
21:40 jeff 2. continue to give an option for strict workstation requirement when provided (the current mode)
21:43 jeff i'd also like to see support for forcing a given workstation for a given user, or requiring a valid workstation for a given user, or even a combination of the two (this user must provide a valid workstation, and it must be on this list of 1 or more workstations), but that's probably into new-feature territory.
21:59 jonadab joined #evergreen

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat