| Time |
Nick |
Message |
| 07:01 |
|
agoben joined #evergreen |
| 07:15 |
|
rjackson_isl joined #evergreen |
| 07:16 |
|
bos20k joined #evergreen |
| 07:38 |
|
bdljohn joined #evergreen |
| 07:39 |
|
bos20k joined #evergreen |
| 07:55 |
gmcharlt |
starting maintenance on git.evergreen-ils.org |
| 07:58 |
|
littlet joined #evergreen |
| 08:11 |
|
Dyrcona joined #evergreen |
| 08:21 |
|
abowling1 joined #evergreen |
| 08:36 |
|
mmorgan joined #evergreen |
| 08:52 |
Dyrcona |
gmcharlt++ |
| 08:55 |
gmcharlt |
and the maintenance is now complete |
| 09:04 |
csharp |
gmcharlt++ |
| 09:06 |
JBoyer |
gmcharlt++ |
| 09:22 |
|
aabbee joined #evergreen |
| 09:27 |
|
jvwoolf joined #evergreen |
| 09:49 |
|
abowling joined #evergreen |
| 09:52 |
|
terran joined #evergreen |
| 10:08 |
gmcharlt |
git.evergreen-ils.org now has an SSL cert and redirects HTTP to HTTPS |
| 10:09 |
gmcharlt |
this shouldn't cause any problems... but if it does, please let me know |
| 10:09 |
Dyrcona |
It works for me. |
| 10:14 |
gsams |
I've run into an odd issue with an item that refuses to check in, but doesn't throw a visible error. It just sounds the error. I checked the console and it shows "Possibly unhandled rejection' |
| 10:16 |
|
Christineb joined #evergreen |
| 10:18 |
mmorgan |
gsams: Anything unusual about the item? Any checkin modifiers turned on? |
| 10:19 |
gsams |
mmorgan: As far as I can tell, there is nothing special about the item. It's an item loaned to a different library's patron, but on return there was no method of checkin that would work. |
| 10:20 |
gsams |
Pulled up their account and right clicked the item, tried scanning it with no modifiers, item status screen, all produce the error sound but no visible error. |
| 10:21 |
JBoyer |
anything interesting in the logs? |
| 10:23 |
JBoyer |
There may be nothing since an unhandled exception happens because the JS missed something, but maybe something unusual stands out. |
| 10:26 |
gsams |
JBoyer: I'm not seeing anything, but I may need to dig a bit more. |
| 10:26 |
mmorgan |
Any clue in item status? A transit with no Receive or Cancel time? |
| 10:26 |
gsams |
well, maybe I am. |
| 10:27 |
gsams |
Nothing in Item status is out of the ordinary for a checked out item. |
| 10:27 |
gsams |
It does have a transit with no receive or cancel time |
| 10:28 |
gsams |
only one |
| 10:28 |
gsams |
So it's not able to write a new transit because the old one is still open I'm guessing? |
| 10:28 |
JBoyer |
That may confuse the checkin process since it's not supposed to be possible to be checked out and in transit at the same time. |
| 10:29 |
JBoyer |
Oh, if the item doesn't belong where it's returned that transit will break things. |
| 10:29 |
mmorgan |
gsams: Try cancelling the transit in item status, then checking it in again. |
| 10:29 |
gsams |
mmorgan++ #that worked |
| 10:30 |
gsams |
I wonder what caused that to happen. |
| 10:30 |
JBoyer |
mmorgan++ sleuthing |
| 10:31 |
* mmorgan |
is always suspicious of hanging transits. |
| 10:31 |
JBoyer |
gsams, it's still possible to scan items "too fast" when checking things out, one fills a hold, the second tries to send the item home. :( |
| 10:31 |
JBoyer |
(or somehow a request is sent twice, how it happens is a little up in the air) |
| 10:32 |
mmorgan |
Maybe when it was checked out, it was In transit? And the checkout didn't handle cancelling the transit? |
| 10:32 |
JBoyer |
the timestamps would help answer that. I think the examples we've seen locally put the checkout and transit within a second of each other. |
| 10:36 |
gsams |
Now I just need to figure out what happened when a library checked a book in, but ended up with a different book and barcode number displaying. |
| 10:37 |
Dyrcona |
Bad scan? Typo if they entered it manually. |
| 10:37 |
gsams |
Well, normally I'd think that'd be the case, but it was one library trying to fulfill a hold for another, and the item that came up instead was from a completely different third library. |
| 10:37 |
Dyrcona |
We had a library that had their scanner on a stand with a window behind it, and it would "scan" passing cars at certain times of the day, when the reflection from the sun was just right. |
| 10:38 |
Dyrcona |
Still could be a bad scan couples with autocomplete in the browser. |
| 10:39 |
mmorgan |
@blame physics |
| 10:39 |
pinesol |
mmorgan: physics is NOT CONNECTED TO THE NETWORK!!! |
| 10:40 |
Dyrcona |
That would be...bad. |
| 10:40 |
mmorgan |
:) |
| 10:40 |
JBoyer |
Somebody aimed their ship at "outside" and flipped on the infinite improbability engine. |
| 10:40 |
gsams |
I think Kurzgesagt did a video on that once. |
| 10:41 |
mmorgan |
gsams: So different book, totally unrelated to the hold? |
| 10:42 |
gsams |
Yeah, unrelated to the hold or either of the libraries related to the process. |
| 10:43 |
gsams |
I think, I'm still getting more info on it |
| 10:43 |
* mmorgan |
would tend to agree with Dyrcona, some combination of bad scan/barcode completion. |
| 10:43 |
gsams |
The writeup was... lacking |
| 10:44 |
Dyrcona |
gsams: Is there any other kind of writeup? |
| 10:44 |
Dyrcona |
j/k |
| 10:44 |
csharp |
@band add Lacking Writeup |
| 10:44 |
pinesol |
csharp: Band 'Lacking Writeup' added to list |
| 10:45 |
JBoyer |
Expected: not break Observed: broke Correction: un-break. |
| 10:45 |
mmorgan |
"Possibly unhandled rejection" |
| 10:46 |
JBoyer |
mmorgan, if that's not a band name suggestion I'll say that sprinkling a ton of .catch() methods around the client would help at least allow some things to hit the console logs |
| 10:47 |
Dyrcona |
The "possibly" in that message is too pessimistic. There was an unhandled rejection. |
| 10:47 |
mmorgan |
It's a better band name than error message, certainly. |
| 10:47 |
JBoyer |
++ |
| 10:48 |
Dyrcona |
@band add "Possibly Unhandled Rejection" |
| 10:48 |
pinesol |
Dyrcona: Band 'Possibly Unhandled Rejection' added to list |
| 10:48 |
JBoyer |
I heard @band is opening for the Possibly Unhandled Rejections |
| 10:48 |
JBoyer |
Not how that works. :/ |
| 10:49 |
JBoyer |
@band is opening for the Possibly Unhandled Rejections |
| 10:49 |
Dyrcona |
I head [band] is opening for [band] |
| 10:49 |
* JBoyer |
throws hands up, returns to the toil. |
| 10:49 |
Dyrcona |
Ah, [band] only works in the context of another command |
| 10:49 |
Dyrcona |
@praise [band] for opening for [band] |
| 10:49 |
* pinesol |
Fraud Dog is the very model of a modern major hacker for opening for The EOLI Folk |
| 10:50 |
csharp |
@band |
| 10:50 |
pinesol |
csharp: All The Jeffs |
| 10:50 |
Dyrcona |
Anyway, JBoyer is right about .catch(). An "unhandled rejection" is AngularJS-speak for "an error happened and I don't know what to do with it." |
| 10:51 |
Dyrcona |
Kind of like the network failures we throw in XUL. |
| 10:51 |
csharp |
Unhandled Rejection is the story of basically every Valentines Day before I met my wife |
| 10:51 |
JBoyer |
More Promise spec than Angular, but yes, it's async try/catch. |
| 10:51 |
JBoyer |
csharp++ |
| 10:51 |
JBoyer |
csharp++ |
| 10:51 |
terran |
csharp++ |
| 10:51 |
Dyrcona |
csharp++ |
| 10:51 |
JBoyer |
2 for that one >< |
| 10:52 |
* csharp |
is here all week folks |
| 10:52 |
Dyrcona |
@quote add '<csharp> Unhandled Rejection is the story of basically every Valentines Day before I met my wife' |
| 10:52 |
pinesol |
Dyrcona: The operation succeeded. Quote #193 added. |
| 10:53 |
Dyrcona |
JBoyer++ for correcting my slightly erroneous statement. |
| 10:54 |
JBoyer |
Just want the log people to know that JS has come a long way since Netscape, even if I still don't like a whole lot about it. |
| 10:55 |
Dyrcona |
:) |
| 10:55 |
csharp |
I'm still on the "catching every other word" level of JS fluency |
| 10:55 |
csharp |
one of these days I'm going to have to finish all those half-started Lynda.com classes |
| 11:00 |
gsams |
Dyrcona++ |
| 11:00 |
gsams |
csharp++ |
| 11:00 |
gsams |
JBoyer++ |
| 11:00 |
JBoyer |
There's always Javascript: The Good Parts. ;) |
| 11:02 |
Dyrcona |
Maybe I should finish my ebook copy of that one.... :) |
| 12:06 |
|
beanjammin joined #evergreen |
| 12:06 |
Bmagic |
Did I miss it or is there a bug for columns in the web client grid that are not clickable (sortable) - some are blue and some are black. The "Items Overdue" column for example in the group member details is not sortable |
| 12:09 |
|
jihpringle joined #evergreen |
| 12:21 |
|
Bmagic_ joined #evergreen |
| 12:21 |
|
devted_ joined #evergreen |
| 12:36 |
|
Ndeedee joined #evergreen |
| 12:37 |
terran |
Bmagic: I've seen a number of bugs for missing columns, but don't think I've seen any for the sorting issues. There are quite a lot that aren't sortable, though. |
| 12:50 |
|
nfburton joined #evergreen |
| 12:50 |
|
Christineb joined #evergreen |
| 13:01 |
aabbee |
i'm using the latest version from git. does anyone else get a bunch of "TypeError: "$scope.patron is undefined" messages on javascript console when registering a new patron? |
| 13:02 |
aabbee |
when opening the register patron screen (you don't have to actually save anything). |
| 13:02 |
aabbee |
no errors when editing an existing patron. |
| 13:04 |
JBoyer |
aabbee, have you tried an empty cache and hard reload? (someday we'll have to set up a way to change the name of the JS bundle at build time so "turn it off and back on again" is no longer the first suggestion.) |
| 13:06 |
aabbee |
yes. i've told firefox to not keep http cache when dev console is open, and deleted it from history. i get similar errors (but not as many) in chromium: "TypeError: Cannot read property 'isnew' of undefined" |
| 13:07 |
JBoyer |
Oh, that rings a bell. I think the last time that came up the fm_IDL.xml used by the client was out of date. try copying /openils/conf/fm_IDL.xml to /openils/var/web/reports/ |
| 13:07 |
Dyrcona |
aabbee: I was just going to paste in the error that I get in Chromium on 3.2: TypeError: Cannot read property 'isnew' of undefined |
| 13:08 |
Dyrcona |
I think it's mostly harmless, i.e. just noise, but it should probably be made to go away. |
| 13:09 |
aabbee |
it's louder in FF than Chromium. it doesn't seem to cause any problems, so yes, "just noise". |
| 13:09 |
JBoyer |
Ah, that's true. Were you seeing a failure to operate aabbee, or just noting the errors messages (which would ideally not be there, no...) |
| 13:09 |
aabbee |
just seeing the error messages. it's still functional. |
| 13:09 |
JBoyer |
I've seen things outright break when the IDL is out of sync, but Dyrcona is right, that message is harmless. |
| 13:10 |
Dyrcona |
JBoyer: I'm not sure that error means that the IDL is out of sync, becuase I'm 99% positive that the IDL on this system is up to date. |
| 13:10 |
JBoyer |
I thought a proposed fix for that was posted recently. |
| 13:10 |
Dyrcona |
And, I'm running in an incognito window to avoid cache, etc. |
| 13:10 |
JBoyer |
I think the last time the isnew thing came up there was *also* an issue with the IDL. |
| 13:11 |
Dyrcona |
A fix may have been posted. I can't keep up with everything. :) |
| 13:11 |
aabbee |
Dyrcona: do you have to reregister your workstation every time you reload then? |
| 13:11 |
Dyrcona |
Yes, with incognito windows you do. |
| 13:12 |
Dyrcona |
Not every time I reload. Just every time I close a window and open a new one. |
| 13:12 |
Dyrcona |
It keeps the cache while the window is open. |
| 13:12 |
Dyrcona |
At least on Chromium it seems to. |
| 13:13 |
aabbee |
i was trying to sort out something else ("why does prefix keep showing up even when i set au.prefix.show to false?"), and my console messages were getting drowned out by the errors on FF. /openils/conf/fm_IDL.xml /openils/var/web/reports/fm_IDL.xml are identical. |
| 13:14 |
Dyrcona |
Yeah, bogus error messages get in the way. |
| 13:14 |
* Dyrcona |
checks the IDL files on the server. |
| 13:15 |
Dyrcona |
And, yes, they're identical on the server that I'm using. |
| 13:17 |
aabbee |
tangentially related, why *does* prefix continue to show up on the patron register screen even when the org unit setting is false? skim through of the code looks like it assumes you're using the setting to force the field to remain onscreen when a user selects to show "required fields" as opposed to forcing it to go away. is that a bug, or expected? |
| 13:17 |
JBoyer |
Sorry for the noise, the isnew errors came up during an issue where editing existing users always failed on a username check, that was caused by the IDL, the isnew thing is the JS trying to access that variable before it's set. |
| 13:17 |
JBoyer |
irc_logs++ |
| 13:17 |
aabbee |
JBoyer: broken promises? |
| 13:17 |
JBoyer |
That's one way to look at it, heh. |
| 13:18 |
JBoyer |
But yes, something in the patron controller is likely getting ahead of itself. |
| 13:18 |
* aabbee |
queues division bell by pink floyd |
| 13:19 |
JBoyer |
And I know a lot of the UI can sometimes check various state vars frequently before first paint even. (makes stepping through the debugger great fun.) |
| 13:19 |
* Dyrcona |
thinks the UI is doing too much, but that's a discussion for another time. |
| 13:23 |
aabbee |
yeah, i put some console.logs in the $scope.show_field function, and was surprised by how many times it's called. |
| 13:23 |
aabbee |
even with the ui.patron.edit.au.prefix.show to false, field_visibility.prefix is 0. this is compared (>=) to $scope.edit_passthru.vis_level which is 0 when "All Fields" is selected. to hide the prefix, i'd need to set field_visibility.prefix = -1, but i don't see a way to do that. i can't tell if this is a bug or if i'm just using the setting incorrectly. |
| 13:24 |
Dyrcona |
Sounds like a bug. |
| 13:24 |
Dyrcona |
If I understand correctly, you set visibility of au.prefix to 0, but it still shows up when All Fields is not checked? |
| 13:25 |
aabbee |
yes. well -- i set the au.prefix.show to "false", but that results in field_visibility.prefix === 0 |
| 13:26 |
aabbee |
is $scope.edit_passthru.vis_level supposed to be 0 or 1 when showing "All Fields"? |
| 13:27 |
aabbee |
looks like 0. so if i understand this, the vis_level is good, but field_visibility.prefix needs to be -1 instead of 0. |
| 13:27 |
Dyrcona |
I'm not sure on the latter question, but it would be good to check values of ui.patron.edit.au.prefix.require and ui.patron.edit.au.prefix.suggest also. |
| 13:27 |
aabbee |
i didn't touch suggest, but require is false. |
| 13:28 |
Dyrcona |
Are you having this problem with other fields in the UI? |
| 13:28 |
* Dyrcona |
would suspect yes. |
| 13:28 |
aabbee |
i haven't tried it with anything else. |
| 13:29 |
* Dyrcona |
has a look. |
| 13:31 |
aabbee |
nothing in Open-ILS/web/js/ui/default/staff/circ/patron/regctl.js sets field_visibility to anything less than 0. and "All fields" sets the threshold to 0. so i don't think it'll be possible to hide anything with this setting. of course, i could just remove the field from the template, and it'll be gone. |
| 13:33 |
Dyrcona |
Oh. I think I misunderstood the problem. |
| 13:34 |
Dyrcona |
I thought you meant it was showing up if you did required or suggested fields. You want it to go away completely. |
| 13:34 |
Dyrcona |
I was about to say that the field setting seems to be working as expected for me. |
| 13:35 |
aabbee |
correct. by default, prefix shows up all the time. i want it to go away entirely. i tried setting au.prefix.show = false, and was surprised when it continued to show up. |
| 13:35 |
aabbee |
that's why i couldn't tell if it was a bug or if i wasn't using the setting correctly. |
| 13:36 |
Dyrcona |
It will show up if you select all fields. If you select only required fields, it will disappear. |
| 13:36 |
Dyrcona |
If you never want the prefix to show up, then you'll have to remove it via code or the template. |
| 13:37 |
aabbee |
of course it disappears when i select tonly required fields. it's not a required field :-) |
| 13:37 |
Dyrcona |
I suppose that might be a bug, in all fields. |
| 13:38 |
Dyrcona |
I don't recall what XUL does in this case, but that doesn't mean XUL wasn't buggy, either. :) |
| 13:40 |
Dyrcona |
I think this is worthy of a Lp bug so there can be some discussion of the behavior. |
| 13:40 |
aabbee |
i deleted the au.prefix.{show,require,suggest} settings and get the same behavior as when i explicitly set them all to false. prefix shows up with "All fields", and doesn't show up for "Required fields" or "Suggested fields". so these settings are useful for making things show up, but setting them to false isn't useful for making them go away. |
| 13:40 |
Dyrcona |
Right, and that seems like a bug to me, but one person's bug is another's feature. :) |
| 13:47 |
Dyrcona |
Mabye the bug is using 1 for suggested fields and 2 for shown fields, and also using 0 for the pass thru visibility? |
| 13:48 |
Dyrcona |
I *think* it should be 2 for suggested fields, 1 for shown fields, and passthru visibility should be 1 for all fields, 2 for suggested fields, and 3 for required fields. Seems like changing that would fix it, no? |
| 13:49 |
aabbee |
well, a field's default visibility is 0. so that would make more fields go away than you want. |
| 13:49 |
Dyrcona |
Of course, we'd probably want to use visibility 1 and not 0 for fields where the setting isn't set. |
| 13:50 |
Dyrcona |
:) |
| 13:51 |
aabbee |
it might be easier say that if "au.prefix.show" is set to "false", then field_visibility.prefix should be -1. |
| 13:53 |
Dyrcona |
I don't think the show settings are intended to do what you, I, and logic would think. :) |
| 13:55 |
Dyrcona |
Here's the description for one of them: "The prefix field will be shown on the patron registration screen. Showing a field makes it appear with required fields even when not required. If the field is required this setting is ignored." |
| 13:55 |
Dyrcona |
Setting it to false is not intended to make it go away. |
| 13:56 |
aabbee |
right. "show" is an "opt in" setting, and can't be used for "opt out". i was confused, but the behavior is consistent and makes sense once you know what it's doing. |
| 13:56 |
aabbee |
what i originally thought i wanted is hard (and possibly not worth messing with) because right now it can just pretend unset values are false by default. it could be confusing if we start treating "false" as a different behavior than "null". |
| 13:56 |
Dyrcona |
So, the question is, should setting to false make it disappear when all fields is clicked? That would be a change in behavior. |
| 13:57 |
Dyrcona |
aabbee: It's not that hard to implement. It looks like a few changes in regctl.js. I don't know if that turns up anywhere else. |
| 13:58 |
Dyrcona |
Your idea of setting visibility to -1 is one way to do it. |
| 13:59 |
Dyrcona |
And, yes, that would be simpler than the changes I suggested and shouldn't be too hard to maintain as a local customization. |
| 13:59 |
aabbee |
no, the javascript is easy. (hacking the fields out of the template is also easy.) i meant that it's hard for a user to understand the difference between "false" and "null" if those two things used to mean the same thing. |
| 13:59 |
Dyrcona |
Well, there are reasons for false and null to be different. |
| 13:59 |
csharp |
@decide false or null |
| 13:59 |
pinesol |
csharp: go with null |
| 14:00 |
Dyrcona |
Though, in this case it's more like false versus undefined or not set. |
| 14:00 |
aabbee |
bah. javascript Null was a mistake. yes, i meant undefined. |
| 14:01 |
Dyrcona |
Well, I was thinking in terms of the database. :) |
| 14:01 |
aabbee |
ja, the environment that makes sense :-P |
| 14:02 |
aabbee |
@hates |
| 14:02 |
pinesol |
aabbee hates javascript |
| 14:02 |
Dyrcona |
The current behavior seems confusing to me, until I read the description of one of the settings again. Though, I knew it behaved that way before. |
| 14:03 |
Dyrcona |
false basically doesn't do anything, so no point in setting it. |
| 14:03 |
* Dyrcona |
doesn't like useless setting values. |
| 14:03 |
Dyrcona |
@hates |
| 14:03 |
pinesol |
Dyrcona hates JavaScript; and Launchpad Search |
| 14:03 |
Dyrcona |
:) |
| 14:04 |
Dyrcona |
@loves |
| 14:04 |
pinesol |
Dyrcona loves git; sed; OpenBSD; gnu/emacs; git-quickpick; and tmux |
| 14:04 |
aabbee |
@loves |
| 14:04 |
pinesol |
aabbee: aabbee doesn't seem to love anything. |
| 14:04 |
aabbee |
truf. |
| 14:07 |
Dyrcona |
Setting show to true makes the field show up regardless of which set of fields you've clicked on. |
| 14:07 |
aabbee |
bug 1815950 |
| 14:07 |
pinesol |
Launchpad bug 1815950 in Evergreen "fields should be hidden when the relevant ".show" org unit setting is false" [Undecided,New] https://launchpad.net/bugs/1815950 |
| 14:08 |
aabbee |
let me know if i should edit that. i'm just going to strip this particular field from the template for now, but it'd be neat if this worked by eg4, when the angularjs (and .tt2) stuff goes away so i don't have to do it again :-) |
| 14:11 |
aabbee |
Dyrcona++ |
| 14:17 |
Dyrcona |
aabbee++ # I added a comment describing how I think it should work. |
| 14:17 |
Dyrcona |
We could probably get this in by 3.4 unless someone has a really strong objection to the change. |
| 14:24 |
aabbee |
> can you delete an org_unit setting from an org unit via the client |
| 14:24 |
aabbee |
yes, but it's an older dojo interface. the "edit" button brings up a dialog that has a "delete" button. |
| 14:25 |
Dyrcona |
I thought so, but it has been ages since I've used that interface. Other people do that here, and when I need to do, I just insert, update or delete in the database. |
| 14:33 |
|
jonadab joined #evergreen |
| 15:09 |
|
sandbergja joined #evergreen |
| 15:13 |
|
mmorgan joined #evergreen |
| 15:50 |
sandbergja |
berick: do you have a publically available demo server with your angular staff catalog branch (like the one you showed to the Cataloging Working Group)? |
| 15:55 |
csharp |
here's a weird one: I have a library that when trying to register a new workstation and after selecting their branch, the name disappears from the field and they can't register the station |
| 15:55 |
csharp |
I can confirm the behavior on my own workstation |
| 15:55 |
csharp |
I've cleared the cache, run autogen, then cleared the cache again - same thing |
| 15:55 |
csharp |
and no other library on the list that I've tried has the same behavior |
| 15:56 |
csharp |
I thought it might be because the unit is OPAC visible = false, but others that are not opac visible register fine |
| 15:57 |
csharp |
vendor.bundle.js:6 TypeError: Cannot read property 'shortname' of undefined at t.$scope.register_ws (app.js:925) |
| 15:57 |
csharp |
that's from the end user - I haven't seen that error in FF on my own station yet |
| 15:59 |
csharp |
same behavior in Chrome (also no console error in my case) |
| 15:59 |
csharp |
it appears in the box for a split second, then disappears |
| 15:59 |
csharp |
@monologue |
| 15:59 |
pinesol |
csharp: Your current monologue is at least 10 lines long. |
| 16:00 |
Dyrcona |
csharp: can_have_users on the org unit? |
| 16:01 |
Dyrcona |
or ou_type. I forget where that lives. |
| 16:02 |
csharp |
yes (it's in ou type) it's a branch - nothing special |
| 16:02 |
csharp |
name is HCLS-HQS |
| 16:02 |
csharp |
so no weird unicode or anything |
| 16:03 |
* csharp |
renames the branch HCLS-🦕 |
| 16:04 |
|
stephengwills joined #evergreen |
| 16:05 |
|
stephengwills left #evergreen |
| 16:05 |
csharp |
actually... |
| 16:05 |
csharp |
looking at the existing ws names, looks like there's a trailing space |
| 16:06 |
bshum |
Of course there is |
| 16:07 |
csharp |
that's it |
| 16:07 |
csharp |
jeez |
| 16:08 |
csharp |
so my unicode joke wasn't terribly off the mark :-) |
| 16:08 |
sandbergja |
csharp: I liked your unicode joke! |
| 16:08 |
csharp |
sandbergja: :-) |
| 16:09 |
csharp |
🦄 🐷 🦁 😀 |
| 16:10 |
littlet |
csharp++ |
| 16:14 |
|
jvwoolf left #evergreen |
| 16:17 |
csharp |
argh - still not working - don't know if that's stubborn cache or what |
| 16:17 |
csharp |
I made the name change, then ran autogen, then cleared caceh |
| 16:17 |
csharp |
cache |
| 16:18 |
bshum |
You ran autogen and restarted apache right? Or reloaded, etc. |
| 16:20 |
csharp |
not apache, no |
| 16:21 |
Dyrcona |
Shouldn't have to restart apache after autogen. |
| 16:21 |
bshum |
I don't know if that's changed with web client, don't listen to me |
| 16:21 |
Dyrcona |
never had to, really. |
| 16:21 |
Dyrcona |
:) |
| 16:21 |
bshum |
Uh... |
| 16:21 |
bshum |
In my experience, I always had to |
| 16:21 |
bshum |
But /shrug, maybe I'm remembering wrong |
| 16:22 |
Dyrcona |
My experience has been different. You do have to restart apache after restarting a few services, but not every service. |
| 16:23 |
Dyrcona |
It may just be the router that requires an apache restart now that I think about it, but usually a good idea to restart apache after restarting services. |
| 16:24 |
jihpringle |
csharp: could the cookies in the browser be hanging onto the old branch code? |
| 16:24 |
Dyrcona |
Unrelated, I like how Google's top hits for Postgresql documentation searches always seem to pick on documentation for unsupported releases. I usually get 8.4 or 9.3 docs, unless I search for something added later. |
| 16:24 |
csharp |
probably |
| 16:24 |
Dyrcona |
Try with an incognito or private browsing window. |
| 16:25 |
csharp |
jihpringle++ # yep |
| 16:25 |
csharp |
cookies+- |
| 16:26 |
jihpringle |
workstation registration issues always seem to come down to cookies for us :) |
| 16:26 |
bshum |
Talking about cookies makes me wish I had some to snack on :( |
| 16:27 |
Dyrcona |
@dessert bshum |
| 16:27 |
* pinesol |
grabs some chocolate croissants for bshum |
| 16:28 |
csharp |
@hate cookies |
| 16:28 |
pinesol |
csharp: The operation succeeded. csharp hates cookies. |
| 16:28 |
csharp |
@love Cookies |
| 16:28 |
pinesol |
csharp: But csharp already hates Cookies! |
| 16:28 |
csharp |
heh |
| 16:28 |
Dyrcona |
So, my latest search turns up a link to the 8.2 documentation after a couple of stack overflow links...Really, Google? |
| 16:28 |
csharp |
@blame cookies |
| 16:28 |
pinesol |
csharp: cookies stole csharp's ice cream! |
| 16:28 |
csharp |
@whocares cookies |
| 16:28 |
pinesol |
csharp hates cookies |
| 16:29 |
Dyrcona |
csharp: Have you tried in an incognito or private window? That bypasses cookies and cache, etc. on the browser. |
| 16:29 |
aabbee |
Dyrcona: i added a patch (two whole lines!) to bug 1815950 |
| 16:29 |
pinesol |
Launchpad bug 1815950 in Evergreen "fields should be hidden when the relevant ".show" org unit setting is false" [Wishlist,Confirmed] https://launchpad.net/bugs/1815950 |
| 16:29 |
csharp |
yeah - I have, just knew that wasn't going to solve it for the libraries involved |
| 16:30 |
csharp |
hopefully the fact that the complaint was "I can't register a workstation" means they aren't losing too much in the way of preexisting data |
| 16:31 |
Dyrcona |
aabbee: Cool. |
| 16:36 |
jihpringle |
anyone using the Evergreen self check in 3.1 or 3.2 with audio alerts set to True and hearing the alerts? |
| 16:38 |
jihpringle |
or has the audio alerts set to True and also not hearing them? |
| 16:45 |
bshum |
So, you're saying you're not hearing the sounds? :) |
| 16:45 |
Dyrcona |
jihpringle: I have been told that the sounds do not work for us on 3.0, either. |
| 16:46 |
Dyrcona |
That's even after making sure that the files were copied into the correct locations and seeing the files being served in the apache log files. |
| 16:46 |
Dyrcona |
I didn't get any farther than that. |
| 16:46 |
bshum |
Ah darn, I was going to say the file thing |
| 16:46 |
bshum |
I guess that's not the only reason it's broken then :\ |
| 16:50 |
jihpringle |
thanks Drycona: I'll report it as a bug |
| 17:00 |
jihpringle |
https://bugs.launchpad.net/evergreen/+bug/1815968 |
| 17:00 |
pinesol |
Launchpad bug 1815968 in Evergreen "Evergreen Self Check: Audio Alerts Don't Sound" [Undecided,New] |
| 17:23 |
|
mmorgan left #evergreen |
| 18:17 |
bshum |
berick: One thing I just remembered about 18.04.1 is that it has a missing universe repo, so you have to add it manually before starting the ansible stuff or else it'll bomb unhappily. |
| 18:17 |
bshum |
I see that 18.04.2 is along, I'll try getting a fresh VM built with that ISO and see if they fixed that universe repo missing problem |
| 18:18 |
bshum |
Or maybe this is the new normal... |
| 18:19 |
bshum |
Oh, hmm, they haven't updated the link on ubuntu.com, it's still pointed at 18.04.1 server |
| 18:21 |
bshum |
Reading the 18.04.2 notes, they may have fixed it |
| 18:25 |
bshum |
I guess they'll eventually fix up the links. In the meantime, found the 18.04.2 ISO and will try building that all out |
| 18:36 |
bshum |
Whew, 18.04.2 is good. One less thing to worry about during installs :D |
| 18:37 |
* bshum |
lets ansible do its thing while he eats |
| 22:57 |
* Dyrcona |
has not experienced the problem with 18.04.1 that bshum mentioned earlier because I use the alternate server install image with the old style installer. |
| 22:57 |
|
stephengwills joined #evergreen |
