| Time |
Nick |
Message |
| 03:09 |
|
gsams joined #evergreen |
| 04:14 |
|
dcook joined #evergreen |
| 04:50 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 08:01 |
|
jboyer-home joined #evergreen |
| 08:06 |
|
rjackson-isl joined #evergreen |
| 08:21 |
|
dkyle left #evergreen |
| 08:29 |
|
eby__ joined #evergreen |
| 08:31 |
|
eby__ joined #evergreen |
| 08:33 |
|
Sato joined #evergreen |
| 08:40 |
|
Dyrcona joined #evergreen |
| 08:42 |
Dyrcona |
any laters for me? |
| 08:42 |
Dyrcona |
Nope. |
| 08:46 |
|
tspindler joined #evergreen |
| 08:48 |
|
kbeswick joined #evergreen |
| 08:52 |
|
collum joined #evergreen |
| 08:55 |
|
ericar joined #evergreen |
| 08:59 |
|
RoganH joined #evergreen |
| 09:04 |
|
mrpeters joined #evergreen |
| 09:09 |
|
mmorgan joined #evergreen |
| 09:11 |
|
ericar_ joined #evergreen |
| 09:31 |
|
yboston joined #evergreen |
| 09:42 |
|
mllewellyn joined #evergreen |
| 10:16 |
|
dkyle joined #evergreen |
| 10:39 |
* dbs |
ponders adding a robots.txt.example like http://laurentian.concat.ca/robots.txt to the default install (.example to avoid blowing away existing ones) |
| 10:41 |
Dyrcona |
Ours is a sledgehammer: Disallow: / |
| 10:42 |
phasefx |
btw, that qatests failure, seems like a race condition: http://testing.evergreen-ils.org/~live/test.46.html Unable to retrieve settings from settings server, retrying.. and it looks like it succeeds on the retry |
| 10:42 |
Dyrcona |
phasefx: fwiw, we see a similar message with action triggers from time to time. |
| 10:43 |
Dyrcona |
except it reports, "going to sleep" |
| 10:43 |
dbs |
Dyrcona: huh. given a sitemap like https://bugs.launchpad.net/evergreen/+bug/1330784 and a decent robots.txt, wouldn't you want search engines to index your bib records and holdings? |
| 10:43 |
pinesol_green |
Launchpad bug 1330784 in Evergreen "Evergreen needs automated sitemap generation" (affected: 1, heat: 8) [Wishlist,New] |
| 10:43 |
phasefx |
Dyrcona: that sounds scarier |
| 10:45 |
Dyrcona |
dbs: We had some performance issues with spiders at one point. |
| 10:48 |
dbs |
Dyrcona: right, but a good robots.txt will help keep spiders away from bad paths (anything other than record details pages or library pages) |
| 10:50 |
Dyrcona |
dbs: Well, we might switch to using yours, then. |
| 11:01 |
|
akilsdonk joined #evergreen |
| 11:05 |
paxed |
unfortunately, there are robots which do not obey robots.txt - most seem to come from china and thereabouts. |
| 11:08 |
Dyrcona |
paxed: Yep, or to be home grown. |
| 11:09 |
dbs |
paxed: exactly, in which case robots.txt doesn't matter at all |
| 11:10 |
|
bmills joined #evergreen |
| 11:10 |
dbs |
So having a Disallow: * robots.txt removes the possibility of well-behaved crawlers from doing good things while doing nothing for bad ones. |
| 11:16 |
Dyrcona |
dbs: Fun trick: put a line in robots.txt with a disallow to a script. |
| 11:16 |
Dyrcona |
When the script is executed, it updates the firewall to block the source IP address. |
| 11:18 |
Dyrcona |
That catches bots that look at robots.txt to deliberately break your rules. |
| 11:22 |
dbs |
Dyrcona: heh, that's a good idea :) |
| 11:22 |
dbs |
Disallow: /show_passwords # SUPER SECRET! |
| 11:23 |
Dyrcona |
heh |
| 11:24 |
Dyrcona |
Actually, while playing around with getting Dancer to work via Apache on my dev server, I exposed our Novelist password for about five minutes. |
| 11:24 |
Dyrcona |
I wrote a route to print the current environment. |
| 11:24 |
|
vlewis joined #evergreen |
| 11:54 |
Dyrcona |
Just curious: Anyone else circulating cake pans? |
| 11:57 |
jboyer-home |
Dyrcona: We have some libs that do. I don’t know how It |
| 11:57 |
jboyer-home |
I’d feel about it, that is. |
| 11:58 |
Dyrcona |
jboyer-home: I just got asked to add parameters for cake pans. I thought it would be funny to add a cake pan circ_modifier "for cake pans, and anything else." ;) |
| 11:58 |
Dyrcona |
As it is, we're going with equipment, since this library doesn't use it already. |
| 11:58 |
jboyer-home |
Cake pans and kitchen sinks! |
| 11:59 |
Dyrcona |
Cake pans and telescopes. :) |
| 11:59 |
Dyrcona |
Another library circulates telescopes. |
| 11:59 |
jboyer-home |
We have a realia circ mod, which covers most of these bases and means not a thing to patrons. |
| 12:00 |
csharp |
we have a library circulating ukuleles - that resulted in a new circ modifier of "Realia" |
| 12:01 |
jboyer-home |
Though I wouldn’t have much of a problem checking out a telescope. Something about food-ware doesn’t work for me. |
| 12:01 |
* csharp |
gets the heebie jeebies just thinking about that :-/ |
| 12:01 |
Dyrcona |
;) |
| 12:01 |
Dyrcona |
We have equipment and misc as circ modifiers. |
| 12:01 |
csharp |
I get very OCD about used stuff ;-) |
| 12:02 |
Dyrcona |
We use marc information in our circ matchpoints, too. |
| 12:02 |
Dyrcona |
I guess if you wash it real good before using it and taking it back.... |
| 12:03 |
Dyrcona |
We use the marc type for realia. |
| 12:03 |
jboyer-home |
I can see it being a problem if you don’t use marc info. We might be able to use equipment here if we looked at the marc info in addition, but our equipment circ mod has very short default durations. A byproduct of all of the time we spent on circ scripts. |
| 12:05 |
jboyer-home |
That isn’t the most sturdily constructed sentence, but I hope the meaning isn’t entirely lost. :/ |
| 12:09 |
Dyrcona |
Our members vary on the circulation duration for equipment, usually 1-2 or 7 days. |
| 12:12 |
jeff |
At least one location used to circulate cake pans, but does not anymore. |
| 12:14 |
* Dyrcona |
sometimes regrets the decision NOT to use circ modifiers as item types. |
| 12:16 |
jboyer-home |
What sort of circ_mods do you have instead? |
| 12:17 |
Dyrcona |
We use them as modifiers, so we have things like equipment, miscellaneous, hot, bestseller, holiday, rental, etc. |
| 12:18 |
Dyrcona |
We usually make the main circ rules off of marc_type, level, etc. |
| 12:18 |
jboyer-home |
I see. equipment is close enough to the line that I was having a hard time seeing how it wasn’t an item type. :) |
| 12:19 |
Dyrcona |
Yep. We also have play for playaway, so its kind of a mish mash. |
| 12:20 |
Dyrcona |
I was trying to keep things "simple." |
| 12:20 |
Dyrcona |
Turns out, you need to be a genius to understand simplicity. |
| 12:23 |
jboyer-home |
Well, what’s that old programmer adage? Build one to throw away? |
| 12:23 |
jboyer-home |
;) |
| 12:23 |
Dyrcona |
Yep. :) |
| 12:24 |
jboyer-home |
I’m sure staff will be very understanding. :D |
| 12:25 |
Dyrcona |
We were going to switch to a system where the circ_modifier encoded the rules, like 7d-0r-0h for 7 days, no renewals, no holds. |
| 12:25 |
bshum |
We thought about that for awhile too. |
| 12:25 |
Dyrcona |
That proved to be very difficult when trying to update the existing copies/matchpoints. |
| 12:26 |
* bshum |
only regrets trying to shove "movie" as a circ mod for folks when they all really, really wanted "dvd", "video", "bluray", etc. |
| 12:27 |
|
hbrennan joined #evergreen |
| 12:27 |
Dyrcona |
we do that with MARC. |
| 12:27 |
bshum |
That still bothers some people, but we're slowly phasing out some of those distinctions over time. :( |
| 12:27 |
Dyrcona |
We recently fixed a bunch of DVD and Blu-ray records that said they were VHS and/or Laserdisc. |
| 12:28 |
bshum |
Yeah, I'm pretty sure that's why we're not using MARC to define policy |
| 12:28 |
bshum |
Nobody felt super confident on that front :) |
| 12:28 |
Dyrcona |
Well, you're search will be messed up, too. |
| 12:28 |
Dyrcona |
s/you're/your/ |
| 12:28 |
bshum |
Especially now with the newer format stuff |
| 12:28 |
Dyrcona |
Yep. |
| 12:28 |
bshum |
We're slowly repairing those |
| 12:28 |
bshum |
On a more case by case basis |
| 12:29 |
bshum |
My favorite is the library that cataloged all their movies on whichever bib they found first, regardless of actual type. |
| 12:29 |
Dyrcona |
Yeah, well.....Nothing software can really do about that. ;) |
| 12:54 |
bshum |
yboston: Minor tidbit, and something I can try putting on there when I get a few minutes after my next meetings this afternoon; we need to put a quick release note for https://bugs.launchpad.net/evergreen/+bug/1327284 |
| 12:54 |
pinesol_green |
Launchpad bug 1327284 in Evergreen "Display "Imported As" in Vandelay queue" (affected: 7, heat: 36) [Undecided,New] |
| 12:57 |
yboston |
bshum: are you suggesting that I put write a release note for this feature? I can do thta today, or are you asking something else? |
| 12:57 |
bshum |
yboston: I just mentioned it to you since you've been campaigning for adding the feature for 2.7. If you have time to whip up a short sentence, that'd be great :) |
| 12:58 |
* bshum |
will return later. |
| 12:58 |
yboston |
bshum: count on me, I will get it done today |
| 13:07 |
|
ldw joined #evergreen |
| 13:30 |
* dbs |
curses http://docs.evergreen-ils.org/2.1/html/sipserver.html for pointing at the dead-for-three-years atz SIP repository |
| 13:30 |
dbs |
but I guess we don't have anything at all about SIP in current docs. |
| 13:31 |
dbs |
http://wiki.evergreen-ils.org/doku.php?id=evergreen-admin:sip has the right git repo at least |
| 13:31 |
yboston |
dbs, my intern and I had converted some old docs into asciidoc, but at the time I was told that nothing had really cahnged from 2.1. I can upload theasciidoc version this week to make updtes easier |
| 13:31 |
* dbs |
doesn't even know how we would go about fixing really old DocBook-based docs |
| 13:32 |
yboston |
*updates |
| 13:32 |
dbs |
yboston: that would be great, as I was considering just rewriting it in asciidoc myself |
| 13:32 |
yboston |
I'll do that in the next 48 hours |
| 13:32 |
yboston |
should I put it in a collab brnach? |
| 13:32 |
yboston |
*branch |
| 13:33 |
* dbs |
is cursing the 2.1 docs for pointing at the atz repo because that fork introduced checksum errors that sucked up about 4 hours of my debugging time |
| 13:33 |
dbs |
yboston: if you want eyes on it before committing, sure |
| 13:34 |
Dyrcona |
dbs: SIPServer? |
| 13:34 |
* Dyrcona |
would like to point out that some 3M products don't get the checksumming correct. |
| 13:35 |
dbs |
Dyrcona: yes, we've been back and forth on this before |
| 13:36 |
Dyrcona |
dbs: Yes, SIP is such a pleasure. I can discuss it any time. ;) |
| 13:36 |
dbs |
but the main repo got things back on track in general, whereas atz' fork unequivocally broke it |
| 13:36 |
|
bmills joined #evergreen |
| 13:37 |
Dyrcona |
yep, dbs++ |
| 13:37 |
dbs |
SIP-- |
| 13:37 |
dbs |
Dyrcona++ |
| 13:37 |
dbs |
collaboration++ |
| 13:38 |
Dyrcona |
definitely, collaboration++ |
| 13:40 |
jeff |
where possible, disable cSIP checksums. :-) |
| 13:40 |
jeff |
s/cSIP/SIP/ :P |
| 13:40 |
jeff |
mosh++ |
| 13:40 |
jeff |
lag-- |
| 13:44 |
Dyrcona |
NCIP is a whole 'nother bucket o' fun. :) |
| 13:48 |
jeff |
indeed. |
| 13:49 |
jeff |
but i was happy to see SIP checksums die in SIP3 |
| 13:57 |
jboyer-home |
I wonder if anyone still uses a serial SIP connection. That sounds like a good place to have checksums. (It belongs in a museum!) |
| 13:59 |
jeff |
that was indeed the original place to have checksums. i have a written tale somewhere here (and i should find and scan it in) of a data migration of an old newspaper index where the transfer from one machine to another was flawed because of lack of parity/checksum on the transfer protocol combined with a too-fast-to-be-accurate baud rate :-) |
| 14:01 |
|
RoganH joined #evergreen |
| 14:01 |
jboyer-home |
Ugh. I can only imagine taking the better part of a day for some screaming fast 4500baud transfer to fail mysteriously. |
| 14:02 |
Dyrcona |
I used to use the Internet over a 14.4k (shared) modem. Shared using GNU/Linux as a gateway with dial on demand..... |
| 14:03 |
Dyrcona |
<sings>Those were the days....</sings> |
| 14:08 |
mllewellyn |
Does anyone know of an online source of SAN codes for libraries that doesn't cost money to access? |
| 14:19 |
|
CM joined #evergreen |
| 14:30 |
jeff |
jboyer-home: fail? surely you jest. no, in this case it was "silently corrupted" -- see my previous mention of no parity/checksum/etc :-) |
| 14:31 |
jboyer-home |
I guess I was looking at it as “a failure” rather than the connection dropping. But yes, they should be so lucky for it to actually fail. :) |
| 14:40 |
Dyrcona |
From English to gibberish in 4.5 femtoseconds! |
| 14:50 |
jboyer-home |
A failure of communication, or a successful obfruscation? We report, you decide! |
| 15:09 |
csharp |
@dunno add What we have here is a failure to communicate. |
| 15:09 |
pinesol_green |
csharp: The operation succeeded. Dunno #31 added. |
| 15:10 |
Dyrcona |
csharp++ |
| 15:16 |
|
ericar_ joined #evergreen |
| 15:21 |
bshum |
dbwells: We're curiously wondering about 35dfab068abab95c524bb73adce3626f3c472c97 |
| 15:21 |
bshum |
Err, oops |
| 15:21 |
bshum |
Wrong hash, heh |
| 15:22 |
bshum |
a457813d632916c0d79ec38ffe4ddf2662f91002 |
| 15:22 |
pinesol_green |
[evergreen|Dan Wells] 'Opportunistic' Acq In-process Copy Overlay - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a457813> |
| 15:22 |
bshum |
Where it only matches on in-process items |
| 15:22 |
bshum |
I think mllewellyn is wondering why it only matches for in-process, and not other item statuses, like "on order" |
| 15:23 |
bshum |
Or if there's a specific workflow we're supposed to be aiming for |
| 15:25 |
bshum |
Oh, is it related to receiving an acq item that turns it to an in process status, hmm? |
| 15:25 |
dbwells |
It's been a while since I wrote that, so I can't really comment with certainty anymore. |
| 15:26 |
dbwells |
Yes, that sounds right. |
| 15:26 |
dbwells |
Our workflow is certainly order->receive->catalog. |
| 15:27 |
bshum |
I guess that's what mllewellyn is attempting to see if we can solve, because the library is skipping the receiving step, so the items are in an on order state and then we hope to overlay them from that point through loading. |
| 15:27 |
bshum |
Not sure if there's something else we're missing. |
| 15:28 |
bshum |
Thanks dbwells, I'll ponder more |
| 15:28 |
|
mrpeters joined #evergreen |
| 15:29 |
bshum |
The other thing we're pondering is maybe editing the EDI template we're sending out to include the copy ID to the vendor. If we use copy ID match overlay, that doesn't care on the status, so that might work better anyways. |
| 15:29 |
bshum |
Hmm, pondering, pondering :) |
| 15:31 |
dbwells |
bshum: My best recollection is that I kept the code as targetted as possible in selecting eligible copies to reduce risk of bugs causing damage. I could imagine it being expanded to include other statuses, probably as a waterfall (e.g. In process, first, then On-order if no In process copies exist). |
| 15:34 |
dbwells |
I'm also not understanding an acq workflow where the receive step gets skipped, but I'm probably not being creative enough :) |
| 15:35 |
dbwells |
If your workflow is such that you can use copy ID as an overlay, I'd say that's much better overall. |
| 15:39 |
bshum |
Yeah I think that might be the way to go in this case. Course the fun part is figuring out the PO JEDI template entries. |
| 15:53 |
bshum |
Strange |
| 15:53 |
bshum |
copy_id => lid.id, # for INC_COPY_ID |
| 15:53 |
bshum |
So it sets the copy_id to the lineitem ID in the EDI template if we include copy data |
| 15:54 |
bshum |
But the label for the entry is copy_id |
| 15:54 |
bshum |
That's weird looking. |
| 15:54 |
bshum |
Maybe this is a weird interaction with whichever vendor was first testing the EDI GIR stuff? |
| 15:56 |
bshum |
Or maybe something to do with electronic invoicing? |
| 15:56 |
bshum |
Sigh... |
| 15:56 |
bshum |
@hate acq |
| 15:56 |
pinesol_green |
bshum: But bshum already hates acq! |
| 15:57 |
bshum |
Hmm |
| 15:58 |
bshum |
Or we add a part to the EDI message for eg_copy_id to pass the copy ID direct |
| 16:11 |
dbwells |
bshum: The release notes for the original overlay feature mention "For either type of queue, however, overlay occurs against a real copy (asset.copy). In the ACQ queue case, we use the lineitem_detail ID because this is the data ACQ providers and sub-systems will have access to." |
| 16:11 |
dbwells |
That makes me think it might do what you need as long as you pick "Acquisitions Records" in Import Records when doing the overlay (?) |
| 16:12 |
dbwells |
Just some thoughts |
| 16:16 |
bshum |
Interesting. |
| 16:17 |
mllewellyn |
dbwells, would we need a Holdings Import profile if we picked Acquisitions Records? Or how would we get the loader to match on lineitem detail? |
| 16:22 |
dbwells |
Yes, I think you would still need a Holdings Import profile. For the purposes of the copy overlay feature added in 2.3, it looks like selecting "Acquisitions Records" triggers the code to grab the real copy ID from the LID before doing the overlay. Whether acq record queues have other special qualities when used in this way, I don't know. |
| 16:23 |
dbwells |
I'm not an expert, I'm just glancing over the original bug: https://bugs.launchpad.net/evergreen/+bug/1031144 |
| 16:23 |
pinesol_green |
Launchpad bug 1031144 in Evergreen "Vandelay copy overlay" (affected: 2, heat: 12) [Undecided,Fix released] |
| 16:24 |
mllewellyn |
dbwells, thanks that looks like it answers a lot of my questions. |
| 16:24 |
bshum |
dbwells++ |
| 16:34 |
|
tspindler left #evergreen |
| 16:51 |
|
patrick joined #evergreen |
| 16:51 |
|
patrick left #evergreen |
| 16:54 |
|
pgardella joined #evergreen |
| 17:17 |
|
mmorgan left #evergreen |
| 17:23 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:28 |
|
gsams joined #evergreen |
| 19:02 |
|
vlewis_ joined #evergreen |
