| Time |
Nick |
Message |
| 00:02 |
|
zerick joined #evergreen |
| 01:15 |
|
jeff joined #evergreen |
| 01:15 |
|
jeff joined #evergreen |
| 01:26 |
|
MsAngel joined #evergreen |
| 01:26 |
MsAngel |
Hello I have problem in autogen.sh |
| 01:26 |
MsAngel |
ubuntu 12.04 and evergreen 2.5.4 |
| 05:02 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:59 |
csharp |
@later tell Dyrcona this made me think of you: http://developers.slashdot.org/story/14/04/30/0042250/the-ways-programming-is-hard |
| 05:59 |
pinesol_green |
csharp: The operation succeeded. |
| 07:05 |
|
timf joined #evergreen |
| 07:28 |
csharp |
looks like the upgrade path from 2.1 to 2.3 and forward doesn't include script 0738 |
| 07:28 |
csharp |
PINES doesn't have the updated vandelay.get_expr_from_match_set function either, so we'll have to schedule a time to run 0738 separately |
| 07:29 |
csharp |
(looking back at frank__'s problem yesterday rang a bell about the same issue I found on our acq testing server) |
| 07:41 |
|
collum joined #evergreen |
| 07:43 |
bshum |
csharp: I'm stepping out momentarily, today is one of my random days off; but I just wanted to touch base with you briefly on the Ubuntu 14.04 situation |
| 07:44 |
bshum |
I removed my working branch playtest for opensrf, I've been finding further complications with how I was hammering the changes to deal with the warnings during autoreconf |
| 07:45 |
bshum |
As we poke at the installation further with Evergreen once we figure out OpenSRF, I think the other thing that'll be interesting is seeing how use of Apache 2.4 goes. I've never had opportunity to try the files in apache_24, but 14.04 might need to draw from those. |
| 07:46 |
bshum |
Anywho, I'll try and catch back up a bit later on things. |
| 07:54 |
csharp |
bshum: thanks for the follow-up. While I'm sorry to hear that the 14.04 transition is not a clean one, I'm glad to know I wasn't the only one stymied by the changes ;-) |
| 07:55 |
csharp |
as usual, I have several irons in the fire this week, but if I get a chance, I'll revisit ;-) |
| 07:57 |
csharp |
@weather 30345 |
| 07:57 |
pinesol_green |
csharp: The current temperature in Lakeside, Atlanta, Georgia is 64.2°F (7:45 AM EDT on April 30, 2014). Conditions: Partly Cloudy. Humidity: 94%. Dew Point: 62.6°F. Pressure: 29.81 in 1010 hPa (Steady). Wind Advisory in effect until noon EDT today... |
| 07:58 |
* csharp |
looks out and sees calm, still trees |
| 08:02 |
|
rjackson-isl joined #evergreen |
| 08:15 |
|
akilsdonk joined #evergreen |
| 08:22 |
bradl |
csharp: yeah, where is the "we're 100% sure" crazy weather... |
| 08:23 |
* csharp |
braces for karmic tornado that we're now due |
| 08:23 |
csharp |
@band add "Karmic Tornado" |
| 08:23 |
pinesol_green |
csharp: Have you tried turning it off and back on again? |
| 08:25 |
|
jcamins joined #evergreen |
| 08:27 |
berick |
heh, speaking of, I was woken up by a 5am tornado warning alert on my phone. |
| 08:28 |
berick |
no tornado (though, not complaining) |
| 08:28 |
bradl |
berick: geez. I think my house got about 12 drops of rain and the forecast yesterday afternoon said 100% chance of 1-2 inches of rain |
| 08:29 |
* csharp |
tries to return the canoe he bought based on those predictions |
| 08:34 |
berick |
bradl: it's pretty much the same here. a few heavy rain blasts, but nothing compared to the predictions. |
| 08:35 |
csharp |
@quote random |
| 08:35 |
pinesol_green |
csharp: Quote #34: "Never believe quotes you read on the Internet. -- Abraham Lincoln" (added by Dyrcona at 09:51 AM, November 06, 2012) |
| 08:36 |
berick |
@coffee |
| 08:36 |
* pinesol_green |
brews and pours a cup of Espresso Nuevo, and sends it sliding down the bar to berick |
| 08:43 |
|
Shae joined #evergreen |
| 08:53 |
|
mmorgan joined #evergreen |
| 08:54 |
* csharp |
sighs |
| 08:55 |
csharp |
evergreen-ils.org not loading :-/ |
| 08:55 |
csharp |
system load is fine |
| 08:59 |
csharp |
okay - it was someone DoSing the server trying to hack WP |
| 08:59 |
csharp |
iptables++ |
| 09:03 |
|
ericar joined #evergreen |
| 09:14 |
|
kmlussier joined #evergreen |
| 09:23 |
csharp |
hmm, some of our catalogers are getting mixed secure/insecure content warnings inside the staff client this morning |
| 09:23 |
csharp |
still sketchy on details, but I didn't know the staff client did that ;-) |
| 09:26 |
tsbere |
csharp: Do you load added content such as Syndetics, or perhaps Novelist, into your catalog in the staff client? If the answer is yes I blame the third party getups. |
| 09:28 |
|
dluch joined #evergreen |
| 09:28 |
tsbere |
jeff: If you still want use case and/or reasons for that code I have them |
| 09:28 |
jl- |
the staff client is not letting me delete the example branches (org units) |
| 09:28 |
jeff |
tsbere: hit me! |
| 09:29 |
tsbere |
jeff: The first part, checking hold_copy_map, allows for a more accurate representation of "this copy could fill the hold", for example parts or issuances. The second part that says "only do that check" allows us to avoid non-holdable copies filling holds, for example. |
| 09:30 |
|
mllewellyn joined #evergreen |
| 09:30 |
jl- |
I guess I can make them invisible |
| 09:30 |
tsbere |
jeff: The original issue was "these non-holdable three-day copies of new materials are causing the holds for the three week items to vanish" |
| 09:30 |
jl- |
anyway, the real question is: can Org Type "System" have volumes/copies? |
| 09:30 |
tsbere |
jl-: You probably have to wipe out the addresses at a minimum |
| 09:31 |
tsbere |
jl-: And if you want it to go tell it that it can. ;) |
| 09:31 |
jl- |
tsbere: ah, so all I need is a Consortium > Library1, Library2 -- do I make the Libraries "Systems" to be able to hold copies? |
| 09:31 |
jl- |
there won't be any sub libraries |
| 09:32 |
tsbere |
jl-: If you look at the org unit types you can see most of what you likely need there for options |
| 09:32 |
tsbere |
jl-: Including the ability to re-name things if you want |
| 09:33 |
jeff |
tsbere: thanks. understood the first part (nice improvement!), wasn't clear on scenarios where the second part was valuable. |
| 09:34 |
|
yboston joined #evergreen |
| 09:34 |
jeff |
tsbere: in our case, the non-holdable and the holdable copies both check out for the same time, so we want the holds fulfilled. :-) |
| 09:34 |
jeff |
(just another case of "isn't useful to this situation doesn't mean it isn't useful to others" -- and i wanted to understand what the use to others was) |
| 09:35 |
jl- |
tsbere: found it thx |
| 09:35 |
tsbere |
jeff: I seem to recall a bad interaction with parts too. "The part copy is on the same bib as the title hold, so lets wipe out the title hold..." |
| 09:35 |
jl- |
according to the unit types, the library must be a branch |
| 09:35 |
jl- |
to have copies |
| 09:36 |
|
mrpeters joined #evergreen |
| 09:36 |
tsbere |
jl-: Note that you can edit those types to change that. :P |
| 09:39 |
jeff |
tsbere: yeah... i can see that being a potential issue. i wonder if there are other situations similar to age hold protection (which isn't an issue in this scenario) where ahcm contains otherwise-unsuitable items that are eliminated at attempted capture time. |
| 09:40 |
jl- |
any insight on cache warming? how long does it take and is there anything I can do to speed it up? it seems like searching is very slow after an import |
| 09:40 |
jeff |
i can almost see a future need for ahcm to be "copies that (at least at time of targeting) can actually fill a hold" and some new map containing "copies that are considered equivalent for this hold, but might be unholdable" |
| 09:41 |
tsbere |
jeff: The main issue is "Copy, Location, or Status said no, so they weren't included in ahcm" - If the hold matrix rejects it otherwise the code may still fire. |
| 09:41 |
jeff |
where the new map could be used for things like Checkout Fills Related Hold, and ahcm would benefit from a performance boost when it comes to op-capture and some age hold protection (especially with things like FIFO holds) scenarios. |
| 09:42 |
jeff |
yeah, i have to look at current ahcm logic again before going much further down this trail of thoughts. |
| 09:44 |
tsbere |
jeff: One option could be "run the capture-time hold targeter checks for the copy and hold(s) and see if any return holdable" - Would still be based on a listing in ahcm, but would allow for skipping of truely unholdable items....or we could add an option to the hold matrix. "If this flag is true don't let this copy fill related holds" |
| 09:47 |
jeff |
yeah, i was thinking the opposite -- but like the flag/bool idea in ahcm... it would change the logic to "if it's in ahcm, it is (at time of targeting) considered suitable to fill a related hold", and "if it ALSO has the bool FOO, it (at time of targeting) can actually fill the hold" |
| 09:48 |
jeff |
so an age protected copy at a library where there are 94 other holds on that title wouldn't do permit checks on all 94 holds (and be denied due to age hold protection) every time it checks in |
| 09:48 |
tsbere |
jeff: The catch being we don't run the indb (or really any) checks on every copy before it goes into ahcm. |
| 09:48 |
tsbere |
Just the copies we consider for pull list |
| 09:49 |
jeff |
tsbere: yeah, but i'm wondering if it might not make sense to do those (or maybe some of those) checks at ahcm-time. |
| 09:49 |
jeff |
the case i just described is a little pathological, but i think that there's room for checkin-time performance improvements by pulling on this thread a little bit. |
| 09:52 |
|
kmlussier joined #evergreen |
| 09:56 |
jeff |
since things change over time, the bool that indicates if the copy is suitable for op-capture would serve to eliminate from consideration unsuitable (at time of targeting) copies, and any candidate copy would be run through the usual checks at the moment of attempted capture, not trust the (hours old) ahcm claim of suitability. |
| 09:57 |
jeff |
and copies that were unsuitable for op-capture at time of ahcm generation would be skipped, in some cases inappropriately, if their circumstances had changed in a way that did not result in ahcm being updated or the hold being retargeted. |
| 09:57 |
jeff |
but i think that's acceptable, and not much (if any) different from now. |
| 09:58 |
jeff |
but overall I think that it does mean that the hold targeter could/would take longer to run. |
| 09:59 |
tsbere |
jeff: In many cases orders of magnitude longer to run. <_< |
| 10:03 |
|
denishpatel joined #evergreen |
| 10:05 |
jeff |
for the "speed up checkin" goal then, i suspect it might be better to identify things like age hold protection and target optimizations for those scenarios. |
| 10:09 |
jl- |
berick: ping |
| 10:10 |
|
pmurray_away joined #evergreen |
| 10:12 |
|
pmurray joined #evergreen |
| 10:13 |
jl- |
nvm berick, I ran your create_holding.py but only had set one org unit "2" but it expects at least 2 so I set 2 twice |
| 10:14 |
berick |
jl-: org_ids=(2) doesn't work? |
| 10:14 |
jl- |
no |
| 10:15 |
jl- |
but (2, 2) worked berick |
| 10:16 |
berick |
huh, odd |
| 10:17 |
jl- |
it said something about len int |
| 10:19 |
berick |
crazy, i guess python turns a single-item tuple into a bare single item.. |
| 10:19 |
berick |
org_ids=[2] would probably do it |
| 10:20 |
jl- |
2, 2 seemed to generate the desired sql |
| 10:20 |
jl- |
interesting tho |
| 10:20 |
berick |
yeah, that'll work too |
| 10:21 |
csharp |
tsbere: thanks for the hint - it was NoveList Select over http rather than https |
| 10:22 |
tsbere |
csharp: We run into that fairly often when people pop open the added content tab with Syndetics. >_> |
| 10:29 |
|
tspindler joined #evergreen |
| 10:37 |
pastebot |
"mrpeters" at 64.57.241.14 pasted "New vhost in eg.conf, still not seeing right custom templates" (10 lines) at http://paste.evergreen-ils.org/21 |
| 10:38 |
mrpeters |
^^ got the custom hostname we were hoping for, configured the new vhost and put the customized .tt2 files in the templates_custom directory but only see them if i uncomment the 2nd entry in eg_vhost.conf for the template directories...problem is, then we ONLY see those templates on both hostnames... |
| 10:38 |
mrpeters |
what am i mixing up? i also tried reversing the order of the template locations in eg_vhost.conf to no avail. |
| 10:39 |
tsbere |
mrpeters: Where are you when you look at the templates? Opac? Staff Client? |
| 10:40 |
mrpeters |
Firefox, hitting the secondary hostname |
| 10:40 |
tsbere |
http or https? |
| 10:40 |
jeff |
mrpeters: try something like this in your Location block in the new virtualhost declaration? |
| 10:40 |
jeff |
PerlSetVar OILSWebTemplatePath "/openils/var/templates" |
| 10:40 |
jeff |
PerlAddVar OILSWebTemplatePath "/openils/var/templates_custom" |
| 10:40 |
|
gsams joined #evergreen |
| 10:40 |
jeff |
and yes, http vs https would be a major consideration, since that VirtualHost block is defining only port 80. |
| 10:41 |
|
Dyrcona joined #evergreen |
| 10:41 |
mrpeters |
yeah, i was wondering about https too...its http since it's just the "mainlogo.tt2" that is customized |
| 10:41 |
jeff |
if it works on http but not https, disregard my suggestion for pairing PerlSetVar with PerlAddVar |
| 10:41 |
mrpeters |
it doesnt work on http |
| 10:41 |
jl- |
berick: the only critical part I changed was I added 'WHERE id <= 287904' when selecting from biblio.record_entry to guarantee only selecting bibs from university a) and assigning to that org unit http://paste.debian.net/hidden/9d277334/ -- do I need to also add a ceiling to for i in range(num_copies)? I will run the script later for a different org unit with >= 287905 |
| 10:41 |
|
Dyrcona left #evergreen |
| 10:41 |
yboston |
jeff & jboyer-isl : just pushed to working a slightly edited copy of the Stripe release notes info, that I plan to commit to the main docs. let me know if I you have any suggestions for me, and note that the release notes information will be left where it is http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=25ab425af44bd09a979b8d549e12398ff9c4499a |
| 10:42 |
mrpeters |
same deal with the PerlSetVar loaded |
| 10:42 |
mrpeters |
though, should i uncomment templates_custom from eg_vhost now? |
| 10:43 |
tsbere |
mrpeters: Just a thought, are you certain you are getting the correct vhost? Is your other directive matching instead of this one? (you could add your Location block from the one you pasted to the other one temporarily to test) |
| 10:43 |
mrpeters |
yeah let me throw up that section of the eg.conf |
| 10:44 |
pastebot |
"mrpeters" at 64.57.241.14 pasted "eg.conf" (22 lines) at http://paste.evergreen-ils.org/22 |
| 10:45 |
jboyer-isl |
yboston: Looks good to me, though I wonder about the point of including the bare setting names. Is that so direct-db users have an easier time setting them, or just because they were in the notes and were left? |
| 10:45 |
jboyer-isl |
Since they don't appear anywhere in the Lib Settings Editor, including them in the notes may confuse readers. |
| 10:46 |
jboyer-isl |
Docs, not notes. |
| 10:46 |
yboston |
jboyer-isl: I left them there because they were "there" and was being conservative |
| 10:47 |
yboston |
jboyer-isl: and I knew I would get good feeback from you or jeff, therefore I can take them out of the main docs, but keep them in the release notes |
| 10:47 |
mrpeters |
so, if i come in on that first hostname -- i get the TPAC that we want to see |
| 10:47 |
mrpeters |
if i come in on the second vhostname, still see the same tpac -- unless I uncomment the templates_custom directive in eg_vhost.conf |
| 10:47 |
mrpeters |
but, then that becomes the template everywhere |
| 10:48 |
mrpeters |
tried flipflopping so it would load the "public" one first, and the internal one second but i still always get whatever the 2nd directive is in eg_vhost.conf |
| 10:48 |
jboyer-isl |
yboston: Yeah, I suspect the people who would make the most use of the raw setting names would read the notes vs. the docs normally. |
| 10:48 |
tsbere |
mrpeters: Removing the PerlSetVar directive from what you pasted, what happens if you move the <Location /eg> block to the upper virtualhost block? |
| 10:48 |
* mrpeters |
must be making this way too hard |
| 10:48 |
pastebot |
"berick" at 64.57.241.14 pasted "for jl-" (6 lines) at http://paste.evergreen-ils.org/23 |
| 10:48 |
berick |
jl-: yes, you'll need to limit which callnumbers the new copies can be linked to. |
| 10:49 |
berick |
by limiting the call numbers to those owned by the requested org units |
| 10:49 |
berick |
that paste is untested |
| 10:49 |
yboston |
jboyer-isl: this is excelent feedback, good expereince for me/DIG moving forward with copying content fromt he release ntoes to the main docs |
| 10:49 |
berick |
not sure if the syntax will be correct |
| 10:49 |
berick |
but you get the idea |
| 10:49 |
mrpeters |
tsbere: good things...i get the proper internal TPAC |
| 10:49 |
yboston |
jboyer-isl: I will make the change |
| 10:49 |
mrpeters |
but, i get the internal pac on the public pac now too |
| 10:50 |
tsbere |
mrpeters: They are thus using the same vhost entry, something is wrong with the vhost selection |
| 10:50 |
jl- |
berick: I don't have any call numbers |
| 10:51 |
berick |
jl-: the script creates call numbers |
| 10:51 |
mrpeters |
anyone have a highly customized eg.conf they'd be willing to share? |
| 10:52 |
jboyer-isl |
mrpeters: you need to move the ServerName into the VirtualHost directive. They currently both match "Everything on port 80" and just one of them is being used no matter what hostname your browser is using. |
| 10:52 |
tsbere |
mrpeters: MVLC has highly customized....but not in a way that will help you. >_> |
| 10:52 |
mrpeters |
hmm, ServerName is there no? |
| 10:52 |
mrpeters |
oh, damn it i see what you mean now |
| 10:52 |
jboyer-isl |
I'm referring to the <VirtualHost *:80> directives, the * is what is causing this pain. |
| 10:52 |
mrpeters |
yes yes yes, darn it |
| 10:53 |
jboyer-isl |
And you'll want to add an https version anyway in case someone logs in on that hostname, or your customizations will disappear after login. |
| 10:54 |
mrpeters |
yeah, i actually think we may be OK with the http only because of the fact that these are "locked down" OPAC machiens that can only hit http://anytown.lib.st.us |
| 10:54 |
mrpeters |
thus why we wanted to remove the external database links |
| 10:55 |
jboyer-isl |
I see. That's probably not a bad idea. |
| 11:01 |
|
kmlussier1 joined #evergreen |
| 11:02 |
|
jwoodard joined #evergreen |
| 11:11 |
tsbere |
jboyer-isl / mrpeters : I will point out that I have a lot of *:80 entries on various servers that select properly based on ServerName and ServerAlias directives. >_> |
| 11:11 |
mrpeters |
i created a second eg.conf called eg_local.conf and took out the default vhost and plugged in my custom one and its working |
| 11:12 |
mrpeters |
damn, no its not after refresh of the public hostname |
| 11:12 |
* tsbere |
also, however, uses ServerName entries *without* the :80 on them..... |
| 11:12 |
tsbere |
mrpeters: Perhaps remove the :80 from your ServerName directives and see if that helps? |
| 11:13 |
mrpeters |
worth a shot! |
| 11:14 |
mrpeters |
oh hey it helps if you don't mistype the city name ;P |
| 11:14 |
mrpeters |
in ServerName |
| 11:14 |
yboston |
I have a git question. I have two documentation commits on the working repo that I want to move to the main repo's master branch. (I already have permission to make commits to the docs dir) |
| 11:14 |
yboston |
I not sure what the preffered way to do this is, but I think I should be using a workflow similar to when I backport documentation commits to older release branches. I plan to... |
| 11:15 |
yboston |
1) git fetch --all and merge in any missing changes from origin/master into to my (main repo) master branch 2) I will cherry pick the two commits from my working branch |
| 11:15 |
yboston |
3) push changes back into origin/master is this correct? |
| 11:15 |
mrpeters |
bah, same deal without the :80 in ServerName as well |
| 11:15 |
mrpeters |
always loads the templates_custom |
| 11:16 |
tsbere |
mrpeters: If the requested hostname matches nothing it will grab either the first or last matching virtualhost. I can't recall which. >_> |
| 11:17 |
tsbere |
yboston: Looks correct at a quick glance (you may want to change step 1 to just "git pull" or "git pull origin/master" with the master branch checked out, though) |
| 11:18 |
mrpeters |
yeah -- i think that may be the problem tsbere -- i dont think the original configuration of this server was done right: |
| 11:18 |
mrpeters |
* Reloading web server config apache2 apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1 for ServerName |
| 11:18 |
mrpeters |
[Wed Apr 30 10:18:17 2014] [warn] NameVirtualHost *:80 has no VirtualHosts |
| 11:20 |
jboyer-isl |
tsbere: Thanks for the clarification on VirtualHost *:80, I've not actually done much with vhosts, so it seemed to make the most sense to me at the time. It's obviously something else. |
| 11:20 |
yboston |
tsbere: thanks. BTW, I have been using git fetch then merge to get more info on recent changes to both repositories inteas of the simpler git pull |
| 11:20 |
tsbere |
mrpeters: The "has no VirtualHosts" would imply you have "NameVirtualHost *:80" multiple times, or you stopped using *:80 |
| 11:21 |
yboston |
s/inteas/instead/ |
| 11:21 |
mrpeters |
ports.conf has it, and then eg.conf but its commented out |
| 11:21 |
tsbere |
mrpeters: As for the fully qualified hostname thing, I get that frequently, but have never had issues with virtualhosts when seeing it....which virtualhost is used should depend on what the client sends. |
| 11:22 |
tsbere |
yboston: git log origin/master..otherbranch ;) |
| 11:22 |
mrpeters |
and i think its stock to have it commented out in eg.conf |
| 11:22 |
tsbere |
mrpeters: I am just throwing out what I do know. I do not claim to be an expert, in general or on your install. |
| 11:23 |
tsbere |
mrpeters: Another thought: Do you have a proxy anything in the mix? It may be changing or removing the hostname from the client request. >_> |
| 11:23 |
yboston |
tsbere: you are right, thanks again |
| 11:24 |
mrpeters |
tsbere: its totally possible...we don't get to touch any of the DNS side of things, i doubt they have a proxy going to this server but it is plausible |
| 11:24 |
tsbere |
yboston: I will actually git fetch --all and then git pull, but that is mainly because pull is easier to type than the equiv merge command. >_> |
| 11:24 |
mrpeters |
no proxy on my end, though |
| 11:24 |
mrpeters |
no worries about not being an expert, the help is appreciated |
| 11:24 |
mrpeters |
i haven't had this sort of issue using vhosts before, and we do it all the time |
| 11:24 |
mrpeters |
its really strange |
| 11:25 |
mrpeters |
what boggled me was when i put the "internal" hostname in its own conf file, the eg.conf still saw the customized templates |
| 11:26 |
|
kmlussier joined #evergreen |
| 11:26 |
tsbere |
mrpeters: How about this: Does the IP you get when you look the domains up match the IP the server thinks it has? |
| 11:27 |
yboston |
tsbere: I am still doing the git rookie penance of "don't use git pull until you are really clear what it does, until then use git fetch, git merge" and I like seeing the list of all the changes to the working repo when I do git fetch --all |
| 11:27 |
mrpeters |
yeah, they both resolve to the Evergreen server |
| 11:27 |
jeff |
i would amend that to "don't use git pull" |
| 11:27 |
* jeff |
is in the habit of using git fetch combined with git merge --ff-only |
| 11:28 |
* jcamins |
uses git pull only on one-person projects. |
| 11:28 |
|
kmlussier joined #evergreen |
| 11:28 |
* jeff |
nods |
| 11:28 |
yboston |
I could have used git merge --ff the other day, but isntead before I knew it I had done a non ff-merge on a topic branch :( |
| 11:29 |
|
ericar joined #evergreen |
| 11:29 |
jeff |
yboston: yeah. by breaking yourself of the "git pull" habit and starting to use --ff-only (or making yourself a shell or a git alias for all of that), you avoid some of that. |
| 11:30 |
jcamins |
In Koha development there's a lot of rebasing. |
| 11:30 |
jcamins |
(FWIW, if you want to see a slightly different model) |
| 11:30 |
jeff |
better IMO to have "sorry, can't do that" than "sorry, can't do that, but i tried, and now it's a mess, and could you please sort this out for me and let me know when it's fixed?" :-) |
| 11:31 |
yboston |
jeff: I think I found my newest git allias |
| 11:31 |
* dbs |
finds it easy enough to create a new branch and cherry-pick cautiously if "git pull" fails |
| 11:31 |
dbs |
yboston / Dyrcona: https://listserv.nd.edu/cgi-bin/wa?A2=ind1404&L=CODE4LIB&F=&S=&P=227426 (OCLC guy Roy Stewart says "Go ahead and redistribute OCLC records at will) |
| 11:32 |
* dbs |
also doesn't mind rebasing at all |
| 11:33 |
* tsbere |
uses git pull on his local "clean" branches, he uses git fetch --all && git rebase on "dev" branches |
| 11:34 |
|
Christineb joined #evergreen |
| 11:35 |
|
ericar joined #evergreen |
| 11:35 |
* jeff |
is a fan of rebasing |
| 11:35 |
yboston |
thanks for sharing your approaches |
| 11:36 |
jeff |
part of the decision on what approach I use is driven by the project i'm working on. |
| 11:36 |
jeff |
(as others have said) |
| 11:36 |
yboston |
dbs: thanks for sharing about OCLC, will do mi git stuff first then study your links carefully |
| 11:40 |
|
geoffsams joined #evergreen |
| 11:44 |
|
kmlussier1 joined #evergreen |
| 11:45 |
yboston |
another git question…my two working commits have my sign off already, I suspect I may not want to use the "-s" flag on the git cherry-pick command so a second sign-off for myself is added? |
| 11:46 |
tsbere |
yboston: If your sign-off is already there feel free to skip the -s, yes |
| 11:47 |
tsbere |
sometimes git will say "oh, that is already there".....but not often enough in my opinion. >_> |
| 11:47 |
|
kmlussier joined #evergreen |
| 11:48 |
|
ericar joined #evergreen |
| 11:49 |
yboston |
tsbere: thanks |
| 11:53 |
jl- |
berick: can I query you for a sec |
| 11:53 |
pinesol_green |
[evergreen|Yamil Suarez] Documentation: Copied Stripe payment info into 'Library Settings Editor' - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=09fbc00> |
| 11:53 |
pinesol_green |
[evergreen|Yamil Suarez] Documentation: Removed bare setting names from Stripe payment doc - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e7957e6> |
| 11:53 |
|
eby__ joined #evergreen |
| 12:02 |
|
ericar joined #evergreen |
| 12:09 |
pinesol_green |
[evergreen|Yamil Suarez] Documentation: added missing word to 'library settings editor' docs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=88b85a8> |
| 12:20 |
dbs |
yboston: err, Roy Tennant. I have no idea where I got Roy Stewart from. Yeesh. |
| 12:33 |
* mrpeters |
thinks im getting to the bottom of this vhosts deal --- /etc/apache2/ports.conf has a *:80 in it -- should that be commented out and the vhosts for each hostname in eg.conf allowed to do the job based on the hostname that was entered by the user? |
| 12:43 |
tsbere |
mrpeters: Vhosts don't care about hostnames. They care about IP addresses and ports....hostnames only come into play for namevirtualhost sets, those are then defined with ServerName and ServerAlias directives |
| 12:45 |
mrpeters |
the thing thats tripping me up is if change the default eg.conf from VirtualHost *:80 to VirtualHost hostname:80 i get /eg not found |
| 12:45 |
mrpeters |
ServerName hostname:80 as well |
| 12:45 |
tsbere |
mrpeters: Probably due to other issues. hostname may not resolve to anything properly useful in that situation |
| 12:46 |
mrpeters |
resolves to localhost, as it should |
| 12:46 |
tsbere |
mrpeters: Here is another question: How many files (links) exist in the sites-enabled folder? |
| 12:46 |
mrpeters |
just eg.conf |
| 12:46 |
tsbere |
mrpeters: In the <VirtualHost blah> block "resolves to localhost" is actually *bad*. "Resolves to the actual public IP" would be more tolerable....if you have a NameVirtualHost entry for the public IP. |
| 12:47 |
tsbere |
mrpeters: Note that is assuming it works at all, I am not sure it does properly |
| 12:47 |
tsbere |
better to stick with ip, *, or _default_ with appropriate port info |
| 12:48 |
|
ericar joined #evergreen |
| 12:48 |
tsbere |
Hmmm |
| 12:48 |
|
krvmga joined #evergreen |
| 12:48 |
tsbere |
mrpeters: What exactly are you trying to change in this situation again? Because individual vhosts and entire template directories for a single file seems like overkill to me. |
| 12:49 |
krvmga |
Take a look at this search, particularly noting the third return (show more details is on) http://bark.cwmars.org/eg/opac/results?query=finding%20nemo;qtype=keyword;locg=1;detail_record_view=1 |
| 12:49 |
mrpeters |
show a different "homesearch.tt2" if you come in on one hostname |
| 12:49 |
krvmga |
Notice that neither Amherst nor Greenfield appears in the list |
| 12:49 |
tsbere |
mrpeters: Add some login to homesearch.tt2 to look at the hostname it came in on? |
| 12:49 |
krvmga |
If you click on the item, you get this: http://bark.cwmars.org/eg/opac/record/3063181?query=finding%20nemo;qtype=keyword;locg=1;detail_record_view=1 |
| 12:50 |
krvmga |
amherst and greenfield are both listed. |
| 12:50 |
krvmga |
what i don't understand is why don't they appear in the initial search returns? |
| 12:51 |
mrpeters |
hmm, not sure that would accomplish what they want. right now that tt2 is customized to have links to all of their databases, etc. which aren't accessible INSIDE the library because the machines are restricted to the OPAC only |
| 12:51 |
mrpeters |
so people are getting angry when they try to use a database and cant when its locked down |
| 12:51 |
mrpeters |
but, we wouldnt want users to have to "log in" from home to see the databases listing |
| 12:52 |
tsbere |
krvmga: Because "show more details" view limits to a subset of copies and the full record shows many more? |
| 12:52 |
mrpeters |
since they already do that after clicking a database |
| 12:52 |
krvmga |
tsbere: but wouldn't the system want to show them in alphabetical order? |
| 12:52 |
bshum |
Five unique call numbers with a max of five copies. |
| 12:52 |
bshum |
So max of 25 |
| 12:53 |
tsbere |
mrpeters: .... [% IF ENV.SERVER_NAME != 'Some hostname' %]Stuff to hide if that hostname matches[% END %] maybe? (note: untested) |
| 12:53 |
krvmga |
tsbere: so amherst and greenfield should have appeared |
| 12:53 |
tsbere |
krvmga: I don't think the ordering is alphabetic at that point, at least for which ones to show. I could be wrong. |
| 12:53 |
mrpeters |
hmm hadn't thought of approaching it from the template toolkit side |
| 12:54 |
krvmga |
tsbere: i wonder, then, what governs the ordering? |
| 12:54 |
tsbere |
krvmga: The code, of course. ;) |
| 12:54 |
krvmga |
tsbere: :) |
| 12:55 |
krvmga |
tsbere: at first i thought "could it be the number of copies a library owns?" but libraries with one copy and libraries with multiple copies were showing up, so that wasn't it. |
| 12:57 |
krvmga |
tsbere: then i thought "could it be that libraries whose copies were checked out didn't show up?" (because amherst's and greenfield's copies were out) but chicopee's was checked out, too, and it showed up. so it wasn't that. |
| 12:59 |
krvmga |
tsbere: i think i've got it! EUREKA! it's sorting on call number as related to the search |
| 13:01 |
krvmga |
tsbere: so, for instance, Marlborough actually has three copies but the call numbers are J DVD FINDING and J DVD DISNEY. J DVD DISNEY does not show up in the show more details returns. |
| 13:01 |
tsbere |
krvmga: or it could just be a fluke. :P |
| 13:01 |
krvmga |
tsbere: or that. |
| 13:02 |
krvmga |
tsbere: i'll test it on some other searches and see what happens. |
| 13:08 |
mrpeters |
score....got it! |
| 13:09 |
|
RoganH joined #evergreen |
| 13:09 |
pastebot |
"mrpeters" at 64.57.241.14 pasted "working eg.conf with secondary vhost for custom templates" (22 lines) at http://paste.evergreen-ils.org/24 |
| 13:10 |
tsbere |
mrpeters: Was the issue the ServerName directives? I notice they are different. :P |
| 13:10 |
tsbere |
mrpeters: Also, you can probably ditch the ServerAlias 127.0.0.1 lines. :P |
| 13:11 |
krvmga |
as far as i know, there's no way to set the default display in search returns to be "Show More Details". Am i right? |
| 13:11 |
mrpeters |
yeah, those were holdovers from stock eg.conf |
| 13:11 |
mrpeters |
tsbere: it was -- i was putting the different domain names in the <VirtualHost :80> line |
| 13:11 |
tsbere |
krvmga: There are lots of ways. None of them as simple as "set this option" though. |
| 13:12 |
krvmga |
tsbere: that's what i thought. thanks. |
| 13:12 |
RoganH |
krvmga: I looked once and didn't find a way to do it without a lot of work. |
| 13:14 |
dbs |
krvmga: i seem to recall sorting results based on library preference and proximity of libraries to that preferred library |
| 13:14 |
krvmga |
RoganH: you create your own custom table.tt2 to override /openils/var/templates/opac/parts/result/table.tt2 |
| 13:15 |
dbs |
Funny, many sites make "show details" the default. Maybe we should just make it the default. A lot easier to hide stuff it templates than to show it :) |
| 13:15 |
tsbere |
krvmga/RoganH: Very (VERY) easy if you want to remove the no details mode....not really that much harder to reverse things, I wouldn't think. But not based on users and such. |
| 13:15 |
RoganH |
krvmga: yeah, that was more than I wanted to invest into it for a casual "can we do this" question from staff |
| 13:16 |
krvmga |
dbs: i agree |
| 13:16 |
RoganH |
dbs: I'd be fine with making it default. |
| 13:16 |
tsbere |
The issue I have is "(some) staff members want it on all the time, but patrons don't" |
| 13:16 |
jeff |
yeah, we force staff context to "show more details": https://github.com/tadl/Evergreen_templates_tadlskin/commit/fef3b7a183e2d2ba9090b89db66893625e9db061 |
| 13:16 |
|
jihpringle joined #evergreen |
| 13:16 |
RoganH |
It's one of those things we'd like but not one really is passionate about and so it kind of floats to the middle of the barrel in terms of projects. |
| 13:17 |
krvmga |
tsbere: yes, we have the same issue. some are "we love it" others are "the screen is cluttered!" |
| 13:17 |
RoganH |
not one = no one, my fingers seem to be adding letters |
| 13:17 |
tsbere |
For even *more* fun, the staff members that want it on by default want a user setting....and share the account with staff members that hate it. >_> |
| 13:18 |
krvmga |
tsbere: that extra complainy goodness... |
| 13:19 |
jeff |
stop sharing accounts. :P |
| 13:19 |
krvmga |
i'm still testing some examples of the search returns and they're not panning out consistently yet. |
| 13:20 |
tsbere |
jeff: I argued against it. I was outvoted. And for that matter, not really given a vote. |
| 13:20 |
dbs |
Hmm: artrhyno wrote 209edc8199677 a couple of years ago |
| 13:20 |
jeff |
i'm still interested in ideas like "require ssl client cert for any staff access" combined with "ssl client cert and maybe a role account gets you minimum access, but MOST things require you to log in with your individual staff credentials that are yours and yours alone" -- that's a mix of code and policy. |
| 13:20 |
jeff |
commit 209edc8199677 |
| 13:20 |
jeff |
? |
| 13:20 |
jeff |
maybe not. |
| 13:21 |
jeff |
http://git.evergreen-ils.org/?p=contrib/Conifer.git;a=commit;h=209edc8199677 |
| 13:21 |
dbs |
jeff++ |
| 13:21 |
jeff |
> TPAC: Make "Show more details" in results optional |
| 13:21 |
tsbere |
jeff: SSL certs can be fun....and highly annoying. Once we have a 100% browser based client (note: I doubt we will ever have one, the printing stub makes it no longer 100% browser based IMO) it would be easier. |
| 13:21 |
|
denishpatel joined #evergreen |
| 13:22 |
dbs |
jeff: maybe some combo of your commit and art's for goodness ? |
| 13:22 |
jeff |
yeah, i'm looking at that future when i make the "still interested in" statement above. :-) |
| 13:23 |
jeff |
dbs: yeah, i like the idea of a config option or two, especially since it's something people have interest in changing. |
| 13:24 |
|
gsams joined #evergreen |
| 13:25 |
jeff |
when we talk about default, having defaults perhaps be different for staff/patrons, and having staff/patrons be forced into one or the other... i start to wonder if it doesn't make sense to have a block of options that can be set with a context as well. |
| 13:26 |
jeff |
which is a poor way of saying, "having something that enables checks for "what is this setting" to consult the staff or patron config option by that name if one is set as an override of sorts" |
| 13:26 |
tsbere |
The fact that some people customize the option into oblivion (usually implementing a middle ground level of details) makes it harder to add a user or workstation level default. Teaching the system to remember the value in a cookie could be nice, though... |
| 13:26 |
dbs |
The settings system needs a settings system |
| 13:27 |
|
hbrennan joined #evergreen |
| 13:27 |
jeff |
but when thinking about different contexts (i.e. user/workstation/org defaults/settings/overrides), i start to wander into "which one overrides all" territory. :P |
| 13:28 |
dbs |
The user's greasemonkey script |
| 13:32 |
|
gsams joined #evergreen |
| 13:36 |
jeff |
reminding us that "override" and "force" do not always mean what we think they mean. :-) |
| 13:41 |
csharp |
@override |
| 13:41 |
pinesol_green |
csharp: http://wonder-tonic.com/geocitiesizer/content.php?theme=2&music=6&url=evergreen-ils.org |
| 13:41 |
csharp |
@force |
| 13:41 |
pinesol_green |
csharp: MARC still isn't dead yet, alas |
| 13:41 |
csharp |
@librarian |
| 13:41 |
pinesol_green |
csharp: Management:10, Cataloging:14, Acquisitions:14, Reference:10, Circulation:14, Systems:11, Research:11, Custodial:9 |
| 13:43 |
|
kmlussier joined #evergreen |
| 13:45 |
kmlussier |
krvmga: I haven't entirely read through the responses to your question, but I suspect part of what you're seeing is due to the fact that C/W MARS uses a custom org tree. |
| 13:48 |
krvmga |
kmlussier: i'll investigate that |
| 13:49 |
krvmga |
kmlussier: thx |
| 13:49 |
kmlussier |
krvmga: So you use your custom org tree to sort all of your ou's alphabetically. However, if what dbs says is true (the results sort by preferred library then proximity), then those libraries you aren't seeing are probably further away in the real org tree. |
| 13:49 |
kmlussier |
IOW, they're in another region? |
| 13:50 |
dbs |
fwiw, that is a very distant memory of mine, that just might happen to be true |
| 13:51 |
krvmga |
kmlussier: what dbs said would make sense if the searcher was logged in and had a preferred library set. the issue was appearing, though, in the opac without being logged in. |
| 13:51 |
kmlussier |
dbs: It matches my memory. |
| 13:51 |
kmlussier |
krvmga: Sure, in that case then, you wouldn't get the preferred library, but the sorting would reflect what you have in your org tree. |
| 13:53 |
kmlussier |
I'm fairly sure the custom org tree that is you use to control your library selector does not carry over on to your search results page. |
| 13:53 |
krvmga |
kmlussier: i don't think that explanation works because amherst and chicopee are both in the "western" org tree so i don't see why amherst wouldn't appear in the initial results but chicopee would. |
| 13:54 |
kmlussier |
krvmga: OK, I stand corrected then. |
| 13:55 |
* kmlussier |
runs off to a meeting. |
| 13:55 |
|
kmlussier left #evergreen |
| 13:58 |
dbs |
krvmga: part of the sorting algorithm also depends on availability |
| 13:58 |
dbs |
In this case, it looks like "Lost" is being considered equivalent to "Available" for some reason |
| 13:59 |
dbs |
Whereas libraries that have all "Checked out" copies get hidden, because they don't have anything immediately available to the user. |
| 14:02 |
krvmga |
dbs: that's where i went to start with. except it broke down when i saw that the second chicopee copy was "Checked Out" |
| 14:03 |
tsbere |
krvmga: Ahh, but it possibly gets pulled in due to the first chicopee copy not being checked out and there not being other chicopee copies to show? |
| 14:05 |
dbs |
tsbere: exactly |
| 14:05 |
* dbs |
is now tempted to actually *look at the code* |
| 14:06 |
|
gsams joined #evergreen |
| 14:09 |
krvmga |
tsbere: if i understand correctly, dbs was saying that "Lost" was being treated like "Available" (which i would think was a bug but that's neither here nor there) |
| 14:10 |
tsbere |
krvmga: That may be a case of the code assuming that only certain values are opac visible to begin with. |
| 14:10 |
krvmga |
tsbere: but it does match the data because Marlborough has three copies, one checked out, one lost, and one available. the checked out one does not show. |
| 14:10 |
|
RoganH left #evergreen |
| 14:11 |
krvmga |
which, if "lost"="available" would mean that the system was displaying the two available copies |
| 14:12 |
krvmga |
so the question becomes how do i fix it so that the system does not equate "lost" and "available"? |
| 14:13 |
* dbs |
has had enough and is *looking at the code* |
| 14:13 |
dbs |
Open-ILS/src/sql/990.schema.unapi.sql has the ranking functions |
| 14:14 |
dbs |
http://pastebin.com/AiYvEfqa for convenience |
| 14:15 |
dbs |
copy status ranking is based on opac_visible, copy_active, and not being checked out - so if your "Lost" is opac_visible and copy_active in config.copy_status, then that's much more valuable than "Checked out" |
| 14:17 |
krvmga |
dbs: yes, i see it clearly. |
| 14:17 |
krvmga |
dbs++ |
| 14:17 |
dbs |
"Lost" is not opac_visible or copy_active by default (based on 002.schema.config.sql and 950.data.seed-values.sql) |
| 14:17 |
dbs |
so my suspicion is that your Lost is not the default :) |
| 14:17 |
krvmga |
dbs: i immediately twigged to that. |
| 14:18 |
bshum |
Yeah, we showed lost and missing for a time. And then we hid them after a few years of suffering (which I foretold) |
| 14:19 |
* tsbere |
wonders if a rank and/or show in details view flag would be a good idea for copy statuses.... |
| 14:19 |
dbs |
uhh, like a "really_really_opac_visible" ? |
| 14:20 |
jeff |
kinda_opac_visible BOOL NOT NULL DEFAULT TRUE |
| 14:20 |
krvmga |
a for_sure_no_kidding_opac_visible |
| 14:20 |
tsbere |
dbs: Well, in this case I wouldn't want to hide it from the record, just something to indicate priority on the search results details list... |
| 14:20 |
jeff |
kinda_opac_visible BOOLISH NOT NULL DEFAULT MAYBE |
| 14:23 |
krvmga |
me takes his eg toys and goes off to play in his own backyard for a while. |
| 14:23 |
krvmga |
obviously i haven't had lunch yet if i forget the / |
| 14:24 |
krvmga |
and the bartender says "why the long face?" oh, wait, did i forget to tell you that it was a horse? |
| 14:25 |
krvmga |
wrecking jokes since 1987. |
| 14:25 |
krvmga |
thanks everyone for pitching in. |
| 14:25 |
krvmga |
tsbere++ |
| 14:26 |
krvmga |
dbs++ |
| 14:26 |
krvmga |
jeff++ |
| 14:26 |
krvmga |
kmlussier++ |
| 14:28 |
|
jcamins_ joined #evergreen |
| 14:40 |
jl- |
berick are you there |
| 14:52 |
|
kmlussier joined #evergreen |
| 15:06 |
|
bmills joined #evergreen |
| 15:46 |
mrpeters |
anyone have a magic spell (would be handy for the magic spells page :P) to do a mass update of MARC records to add a 856$9 to a list of bib ID's? |
| 15:51 |
|
geoffsams joined #evergreen |
| 15:53 |
mrpeters |
perhaps a variation of UPDATE biblio.record_entry SET marc = regexp_replace(marc,E'<datafield[^>]*?tag="059".+?</datafield>','','g'); will do the trick |
| 15:53 |
eeevil |
mrpeters: something like: regexp_replace(marc,'(datafield tag="856"[^>}+>.+?)(<\/datafield>)','\1<subfield code="9">BLAH</subfield>\2') |
| 15:54 |
mrpeters |
eeevil++ was on the right track :) |
| 15:55 |
eeevil |
aye. the regex will probably need to be more specific, though |
| 15:55 |
mrpeters |
yeah, this helps confirm that a regexp replace was the way to go though. appreciated. |
| 15:58 |
* jeff |
mumbles something about http://stackoverflow.com/a/1732454/157515 |
| 15:59 |
jeff |
but in all seriousness, i think i'll poke at a helper function for that kind of 856 batch update. i think that dkyle had some 856-merging tools a while back for operating on vandelay queues. |
| 16:00 |
|
vlewis joined #evergreen |
| 16:01 |
mrpeters |
i think these may be pretty painless...all seem to have the format of: |
| 16:01 |
mrpeters |
<datafield tag="856" ind1="4" ind2="2"><subfield code="u">http://www.foo.com</subfield></datafield> |
| 16:02 |
mrpeters |
they just lack the $9 so they dont display without a trancendent bib source |
| 16:03 |
tsbere |
mrpeters: How many of them have more than one 856? |
| 16:03 |
mrpeters |
hm not sure |
| 16:03 |
mrpeters |
a good question though |
| 16:03 |
jeff |
ind2 needs to be 0 or 1 for located uris to work, at least according to docs. i haven't checked that against current code before making this statement. |
| 16:04 |
mrpeters |
jeff: thats good to know |
| 16:04 |
mrpeters |
geoffsams: did you know about that one? |
| 16:04 |
jeff |
ind2 indicates that the item is a "related resource" |
| 16:05 |
jeff |
as opposed to 0 "resource" or 1 "version of resource" |
| 16:05 |
dbs |
ind2=2 is often "table of contents" or "author notes" |
| 16:05 |
dbs |
aka "nothing a user ever wants to see" |
| 16:05 |
jeff |
the classic loc.gov 856 tags in many records. |
| 16:05 |
mrpeters |
some of them are 0 and 1, but some are 2 |
| 16:06 |
dbs |
(at least, not when they're expecting the actual electronic version of the resource) |
| 16:06 |
* jeff |
nods |
| 16:13 |
|
gsams joined #evergreen |
| 16:22 |
mrpeters |
oh hey, this looks nice! http://biblio.laurentian.ca/tickets/conifer/wiki/cataloguingAdding856 |
| 16:34 |
|
tspindler left #evergreen |
| 16:35 |
mrpeters |
does the placement of $9 have to be at the end, or can it be before the alpha subfields? |
| 16:35 |
* mrpeters |
doesnt want to go to library school :P |
| 16:35 |
hbrennan |
haha |
| 16:36 |
* kmlussier |
went to library school and doesn't know the answer to that question. |
| 16:38 |
dbs |
mrpeters: it can be anywhere, but normally is at the end |
| 16:41 |
|
mtcarlson_away joined #evergreen |
| 17:09 |
bmills |
hello. has anyone found a way to uncover what hold matrix matchpoint id was used in a specific hold request? or if that is possible to find out? i'm looking to test and see what policies are being used when certain users are making hold requests |
| 17:18 |
|
RBecker joined #evergreen |
| 17:18 |
gsams |
mrpeters: our cataloging committee should be aware of that, and should be working that direction. We did have a bad start entering records without the URI information at first, but new ones coming in should be setup properly according to the documentation for 2.3(currently) |
| 17:30 |
|
mmorgan left #evergreen |
| 17:35 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:38 |
|
geoffsams joined #evergreen |
| 18:05 |
|
gsams joined #evergreen |
| 18:32 |
|
gsams joined #evergreen |
| 18:57 |
|
ktomita joined #evergreen |
| 19:19 |
|
gsams joined #evergreen |
| 19:49 |
|
jbfink joined #evergreen |
| 20:06 |
|
gsams joined #evergreen |
| 20:57 |
|
geoffsams joined #evergreen |
| 21:34 |
bshum |
@later tell kmlussier Take a look at your laters, I left you some more notes. |
| 21:34 |
pinesol_green |
bshum: The operation succeeded. |
| 21:51 |
|
shadowspar joined #evergreen |
| 21:51 |
|
gsams joined #evergreen |
| 23:43 |
|
eby__ joined #evergreen |
