| Time |
Nick |
Message |
| 01:13 |
|
jeff_ joined #evergreen |
| 06:54 |
|
TARA joined #evergreen |
| 07:01 |
csharp |
miker: will you be creating a rel_2_11 branch? I see a problem with the release notes (cancled transit section has some missing information) and wanted to submit a patch |
| 07:03 |
csharp |
actually, now I that I've asked, I can see that it's still in RELEASE_NOTES_NEXT, so no problem :-) |
| 07:07 |
miker |
csharp: dbwells will be creating a branch, but not yet. we do that at GA time to reduce duplicate effort when fixing bugs |
| 07:13 |
csharp |
makes sense |
| 07:14 |
|
TARA joined #evergreen |
| 07:16 |
csharp |
miker: my formatting fix is at the tip of http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/csharp/lp1613374_canceled_transit_item_status - seems too small a fix for its own bug - how would I make sure that gets noticed? |
| 07:21 |
|
rjackson_isl joined #evergreen |
| 07:26 |
|
agoben joined #evergreen |
| 07:40 |
JBoyer |
jeff, I kind of followed up on lp 1481441, by filing lp 1576754 and then not doing anything else yet. |
| 07:40 |
pinesol_green |
Launchpad bug 1481441 in Evergreen "action.hold_request_permit_test fail_parts can be confusing to end users" [Medium,Fix committed] https://launchpad.net/bugs/1481441 |
| 07:40 |
pinesol_green |
Launchpad bug 1576754 in Evergreen "Custom Error Messages for Circ/Hold Matrix Matchpoints" [Wishlist,New] https://launchpad.net/bugs/1576754 |
| 08:01 |
|
ericar joined #evergreen |
| 08:04 |
|
kmlussier joined #evergreen |
| 08:07 |
kmlussier |
Good morning #evergreen. Happy last day of August! |
| 08:07 |
|
ericar joined #evergreen |
| 08:31 |
tsbere |
kmlussier: I dunno about good. I have my last meeting of August this morning. Maybe it will be a good afternoon? ;) |
| 08:34 |
|
mmorgan joined #evergreen |
| 08:36 |
kmlussier |
tsbere: Feel free to take my 'good mornings' as best wishes for your day, not as a prediction as to how it will turn out. |
| 08:45 |
|
Dyrcona joined #evergreen |
| 08:48 |
kmlussier |
rhamby / JBoyer : The hack-a-way is Tuesday thru Thursday this year? Is that right? Just checking to make sure I make the right travel plans. |
| 08:49 |
JBoyer |
kmlussier, yes. |
| 08:49 |
kmlussier |
JBoyer: Excellent. Thanks! |
| 08:50 |
kmlussier |
For some reason, I thought it was happening during the election, but I guess I was wrong. |
| 08:50 |
csharp |
thank $DEITY, no |
| 08:51 |
JBoyer |
Yeah, that's likely just a travel day. But you know, if anyone wants to vote Trump they can do that when they get back. ;) |
| 08:52 |
csharp |
and by Tuesday, it is meant "fly in on Tuesday and start work on Wednesday", correct? |
| 08:52 |
|
egbuilder joined #evergreen |
| 08:52 |
csharp |
JBoyer: you just answered me as I asked :-) |
| 08:53 |
* csharp |
plans to vote via the plane wifi |
| 08:54 |
JBoyer |
kmlussier, Actually I think I mis-answered you re: Tues - Thurs. Let me double check that. (With Tues as a travel day that's a pretty short event) |
| 08:55 |
csharp |
it has traditionally been Wed, Thurs, and Friday (sometimes a half-day) |
| 08:55 |
kmlussier |
Election day is the following week. |
| 08:55 |
kmlussier |
On the 8th |
| 08:55 |
csharp |
right |
| 08:56 |
kmlussier |
If the event starts on Tuesday, then it means I'm traveling on Halloween, which could be problematic. Of course, I could always take an early morning flight. |
| 08:56 |
JBoyer |
No, it's definitely Wed - Fri. I just wanted to double check. (and have.) |
| 08:57 |
kmlussier |
Ack! I see why I was confused. I was looking at the August calendar, where the 2nd is a Tuesday. |
| 08:59 |
* Dyrcona |
should make his hackaway travel arrangements. |
| 09:01 |
rhamby |
kmlussier: what JBoyer said :) |
| 09:05 |
JBoyer |
I was apparently under the impression that that Tuesday was election day. Good thing it came up or I'd have been very confused that day. |
| 09:08 |
csharp |
"the Tuesday next after the first Monday in the month of November" http://memory.loc.gov/ll/llsl/005/0700/07590721.tif |
| 09:09 |
csharp |
so it will never collide with All Saints Day (though I'm not sure that was a consideration) |
| 09:09 |
* csharp |
just got curious why the election *wasn't* on the first |
| 09:09 |
Dyrcona |
It's never on the first. |
| 09:10 |
Dyrcona |
First Tuesday in November, unless it is the first, then it is the second Tuesday in November. |
| 09:19 |
|
yboston joined #evergreen |
| 09:28 |
|
rlefaive joined #evergreen |
| 09:44 |
miker |
csharp: I grabbed your formatting fix |
| 09:45 |
pinesol_green |
[evergreen|Chris Sharp] LP1613374: Release notes formatting fix. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=43bf9d2> |
| 09:50 |
|
Christineb_away joined #evergreen |
| 09:50 |
|
jvwoolf1 joined #evergreen |
| 10:00 |
|
rlefaive joined #evergreen |
| 10:02 |
csharp |
miker++ # thanks |
| 10:04 |
jeff |
figured out last night why sipserver moves from a syslog ident of "opensrf_sip" to "" to "SIPServer.pm". |
| 10:05 |
|
jwoodard joined #evergreen |
| 10:05 |
berick |
jeff: https://bugs.launchpad.net/opensrf/+bug/1473479 |
| 10:05 |
pinesol_green |
Launchpad bug 1473479 in OpenSRF "Mixing syslog configs leads to logging chaos" [Wishlist,Confirmed] |
| 10:06 |
jeff |
oh thank goodness. it's not just me. :-) |
| 10:08 |
jeff |
berick: the thought I had was to pass an argument to OpenSRF::System->bootstrap_client, but I'm interested in your approach also. |
| 10:11 |
berick |
jeff: yeah, that would work too.. |
| 10:11 |
jeff |
similar but different issues abound with opensrf under an apache context (both the C modules and the mod_perl bits). Quick fix seems to be to pipe ErrorLog to a process instead of directly to syslog, and longer term fix might be to have some or all of those things log via established apache log routines. I had given less thought to that so far. |
| 10:11 |
jeff |
but at least for the mod_perl bits, having Apache set your proposed OSRF_ADOPT_SYSLOG env var would probably work. |
| 10:13 |
miker |
jeff: FWIW, we pipe to /usr/bin/logger and use -t to set the log tag we want |
| 10:13 |
jeff |
miker: seems sanest, and gets you stderr to boot. |
| 10:14 |
jeff |
i think that once you eliminate apache's syslogging, the C and mod_perl syslog calls don't conflict with each other too much. My notes might disagree with me. |
| 10:18 |
jeff |
berick++ miker++ |
| 10:41 |
kmlussier |
StomproJ: I was reading your question from last week regarding Reshelving status. We have a site that did not have the option to run the Reshelving script more frequently than every 24 hours (too large). They ultimately went with a label change to "Recently Returned" that seemed to make people happy. |
| 11:03 |
|
Dyrcona1 joined #evergreen |
| 11:13 |
jeff |
hrm. need to spin up a pre-2.10 instance to test something. |
| 11:18 |
* csharp |
dreams up library-themed horror movie: THE UNRETURNED |
| 11:19 |
berick |
csharp++ |
| 11:20 |
dbwells |
csharp++ # I needed that laugh :) |
| 11:20 |
berick |
in a world, where some materials never make it home |
| 11:22 |
csharp |
berick++ # :-) |
| 11:22 |
dbwells |
the lost, the missing, the DAMAGED... |
| 11:22 |
csharp |
ha! |
| 11:24 |
* berick |
chuckles |
| 11:25 |
csharp |
oooh - once you see library statuses in that light, they all start looking creepy (e.g. BINDERY) |
| 11:27 |
jeff |
"After Aug 31, 2016 all new support tickets will be assigned subject/summary lines in the style of '[staff member] and the Case of the [verb] [noun]' |
| 11:27 |
csharp |
jeff++ |
| 11:27 |
jeff |
though [verb] there is a bit limiting. |
| 11:27 |
jeff |
we'll be flexible. |
| 11:28 |
jeff |
Jeff and the Case of the Deleted This Old House Magazines |
| 11:28 |
jeff |
"the serials are... still! checked! out!" |
| 11:29 |
berick |
the in house use is coming from.. inside the library! |
| 11:29 |
jeff |
"ah, here's the problem. these serial units are all in the upside down." |
| 11:30 |
jeff |
"there's some good news, though... less than a dozen were affected. by my count, only... Eleven." |
| 11:31 |
berick |
*rimshot* |
| 11:32 |
csharp |
I'm sure the fact that I have the Stranger Things theme music in my head got me seeing the "List of Unreturned Items" report I'm working on in this light |
| 11:33 |
* csharp |
wipes blood from nose |
| 11:48 |
* tsbere |
should really have someone update his gitadmin alias membership to change mvlc.org to mvlcstaff.org |
| 11:48 |
tsbere |
But then I might have to deal with Microsoft's junk mail filter instead of one I control.... |
| 11:49 |
csharp |
tsbere: I'm in the file - do you want me to change it? |
| 11:50 |
tsbere |
csharp: I suppose it is probably for the best that it be updated, if only to slowly whittle down the places using the @mvlc.org one. |
| 11:50 |
csharp |
okay - will do |
| 11:51 |
* tsbere |
only thought of it just now due to Dyrcona being added to the gitadmins group in gitolite |
| 11:51 |
csharp |
tsbere: done |
| 11:51 |
tsbere |
csharp++ |
| 11:59 |
|
maryj joined #evergreen |
| 12:08 |
|
bmills joined #evergreen |
| 12:09 |
|
brahmina joined #evergreen |
| 12:58 |
|
jihpringle joined #evergreen |
| 12:58 |
|
maryj joined #evergreen |
| 13:21 |
|
Griff`Ron joined #evergreen |
| 13:22 |
jeff |
oh well that's annoying. |
| 13:22 |
jeff |
web client "check in" action from patron's "items out" checks in by barcode, not copy id. |
| 13:24 |
mmorgan |
Not good :-( |
| 13:26 |
mmorgan |
Though that would make it consistent with viewing item details, wouldn't it? |
| 13:27 |
jeff |
it is inconsistent with the current xul client's checkin option from a patron's Items Out |
| 13:27 |
|
Griff`Ron joined #evergreen |
| 13:27 |
jeff |
but it really only matters when you're dealing with an unusual situation, like a patron with an open circulation on a deleted copy. |
| 13:28 |
tsbere |
Which is important |
| 13:28 |
tsbere |
But not a normal test case |
| 13:28 |
jeff |
checking in a deleted copy by barcode will either fail (because the barcode is not found), or will checkin the wrong copy (because another item with that same barcode has since been created). |
| 13:28 |
mmorgan |
jeff: right. We've had confusion about that in the past. |
| 13:28 |
jeff |
in my case, the latter happened. |
| 13:29 |
* Dyrcona |
jogs tsbere's memory about two patrons with the "same" item checked out, where one was a deleted barcode and the other not. |
| 13:29 |
Dyrcona |
jeff: I say that's a bug. :) |
| 13:29 |
mmorgan |
We've had that happen in the xul client. |
| 13:29 |
tsbere |
Dyrcona: For more fun, yesterday I found one patron with the "same" item checked out (and lost) twice back in 2012.... |
| 13:30 |
Dyrcona |
yep. In the XUL client you can check the deleted copy in from the patron's items out. Sounds like you can't in the web staff client. |
| 13:30 |
berick |
probably an easy one to fix, too.. {copy_barcode:..} => {copy_id: ..} |
| 13:30 |
Dyrcona |
tsbere: I am not surprised. |
| 13:31 |
* csharp |
looks into adding NOT LIKE and NOT ILIKE filter operators to the reporter |
| 13:31 |
mmorgan |
It also causes confustion that viewing item details from checked out items does it by barcode. |
| 13:31 |
mmorgan |
confusion, that is. |
| 13:32 |
csharp |
@decide confusion or confustion |
| 13:32 |
pinesol_green |
csharp: go with confusion |
| 13:32 |
jeff |
mmorgan: oh, i see what you mean there also. |
| 13:32 |
mmorgan |
staff can't understand why the available item is still showing as checked out on a patron record. |
| 13:32 |
* jeff |
nods |
| 13:32 |
mmorgan |
Then they try and check it in by barcode - sometimes checking in the wrong item, so the result is the same. |
| 13:33 |
Dyrcona |
Yes, fun times. :) |
| 13:34 |
* mmorgan |
runs away for a bit. |
| 13:35 |
* tsbere |
has considered an asset.copy trigger to change the barcodes to DELETED: <original barcode>, but at this point that would break an undelete tool we have set up |
| 13:44 |
tsbere |
Anyone want to look at some of the address cleanup/normalization stuff I have been playing with? Currently it is all SQL scripts, but I figure that isn't a bad place for others to start from either. |
| 13:45 |
* csharp |
raises hand |
| 13:45 |
csharp |
it may not be today, but yep, I'm interested |
| 13:45 |
tsbere |
csharp: My main "cleanup" script so far is http://tomtrunk.mvlcstaff.org/address_cleanup.sql - You need http://tomtrunk.mvlcstaff.org/extend_reporter.zip_info.sql for some of it. |
| 13:46 |
tsbere |
csharp: http://tomtrunk.mvlcstaff.org/address_standardize_tests.sql has the "load the stuff I am using for standardizing" commands and then some playing with data queries |
| 13:50 |
* tsbere |
uses the extend_reporter.zip_info table for some reports as well |
| 13:58 |
dbs |
This might be of interest to DIG: https://www.drupal.org/drupalorg/blog/documentation-overhaul (I find seeing what other projects are trying to do useful, even if not applicable) |
| 14:11 |
|
Christineb joined #evergreen |
| 14:12 |
|
Griff`Ron joined #evergreen |
| 14:12 |
StomproJ |
kmlussier, Thanks, that is a good idea to consider. I just re-enabled the script running hourly for now, and added the sql query from the bug report that is supposed to find the issues to our daily error report. Running the script hourly never takes more than a few seconds for us so I don't think we will ever hit it. |
| 14:42 |
mmorgan |
StomproJ: A thought I had, but never actually suggested was renaming the "Reshelving" status to "Available " (with a space at the end). Just seems wrong, but would get the job done. |
| 14:44 |
csharp |
the public library system where I used to work used "recently returned" as kmlussier suggested |
| 14:46 |
berick |
"Limbo" |
| 14:47 |
StomproJ |
"Available, Maybe?" |
| 14:47 |
jeff |
"Somewhere in Zip Code 00000000O" |
| 14:47 |
jeff |
(please note the trailing uppercase O there) |
| 14:47 |
kmlussier |
The nice thing about 'recently returned' is that it gives staff a heads up that I might not yet been on the shelf, without giving people the impression that it takes an entire day to reshelve a book. |
| 14:49 |
jeff |
i don't remember which order we used to use in our old jspac summaries here. |
| 14:50 |
jeff |
2 available in Adult Fiction (FIC STE) plus 1 recently returned |
| 14:50 |
jeff |
3 available (1 recently returned) in Adult Fiction (FIC STE) |
| 14:50 |
jeff |
maybe we continued to experiment and never settled on one before we moved on. |
| 14:56 |
kmlussier |
heh, 'I might not yet be on the shelf.' |
| 14:56 |
kmlussier |
@dessert |
| 14:56 |
* pinesol_green |
grabs some Lemon Chess Pie for kmlussier |
| 15:02 |
jeff |
Shrodinger's Kittens and the Search for Reality: 530.12 in Adult Non-fiction: Reshelving |
| 15:02 |
|
Dyrcona joined #evergreen |
| 15:04 |
jeff |
Library Catalogs and Quantum Availability: An Introduction in an Indeterminate Number of Parts |
| 15:06 |
mmorgan |
jeff++ |
| 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? |
| 15:31 |
Dyrcona |
You should be able to find what request was sent to it by looking for the PID in the log. |
| 15:31 |
Dyrcona |
Or at least what client/drone sent it the message. |
| 15:31 |
jeff |
or start with what Dyrcona suggested |
| 15:32 |
tsbere |
pgadmin server status? |
| 15:32 |
* tsbere |
assumes that if the drone is actually doing something then the query will be sitting there |
| 15:32 |
Dyrcona |
yeah, what tsbere said, too. |
| 15:38 |
jeffdavis |
strace shows that it's doing something, though I can't tell what |
| 15:39 |
JBoyer |
I'm guessing looking up an ip, trying to connect, maybe one other step, looking up an ip, etc. Close? |
| 15:40 |
kmlussier |
berick / JBoyer: I'll be there! |
| 15:40 |
berick |
jeffdavis: API calls are logged before processing starts |
| 15:41 |
berick |
well, they're sent to the logger/file |
| 15:43 |
jeffdavis |
berick: ah, that's good to know. Not seeing a corresponding log entry for this one though, oddly. Weird. |
| 15:45 |
berick |
kmlussier: woot! |
| 15:46 |
berick |
jeffdavis: maybe what JBoyer was getting at... if you see it trying to connect/write to a socket, you can lsof the file descriptor and see what the socket's connected to. i would not be surprised if it's looping on a broken jabber socket. |
| 15:47 |
berick |
especially if the CPU is high and steady. |
| 15:48 |
berick |
if it's talking to the DB I would expect the CPU usage to vary as it waits on I/O |
| 15:51 |
jeffdavis |
berick: broken jabber socket is sounding very likely - thank you for that! |
| 15:54 |
dbs |
And hast thou slain the jabberwock? |
| 15:56 |
* dbs |
looks at the Hack-a-Way dates. mmm, already doing some travelling in November :/ |
| 15:59 |
dbwells |
csharp: I read "old dojo bandaid fixes" as "old banjo fixes". Got all excited for nuthin'. |
| 16:02 |
* tsbere |
stares at a collection of patron addresses that don't parse, specifically the ones that are in a form of street1: # some street street2: # other street, sometimes street2: # other street city |
| 16:07 |
* dbs |
notes that the wiki needs an upgrade again |
| 16:08 |
* dbs |
wonders if he should just hit the "wiki upgrade" button and damn the consequences... |
| 16:08 |
dbs |
I upgraded our local dokuwiki to the new version with no problems; the eg wiki is super-stock; what could possibly go wrong? |
| 16:09 |
tsbere |
dbs: I think you *were* going to be fine, then you invoked "what could possibly go wrong?" and have now summoned Murphy. :P |
| 16:10 |
dbs |
hah |
| 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:26 |
csharp |
d'oh! |
| 16:26 |
Dyrcona |
StomproJ: begin; ..... rollback; :) |
| 16:27 |
Dyrcona |
But, most of us have been there before. |
| 16:27 |
csharp |
I typically make a csharp.backup_table_of_what_is_changing then run the update against the id in the backup table |
| 16:27 |
csharp |
and use transactions |
| 16:28 |
StomproJ |
Yes, realized it about 10 minutes after the commit though. It shouldn't be that bad to undelete the bre, then the volumes, and then look at which copies used to point to those volumes. |
| 16:29 |
Dyrcona |
Well, hopefully you noticed before any staff or patrons did. |
| 16:32 |
StomproJ |
The fact that reporter.super_simple_record title only includes the 245a bit me. Anyone want to look at my pull request on bug 1048822 ? |
| 16:32 |
pinesol_green |
Launchpad bug 1048822 in Evergreen "Simplified Pull List - Need fuller title" [Wishlist,Confirmed] https://launchpad.net/bugs/1048822 |
| 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 |
| 16:56 |
csharp |
hey - that was faster than I predicted - now to see what it did ;-) |
| 17:07 |
Dyrcona |
StomproJ: I don't think it does delete empty volumes. AFAIK, the delete of empty volumes is handled in the Perl code, not in the database. |
| 17:07 |
* Dyrcona |
goes back to editing an email before hitting send and then going home. |
| 17:10 |
Dyrcona |
And that's that... Good night, Evergreen! |
| 17:11 |
|
mmorgan left #evergreen |
| 17:13 |
csharp |
StomproJ: some of the titles get super long with this change - I might want to ask my colleagues and maybe even a couple of library staff to poke at it before signing off |
| 17:13 |
csharp |
I'll follow up tomorrow |
| 17:14 |
csharp |
I know our staff have complained about not enough title info too, though |
| 17:15 |
csharp |
long title example: "history of the old cheraws containing an account of the aborigines of the pedee the first white settlements their subsequent progress civil changes the struggle of the revolution and growth of the country |
| 17:15 |
csharp |
afterward extending from about a d 1730 to 1810 with notices of families and sketches of individuals" |
| 17:19 |
jeff |
those titles don't look super simple. |
| 17:21 |
jeff |
I think bug 1251394 is likely to help here, and aiui it is likely to get some fresh attention as it appears to have been included within the scope of some recently funded development. |
| 17:21 |
pinesol_green |
Launchpad bug 1251394 in Evergreen "Metabib Display Fields" [Wishlist,Triaged] https://launchpad.net/bugs/1251394 |
| 17:24 |
kmlussier |
jeff: I think that one's still looking for funding partners. |
| 17:25 |
kmlussier |
Just in case anyone's interested. ;) |
| 17:25 |
StomproJ |
csharp, Should it be limited to a certain number of characters, just do a hard cutoff of the extra info? |
| 17:29 |
csharp |
StomproJ: that sounds reasonable in the abstract - I'd like to query my colleagues on it |
| 17:30 |
|
jvwoolf1 left #evergreen |
| 19:45 |
|
brahmina joined #evergreen |
| 19:58 |
|
jvwoolf left #evergreen |
| 23:38 |
|
Griff`Ron joined #evergreen |
| 23:48 |
dbs |
backing up dokuwiki on lupin now |
| 23:50 |
|
Griff`Ron joined #evergreen |
| 23:55 |
dbs |
And dokuwiki is now upgraded. yayz |
