Time |
Nick |
Message |
00:19 |
|
mrisher joined #evergreen |
00:20 |
|
mrisher joined #evergreen |
00:23 |
|
Stompro joined #evergreen |
00:39 |
|
mrisher joined #evergreen |
00:39 |
|
mrisher joined #evergreen |
01:09 |
|
sandbergja joined #evergreen |
06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
06:16 |
|
yar joined #evergreen |
06:23 |
|
RBecker joined #evergreen |
06:23 |
|
devted joined #evergreen |
06:46 |
|
agoben_ joined #evergreen |
07:20 |
|
rjackson_isl_hom joined #evergreen |
07:28 |
|
Dyrcona joined #evergreen |
08:08 |
|
alynn26 joined #evergreen |
08:38 |
|
mmorgan joined #evergreen |
08:53 |
|
collum joined #evergreen |
08:56 |
|
Stompro joined #evergreen |
09:14 |
|
dbwells joined #evergreen |
09:16 |
|
rfrasur joined #evergreen |
09:21 |
Dyrcona |
Ah ha! My problem is the org_close_overlap function: https://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/Application/Storage/Publisher/actor.pm#l363 |
09:23 |
Dyrcona |
eby++ # Again, for unexpected synchronicity: http://irc.evergreen-ils.org/evergreen/2019-01-24#i_392181 |
09:24 |
eby |
don't think i got to that feature request |
09:37 |
Dyrcona |
Except....I see the queries running that match that SQL exactly. However, I don't see any calls to the storage method in the logs. Also, there are two definitions for the function! |
09:38 |
Dyrcona |
https://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/Application/Storage/Publisher/actor.pm#l350 |
09:38 |
Dyrcona |
"That's a bingo!" |
09:39 |
Dyrcona |
Well, one of those similar loops. At least I have something to test. |
09:40 |
mmorgan |
Dyrcona++ |
09:40 |
Dyrcona |
Also, I'm not clear on the difference between api level 1 and api level 0. How would I know which is being used? |
09:51 |
Dyrcona |
request open-ils.storage open-ils.storage.actor.org_unit.closed_date.overlap 207, "2020-10-16T16:30:43-0400" |
09:52 |
Dyrcona |
This one "hangs" on my test server. |
09:54 |
Dyrcona |
And, there's a query running from time to time checking "random" dates. |
09:54 |
Dyrcona |
Now, to see what's so special about 2020-10-16. |
09:55 |
|
mantis1 joined #evergreen |
09:57 |
Dyrcona |
Another thing that I can never remember: actor.hours_of_operation.dow_0_* is Monday? |
10:00 |
Dyrcona |
Also, the client gave up with "received no data from server," but the queries are still showing up on the db server. |
10:01 |
Dyrcona |
I don't suppose there's a way to find the client PID for a storage process running queries against postgres? |
10:01 |
berick |
Dyrcona: pg_stat_activity will show client pid, but not useful if you have a pgpool, etc. in the middle |
10:02 |
mmorgan |
Dyrcona: Is there anything odd about the org_unit_closed entries for that library? |
10:02 |
|
terranm joined #evergreen |
10:02 |
* berick |
is considering adding pid to the application_name |
10:03 |
Dyrcona |
mmorgan: It's only open 1 day/week. Closed on Friday, near as I can tell. The 16th blows up, but the 30th, another Friday, doesn't blow up. |
10:03 |
terranm |
gmcharlt: JBoyer: mmorgan: does the targeting on this look right now? https://bugs.launchpad.net/evergreen/3.6/+bug/1017990 |
10:03 |
pinesol |
Launchpad bug 3 in mono (Ubuntu) "Custom information for each translation team" [Undecided,Fix committed] |
10:04 |
Dyrcona |
berick: I see client addr and client port, but not client pid in pg_stat_activity. pid is the backend pid. |
10:05 |
Dyrcona |
I'm going to shutown the backend pid and see what happens. |
10:05 |
JBoyer |
terranm, the 3.6 series isn't strictly necessary but otherwise yes. |
10:06 |
berick |
Dyrcona: doh, I'm thinking of port :\ |
10:06 |
terranm |
JBoyer++ |
10:06 |
JBoyer |
terranm, oh, and you may as well duplicate the Importance |
10:06 |
mmorgan |
terranm: and also duplicate the Status |
10:06 |
terranm |
Will do, thx |
10:07 |
Dyrcona |
berick: Yeah, I can use the port and addr combination to kill the drone, I think, but I'm not sure how opensrf will react. |
10:07 |
berick |
Dyrcona: if the drone is busted, kill it. the listener will just spawn a new one (if needed) |
10:08 |
JBoyer |
Does anyone recall if we have any specific preferences for deleting obsolete series or just leaving them marked wontfix on bugs? That example has 7 rows now, one for 3.1 - 3.6 plus non-targeted. |
10:08 |
JBoyer |
terranm++ |
10:08 |
Dyrcona |
canceling the backend seems to work. |
10:09 |
Dyrcona |
JBoyer: I'm not sure it is documented anywhere. I guess it is up to the individual's discretion. I think I'd lean towards wontfix versus invalid. |
10:09 |
mmorgan |
Also, can old series targets be recycled? For example, change a 3.1 series with status Won't Fix to 3.6.1 series with the appropriate status? |
10:10 |
Dyrcona |
mmorgan: Drop the 3.1 series and add the 3.6 series. |
10:10 |
Dyrcona |
Now, that I think about it. If the bug is going forward, I'll often drop the old series. |
10:10 |
JBoyer |
Dyrcona, I mean if a bug is still valid but has old series targeted. Keep the history or keep them tidy. (I lean toward tidy myself) |
10:11 |
JBoyer |
Sounds like we're on the same page |
10:11 |
JBoyer |
Dyrcona++ |
10:12 |
Dyrcona |
JBoyer++ |
10:12 |
Dyrcona |
mmorgan++ # For clarifying my thought on the question that I didn't completely understand. |
10:13 |
mmorgan |
Dyrcona: JBoyer: Does dropping the 3.1 and adding the 3.6 have a different result than recycling the 3.1? |
10:13 |
JBoyer |
Other than the fact that LP won't let you do that, no I suppose not. :) |
10:13 |
mmorgan |
It won't? |
10:13 |
* mmorgan |
is going to try :) |
10:14 |
JBoyer |
Well, we don't want to end up in a situation where there's a 3.2 target with a 3.5 milestone. I don't think you can change the series targets once they exist. |
10:15 |
mmorgan |
Oh Ok, I get it now |
10:15 |
JBoyer |
Now, if there are *no* series targeted (the Affected column just has Evergreen in it) then you can just change the milestone, yeah. |
10:15 |
mmorgan |
JBoyer++ |
10:15 |
JBoyer |
mmorgan++ |
10:15 |
Dyrcona |
I'm also getting results from the overlap function that don't make sense..... |
10:16 |
Dyrcona |
If I check for tomorrow, it says the library is closed from 10/16 to 10/28. If I check for today, when they're open, nothing comes back. |
10:17 |
Dyrcona |
If I check for yesterday, it says that the library is closed from 10/19 through today at 4:30. |
10:19 |
Dyrcona |
Looks like it only checks the date and returns whatever time it is given. |
10:19 |
Dyrcona |
This is all kinds of buggy. |
10:21 |
jeff |
ERROR: invalid input syntax for type money: "8paperbackcopies" |
10:21 |
rfrasur |
err |
10:22 |
rfrasur |
I wanna pay my bills using paperback books. |
10:22 |
jeff |
seven swans a swimming... |
10:22 |
berick |
that's valid barter currency |
10:22 |
rfrasur |
yep yep |
10:23 |
Dyrcona |
Five cans of souuup! |
10:24 |
rfrasur |
lol, that's very revolutionary of you, Dyrcona. |
10:27 |
Dyrcona |
Well, food for fines is a thing. |
10:29 |
rfrasur |
Yes. It is. I was referring to current cultural soup can references. |
10:29 |
Dyrcona |
Canceling the backend only works for some of these. I canceled one, and that backend is running another, related query now. |
10:30 |
Dyrcona |
Current cultural references? |
10:30 |
rfrasur |
lol, I'll leave to you to track down or not. I'd go with "don't." It's political crap and I regretted it as soon as I said it. |
10:31 |
Dyrcona |
My score in Post-Ruin Culture is low. I'm only up on Pre-Ruin Culture. <- Obscure '80s RPG reference |
10:31 |
Dyrcona |
Dunno, but a soup can forge can come in handy. :) |
10:32 |
rfrasur |
I think it's worth prioritizing your current score balance. |
10:35 |
Dyrcona |
:) |
10:35 |
Dyrcona |
Looks like I'm going to have to kill the drones. One of them, at least, keeps coming back. |
10:51 |
Dyrcona |
This is tedious |
11:05 |
Dyrcona |
Well, that's all of the ones running, now. I suspect more will start up after the library opens this afternoon. At least, I'll know what to look for in the logs. |
11:06 |
|
dbwells joined #evergreen |
11:46 |
csharp |
I just removed 3.1 targets from the remaining open bugs, FYI |
11:46 |
rfrasur |
csharp++ |
11:48 |
terranm |
csharp++ |
11:50 |
|
jihpringle joined #evergreen |
11:55 |
|
sandbergja joined #evergreen |
11:56 |
mmorgan |
csharp++ |
11:59 |
|
Christineb joined #evergreen |
12:20 |
JBoyer |
terranm++ # I'm already applying cleanup to things. |
12:20 |
terranm |
Great! |
12:30 |
|
dbwells joined #evergreen |
13:07 |
|
collum joined #evergreen |
13:36 |
|
JonGeorg joined #evergreen |
13:43 |
|
dbwells joined #evergreen |
13:57 |
JonGeorg |
Hello. I am having an issue removing duplicate digital bookplates from an item record. I added the extra permissions, to myself and the user in question and am following the documentation on https://docs.evergreen-ils.org/3.2/_removing_item_tags_from_items.html including with and without hitting Apply first. I've used other browsers and computers, |
13:57 |
JonGeorg |
with the same results. Bug #1761615 could be related. Has anyone else had similar issues removing them? |
13:57 |
pinesol |
Launchpad bug 1761615 in Evergreen "deleting an item does not remove its copy tags" [Undecided,Confirmed] https://launchpad.net/bugs/1761615 |
14:10 |
JonGeorg |
Another issue is that when cron runs /etc/profile && /openils/bin/bookbag_update.pl I'm getting a loghandler error. I can't find anything on that error, but am getting the impression that it's an undefined function within perl, but that doesn't make any sense. |
14:12 |
|
dbwells joined #evergreen |
14:14 |
|
Dyrcona joined #evergreen |
14:19 |
Dyrcona |
JonGeorg: Pasting the exact error message somewhere would be helpful, but I'll wager that your environment is not properly setup in cron. |
14:20 |
Dyrcona |
In short, sourcing /etc/profile or /etc/.bashrc doesn't work in cron on modern Linux, because most default versions of the .bashrc ship with code that exits if it is not being run from an interactive shell. |
14:21 |
Dyrcona |
Sorry, didn't mean /etc/... I actually meant /home/user/.profile and /home/user/.bashrc. Unless you edited it /etc/profile won't either. |
14:22 |
Dyrcona |
The fix is to set the environment variables at the top of the crontab. |
14:24 |
Dyrcona |
In fact, I'd discourage source environment files in favor of setting the variables in the crontab. |
14:25 |
Dyrcona |
terranm++ # Bug wrangling. |
14:26 |
Dyrcona |
JonGeorg: Barring the environment, you're likely missing a Perl package. |
14:30 |
Dyrcona |
So, I can consistently make open-ils.storage.actor.org_unit.closed_date.overlap spin for this one org unit with a date of 2020-10-16. |
14:31 |
Dyrcona |
Now, to figure out why. |
14:33 |
Dyrcona |
Killing the drone is the only reliable way to stop it. |
14:33 |
Dyrcona |
I just got lucky on my test server last time that I canceled the postgres backend. |
14:33 |
JonGeorg |
This was an issue from a while back, so I was looking through my notes. The issue was when we tried to manually run the command. This is from an inherited system. There are no errors in syslog. So I'm thinking it was an error with how I was attempting to run the command manually, as we were trying to see if an update to the bookbag had been |
14:33 |
JonGeorg |
populated or not. It was telling me the error was on line78 which is the "$log = new Loghandler($logFile);" line and I couldn't find any reference to that function anywhere. I think I might have gone down a rabbit hole over nothing. I'll do some more checking to make sure it's working correctly. |
14:38 |
Dyrcona |
JonGeorg: I'm not find any script by the name of bookbag_update.pl i the source code. |
14:38 |
* Dyrcona |
can type gud.... ;) |
14:50 |
abneiman |
terranm++ csharp++ # all the bug wranglin' |
14:51 |
csharp |
yeehaw! |
14:53 |
Dyrcona |
Bleh. Trying to make something standalone from the publisher code feels like too much work. |
14:54 |
JonGeorg |
Looking over it all again with a fresh, non-panicked eye :) , it looks like it was written for our consortia probably by my predecessor. |
14:57 |
Dyrcona |
It would be nice if I could use a debugger on this code. |
14:57 |
Dyrcona |
JonGeorg: Did you recently upgrade the O/S on the machine where you're having this problem? |
14:59 |
|
abowling joined #evergreen |
14:59 |
rfrasur |
https://meet.google.com/hve-jeby-cte |
14:59 |
Bmagic |
we're here https://meet.google.com/hve-jeby-cte&sa=D&source=calendar&ust=1603647947391000&usg=AOvVaw19TNt-dV5CL9VQ2KD31zb_ |
15:00 |
rfrasur |
If you wanna come to the New Developers Working Group |
15:00 |
JBoyer |
JonGeorg, I think bookbag_update.pl may be a filename used in the pre-3.4 carousels that MEC made available, if that helps you track things down |
15:02 |
Bmagic |
JonGeorg - bookbag_update.pl is a "custom" script - and if you have been running it before and suddenly it's not working - I would guess that your version of Perl updated? If so, that script might* need a new line added to the top "use lib qw('.');" |
15:03 |
Dyrcona |
Bmagic: That probably works, but there are better solutions. BTW, did you that I marked your bug a duplicate of mine? |
15:04 |
Dyrcona |
Trouble with using '.' is it changes depending on where you run the command. |
15:05 |
JonGeorg |
No the OS was last upgraded a while ago, before we noticed the issue. But worth checking. Thanks. |
15:05 |
Bmagic |
Dyrcona: if you are referring to the SIPServer bug I reported - yes, jeff marked it duplicate |
15:05 |
JonGeorg |
I look into when perl was last updated thanks |
15:06 |
Bmagic |
JonGeorg: Dyrcona makes a good point - in that if you find that you need to add that line to the top of that script, then you will likely need to also change your cronjob to cd into the working directory before executing the script |
15:07 |
Dyrcona |
Bmagic JonGeorg: It's better to put your Perl libraries somewhere specific and specify that directory. |
15:08 |
Bmagic |
agreed |
15:10 |
Dyrcona |
Too bad kivilahtio's debuggin instruction don't work anymore. They stopped working for me somewhere around Ubuntu 16.04. |
15:18 |
Dyrcona |
Hm... |
15:19 |
Dyrcona |
I discovered something interesting by removing this library's closed dates. The default start and end for the closed spanset runs from 10/11 to 10/21 for 10/16. The end is correct. They're open today, but they weren't open on the 10th. |
15:20 |
Dyrcona |
In fact, they were last open on the 14th, so I think it should be from the 15th to the 21st, no? |
15:21 |
Dyrcona |
My suspision now is that the closed on the 12th was breaking things because a) it is right after the 11th and b) the library is normally closed. |
15:21 |
Dyrcona |
I'm going to put that date back and see what happens. |
15:23 |
Dyrcona |
Nope. It's not that date by itself. |
15:48 |
Dyrcona |
Well, I found my culprit date, though I don't know exactly why it causes this particular problem. On the plus side, it's not that likely to happen again. |
16:06 |
|
terranm joined #evergreen |
16:15 |
|
jihpringle joined #evergreen |
16:16 |
rfrasur |
Dyrcona++ |
16:37 |
csharp |
Dyrcona: it's almost worse when you go through all that and realize it's a one-time thing |
16:37 |
csharp |
then in 3 years you'll be back wondering what it was before :-) |
16:45 |
Dyrcona |
Well, I don't think it will happen for this library again this year. |
17:05 |
|
sandbergja joined #evergreen |
17:06 |
|
mmorgan left #evergreen |
17:39 |
berick |
terranm++ bug-wrangle-mania++ |
18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
19:14 |
|
jihpringle joined #evergreen |
19:38 |
|
dbwells joined #evergreen |
20:16 |
|
dbwells joined #evergreen |
20:55 |
|
jvwoolf1 joined #evergreen |
21:30 |
|
jvwoolf joined #evergreen |
21:59 |
|
sandbergja joined #evergreen |