| 09:56 |
|
Dyrcona joined #evergreen |
| 09:57 |
Dyrcona |
And now, I remember one of the reasons that I always used to use a separate partiton for /home.... |
| 09:59 |
Dyrcona |
You can't safely fsck a mounted volume, and you can't unmount / if you want to run fsck, so I need to make a recovery disk. |
| 10:00 |
Dyrcona |
I ain't got time for that, so at the risk of having corrupted files, I continue with testing my 2.9.5 to 2.10.7 upgrade. |
| 10:28 |
StomproJ |
Ahhhahh, my memcache server is hitting a openvz tcprcvbuf limit, causing connections to fail. |
| 10:31 |
* Dyrcona |
uses kvm, so wouldn't know about that. :P |
| 10:34 |
StomproJ |
Proxmox has moved away from openvz, so I won't use it in the future either. |
| 13:32 |
* Dyrcona |
drives his wife nuts. :) |
| 13:33 |
Dyrcona |
NCIP isn't a standard so much as it a smorgasboard of options. That's why "profiles" exist, though NCIPServer was not written to target any specific profile. |
| 13:34 |
Dyrcona |
I was given some documentation and "sample" messages. |
| 13:34 |
Dyrcona |
Spent several months coding, then got it to actually work with the vendor once testing starting. |
| 13:35 |
Dyrcona |
Changes have accrued while it is in production and real things happen. |
| 13:35 |
|
ssieb joined #evergreen |
| 13:35 |
* kmlussier |
feels sympathy for Dyrcona's wife. |
| 14:05 |
|
Christineb joined #evergreen |
| 14:21 |
Dyrcona |
Can someone see what's wrong with this: [% date.format(helpers.format_date(circ.due_date), '%A, %B %d, %Y') %] |
| 14:21 |
Dyrcona |
I put that in a template and it is erroring out with invalid date format, but that looks correct to me. |
| 14:22 |
Dyrcona |
I don't have a quick way to test it, unfortunately. |
| 14:27 |
berick |
Dyrcona: see if circ.due_date is null |
| 14:27 |
dbs |
is it an invalid input date perhaps? |
| 14:28 |
Dyrcona |
In every single courtesy notice for the past week? |
| 14:35 |
bshum |
pinesol_green is wise to keep its opinion to itself... |
| 14:35 |
pinesol_green |
bshum: I am only a bot, please don't think I'm intelligent :) |
| 14:35 |
pinesol_green |
bshum: Down time is a fact of business when you're a poor 501c3 corporation. |
| 14:38 |
* Dyrcona |
pines for a test environment. |
| 14:39 |
* jeff |
uses PINES for a test environment |
| 14:39 |
Dyrcona |
:) |
| 14:39 |
jeff |
(not really, but i couldn't let that pun opportunity go to waste) |
| 14:46 |
* jeff |
sends out a few emails in an attempt to gather iNCIPit forks |
| 15:37 |
csharp |
@karma karma karma karma karma chameleon |
| 15:37 |
pinesol_green |
csharp: karma karma karma chameleon has neutral karma. |
| 15:38 |
berick |
chameleon++ |
| 15:40 |
csharp |
@who is using PINES as a test environment? |
| 15:40 |
pinesol_green |
Stompro is using PINES as a test environment. |
| 15:40 |
miker |
whew! I thought pinesol was about to rat me out... |
| 15:41 |
miker |
CRAP ... I said the quiet part loud again |
| 15:41 |
kmlussier |
@blame miker |
| 15:41 |
pinesol_green |
kmlussier: miker stole bradl's tux doll! |
| 15:41 |
csharp |
@blame inner monologues |
| 15:41 |
pinesol_green |
csharp: inner monologues musta been an Apple employee. |
| 15:41 |
berick |
wait, we're not supposed to be using PINES as a test environment? |
| 15:42 |
miker |
berick: define "supposed" .... |
| 15:42 |
miker |
also, define "test" |
| 15:42 |
berick |
hah |
| 16:13 |
Bmagic |
csharp: was it you who used the TTP-247 barcode printers for replacing barcodes during migration? |
| 16:19 |
|
jvwoolf joined #evergreen |
| 16:52 |
kmlussier |
We're getting some test failures on the purge-user-activity tests. http://testing.evergreen-ils.org/~live/test.html |
| 16:53 |
kmlussier |
And on the abort transity copy status live test. |
| 16:53 |
* kmlussier |
misses the twice daily test results that used to post in channel. |
| 16:57 |
csharp |
Bmagic: nope, not me |
| 16:57 |
Bmagic |
cool, no biggie |
| 17:01 |
csharp |
kmlussier: I see what's happening with the perl test - it's expecting the copy status to be "Reshelving" after transit abort and it's now "Canceled Transit" |
| 17:01 |
|
mmorgan joined #evergreen |
| 17:03 |
kmlussier |
csharp: Ah, ok. So is that the one Dyrcona did for his fix before your new feature went in? |
| 17:03 |
csharp |
right |
| 17:31 |
csharp |
Bmagic: the first example's supposed to happen - the transit stores the status it was in when it went into transit so it can resume that status when it gets to its destination |
| 17:32 |
csharp |
and the second problem can have multiple causes, including "checkout fills related hold"-type stuff (probably the most common) |
| 17:32 |
Bmagic |
csharp: right, I understand that part. Missing items are being reported as being on the pull list. Would the hold targeter target missing items? Perhaps it wasn't missing when the targeter ran? |
| 17:32 |
csharp |
oh - yeah, it shouldn't target missing copies |
| 17:33 |
csharp |
auditor.asset_copy_history might help know what happened |
| 17:36 |
csharp |
dbs: are you still managing buildbot/testing.evergreen-ils.org? |
| 17:36 |
* csharp |
would like to create a few new builders on mundungus |
| 17:40 |
dbs |
csharp: I might still be able to! |
| 17:41 |
dbs |
Trying to prep for a hands-on Angular 2 session that I'm supposed to be leading in 1.25 hours atm though |
| 17:41 |
csharp |
dbs: no prob - it will take a while to set up the VMs anyway |
| 17:41 |
csharp |
thanks! |
| 17:41 |
dbs |
Really should have carved out some time before... |
| 17:42 |
dbs |
Looks like my ssh key might have gone dead on testing.evergreen-ils.org |
| 17:43 |
csharp |
ok, I'll see if phasefx_ or miker or someone can get me going |
| 17:57 |
dbs |
gmcharlt used to be my partner in crime for testing.evergreen-ils.org |
| 17:58 |
|
jvwoolf left #evergreen |
| 18:03 |
gmcharlt |
dbs: send me the current one(s) and I'll get you set up again |
| 18:03 |
* gmcharlt |
goes poof, braves Atlanta traffic |
| 08:23 |
jeff |
dbs: regarding your conversation with Apache this morning: is the server_status count showing requests and not connections, while MaxConnectionsPerChild is counting connections not requests? |
| 08:26 |
jeff |
(where one connection may serve up to MaxKeepAliveRequests requests) |
| 08:27 |
* jeff |
starts to wonder if he's running a config different from that which is on disk. short of hijacking a configured perl handler with code that would attempt to read config settings, i'm not sure if there's a way to check that. |
| 08:51 |
StomproJosh |
csharp, re bug 1616220 - There are a bunch of dojo related warnings that my fix doesn't touch. So it doesn't get rid of all the warnings, just reduces the number of them. I can provide some specific examples to make testing easier. |
| 08:51 |
pinesol_green |
Launchpad bug 1616220 in Evergreen "XUL Staff Client CSS Fixes" [Undecided,New] https://launchpad.net/bugs/1616220 |
| 09:02 |
|
bos20k joined #evergreen |
| 09:07 |
|
mmorgan joined #evergreen |
| 09:27 |
dbs |
but the server_status display shows an "Acc" column of 0/85/1186 and I was interpreting the "85" as # requests (per the legend at the bottom "Acc: Number of accesses this connection / this child / this slot") |
| 09:28 |
dbs |
But yeah, maybe I was interpreting it wrong, and now that I'm dropped KeepAlive to 2 from 5 there are more connections turning over |
| 09:28 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1623955: Keep periods in subject links - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f4c7efc> |
| 09:32 |
csharp |
Stompro: thanks - I'll re-test with your new info when you post them :-) |
| 09:33 |
csharp |
Stompro: re: staff initials, at least one of our libraries uses patron stat cats for that |
| 09:36 |
Stompro |
csharp, thanks for the staff initials info. |
| 09:42 |
JBoyer |
Stompro, csharp, I was going to say, initials for patron reg wasn't ringing any bells for me, but csharp's stat cat idea is a good one. I'd poll your members and see if it's worth making a consortium wide stat cat rather than trying to talk a lot of libs through it through it. |
| 09:44 |
|
kmlussier joined #evergreen |
| 08:01 |
|
collum joined #evergreen |
| 08:07 |
|
tspindler joined #evergreen |
| 08:30 |
|
remingtron joined #evergreen |
| 08:31 |
csharp |
hmm, I'm trying to generate the log warnings for bug 1624491, but I'm not able to and I'm not seeing the prox_cache uninitialization warnings on PINES production or test servers :-/ |
| 08:32 |
pinesol_green |
csharp: Error: Could not gather data from Launchpad for bug #1624491 (https://launchpad.net/bugs/1624491). The error has been logged |
| 08:32 |
csharp |
pinesol_green: why not? |
| 08:32 |
pinesol_green |
Factoid 'why not?' not found |
| 09:57 |
jeff |
we're running with... 0? that's surprising to me. |
| 09:58 |
dbs |
The only two modules that I can think of that we run that most sites probably don't run are open-ils.resolver and open-ils.auth_proxy |
| 10:00 |
dbs |
Not sure if there's an easy way to figure out where a memory leak is occurring in apache with a bunch of c and perl mods |
| 10:00 |
jeff |
in test systems earlier this year, i could trigger high memory utilization in apache children. setting MaxConnectionsPerChild seemed to be a solid workaround, and i did have to set it pretty low. |
| 10:01 |
dbs |
jeff: interesting - but you don't need that workaround any more? |
| 10:01 |
jeff |
i'd have to look at notes, but first thing i'd try would be comparing things handled by EGCatLoader with something like static files. |
| 10:02 |
|
jlundgren joined #evergreen |
| 10:36 |
jeff |
if nothing else, in the interest of improving logging / error handling / avoiding this myself. ;-) |
| 10:36 |
Dyrcona |
If I use a barcode from a copy other than the ones I added, I get a response in less than 1 second. I think I'm missing something in the database. |
| 10:37 |
jeff |
yeah. |
| 10:37 |
Dyrcona |
jeff: I can paste it. I was thinking of adding these to concerto for testing purposes in the future. |
| 10:37 |
Dyrcona |
I'll bet there is some setting not switched on in concerto that I'm used to having on and that's my issue. |
| 10:38 |
dbs |
Dyrcona: any chance the bib / volume / copy ingest triggers are failing or aren't running? |
| 10:38 |
jeff |
ideally data that postgres allows you to insert wouldn't cause SIP to fail like that, but maybe the marcxml or something is to blame. |
| 10:42 |
Dyrcona |
Yes. |
| 10:42 |
Dyrcona |
Since I discovered that SIPServer won't start on Ubuntu 16.04, I'm going to move on to a branch for that and then come back to this after that. |
| 10:42 |
jeff |
isn't this expected to fail on recent Encode.pm? |
| 10:43 |
Dyrcona |
jeff: Yes. That was what I was testing, but this is not a recent Encode AFAIK. |
| 10:43 |
jeff |
ah. |
| 10:43 |
Dyrcona |
It failed on 16.04, and I'm testing 14.04 for duplication, etc. |
| 10:44 |
jeff |
my guess right now is that you're running into the bug where sipserver doesn't properly flush the buffer on the socket. |
| 10:44 |
jeff |
because it's not counting bytes. |
| 10:44 |
Dyrcona |
Encode is 2.49... |
| 10:51 |
dbs |
coffee++ |
| 10:51 |
|
Christineb joined #evergreen |
| 10:52 |
csharp |
NOBLE++ |
| 10:55 |
Dyrcona |
I'm going to test and push Bmagic's branch on Lp 1613326. (I think I promised to do that last month, and never found my tuit.) |
| 10:55 |
pinesol_green |
Launchpad bug 1613326 in SIPServer "SIPServer UNIVERSAL removed" [Undecided,New] https://launchpad.net/bugs/1613326 |
| 10:56 |
berick |
noble++ kmlussier++ |
| 10:56 |
jeff |
Dyrcona: pretty sure user/jeff/fix_universal_can will fix your "I want to fix the UNIVERSAL does not export anything message on Ubuntu 16.04" issue |
| 11:08 |
Dyrcona |
I'll add Bmagic's bug number and give him some credit in commit message. How's that? |
| 11:08 |
jeff |
i'll push a new branch with a reasonable commit message and comment on the bug. |
| 11:10 |
Dyrcona |
OK. I'll wait. |
| 11:13 |
Dyrcona |
dbs | jeff: I'm convinced my solution to the Encode issues is not optimal. I haven't even really tested it yet, either. |
| 11:23 |
|
brahmina joined #evergreen |
| 11:29 |
Dyrcona |
jeff++ |
| 11:29 |
Bmagic |
jeff++ |
| 12:19 |
Dyrcona |
Y'know. I may just try putting clean_text() on autoload Item fields and see what that does. |
| 12:20 |
Dyrcona |
But first, I'll finish lunch. |
| 12:20 |
jeff |
title/author with mangled characters were the most common trigger for us. i think that's due to a different issue in how MODS transforms are being done. |
| 12:25 |
terran |
Bug Squashing Day Update: 6 patches have been tested & signed off on, and 3 new patches have been submitted! |
| 12:34 |
jeff |
Dyrcona: bug 1628995 |
| 12:34 |
pinesol_green |
Launchpad bug 1628995 in SIPServer "SIPServer can incorrectly calculate output message length, which can lead to clients hanging" [Medium,New] https://launchpad.net/bugs/1628995 - Assigned to Jeff Godin (jgodin) |
| 12:37 |
dbs |
jeff++ # different fun with encodings (bytes vs. length), heh |
| 12:54 |
* Dyrcona |
adds use bytes; before POSIX::write to see if that makes a difference. |
| 12:55 |
Dyrcona |
Bingo! We have a winner! |
| 12:56 |
Dyrcona |
pysip2 doesn't choke on the multi-byte call number. |
| 12:56 |
csharp |
@blame testing the wrong git branch |
| 12:56 |
pinesol_green |
csharp: testing the wrong git branch WILL PERISH UNDER MAXIMUM DELETION! DELETE. DELETE. DELETE! |
| 12:58 |
Dyrcona |
I'm inclined to fix the length calculation as its own bug and not mix it up with the Encode changes. |
| 12:58 |
jeff |
i don't know that that's the best / long term fix, but i'll amend my commit message and push that branch. we've been using it in production for a while. |
| 12:59 |
Dyrcona |
Where'd you put the use bytes; out of curiosity. |
| 12:59 |
Dyrcona |
? |
| 13:06 |
dbs |
makes sense to keep it locally scoped to the length() call, to avoid having any other side effects |
| 13:07 |
* dbs |
greps to see 15 length() calls to audit to see whether use bytes would be warranted or not |
| 13:07 |
Dyrcona |
yeah, in my test, I did the same. |
| 13:09 |
dbs |
+1 to fixing this one little bug first |
| 13:10 |
* miker |
thinks `require bytes; ... bytes::length()` may be better? |
| 13:10 |
Dyrcona |
miker: It may be better. |
| 13:23 |
Dyrcona |
lines 95, and maybe 179 and 199 |
| 13:24 |
Dyrcona |
I misspoke about SIPServer.pm abov. |
| 13:24 |
Dyrcona |
above. |
| 13:29 |
abowling |
i've tackled this before, but i've slept and forgotten. trying to get a test server up and running to get rid of these darned bugs, and getting: /usr/bin/ld: cannot find -ldbdpgsql |
| 13:29 |
abowling |
anyone have any suggestions/memories? |
| 13:29 |
abowling |
i have installed 9.3 |
| 13:36 |
berick |
abowling: what's the output of: cat /etc/ld.so.conf.d/evergreen.ld.conf |
| 13:39 |
abowling |
berick: might be part of my probelm |
| 13:39 |
abowling |
cat: /etc/ld.so.conf.d/evergreen.ld.conf: No such file or directory |
| 13:40 |
jeff |
miker, others: opinions on "require bytes" being in the same lexical scope as the POSIX::write / bytes::length call? I'm tempted to put it in the Sip package itself, since 1) "require bytes" shouldn't have any side effects and 2) there is a slight possibility we may find other calls to length() that should be bytes::length() before we're done. |
| 13:40 |
abowling |
berick: root evergreen-2-10-6-test:/etc/ld.so.conf.d# cat /etc/ld.so.conf.d/eg.conf |
| 13:40 |
abowling |
/usr/local/lib/dbd |
| 13:41 |
berick |
abowling: is there stuff in /usr/local/lib/dbd/ ? |
| 13:42 |
abowling |
berick: there is, but nothing for psql |
| 13:42 |
berick |
k, you should see libdbdpgsql.so |
| 14:34 |
pinesol_green |
Launchpad bug 1482757 in Evergreen "Loading records with located URIs should not delete and recreate call_numbers" [Undecided,Confirmed] https://launchpad.net/bugs/1482757 |
| 14:38 |
miker |
Dyrcona: mess away |
| 14:39 |
Dyrcona |
miker: Will do, as bug manager. |
| 15:04 |
mmorgan |
dbwells: I'm testing lp 1422379 and see mention of a less onerous upgrade script than originally proposed https://bugs.launchpad.net/evergreen/+bug/1422379/comments/13 |
| 15:04 |
pinesol_green |
Launchpad bug 1422379 in Evergreen "Move money.billing timestamps back to moment of fine" [Medium,Triaged] - Assigned to Michele Morgan (mmorgan) |
| 15:05 |
mmorgan |
, but don't see the alternate upgrade script, but agree that it sounds much less onerous. |
| 15:06 |
kmlussier |
@praise bug squashers |
| 15:06 |
* pinesol_green |
bug squashers goes to eleven |
| 15:06 |
kmlussier |
Bad grammar. |
| 15:06 |
mmorgan |
I've done a lot of testing, generating a lot of fines for hourly as well as daily loan periods and finesk and it looks good so far. |
| 15:08 |
mmorgan |
Did I really say that??? Been a long day... |
| 15:11 |
|
ethomsen joined #evergreen |
| 15:22 |
jeff |
mmorgan: were you able to do any testing on a system with billings dating back a long ways, to Evergreen 1.2.x.x and such? |
| 15:23 |
mmorgan |
jeff: no, I don't have access to such a system. |
| 15:24 |
mmorgan |
Is the only concern there the upgrade script for such systems? |
| 15:26 |
jeff |
i wouldn't say it's my *only* concern, no. :-) |
| 16:50 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged: http://irc.evergreen-ils.org/evergreen | Large pastes at http://paste.evergreen-ils.org |
| 17:01 |
terran |
Dyrcona: Yes, I counted the bugmaster changes that I saw |
| 17:01 |
|
jvwoolf left #evergreen |
| 17:09 |
dbwells |
mmorgan: Thanks for testing that branch! I pushed a rebased version with the reworked upgrade script just now: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbwells/lp1422379_move_billing_timestamps_rebase_v3 |
| 17:16 |
abowling |
berick++ |
| 17:16 |
abowling |
berick: you led me down the trail. the fix is this: cp -R /usr/lib/i386-linux-gnu/* /usr/lib/x86_64-linux-gnu/ |
| 17:16 |
abowling |
after that, make runs fine |
| 07:38 |
pinesol_green |
csharp: [evergreen|Dan Scott] Support Apache 2.4 configuration directives - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d4f6bf8> |
| 07:39 |
csharp |
375054cf |
| 07:39 |
pinesol_green |
csharp: [evergreen|Bill Erickson] Collections user balance API / batch file output - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=375054c> |
| 08:05 |
csharp |
okay, so I just now learned about the collections batch file feature that's been around for years, and I'm looking to enable it. If I browse to /collections/, I'm prompted to log in and I get a 404, but if I create a test file and browse to it it works. Is that the expected behavior, that the file works but the directory doesn't? |
| 08:15 |
|
kmlussier joined #evergreen |
| 08:18 |
* kmlussier |
yawns |
| 08:18 |
kmlussier |
@coffee [someone] |
| 10:09 |
Dyrcona |
rhamby is safe, then. :) |
| 10:09 |
* Dyrcona |
is readying his xenial VM for bug squashing day tomorrow. |
| 10:10 |
rhamby |
:) |
| 10:10 |
* Dyrcona |
believe he will test his new and improved SIP branch. |
| 10:11 |
Dyrcona |
jeff: Do you mind if I start working on a branch to remove clean_text from the Evergreen sip code? |
| 10:12 |
jeff |
if you have lots of free time go for it. i'll take it off my list for today. |
| 10:12 |
jeff |
and i'll be happy to test. |
| 10:13 |
jeff |
or counter, if i'm feeling particularly opinionated. |
| 10:13 |
Dyrcona |
I'll see if I can get to it today.. :) |
| 10:14 |
Dyrcona |
First, I want to make sure that the SIPServer changes don't hose a more-or-less stock master installation. |
| 10:14 |
Dyrcona |
But, so I can test removing clean_text, I'll at least start a branch today. |
| 10:23 |
|
TARA joined #evergreen |
| 11:52 |
|
bmills joined #evergreen |
| 12:11 |
|
bos20k joined #evergreen |
| 12:41 |
* Dyrcona |
checks |
| 12:43 |
Dyrcona |
Nope. |
| 12:44 |
Dyrcona |
Once I set that up, maybe I'll make a Lp bug to have it added to the seed data for concerto. |
| 12:46 |
dbs |
Dyrcona: it doesn't look like there are any users with non-ASCII characters in their names or other data, either. |
| 12:46 |
dbs |
which would be really helpful for testing |
| 12:47 |
Dyrcona |
dbs: Yeah, I was going to look into that, too. I can get some records to load if need be. |
| 12:47 |
Dyrcona |
I think I still have a small file of vietnamese records hanging around somewhere. |
| 12:48 |
dbs |
yep, /[^\d0-\d127] says no match |
| 14:41 |
* JBoyer |
is also distracted by other projects, so isn't really checking the EI db.. |
| 15:03 |
mmorgan |
DPearl: kmlussier: Looks like this can happen when transferring volumes as described in lp 1411422 |
| 15:03 |
pinesol_green |
Launchpad bug 1411422 in Evergreen 2.10 "Copy details repeated in search results when item/volume moved with parts attached" [Medium,Confirmed] https://launchpad.net/bugs/1411422 |
| 15:04 |
kmlussier |
mmorgan: I tried transferring volumes on a test system, but I didn't see the problem occur. |
| 15:05 |
* mmorgan |
didn't try and reproduce, but remembered it being a problem in the past. |
| 15:12 |
kmlussier |
Speaking of that bug, Bmagic_ did you see my comments on bug 1411422 regarding old parts being left behind and the possibility of a regression test? |
| 15:12 |
pinesol_green |
Launchpad bug 1411422 in Evergreen 2.10 "Copy details repeated in search results when item/volume moved with parts attached" [Medium,Confirmed] https://launchpad.net/bugs/1411422 |
| 15:12 |
* kmlussier |
would love to see that bug fix merged. |
| 15:38 |
Dyrcona |
So, I just inserted some copies with SQL and a SIP2 request for item info times out. |
| 15:44 |
|
Bmagic joined #evergreen |
| 15:44 |
Dyrcona |
So, if we had upgraded to Jessie, instead of crashing the vendor's software, these records would crash ours. :( |
| 15:45 |
dbs |
We're on Ubuntu 14.04, fwiw |
| 15:46 |
Dyrcona |
We're on Squeeze in production and I'm testing on Ubuntu 16.04. |
| 15:46 |
Dyrcona |
Ubuntu 14.04 does not exhibit this problem. |
| 15:47 |
Dyrcona |
Well, Perl < 5.20 doesn't exhibit this problem. |
| 15:49 |
jeff |
by nature of including the affected version of Encode.pm |
| 16:02 |
StomproJosh |
jeff, I'm going to start a bug on stacking/multiple AT validators. I've wondered a few times about not being able to have several validators. It would be nice to always include a UsrHasEmail validator for an email notice, along with any others. |
| 16:02 |
dbs |
my hypothesis for the reason that i needed to remove clean_text() for item info was that supercat started encoding the incoming data properly |
| 16:03 |
Dyrcona |
dbs: Could be. Looks like Supercat and SIP are the only modules that call decode_utf8 |
| 16:04 |
Dyrcona |
Wel, I'll remove clean_text() (should be easy) test SIP, and then see what happens with Supercat look ups of these two records I have that break SIP. |
| 16:04 |
dbs |
so if you try to decode it twice now, boom, whereas before decode_utf8() was safe to call multiple times on the same data |
| 16:05 |
jeff |
supercat and/or unapi exhibit other non-crashy encoding issues. |
| 16:05 |
Dyrcona |
Well, I find it breaks on utf-8 data, period. |
| 12:22 |
* kmlussier |
will also recheck the page one last time to make sure I didn't miss any other glaring errors. |
| 12:23 |
csharp |
berick: cstore does see the call |
| 12:23 |
csharp |
which is 405466 bytes |
| 12:23 |
berick |
csharp: ok.. so maybe tsbere is on to something. it's easy to test that one.. sec |
| 12:23 |
csharp |
ok |
| 12:25 |
berick |
csharp: mind seeing what happens if you add this line (and restart trigger) -- maybe on a dev server if possible |
| 12:25 |
berick |
https://gist.github.com/berick/f4e1ac051ac8860faaf72816d867b460 |
| 12:27 |
berick |
yeah, exactly |
| 12:29 |
|
mmorgan1 joined #evergreen |
| 12:36 |
* berick |
steps away for a bit |
| 13:02 |
csharp |
ugh - now I'm in a rabbit hole of trying to get logging working properly on my acq testing server :-/ |
| 13:11 |
|
sandbergja joined #evergreen |
| 13:17 |
* tsbere |
dislikes finding 42 bib records with a bad type character |
| 13:18 |
tsbere |
If anyone wants the query I used to *find* said bib records I am willing to share |
| 13:20 |
|
rlefaive joined #evergreen |
| 13:29 |
dbwells |
kmlussier: Took me a second, but I see the heading you are talking about now. Sure, I can regenerate/repost them when ready. |
| 13:31 |
kmlussier |
dbwells: Thanks! I've also caught a few typos that I missed on previous proofreading. Making the changes now. |
| 13:36 |
csharp |
berick: same behavior after that change |
| 13:38 |
csharp |
I was hopeful when a PO on our test server with 212 items printed, but the 313-long one that triggered the helpdesk ticket is still timing out |
| 13:39 |
berick |
csharp: ok, mind trying one more thing? |
| 13:39 |
csharp |
sure |
| 13:39 |
kmlussier |
Do we have a 2.11 release branch yet? |
| 15:15 |
dbs |
csharp berick: thank you for doing this work, it seems very very similar to what we're seeing (albeit more with checkins than triggers) |
| 15:16 |
dbs |
because it seems superweird for a simple checkin to time out in the database |
| 15:17 |
* dbs |
was wondering if networking issues (like ipv6 routing madness from years past?) might also be playing a role |
| 15:17 |
kmlussier |
Bmagic: I'm unable to test the web client to see if I can replicate it, but there was a recent small fix to the patron search form that might be a starting point for your investigation. |
| 15:17 |
kmlussier |
ee711968 |
| 15:17 |
pinesol_green |
kmlussier: [evergreen|Galen Charlton] LP#1436987: webstaff - fix patron search form - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ee71196> |
| 15:17 |
Bmagic |
thanks! |
| 15:21 |
Dyrcona |
csharp: That would indicate that the call to create the trigger in the database failed. |
| 15:21 |
Dyrcona |
Or timed out along the way, which you already know. :( |
| 15:22 |
Dyrcona |
Well, the event output, rather. |
| 15:22 |
berick |
dbs: well, this one is a problem with the size of the data, a blob of text way larger than any normal processing (unless you're bib records are .3 Megabytes in size) |
| 15:22 |
pinesol_green |
[evergreen|Dan Scott] Add a simple Item Information test for SIP server - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9dd9dca> |
| 15:29 |
csharp |
Dyrcona: stock as of 2.9.2 |
| 15:29 |
berick |
csharp: still on ubuntu 14.04? |
| 15:29 |
csharp |
berick: yep |
| 15:35 |
* Dyrcona |
hands out BLOBs. |
| 15:36 |
Bmagic |
kmlussier: phew - it turned out to be some sort of browser caching issue - opened incognito and violla |
| 15:36 |
kmlussier |
Bmagic: Glad to hear it! |
| 15:38 |
csharp |
I'm going to have to stop working on this until I get my test server updated - I'm monkeying around too much on the prod servers :-/ |
| 15:40 |
Dyrcona |
@bartender |
| 15:40 |
* pinesol_green |
fills a pint glass with Cantillon Saint Lamvinus, and sends it sliding down the bar to Dyrcona (http://beeradvocate.com/beer/profile/388/8954) |
| 15:43 |
|
maryj joined #evergreen |
| 10:46 |
dbs |
current status: what the hell happened to take our nice "running with 5GB of free RAM for a full day" into an OOM situation just a few hours later in the middle of the night |
| 10:53 |
Dyrcona |
A bot? A book on an enter key? A ridiculous search query? |
| 11:04 |
Dyrcona |
JBoyer: This looks like the list of services required for SIP on a 2.9 installation: http://pastebin.com/MmVxGC9j |
| 11:04 |
Dyrcona |
NOTE: I have not tested that on a VM or anything, so something might be missing. |
| 11:05 |
Dyrcona |
That just looks like the things that could actually get used by the calls that the SIP driver makes. |
| 11:06 |
JBoyer |
Dyrcona, I'm running on tuit fumes currently, but I've got a couple places I could test that out eventually. I'll admit trigger is a surprise, but I realize there are the occasional interdependencies that aren't always clear. |
| 11:07 |
Dyrcona |
JBoyer: Well, circ could end up making a call to trigger. It probably won't but it wasn't totally clear. |
| 11:08 |
JBoyer |
Ah, that makes sense for some of the active events. |
| 11:09 |
Dyrcona |
I also could have spent more time on it. :) |
| 11:51 |
dbs |
the Apache drones and their 150M of memory per process :/ |
| 11:52 |
Dyrcona |
miker: I can always take a look when I get the chance, which has not been very often lately. |
| 11:53 |
* dbs |
was tempted to start working with nginx or a similar caching proxy again to try and offload some of that weight, but also doesn't want to add another layer of complexity |
| 11:53 |
Dyrcona |
I've also had a hard time reproducing this myself on a test environment. |
| 11:53 |
dbs |
miker: ah that's what I was thinking of, didn't realize it hadn't been merged yet |
| 11:54 |
miker |
in particular, a pile-up occurs when we get a spew of requests that take a long time to process. the apache backends wait for the opensrf request to finish, even if the client side has gone away. the branch attempts avoid that wait, by checking at 1s intervals for client connectedness when it's inside modperl |
| 11:54 |
miker |
dbs: well, we have had same-search guards for a long time ... 2.5, maybe? ... but that only saves the middle layer and the db |
| 16:58 |
Dyrcona |
A new feature might be to add a command in the staff client to recalculate penalties. |
| 16:58 |
phasefx |
the Refresh button triggers the api call for refreshing penalties |
| 16:59 |
phasefx |
checking something in or out should also do it |
| 17:01 |
mmorgan |
Hmm. On production system, 2.9, penalties are recalculating when I refresh. |
| 17:01 |
mmorgan |
On 2.10.5 test system, penalties don't recalculate when I refresh. |
| 17:01 |
phasefx |
mmorgan: are the org depths the same on the penalty definitions? |
| 17:02 |
phasefx |
between systems |
| 17:02 |
Dyrcona |
And all this time I thought that Refresh only retrieved the patron information again. |
| 17:02 |
phasefx |
wasn't really joking when I suggested org units :) |
| 17:04 |
mmorgan |
So on production system, PATRON_EXCEEDS_FINES has null org_depth |
| 17:04 |
mmorgan |
test system has 0 |
| 17:04 |
phasefx |
what I don't have a good handle on is the behavior with org depths, I just remember they can cause problems |
| 17:04 |
mmorgan |
but it's a consortium wide penalty |
| 17:05 |
* mmorgan |
guesses this won't get solved today will revisit on Monday;-) |
| 17:05 |
phasefx |
mmorgan: I bet if you make it null on the test system it'll work |
| 17:05 |
mmorgan |
Will try that next, but have to run. Have a good weekend, all! |
| 17:05 |
|
mmorgan left #evergreen |
| 17:20 |
|
Stompro joined #evergreen |
| 11:22 |
|
maryj joined #evergreen |
| 11:26 |
Stompro |
Thanks all for the damaged item nfo. Now that I think about it more it is probably a bad idea to combine them, they are two seperate situations that get treated differently in our state law. If we notify about damaged items we will send a seperate notice. |
| 11:35 |
* Dyrcona |
wonders at the usefulness of an interface to undelete patrons. I guess it would only work here because the client doesn't do the obliteration dance on delete for ... reasons. |
| 11:42 |
* kmlussier |
updates the MassLNC community demo server to 2.10.6 early because she had to test something on 2.10 anyway. |
| 11:42 |
kmlussier |
For now, then, we're going to have 2 community demo servers on the same major release. |
| 11:46 |
|
bmills joined #evergreen |
| 12:00 |
Dyrcona |
"hello, headache, my old friend...I feel you've come to me again." |
| 12:00 |
Dyrcona |
"it's just the pain of sinus..." |
| 14:10 |
pinesol_green |
csharp: [evergreen|Bill Erickson] LP#1464709 Rename checkout_ok to is_available - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2c40b84> |
| 14:15 |
Bmagic |
miker: sorry for the delay - The SIP server is working as expected on 2.11rc |
| 14:16 |
Bmagic |
my copy of production database was 2.9.1 and that did not work |
| 14:16 |
miker |
Bmagic: sweet, thanks for testing! |
| 14:16 |
miker |
oh? how did it break? |
| 14:16 |
Bmagic |
I had to raise the db to 2.11rc (to match the Evergreen code) - auth errors otherwise - db functions missing |
| 14:17 |
Bmagic |
I didn't try the SIPServer against 2.9.1 evergreen |
| 14:17 |
miker |
oh, the db was 2.9.1 but the evergreen code was 2.11 |
| 14:17 |
Bmagic |
right |
| 14:17 |
Bmagic |
I suppose the SIPServer will work against older Evergreen installs? |
| 14:18 |
miker |
it should |
| 14:18 |
Bmagic |
I think I can test that as well if needs be |
| 14:18 |
miker |
old drivers should ignore the new parameter |
| 14:18 |
miker |
JBoyer: did you test the new sip stuff (passing a workstation) against old evergreen that doesn't expect to receive that? |
| 14:21 |
rjackson_isl |
miker: the boss is off to one of his many meetings currently so he will get back to you! |
| 14:21 |
miker |
rjackson_isl: heh, thanks :) |
| 14:27 |
|
yboston_ joined #evergreen |
| 14:28 |
miker |
right, that's my reading too |
| 14:29 |
* tsbere |
glares at the glare on his screen as well as the ineffective blinds that are full of intentional holes |
| 14:29 |
|
maryj joined #evergreen |
| 14:31 |
csharp |
kmlussier: I just pushed a probable fix to bug 1624025 to http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/csharp/lp1624025_copy_status_missing_field - are you able to easily test it? I'm not in a place at the moment where I can test it on my own server |
| 14:31 |
pinesol_green |
Launchpad bug 1624025 in Evergreen "Hold targeting weirdness in 2.11" [High,New] https://launchpad.net/bugs/1624025 |
| 14:33 |
kmlussier |
csharp: Yes, berick shared the same fix earlier (up above around the time I was complaining about comcast). It does indeed work. |
| 14:33 |
csharp |
oh great :-) |
| 16:41 |
miker |
the difference that my second commit makes is that it allows you to say "ignore the client's CP field, use this value from the config file" |
| 16:42 |
miker |
well, it will if you do /not/ set client_location_code="true" for your institution(s) |
| 16:42 |
miker |
which gives you the ability to migrate clients over time |
| 16:43 |
Bmagic |
that should work, I will have to setup a test |
| 16:43 |
miker |
by moving their account entries from one institution to another, with differing settings |
| 16:44 |
miker |
please do! I'd like this to get into sipserver before 2.11 goes GA if possible, so sipserver master can be configured (at least) to not break any existing releases |
| 16:45 |
jeff |
i may propose an alternate branch if i can get my thoughts together. |
| 17:03 |
Dyrcona |
Yes. I would tend to agree with server wins. |
| 17:04 |
miker |
anyway, I pushed one more commit that changes the institution policy setting "client_location_code" so that, unless that is set to "true", you get the old behavior (plus the ability to set the value in the config file) |
| 17:04 |
Bmagic |
if a username/password is presented on the xml and from the client, who wins? |
| 17:04 |
miker |
Bmagic: so, if you feel like testing, please try the tip of http://git.evergreen-ils.org/?p=working/SIPServer.git;a=shortlog;h=refs/heads/user/miker/lp1579144_login_location |
| 17:07 |
miker |
Bmagic: for an <account> you mean? the xml is considered authoritative. if they don't match (or the login fails at the ILS) then login fails... so, I guess the ILS is most authoritative, but between XML and client, XML wins. is that what you mean? |
| 17:07 |
Bmagic |
yeah, another joke |
| 17:07 |
Bmagic |
the xml has the username/password/workstation supplied and the sip client has the same. who wins on each one..... |
| 17:09 |
* Dyrcona |
calls it a day. |
| 17:28 |
miker |
git blame --annui ?? |
| 17:29 |
* miker |
really runs away |
| 17:30 |
Bmagic |
lol |
| 17:53 |
Bmagic |
miker: I just tested the SIP server code - something is amiss (probably me) |
| 17:53 |
Bmagic |
LOGIN ERROR: 'Undefined subroutine &Sip::MsgType::to_bool called at Sip/MsgType.pm line 859. |
| 18:37 |
|
_adb left #evergreen |
| 19:17 |
miker |
Bmagic: no, it's me. I'll look at that as soon as I can and let you know. probably in the morning |
| 09:20 |
jeff |
can your apache hosts connect to memcached successfully? |
| 09:20 |
dbs |
jeff: yeah, I realize that -- so many moving parts to tweak |
| 09:21 |
jeff |
any cache-related errors in the logs? |
| 09:21 |
dbs |
tested the apache memcache translator setting of 127.0.0.1:11211 via telnet and that works, no errors reported in the logs |
| 09:21 |
jeff |
there are things that are fetched from config, from the db, and from memcached... also the template toolkit cache... |
| 09:21 |
dbs |
yep |
| 09:22 |
* dbs |
will get back onto debug_timing, whoever thought of adding that was a GENIUS |
| 09:39 |
dbs |
It seems that the apache processes need to be initialized, subsequent requests don't show those kinds of slowdowns (157ms and 83.5ms for initial connection & ssl), so that's an outlier |
| 09:40 |
Dyrcona |
dbs: yes, I've seen that Apache is really slow just after start up. Load also tends to stay high for a couple of minutes, then settles down. |
| 09:40 |
dbs |
hah, there aren't many events in the stock /eg/opac/advanced page it seems, just New page and initial load (At 0.1836: Initial load) |
| 09:40 |
csharp |
same here - just saw that on my test box |
| 09:40 |
dbs |
btw, Dyrcona, thank you for http://blog.mvlcstaff.org/2013/05/what-has-been-going-on.html |
| 09:43 |
jeff |
worst case i can get is 2.30s Load time (per chrome devtools) on a fresh apache start, even with cstore intentionally hobbled to 1 worker. |
| 09:43 |
jeff |
on a fresh apache start. |
| 10:22 |
dbs |
we do have about 20 virtualhosts configured for both 443 and 80, so undoubtedly lots of parsing overhead |
| 10:23 |
JBoyer |
Could be, this machine hosts nothing else and it's generally hit by outside users. |
| 10:24 |
JBoyer |
NOT generally hit by users, that is. |
| 10:24 |
Dyrcona |
So, you're testing against one of 20 virtual hosts on the same hardware? Could be the hardware is slightly overtaxed. |
| 10:26 |
dbs |
Dyrcona: yep |
| 10:26 |
dbs |
although load seems fine |
| 10:26 |
dbs |
at 0.75 for the last fifteen minutes, on an "8 core" VM |
| 10:30 |
JBoyer |
dbs, referring to your speed comment above, I'm seeing ~200Kb/s for our homepage on the same gigabit network. TCP startup speeds I'm guessing? With pages that "small" the speed may never be able to top out. ( I also see 2000Kb/s when testing localhost on it's public IP) |
| 10:30 |
dbs |
total of 14 cstore timeout errors reported over the past 24 hours (determined by grep "perl:error" /var/log/syslog | grep cstore) |
| 10:33 |
jeff |
also laptop-on-wifi here. local system gets me 111.196 ms mean over 100 requests (11.120 seconds total); webby gets 740.887 ms mean over 100 requests (74.089 seconds total) |
| 10:34 |
jeff |
that seems to be more than just rtt hurting me there. second guess is ssl tuning, but in both cases ab selected TLSv1.2,ECDHE-RSA-AES256-SHA384,2048,256 |
| 16:16 |
Dyrcona |
I want to start clark kent on the training server and it has a copy of production. |
| 16:17 |
Dyrcona |
I set recur to false on all of the reports. |
| 16:17 |
Dyrcona |
Is that all I need to do to prevent any surprise reports firing off? |
| 16:17 |
Dyrcona |
We want to test some reports manually. |
| 16:19 |
jeff |
also check for any reports scheduled to run which have not run. |
| 16:19 |
* jeff |
refreshes memory on what columns he means |
| 16:20 |
Dyrcona |
jeff: I was just going to aks. |
| 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 |
| 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++ |
| 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: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: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 |
| 15:26 |
* berick |
hopes more than 4 people are coming to the hackaway |
| 15:26 |
Dyrcona |
csharp: Are you done working on Lp 1360347 |
| 15:26 |
pinesol_green |
Launchpad bug 1360347 in Evergreen "Wishlist - New LSE setting for Acquisitions" [Wishlist,In progress] https://launchpad.net/bugs/1360347 - Assigned to Chris Sharp (chrissharp123) |
| 15:26 |
Dyrcona |
The status is in progress, but the code changes look good to me and we'd like to test it. |
| 15:30 |
jeffdavis |
I've got a pcrud drone that's been running for over 40 minutes, chewing up a lot of CPU. Is there any way to find out what it's up to while it's running? I get the impression that the request (whatever it is) won't be logged until it's complete. |
| 15:31 |
* JBoyer |
hopes there are at least 18 others coming, or there'll be bills to pay. :/ |
| 15:31 |
jeff |
jeffdavis: have you tried attaching to it with something like "strace -p PID_HERE" to see if it's just spinning? |
| 16:10 |
jonadab |
"What's the worst that could happen?" "You mean besides starting a global thermonuclear war?" |
| 16:10 |
* dbs |
upgrades the upgrade plugin |
| 16:11 |
dbs |
I'll be good and wait until I can backup the wiki directory first before I upgrade the wiki. |
| 16:15 |
csharp |
Dyrcona: I'm done until I can actually test it, yes. Our Acq person is out for a while, so I'm waiting for her to return before experimenting |
| 16:15 |
csharp |
Dyrcona: please test if you have the means to do so |
| 16:16 |
csharp |
dbwells: I kept seeing "banjo" in there too :-P |
| 16:17 |
* csharp |
prolly won't bother bringing the ol' ukulele this round |
| 16:19 |
Dyrcona |
csharp: Thanks. I'll see if I can do anything to test it in the meantime, too. |
| 16:19 |
csharp |
Dyrcona++ |
| 16:19 |
* Dyrcona |
tosses another iron in the fire. ;) |
| 16:26 |
StomproJ |
Ooops, just merged all the Readers digest large print into reader digest... to the auditor tables. Where is the undo button in psql. |
| 16:37 |
|
gsams_ joined #evergreen |
| 16:39 |
|
gsams_ joined #evergreen |
| 16:42 |
StomproJ |
Hmm, it doesn't look like asset.merge_record_assets deletes empty volumes, which works out well for me, but I wonder if that is intended. |
| 16:43 |
csharp |
StomproJ: I'll test it, but it will take a long time to apply on our test system, so it won't be quick :-) |
| 16:43 |
StomproJ |
csharp++ thanks. |
| 16:43 |
csharp |
we have a buncha muncha cruncha bibs |
| 16:54 |
|
bmills joined #evergreen |
