| 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=working/Evergreen.git;a=commitdiff;h=f45857003181c8b0083c4d66e07d003d4478f29a |
| 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 |
