Time |
Nick |
Message |
00:58 |
|
wongon joined #evergreen |
06:14 |
|
Newziky joined #evergreen |
06:18 |
|
BigRig joined #evergreen |
06:23 |
|
RBecker joined #evergreen |
06:26 |
|
devi_ joined #evergreen |
06:27 |
devi_ |
hello |
06:27 |
devi_ |
I have, barcode, cat, cn, marc - csv format files to import to Evergreen |
06:27 |
devi_ |
how? |
06:38 |
|
tsbere_ joined #evergreen |
06:39 |
|
TaraC_ joined #evergreen |
06:39 |
|
pinesol_green` joined #evergreen |
06:45 |
|
mtj_ joined #evergreen |
07:37 |
|
mrpeters joined #evergreen |
07:51 |
|
graced joined #evergreen |
08:05 |
|
jboyer-isl joined #evergreen |
08:15 |
|
rjackson_isl joined #evergreen |
08:17 |
|
ericar joined #evergreen |
08:36 |
|
dcook joined #evergreen |
08:42 |
|
RoganH joined #evergreen |
08:51 |
|
mmorgan joined #evergreen |
08:55 |
|
Dyrcona joined #evergreen |
08:57 |
|
Shae joined #evergreen |
09:02 |
|
mmorgan joined #evergreen |
09:03 |
dbs |
Dyrcona++ # sorry I couldn't make the RM election meeting |
09:32 |
kmlussier |
devi_: Did you try following the instructions at the link we sent you last week? http://docs.evergreen-ils.org/2.8/_migrating_from_a_legacy_system.html |
09:39 |
kmlussier |
http://docs.evergreen-ils.org/2.8/_migrating_from_a_legacy_system.html |
09:41 |
|
sarabee joined #evergreen |
09:42 |
bshum |
devi_: Out of curiosity, what legacy system are you attempting to migrate from? |
09:43 |
devi_ |
omg....there is no word about CSV files..... |
09:43 |
kmlussier |
devi_: You can't migrate CSV files. They have to be MARC files. |
09:44 |
Dyrcona |
kmlussier: I've done migrations where patron data and transactions were in CSV. Bib records work best in MARC. |
09:44 |
bshum |
jeff++ # yeah, that's applicable for VMs in certain hosted environments, right? Like Amazon cloud? |
09:44 |
Dyrcona |
Granted, I write my own software each time to load the data. |
09:45 |
Dyrcona |
Which reminds me.....I owe someone some questions about a migration. |
09:45 |
kmlussier |
OK, sorry, I was focusing on the bib data. |
09:45 |
devi_ |
documentation sucks |
09:45 |
devi_ |
:-( |
09:46 |
Dyrcona |
The migration documentation is lacking, 'cause there are way too many variables. |
09:46 |
devi_ |
but everything goes to console and crappy perls sripts :-) |
09:47 |
Dyrcona |
That's how it usually works with large database applications, not just ILS. |
09:51 |
bshum |
devi_: Frustrating as it might initially appear, I might appreciate it more if you'd be a little considerate of others in this community of volunteers who participated in the creation of the docs and scripts. |
09:52 |
bshum |
We do try to help out where best we can. |
09:52 |
devi_ |
ტჰანკ ყოუ |
09:52 |
devi_ |
thank you |
09:52 |
devi_ |
bye |
09:52 |
bshum |
And there are actual support companies who do provide Evergreen migration services. |
09:52 |
bshum |
But alrighty then. |
09:53 |
* csharp |
was about to suggest Evergreen Migration Assistant Pro™ |
09:55 |
csharp |
seriously, though - there couldn't really be a standardized migration tool - as Dyrcona says, each one is different ;-) |
09:56 |
Dyrcona |
Everyone that I have done has been different, even when data was in the same format. |
09:56 |
Dyrcona |
You often run into things that one library did with their system that the other one didn't. |
09:57 |
csharp |
exactly |
10:02 |
Bmagic |
he seemed mad |
10:02 |
jboyer-isl |
Methinks his sadness at everything going to the console means that there is no answer they would find acceptable. If one of you has time to build a universal data massager that can accept csv, xlsx, .prn, .txt, .mrc and so on and just "Make it Work" I'm sure it would be appreciated. |
10:03 |
jboyer-isl |
I'm just a little too busy to build it myself. I'm sure it's not that hard. |
10:03 |
Bmagic |
I was working on a UI for migration last year |
10:03 |
csharp |
heh |
10:03 |
Dyrcona |
Nothing $100 million can't solve. |
10:03 |
bshum |
Well, Bmagic has magic. So I believe in you. |
10:03 |
bshum |
Bmagic++ |
10:03 |
Bmagic |
haha! |
10:04 |
jboyer-isl |
1 Million to buy ads in library pubs saying "Migs are hard! Sorry." and 99 Million for retirement. This is a sound plan. |
10:04 |
RoganH |
Dyrcona: you haven't created an AI that anticipates every ILS's structure for migrations yet? |
10:04 |
csharp |
Webby the Migration Duck |
10:05 |
Dyrcona |
heh |
10:05 |
csharp |
"If anyone knows about migrations, it's us Ducks!" |
10:06 |
kmlussier |
Yeah, he seemed mad, but I'm glad bshum said something. I think it's important people know that we don't necessarily condone the practice of saying somebody else's work sucks. |
10:06 |
kmlussier |
bshum++ |
10:10 |
csharp |
it's a super common reponse from people who are used to proprietary programs with slick GUIs |
10:10 |
csharp |
when they don't see what they're expecting, they draw a lot of erroneous conclusions ;-) |
10:11 |
RoganH |
csharp: though said proprietary programs with slick GUIs don't have built in tools to migrate any form of data into their native needs either |
10:11 |
csharp |
a response to F/LOSS |
10:11 |
csharp |
RoganH: you're exactly right ;-) |
10:11 |
Dyrcona |
What RoganH said. |
10:12 |
RoganH |
slick guis are overrated, they're slow and cumbersome for detailed work anyway |
10:13 |
Dyrcona |
Most guis are designed for direct manipulation. |
10:14 |
Dyrcona |
i.e. working on one "thing" at a time. |
10:16 |
RoganH |
one thing with a limited set of variables associated that can be presented visually without interfering with each other. There are neat tricks that help with dynamic interfaces but GUIs still struggle with some limits. |
10:19 |
Dyrcona |
Well, today's GUIs are basically paintings on the walls of caves. |
10:19 |
|
mllewellyn joined #evergreen |
10:21 |
Dyrcona |
Helps to get the branch name correct when trying to merge. :) |
10:26 |
Dyrcona |
Helps to rebase old stuff now and then, too. |
10:34 |
Dyrcona |
csharp: working/user/csharp/lp1444623-remove-Safe-CPAN-dependency-from-Makefiles needs a rebase. |
10:43 |
|
wongon joined #evergreen |
10:59 |
csharp |
Dyrcona: done |
10:59 |
Dyrcona |
csharp++ |
11:05 |
Dyrcona |
Whee! On floppy per second throughput: Writing objects: 100% (220823/220823), 100.81 MiB | 1.44 MiB/s, done. |
11:10 |
|
ohiojoe joined #evergreen |
11:13 |
jeff |
now i want to make some videos visualizing throughput of various things using various other things. |
11:14 |
jeff |
probably already been done, but that should not prevent me from at some point in the future involving a belt sander to feed a stack of floppies at an appropriate rate across the room. |
11:16 |
tsbere |
jeff: I have seen videos showing the "truck full of tapes" method as a comparison point....including more modern variants. Like "truck full of microsd cards". |
11:46 |
|
roger_skip joined #evergreen |
11:47 |
roger_skip |
Help! I foolishly changed my hostname after I finished the server setup. Now ejabberd hates me. |
11:48 |
bshum |
Oops, totally fixable. |
11:49 |
bshum |
roger_skip: So I'm going to refer you to jeff's suggestions from past IRC conversations on this subject area: http://irc.evergreen-ils.org/evergreen/2014-09-24#i_126336 |
11:50 |
bshum |
roger_skip: But tell us more about your setup and maybe we can offer newer suggestions. |
11:51 |
roger_skip |
Ok. Installed 2.8.1 on Ubuntu Trusty |
11:52 |
roger_skip |
One server, no clients set up yet |
11:53 |
bshum |
So yeah, removing ejabberd's data and then re-registering your ejabberd clients will allow things to go back to normal after a hostname change. |
11:54 |
bshum |
If you think the hostname will alter again, doing what jeff suggests and changing the erlang_node will keep it from needing further change. |
11:54 |
roger_skip |
Great! I'll give it a try. Thank you :) |
12:04 |
bshum |
roger_skip: Hope it all works out, good luck! |
12:13 |
bshum |
ldw: jeffdavis: Question, did Christine's slides for the Overdrive API integration that she showed us at the lightning talk ever make it online somewhere? |
12:15 |
|
montgoc1 joined #evergreen |
12:26 |
|
sandbergja joined #evergreen |
12:27 |
bshum |
@hate SIP2 |
12:27 |
pinesol_green |
bshum: The operation succeeded. bshum hates SIP2. |
12:29 |
jboyer-isl |
I'll stand up for SIP, in it's intended use case, that is. It's a fine protocol for point to point serial connections. It is garbage for the wild, wild, winternet. |
12:30 |
jboyer-isl |
turns out: commas, also garbage. |
12:30 |
bshum |
Heh |
12:30 |
bshum |
I'm just figuring out some email question about SIP2 patron information responses. |
12:30 |
bshum |
Trying to figure out what all the fields mean, whee |
12:31 |
eeevil |
bshum: haha ... you said "mean" ;) |
12:31 |
bshum |
Heh |
12:31 |
jboyer-isl |
I wouldn't know anything about any pdfs marked 3M confidential, but I hear Google knows how to find some documentation that may help. ;( |
12:31 |
jboyer-isl |
;) |
12:31 |
berick |
heh |
12:31 |
bshum |
jboyer-isl: Right, and I know there's a wiki page with some thoughts |
12:31 |
bshum |
Like http://wiki.evergreen-ils.org/doku.php?id=evergreen-admin:sip_support#patron_information |
12:31 |
bshum |
It's really old, but sometimes I find helpful tidbits. |
12:32 |
* berick |
recommends the same 3M document.. which i have never seen |
12:33 |
RoganH |
I've read the document. It diverges from implementations about as far as you'd think it would. |
12:33 |
jeff |
i appreciated the reaction i got when i started to implement fine details using the 3M doc -- they were shocked, and stated that their software didn't support that level of detail, because no ILS did. |
12:34 |
berick |
if you write the docs, they will come... and want more docs |
12:36 |
jboyer-isl |
It looks like the version that Google now finds lacks any limits on distribution (but you can't create derivative protocols, "darn") so that's where you want to start if you just want "what's this field?" info. |
12:38 |
jeff |
look, ma! webhooks-over-email! |
12:39 |
jeff |
(set up an A/T event def to send an email to a fixed address containing just a hold ID when holds go to Available) |
12:43 |
|
wongon joined #evergreen |
12:44 |
|
collum joined #evergreen |
13:05 |
Dyrcona |
Step 5 of the websockets setup in the OpenSRF README is missing some information that will trip up newbies. |
13:06 |
Dyrcona |
It should tell them to cd to the OpenSRF code before running the copy commands. |
13:06 |
Dyrcona |
Someone just blindly copying and pasting commands will get errors. |
13:06 |
bshum |
Dyrcona: I thought of that too when I worked on the OpenSRF steps. |
13:07 |
bshum |
I was thinking at some point to change OpenSRF's README style to be more like Evergreen's, and offer general tips on things like source_dir, etc. |
13:07 |
bshum |
But didn't get around to it, obviously. |
13:07 |
bshum |
:| |
13:09 |
ohiojoe |
I saw a couple of places over the weekend where I thought the OpenSRF fresh install docs could use a little expansion for the sake of newbies.. |
13:11 |
ohiojoe |
I was documenting these in a word document that may or may not be lost.. my Windows installation decided to lockup overnight.. |
13:14 |
ohiojoe |
Which reminds me, it looks like Debian has moved their backports repo for Wheezy and Jessie to a new URL and slightly different format |
13:16 |
ohiojoe |
I have to admit, I'm new to being more than just a user in the EG community, how or to whom should I address documentiation suggestions? |
13:16 |
kmlussier |
ohiojoe: You could send them to the documentation list. |
13:17 |
ohiojoe |
ok, thanks. |
13:23 |
Dyrcona |
You could also open a launchpad bug and tag it documentation. |
13:24 |
ohiojoe |
mm, that would have the added benefit of providing practice for using launchpad... |
13:27 |
Dyrcona |
Speaking of documentation, I can't seem to find the Evergreen instructions for the web staff client setup. |
13:28 |
Dyrcona |
Oh, wait. Just found 'em. ;) |
13:28 |
csharp |
argh - I'm really confusing myself - I'm trying to "reset" some failed Acq PO A/T events and get the edi_pusher.pl script to care about them |
13:29 |
csharp |
I reset the A/T events with 'update action_trigger.event set start_time = null, update_time = null, complete_time = null, state = 'pending' where id in (list of at.event ids);' but the pusher doesn't "see" them |
13:31 |
bshum |
Dyrcona: Yeah that needs to get LP'd at some point too... and I should finish putting more notes into it. |
13:31 |
bshum |
But I think other people should try it out and confirm the process and maybe add better notes than what I've done. I think my perspective isn't good enough on its own anymore. |
13:31 |
Dyrcona |
bshum: I wanted to ask you about the note on 4 about skipping the step if you downloaded a tarball. |
13:32 |
bshum |
Dyrcona: For Evergreen tarballs, from 2.7+ the web client code is compiled automagically via a flag passed to the make_release script |
13:32 |
Dyrcona |
bshum: OK. I did not know that. |
13:32 |
Dyrcona |
Guess it is a good thing that I do now. :) |
13:32 |
bshum |
So for downloaded tarballs, the web client code is all set, and you don't have to install the pre-req's, etc. |
13:33 |
bshum |
For compiling it |
13:33 |
bshum |
2.7 and 2.8 RMs just have to remember to pass that flag along. Guess you'll know too ;) |
13:33 |
bshum |
The flag is -c |
13:34 |
bshum |
Dyrcona: You should bookmark this wiki page: http://wiki.evergreen-ils.org/doku.php?id=dev:release_process:evergreen:2.8 |
13:34 |
bshum |
It's a good workflow of how releases are done |
13:34 |
bshum |
More recently anyways. |
13:35 |
Dyrcona |
bshum: Thanks, I already have that page bookmarked, just haven't given it the attention it deserves, yet. |
13:41 |
Dyrcona |
I am tempted to try the latest tag in Node.js: 0.12.4. |
13:43 |
csharp |
I also noticed a possible "retry" status on the acq.edi_message table, and set that for the messages I'm trying to re-send, but that's not working either :-/ |
13:54 |
|
jihpringle joined #evergreen |
13:56 |
Dyrcona |
Hmm. That second npm install still fails for me unless I do it with sudo. |
13:56 |
Dyrcona |
I also get several warnings. |
13:56 |
* jeff |
refreshes his memory on what kinds of things can key a template dir change |
14:00 |
Dyrcona |
Ah. I figured out the sudo bit. |
14:02 |
Dyrcona |
So, where and when are the steps in 4.2 supposed to happen? |
14:03 |
Dyrcona |
Are they meant to be done during the normal installation steps before building and installing a regular staff client? |
14:03 |
Dyrcona |
Or can they be done in /openils/var/web/js/ui/default/staff after the regular installation? |
14:03 |
Dyrcona |
Doing it in the latter place fails for me on grunt all. |
14:06 |
dbs |
packages of packages of packages, whee :) |
14:07 |
Dyrcona |
heh |
14:08 |
Dyrcona |
Well, I guess I'll find out if I've had success after the database upgrade scripts finish. |
14:08 |
Dyrcona |
I should have started that before embarking on the web staff client steps. |
14:10 |
Dyrcona |
FTL: It looks like the steps are meant to come in the normal installation procedure and are meant to be run in your source checkout/exploded tarball. |
14:10 |
bshum |
Right. |
14:10 |
Dyrcona |
That is, before make install is run. |
14:10 |
bshum |
Yes. |
14:10 |
bshum |
From source directory. |
14:10 |
bshum |
Not installed place |
14:31 |
berick |
in the release builder, we delete the node_modules and bower_modules directories before tar'ing the build. you may want do to the same before 'make install' (or maybe move them somewhere else). |
14:31 |
berick |
otherwise make install copies them to the web dir |
14:31 |
berick |
which is just an extra pile of stuff that does not need to go there |
14:33 |
berick |
still some rough edges, obviously |
14:33 |
Dyrcona |
yep. |
14:33 |
Dyrcona |
I'll just delete them for now. |
14:34 |
Dyrcona |
bower_modules or bower_components? I have the latter and not the former. |
14:34 |
berick |
bower_components, then |
14:34 |
berick |
i forget exactly |
14:35 |
Dyrcona |
S'all right. I can always copy them back if it turns out I need it. |
14:37 |
hopkinsju |
bshum++ (from earlier) |
14:38 |
Dyrcona |
csharp: Have you had any luck with your acq problem? I have no idea how to help, but wonder if you have made any progress. |
14:40 |
csharp |
Dyrcona: thanks for asking - no - no further progress - my next step is to trace the thread from the pusher script back to the whole PO activation process |
14:41 |
csharp |
I'm hurting because I have limited knowledge of the actual process |
14:41 |
csharp |
(that is, the process that staff perform to enter orders and place them) |
14:44 |
Dyrcona |
csharp: same here. I also don't know the code well at all. |
15:04 |
|
krvmga joined #evergreen |
15:04 |
krvmga |
i'm a little confused. when exactly does autogen need to be run when we make changes? |
15:09 |
csharp |
krvmga: basically, if you alter the org tree by adding a branch, making something OPAC visible/invisible, or changing the parent org or something like that, run autogen on anything running Evergreen |
15:09 |
bshum |
And reload/restart apache. |
15:09 |
csharp |
(that is to say, don't forget about utility servers and such, especially ones processing holds) |
15:10 |
krvmga |
thanks! :) |
15:10 |
ldw |
bshum: Here is a link to Christine's slide: https://docs.google.com/presentation/d/1zQrPOn4W3v31OvyTHhb5cUDJZYacE4wiOcsTZy7_erk/edit?pli=1#slide=id.p4 |
15:11 |
bshum |
ldw: Awesome! Thanks for sharing |
15:11 |
krvmga |
also, i discovered this http://support.esilibrary.com/index.php?pg=kb.printer.friendly&id=2#p8 which has a section on when to run autogen. |
15:21 |
ohiojoe |
ok, question about hostnames.. if does it matter, in term of achieving a working installation, what host names I use for public.localhost and private.localhost for the opensrf domains? |
15:21 |
ohiojoe |
For instance, can I just call it public.localhost and private.localhost? Or does that create known issues? |
15:22 |
Dyrcona |
krvmga leaves too soon. You also need to run autogen.sh if you change the IDL. |
15:22 |
ohiojoe |
when working through installing opensrf, I should mention |
15:23 |
bshum |
ohiojoe: It doesn't really matter what you name those particular entries. The reason those are written as such is to allow for the possibility that ejabberd doesn't live on the same place you end up installing and running OpenSRF/Evergreen. That allows for more distributed nature of building an Evergreen cluster as it were. |
15:24 |
Dyrcona |
ohiojoe: I don't think so. I call mine public.{hostname} and private.{hostname} in my /etc/hosts. |
15:24 |
bshum |
ohiojoe: The sample instruction is just there to give you an example. |
15:25 |
Dyrcona |
So, I got the web staff client installed, but when I go to login, clicking on the Sign In button appears to do nothing. |
15:25 |
ohiojoe |
ok, cool, thanks. |
15:25 |
bshum |
ohiojoe: The main idea in most cases I've seen where people construct an Evergreen "brick" whereby a single lead server runs apache/ejabberd, etc. and other serving drone servers provide specific open-ils services, but communicate using the lead device's ejabberd instance. |
15:25 |
jeff |
Dyrcona: page loaded via https? websockets apache instance started without issue, and using a "real" ssl cert? checked browser console for errors? |
15:25 |
bshum |
Real SSL cert tends to be a common quirk. |
15:26 |
Dyrcona |
jeff: check on the first three. |
15:26 |
Dyrcona |
I think this is my problem: Firefox can't establish a connection to the server at wss://jasondev.mvlcstaff.org:7682/osrf-websocket-translator. |
15:27 |
bshum |
Dyrcona: Is the websockets instance configured to use a proper SSL cert? (aka, did websockets even start on the server?). Or maybe firewall? |
15:27 |
* bshum |
would like it better if the apache-websockets instance logged somewhere with more detail when it fails to start properly. |
15:27 |
* bshum |
has found that to be entertaining from time to time figuring out why it doesn't start. |
15:28 |
jeff |
yeah, looks like a timeout on that port. host or network based firewall blackhole? |
15:28 |
jeff |
of course, my source ip is not your source ip... |
15:29 |
Dyrcona |
I need to fix the ssl configuration for the web sockets apache, apparently. |
15:31 |
bshum |
Dyrcona: Yeah the default path assumes that you copy the ssl folder to the apache-websockets dir too. Or change it to /etc/apache/ssl/* |
15:32 |
Dyrcona |
bshum: That wasn't my problem. We also don't use the default names of server.* and we need the Godaddy chain file. |
15:32 |
bshum |
Sure. |
15:32 |
Dyrcona |
But, fixing that, I still get no connection. |
15:32 |
Dyrcona |
Guess I'll check the firewall, next. |
15:33 |
Dyrcona |
Not sure if it sees me by my internal or external IP, and it may not matter depending on what we've done to the firewall. |
15:34 |
Dyrcona |
So, looks like it uses ports 7680 and 7682. |
15:34 |
bshum |
Primarily 7682 for https if memory serves |
15:38 |
Dyrcona |
Changing the firewall didn't help. |
15:41 |
Dyrcona |
Is there more configuration that needs to be done for web sockets? |
15:41 |
* berick |
confirms we're not actually using 7680 |
15:42 |
berick |
Dyrcona: on ubuntu 14.04 i've been having trouble lately starting / restarting apache-websockets via "service apache2-websockets restart" and similar |
15:42 |
Dyrcona |
berick: I did /etc/init.d/apache2-websockets |
15:42 |
berick |
/etc/init.d/.. restart no good either. had to use apache2ctl-websockets restart |
15:43 |
Dyrcona |
Gotta love this: |
15:43 |
Dyrcona |
opensrfjasondev:~$ sudo apache2ctl-websockets restart |
15:43 |
Dyrcona |
[sudo] password for opensrf: |
15:43 |
Dyrcona |
httpd not running, trying to start |
15:43 |
Dyrcona |
opensrfjasondev:~$ sudo apache2ctl-websockets start |
15:43 |
Dyrcona |
httpd (pid 10774) already running |
15:44 |
Dyrcona |
Oops. I thought it was telling me to start it. |
15:45 |
Dyrcona |
berick++ |
15:45 |
Dyrcona |
It is working, now. |
15:45 |
berick |
excellent |
15:45 |
* berick |
was hoping that was a bit of local funkiness :( |
15:45 |
berick |
fwiw, never had that problem on wheezy |
15:48 |
Dyrcona |
berick: The patron registration phase1 looks usable. I assume there is no code behind it? |
15:49 |
berick |
Dyrcona: well, there is a lot of code behind it, but none that sends changes back to the server. |
15:49 |
berick |
it's just fetching data and display stuff for now |
15:49 |
Dyrcona |
berick: heh. that's what I meant. |
15:50 |
berick |
i know :) |
15:52 |
Dyrcona |
:) |
15:52 |
Dyrcona |
A song that seems appropriate for the moment: https://www.youtube.com/watch?v=SSbBvKaM6sk |
15:54 |
berick |
:) |
15:57 |
Dyrcona |
Guess collum is not a fan of Damon Albarn... ;) |
16:08 |
|
mrpeters left #evergreen |
16:11 |
RoganH |
lol |
16:26 |
ohiojoe |
I just figured out what I was doing wrong with ejabberd.. I needed to start (restart) ejabberdctl before registering the public and private jabber users.. |
16:26 |
Bmagic |
ohiojoe: Oh man, I was going to suggest that! |
16:27 |
ohiojoe |
at least that solved the problem on the new VM I just started this afternoon.. |
16:27 |
ohiojoe |
although on the VM at home, I followed the same process as I did today, except today's was uncluttered by my early attempts to solve the ejabberd issues.. |
16:30 |
ohiojoe |
I now wonder whether I should press on, or look through the IRC log from 9/24/14 that was referenced earlier today and harden my install to insure that jabber doesn't get bent out of shape when the server IP changes... |
16:35 |
|
Newziky left #evergreen |
16:59 |
* Dyrcona |
feels a blog post coming on. |
17:06 |
|
mmorgan left #evergreen |
17:09 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
18:04 |
|
TaraC joined #evergreen |
18:20 |
|
dbwells_ joined #evergreen |
18:23 |
|
tsbere joined #evergreen |
18:24 |
|
BigRig_ joined #evergreen |
19:42 |
|
wongon joined #evergreen |
21:43 |
|
collinanderson joined #evergreen |
22:58 |
|
wongon joined #evergreen |