| Time |
Nick |
Message |
| 00:11 |
|
beanjammin joined #evergreen |
| 00:21 |
|
beanjammin joined #evergreen |
| 00:59 |
|
abowling left #evergreen |
| 01:23 |
|
abowling joined #evergreen |
| 01:29 |
|
beanjammin joined #evergreen |
| 04:12 |
|
yar joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:10 |
|
rjackson_isl joined #evergreen |
| 08:45 |
|
mmorgan joined #evergreen |
| 08:48 |
|
littlet joined #evergreen |
| 08:55 |
|
dwgreen joined #evergreen |
| 08:58 |
|
bos20k joined #evergreen |
| 09:01 |
|
kmlussier joined #evergreen |
| 09:04 |
|
yboston joined #evergreen |
| 09:16 |
csharp |
so my takeaway from the hatch discussion from yesterday is we need to merge in JBoyer's and berick's branches to Hatch master - is that right? |
| 09:16 |
* csharp |
is happy to test and signoff wherever would help |
| 09:16 |
csharp |
our testers are hitting the WSOD issue a lot now |
| 09:16 |
* csharp |
saw it himself last week |
| 09:19 |
kmlussier |
csharp: When does it come up? |
| 09:20 |
csharp |
for me it was after installing hatch after running the web client without hatch |
| 09:21 |
miker |
csharp: did you tell it to use hatch for storage? I believe the word is, now, "don't do that, only printing" |
| 09:21 |
csharp |
miker: yes, actually, I think I did |
| 09:21 |
csharp |
I can verify |
| 09:23 |
miker |
JBoyer mentioned that at ~3:38 yesterday, in response to the same issue from Bmagic |
| 09:23 |
miker |
or so it looks... |
| 09:27 |
csharp |
miker: great - I see that now - thanks |
| 09:27 |
csharp |
working fine |
| 09:35 |
|
Dyrcona joined #evergreen |
| 10:01 |
|
jvwoolf joined #evergreen |
| 10:02 |
Bmagic |
installing te new hatch 0.1.2 tooo care if it. the only issue remaining was that the browser cannot be configured to "never remember history" |
| 10:03 |
Bmagic |
sorry phone keyboard |
| 10:06 |
kmlussier |
Is the local storage issue with hatch a bug that needs to be fixed or should we be removing the local storage option from the interface so that others don't make the same mistake? |
| 10:06 |
berick |
if it's a bug, I was not aware of it. |
| 10:07 |
berick |
does clearing the cache, etc. wipe out the indexdb too? |
| 10:09 |
csharp |
kmlussier: I think the storage options should be at the very least greyed out if they're going to break things |
| 10:10 |
Dyrcona |
Clear browsing data on Chromium gives a list of things to clear with check boxes. |
| 10:11 |
kmlussier |
We tested this at the hack-a-way, I think. IIRC, clearing the cookies would also clear local storage. I'm not sure about indexdb. |
| 10:11 |
csharp |
also, it's almost certainly my own fault for tuning out, but I was in the dark about Hatch not being used for storage - I thought that was the point (or *a* point) of it |
| 10:11 |
kmlussier |
My preference would be to fix the hatch storage issue. |
| 10:11 |
csharp |
I think Terran did see that it at least unlinked the DB from the instance so even if it doesn't blow away data it's no longer functional |
| 10:12 |
berick |
csharp: we're in transition. the goal is to move critical settings to the server, but we're not there yet |
| 10:12 |
csharp |
berick: gotcha |
| 10:12 |
Dyrcona |
In Chromium, it is "Cookies and other site data" |
| 10:12 |
kmlussier |
csharp: Yes, that's why I raised the question. I recall that hatch couldn't be used for cross-browser local storage, but I thought the goal was to still use it for more stable local storage. |
| 10:12 |
Dyrcona |
There is also "Hosted App Data." |
| 10:12 |
berick |
hatch storage is a stop-gap for people blowing away their 'site data' |
| 10:13 |
berick |
(but again, who does that?) |
| 10:13 |
berick |
meh, doesn't matter |
| 10:13 |
berick |
csharp: so, you installed hatch, turned on storage, then it just stopped working? |
| 10:14 |
csharp |
berick: yes, but I'm not convinced that's the only thing that caused the WSOD in my case |
| 10:14 |
kmlussier |
berick: There are reasons people need to clear their cache, and I think people who do so might also accidentally clear everything else at the same time just because it's all in the same place. |
| 10:14 |
Dyrcona |
berick: A lot of people delete their browser history. I would also think it is very common on kiosks. |
| 10:15 |
* Dyrcona |
clears the cache from time to time but keeps most everything else. |
| 10:15 |
csharp |
same here |
| 10:15 |
* Dyrcona |
sometimes removes individual cookies. |
| 10:15 |
kmlussier |
Also, many tech support communications start with 'did you clear your cache and cookies?' |
| 10:15 |
berick |
Dyrcona: right my sense is history and cache are fair game, but site data is kind of important in general. |
| 10:16 |
berick |
but it doesn't matter, it's going to happen |
| 10:16 |
csharp |
kmlussier: it was our "have you tried turning it off and back on again" response for years ;-) |
| 10:16 |
Dyrcona |
But, as kmlussier is getting to, a lot of our users aren't that sophisticated. |
| 10:16 |
gmcharlt |
kmlussier: but nobody ever offers to trade in real cookies... |
| 10:16 |
csharp |
@dessert gmcharlt |
| 10:16 |
* pinesol_green |
grabs some Moon Pie and some RC Cola for gmcharlt |
| 10:16 |
kmlussier |
gmcharlt: I'm willing to trade in real cookies under the right circumstances. |
| 10:17 |
berick |
csharp: did you migrate settings to Hatch when you enabled it? |
| 10:17 |
* csharp |
drools thinking about the iced Christmas cookies he plans to make soon |
| 10:17 |
* kmlussier |
would never trade real cookies for Moon Pie and RC Cola. |
| 10:17 |
csharp |
berick: yes (I think) |
| 10:17 |
berick |
csharp: k, thanks |
| 10:17 |
csharp |
I'll have to try it again |
| 10:18 |
berick |
csharp: whenver you do, plz consult the console for errors |
| 10:18 |
csharp |
it happened during a training so I couldn't stop and look |
| 10:19 |
* berick |
is quickly turning into the "console logs or it didn't happen" person |
| 10:19 |
csharp |
ok - just did it again - clicked to use hatch for storage, copied settings to hatch, reloaded - wsod |
| 10:19 |
csharp |
and no other UIs seem to work either |
| 10:20 |
csharp |
no console messages |
| 10:20 |
berick |
doh |
| 10:20 |
csharp |
"pending count 1" |
| 10:20 |
csharp |
twice |
| 10:20 |
Dyrcona |
Whee! StackOverflow Q&As that contradict each other on the A from about the same time. |
| 10:20 |
berick |
csharp: log level is verbose? |
| 10:20 |
berick |
well 'all levels' |
| 10:23 |
berick |
arg, unable to duplicate |
| 10:24 |
csharp |
berick: https://pastebin.com/gew2jimw |
| 10:24 |
csharp |
with "verbose" logging |
| 10:24 |
csharp |
similar when I try to enter any interface |
| 10:24 |
csharp |
this is on Chrome 62 on Ubuntu 17.10 |
| 10:24 |
berick |
csharp: that makes it seem like hatch just isn't working |
| 10:25 |
berick |
csharp: if you have time, I have debug options |
| 10:26 |
csharp |
sure |
| 10:26 |
berick |
cool, open a new chrome tab and go to chrome://extensions |
| 10:26 |
berick |
near the top click on 'Develope mode' checkbox |
| 10:26 |
berick |
scroll down to Hatch and clik the 'backgrond page' link |
| 10:26 |
berick |
that opens a new JS console |
| 10:26 |
berick |
see if anything interesting is in there |
| 10:27 |
berick |
normally it shows 'new port connected..' and 'received message from...' |
| 10:27 |
csharp |
yeah, "Hatch disconnected" |
| 10:27 |
csharp |
retrying every 5 seconds |
| 10:28 |
berick |
csharp: ok. is this from the latest hatch installer exe? |
| 10:28 |
berick |
v0.1.3 |
| 10:29 |
berick |
linked in https://bugs.launchpad.net/evergreen/+bug/1733692/comments/5 |
| 10:29 |
pinesol_green |
Launchpad bug 1733692 in Evergreen "Hatch Windows installer doesn't follow best practices" [High,New] |
| 10:29 |
csharp |
is this from the chrome-store-prep branch - I ran/am running hatch.sh |
| 10:30 |
berick |
this is a branch one beyond the chrome prep branch |
| 10:30 |
berick |
and to be clear, you don't manually run hatch.js |
| 10:30 |
berick |
er, hatch.sh |
| 10:30 |
csharp |
I see - then let me work with that one then report back |
| 10:30 |
berick |
csharp++ |
| 10:31 |
csharp |
also, need to find a windows (v)box somewhere |
| 10:31 |
berick |
what have you been testing on? |
| 10:31 |
csharp |
this was Ubuntu 17.10 |
| 10:31 |
berick |
ohhh |
| 10:31 |
berick |
didn't realize |
| 10:32 |
berick |
well, did you update your org.evergreen_ils.hatch.json file after installing the chrome store version? |
| 10:32 |
berick |
~/.config/google-chrome/NativeMessagingHosts/org.evergreen_ils.hatch.json |
| 10:32 |
berick |
specifically "chrome-extension://ppooibdipmklfichpmkcgplfgdplgahl/" |
| 10:33 |
berick |
and of course the 'path' variable needs to point to hatch.sh |
| 10:39 |
csharp |
no, I didn't |
| 11:01 |
|
rlefaive joined #evergreen |
| 11:23 |
|
NatalieMc joined #evergreen |
| 11:24 |
NatalieMc |
Good morning. I am a new Library Director and new to Evergreen. I am looking to create logins for myself and my staff, but am not sure how to do so. Any help would be greatly appreciated! |
| 11:27 |
dbwells |
NatalieMc: Welcome! |
| 11:27 |
NatalieMc |
Thank you! |
| 11:27 |
dbwells |
I think we could use a little more information. |
| 11:27 |
rhamby |
NatalieMc: welcome |
| 11:28 |
rhamby |
NatalieMc: have you been given any logins for the system at all by whoever set it up? |
| 11:28 |
dbwells |
You're library is already using Evergreen, or at least has it set up? |
| 11:29 |
NatalieMc |
We do have it, and it is set up. Currently only one staff person has login information. Is this typical or do all users get login information? |
| 11:29 |
NatalieMc |
(Sorry - like I said, I've never used Evergreen before) |
| 11:30 |
dbwells |
There is a lot of variation, but I would say it is typical for each staff (or at least each desk) to have their own account. |
| 11:30 |
dbwells |
Are you independent, or part of a larger group/consortium using Evergreen? |
| 11:30 |
jeff |
NatalieMc: By any chance are you part of a consortium, such as NTLC? |
| 11:31 |
NatalieMc |
Ok! That is good to know! I am part of the NTLC! |
| 11:31 |
jeff |
NatalieMc: There is some documentation specific to your consortium here, though I note that the documentation on creating staff users is from 2009 and may or may not have changed since then: https://ntlc.ploud.net/consortium-information/files |
| 11:32 |
* dbwells |
will let jeff take over, as he seems to be in the know :) |
| 11:32 |
NatalieMc |
Thank you! |
| 11:33 |
jeff |
NatalieMc: there's some contact information contained here, if you don't have contact information for reaching out to the consortium for Evergreen support already: https://ntlc.ploud.net/consortium-information -- same disclaimer as with the previous link, I'm not sure if that information is current or not. :-) |
| 11:33 |
|
beanjammin joined #evergreen |
| 11:34 |
NatalieMc |
Jeff: Thank you so much. I really appreciate the help. |
| 11:34 |
jeff |
NatalieMc: you're welcome! |
| 11:35 |
Dyrcona |
jeff++ |
| 11:36 |
berick |
vim tabs tip of the day. :-1tabf <filename> -- opens a new tab to the left of the active tab |
| 11:44 |
|
beanjammin joined #evergreen |
| 11:49 |
|
jihpringle joined #evergreen |
| 11:50 |
|
sandbergja joined #evergreen |
| 11:55 |
|
khuckins joined #evergreen |
| 12:11 |
Dyrcona |
After install Evergreen 3.0.2 with OpenSRF master, opensrf.math and opensrf.dbmath do not start. |
| 12:11 |
|
Christineb joined #evergreen |
| 12:11 |
Dyrcona |
But, when I had just OpenSRF installed opensrf.math worked just fine. |
| 12:15 |
Dyrcona |
Umm... I thought master installed the libraries correctly as lib.... Apparently that didn't happen for me. |
| 12:16 |
Dyrcona |
Ok. Never mind, my checkout was behind current master by quite a bit. :) |
| 12:52 |
jeffdavis |
I'm seeing a weird thing on a test server where OPAC iframes within the web client fail to load with a "too many redirects" error - but only in Chrome. If I open dev tools and check "Disable cache" it works fine. |
| 12:54 |
jeffdavis |
The iframes also work fine if I use a subdomain to connect (foo.example.com) but the main domain (example.com) always fails. |
| 12:55 |
jeffdavis |
It seems like I'm getting a redirect loop somehow, so going to Catalog > Search the Catalog does 'GET /eg/opac/advanced' but the server responds with a redirect to /eg/opac/advanced, ad infinitum. |
| 12:57 |
jeffdavis |
I can load /eg/opac/advanced just fine outside the web client. |
| 13:03 |
berick |
jeffdavis: using nginx? |
| 13:03 |
jeffdavis |
yeah |
| 13:04 |
jeffdavis |
I'm going to try without the proxy and see if it makes a difference |
| 13:04 |
berick |
jeffdavis: a similar issue was fixed by making sure apache ServerName and ServerAlias use port 443 instead of the internal apache port (e.g. 7443) |
| 13:04 |
berick |
e.g. |
| 13:04 |
berick |
<VirtualHost *:7443> |
| 13:04 |
berick |
DocumentRoot "/openils/var/web" |
| 13:04 |
berick |
ServerName localhost:443 |
| 13:04 |
berick |
ServerAlias 127.0.0.1:443 |
| 13:05 |
berick |
thanks to csharp |
| 13:05 |
jeffdavis |
I'll try that, thanks |
| 13:11 |
Dyrcona |
typos-- :) |
| 13:15 |
|
jvwoolf joined #evergreen |
| 13:27 |
Dyrcona |
direct_manipulation-- |
| 13:50 |
|
beanjammin joined #evergreen |
| 14:38 |
|
bos20k_ joined #evergreen |
| 14:38 |
|
remingtron joined #evergreen |
| 15:00 |
|
collum joined #evergreen |
| 15:06 |
kmlussier |
Dev meeting today? |
| 15:07 |
Dyrcona |
Oh, that's right. I got nothing to discuss right now, though. |
| 15:09 |
gmcharlt |
can we agree on a postponement to next week? I can wrangle a meeting reminder and agenda call if so |
| 15:09 |
kmlussier |
gmcharlt: Sounds good to me. |
| 15:12 |
Dyrcona |
OK with me, too. |
| 15:12 |
rhamby |
that sounds like seconding the motion and with no dissent ... robert's rules says the motion carries |
| 15:12 |
Dyrcona |
:) |
| 15:13 |
gmcharlt |
there are, apparently, at least two people in the U.S. named "Robert Rules" |
| 15:33 |
|
pinesol_green` joined #evergreen |
| 15:47 |
|
book` joined #evergreen |
| 15:47 |
|
abneiman joined #evergreen |
| 15:48 |
|
book` joined #evergreen |
| 16:11 |
|
khuckins joined #evergreen |
| 16:24 |
jeffdavis |
kmlussier: re bug 1736419 - I can confirm that I'm still seeing the same behavior as you (no ebooks with located URIs in OPAC search) - do you think we should break that out as a separate bug report? |
| 16:24 |
pinesol_green` |
Launchpad bug 1736419 in Evergreen "Search Showing Bibs with no Holdings" [High,Confirmed] https://launchpad.net/bugs/1736419 |
| 16:26 |
kmlussier |
jeffdavis: I've been chatting with mmorgan about that bug. I'm curious - are you seeing that issue with an upgraded database on records that were loaded prior to the upgrade? |
| 16:27 |
* kmlussier |
isn't convinced it's a different bug at the moment and is generally thinking of it as wonky Located URI searching. |
| 16:28 |
jeffdavis |
I'm seeing it both on an upgraded db with pre-upgrade records and on a fresh install. |
| 16:28 |
jeffdavis |
The upgraded server has some Sitka customizations so that could also be a factor for us locally. |
| 16:28 |
kmlussier |
OK, there goes my theory. |
| 16:30 |
kmlussier |
mmorgan wasn't seeing a difference between her 2.12 and 3.0 located URI search results. I had been thinking it might be a similar issue to the one that I reported in comment #7 of https://bugs.launchpad.net/evergreen/+bug/1698206/ |
| 16:30 |
pinesol_green` |
Launchpad bug 1698206 in Evergreen "Eliminate staged search" [Wishlist,Fix released] |
| 16:33 |
kmlussier |
Sorry, that should have been comment #9, not 7. |
| 16:44 |
|
yar joined #evergreen |
| 16:50 |
|
dbwells joined #evergreen |
| 16:50 |
|
remingtron_ joined #evergreen |
| 16:51 |
|
remingtron joined #evergreen |
| 16:57 |
miker |
kmlussier / jeffdavis: JBoyer and I worked on located uri searching in 3.0 at the hack-a-way ... let me check on the status of that |
| 16:58 |
kmlussier |
miker: Is it bug 1730758? |
| 16:58 |
pinesol_green` |
Launchpad bug 1730758 in Evergreen "biblio.record_entry.vis_attr_vector not updated upon adding a locate URI" [Medium,Confirmed] https://launchpad.net/bugs/1730758 |
| 16:58 |
miker |
nope, not that one |
| 17:02 |
|
jonadab joined #evergreen |
| 17:02 |
|
genpaku joined #evergreen |
| 17:03 |
|
genpaku joined #evergreen |
| 17:05 |
|
Jillianne joined #evergreen |
| 17:05 |
miker |
I was thinking of https://bugs.launchpad.net/evergreen/+bug/1723977 |
| 17:05 |
pinesol_green` |
Launchpad bug 1723977 in Evergreen "Searching specific location in Advanced Search not limiting correctly in 3.0" [Medium,Fix released] |
| 17:06 |
|
mmorgan left #evergreen |
| 17:06 |
kmlussier |
miker: OK. The testing I did for bug 1736419 was on a recent master system that should already have that fix on it. |
| 17:07 |
pinesol_green` |
Launchpad bug 1736419 in Evergreen "Search Showing Bibs with no Holdings" [High,Confirmed] https://launchpad.net/bugs/1736419 |
| 17:07 |
jeffdavis |
likewise, I'm still seeing the luri issue on a 3.0.2 server |
| 17:07 |
miker |
kk, so it's something else |
| 17:08 |
miker |
so you're not seeing luri records at all? |
| 17:10 |
jeffdavis |
AFAICT that's correct. |
| 17:11 |
miker |
jeffdavis / kmlussier: do the records in question have a NULL biblio.record_entry.vis_attr_vector? if so, https://launchpad.net/bugs/1730758 may very well be at fault |
| 17:11 |
pinesol_green` |
Launchpad bug 1730758 in Evergreen "biblio.record_entry.vis_attr_vector not updated upon adding a locate URI" [Medium,Confirmed] |
| 17:11 |
kmlussier |
miker: I don't retrieve them at all in a public catalog search. In a staff client search, I retrieve all of them regardless of my scope. |
| 17:12 |
miker |
in which case, my "tomorrow" comment may come true ... tomorrow (the hack-a-way whirlwind whipped that right out of my head) |
| 17:12 |
bshum |
That's better pinesol. |
| 17:13 |
miker |
kmlussier: that suggests you have a NULL bre.v_a_v, as that's how staff search would look at that situation |
| 17:13 |
miker |
good news is, the upgrade script to correct the data should be very targetted and not too painful in terms of run time |
| 17:14 |
kmlussier |
miker: Well, whatever day it gets fixed will be tomorrow on whatever day precedes it. :) |
| 17:16 |
jeffdavis |
I have a test server where a record with located URIs and non-null vis_attr_vector doesn't show in OPAC search. |
| 17:16 |
jeffdavis |
That server has some customizations though, I'll see if I can confirm on a server running vanilla EG. |
| 17:17 |
miker |
jeffdavis: thanks |
| 17:17 |
kmlussier |
miker: I'm seeing null in that field for my two test records. |
| 17:17 |
miker |
kmlussier: good, that's helpful. thanks |
| 17:19 |
kmlussier |
I'll make a comment on bug 173641. I don't think I'll mark it as a duplicate yet since the behavior rjackson described for public catalog searches is a little different. |
| 17:19 |
kmlussier |
Wrong bug number. You all know what I meant. |
| 17:19 |
miker |
kk, thanks |
| 17:25 |
miker |
ah... I think I see it. it'll be at least tomorrow for a fix, though |
| 18:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 20:10 |
|
beanjammin joined #evergreen |
| 20:11 |
|
Dyrcona joined #evergreen |
| 20:11 |
Dyrcona |
I know no one is likely to be around, but here goes. |
| 20:12 |
Dyrcona |
I'm updating from 2.12.6 to 2.12.8. |
| 20:12 |
Dyrcona |
On my utility server, cstore isn't running if I do osrf_control --diagnostic. |
| 20:12 |
Dyrcona |
However, syslog shows it connecting successfully to the database, then nothing. |
| 20:13 |
Dyrcona |
Dec 6 20:06:05 util open-ils.cstore: [INFO:3339:oils_sql.c:210:] open-ils.cstore successfully connected to the database |
| 20:13 |
Dyrcona |
Same thing happens if I restart-all with force-clean-process. |
| 20:14 |
Dyrcona |
syslog says it connected, but diagnostic a little bit later says it's not running. |
| 20:14 |
Dyrcona |
ps ax | grep cstore shows nothing running either. |
| 20:15 |
Dyrcona |
Same thing is happening with pcrud and reporter-store |
| 20:24 |
Dyrcona |
Nothing to indicate a problem in the logs. |
| 20:28 |
Dyrcona |
Hmm.... I may have to shut everything down. That wasn't the plan. |
| 20:29 |
Dyrcona |
It looks like dropping the actor.usr unaccent indexes is hung up on locks. |
| 20:33 |
Dyrcona |
Cancelling that upgrade script resolves the db connection issue. |
| 20:33 |
Dyrcona |
Guess I'll continue without the unaccent fixes for now. I'll have to find a time to shut everything down to run that upgrade script. |
| 20:41 |
Dyrcona |
@monolog |
| 20:41 |
pinesol_green |
Dyrcona: Thank you Dyrcona! But our princess is in another castle! |
| 20:42 |
Dyrcona |
@monologue |
| 20:42 |
pinesol_green |
Dyrcona: Your current monologue is at least 16 lines long. |
| 21:06 |
Dyrcona |
Grr..... |
| 21:06 |
Dyrcona |
Looks like NFS messes with things, too.... |
| 21:13 |
csharp |
Dyrcona: add CONCURRENTLY to the index drops and creates |
| 21:13 |
Dyrcona |
I've moved on. :) |
| 21:13 |
csharp |
gotcha |
| 21:14 |
Dyrcona |
But, yeah, I'll do that later. Thanks for the suggestion. |
| 21:37 |
|
Dyrcona joined #evergreen |
| 21:37 |
Dyrcona |
So, my laptop suddently decided that it doesn't like Verizon's DNS servers. |
| 21:37 |
Dyrcona |
I am now tethered to my cell phone. |
| 21:37 |
Dyrcona |
Picks a fine time to do this to me. |
| 21:44 |
Dyrcona |
This is gonna take longer than I planned, but having DNS issues wasn't part of the plan. |
| 21:45 |
Dyrcona |
Throws the rhythm off and I'm not sure where I was at this brick.... |
| 21:50 |
Dyrcona |
csharp: I'll do that db upgrade in tomorrow night's regular updates. |
| 23:04 |
Dyrcona |
Oh. I can't use a transaction if I drop index concurrently according to the documentation. |
| 23:04 |
* Dyrcona |
thinks that is "dangerous." |
| 23:21 |
Dyrcona |
So, my network issue naturally has something to do with systemd-resolved...... |
| 23:23 |
Dyrcona |
Going to untether and try wifi again. |
| 23:25 |
|
Dyrcona joined #evergreen |
| 23:26 |
Dyrcona |
Well, whatever it was seems to be resolved now. Maybe Verizon had some issue? |
| 23:26 |
Dyrcona |
Signing out again and going to bed. It has been a long evening. |
| 23:27 |
Dyrcona |
csharp++ # For recommending that I drop the indexes concurrently. |
