| Time |
Nick |
Message |
| 02:50 |
|
berick joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live//archive/2022-06/2022-06-08_04:00:02/test.49.html> |
| 07:25 |
|
rjackson_isl_hom joined #evergreen |
| 07:49 |
|
collum joined #evergreen |
| 08:05 |
|
RFrasur joined #evergreen |
| 08:29 |
|
mantis1 joined #evergreen |
| 08:39 |
|
mmorgan joined #evergreen |
| 09:02 |
|
Dyrcona joined #evergreen |
| 09:03 |
Dyrcona |
I just want to say that Chrome has me so frustrated this morning. I had to sign back into Gmail and now it's acting like I've never used Chrome before. |
| 09:17 |
mmorgan |
Dyrcona: Did you find your way to a different Chrome Profile? |
| 09:27 |
Dyrcona |
mmorgan: I ended up with 2 profiles and it looks like neither had my saved data, so I deleted one. |
| 09:28 |
Dyrcona |
There was a checkbox that I ignored. I probably should have checked it. :) |
| 09:28 |
* mmorgan |
dislikes Chrome profiles |
| 09:30 |
mmorgan |
They can be incredibly handy, but I fear exactly what you describe :) |
| 09:31 |
Dyrcona |
I didn't really look at the profile that I deleted very hard. Chances are, it still had my local storage/data. |
| 09:31 |
Dyrcona |
I'll be more careful on my other laptop with Chromium. |
| 09:44 |
Dyrcona |
Ah ha! I found my old profile: It shows up as "Person 1" when I start Chrome. |
| 09:48 |
Dyrcona |
I also went poking in ~/.config/google-chrome/ and saw that the old profile was still there, so looks like I somehow got two new profiles by not checking the keep local storage checkbox. |
| 10:01 |
Dyrcona |
I think the latter happened because Google asked me to sign in again for every Google service tab that I had open: gmail, calendar, gdrive, etc. |
| 10:05 |
Dyrcona |
Probably another Chrome 102 bug, but I won't bother looking. My sources say that nothing changed on our end regarding managed profiles, so.... |
| 10:14 |
|
jvwoolf joined #evergreen |
| 10:57 |
Dyrcona |
A quick grep -R of the code suggests that we may have other places affected by bug 1976403, but I haven't checked them all. |
| 10:57 |
|
mantis2 joined #evergreen |
| 10:58 |
pinesol |
Dyrcona: Error: Could not gather data from Launchpad for bug #1976403 (https://launchpad.net/bugs/1976403). The error has been logged |
| 11:08 |
berick |
pinesol: you're not alone |
| 11:08 |
pinesol |
berick: git diff origin/hamster |
| 11:12 |
* jeff_ |
updates bug 1976403 with Chrome status |
| 11:12 |
jeff_ |
hrm. |
| 11:13 |
pinesol |
jeff_: Error: Could not gather data from Launchpad for bug #1976403 (https://launchpad.net/bugs/1976403). The error has been logged |
| 11:15 |
Dyrcona |
jeff: One of the Chrome bugs blamed a commit from Microsoft for the breakage. |
| 12:01 |
|
jihpringle joined #evergreen |
| 12:29 |
|
scottangel joined #evergreen |
| 12:29 |
|
DaMobi joined #evergreen |
| 12:34 |
|
collum joined #evergreen |
| 12:42 |
|
collum joined #evergreen |
| 13:29 |
|
Guest84 joined #evergreen |
| 14:13 |
|
jihpringle joined #evergreen |
| 15:07 |
mmorgan |
How often do folks run the hold targeter? |
| 15:10 |
jeffdavis |
every 20 minutes here |
| 15:11 |
mmorgan |
jeffdavis: Thanks, we run it every 15 minutes. |
| 15:12 |
berick |
nightly |
| 15:12 |
mmorgan |
We've seen an interesting issue more than once. Age protection was removed from an item. Shortly thereafter, the hold targeter ran and targeted the item for the 49th hold in the queue. |
| 15:13 |
mmorgan |
There were many holds with a higher priority that this item could fill, but hold 49 just happened to be the one that eligible for retargeting at the right time to grab that item. |
| 15:16 |
Dyrcona |
We have an "unusual" hold targeter schedule: every hour on the hour between 7:00 am and 11:00 pm. We've had different schedules in the past because the performance of the hold targeter seems to be affected after some upgrades. |
| 15:16 |
mmorgan |
Seems like if we ran the targeter nightly, that might happen less. But on the other hand, that item wouldn't get targeted until the targeter ran overnight. |
| 15:17 |
Dyrcona |
We also use a 1 hour soft retarget interval. |
| 15:19 |
Dyrcona |
People do get uptight about the queue order, but it's just a guess at best. |
| 15:19 |
mmorgan |
We're not using a soft regarget interval. Maybe that would help. |
| 15:21 |
Dyrcona |
We've experimented with every half hour, every 15 minutes, etc. Then, it started running into itself and it ended up being 1/hour effectively. We skip the hours between midnight and 6:00 am to avoid the overnight jobs that run during those hours. |
| 15:22 |
Dyrcona |
The soft retarget interval might help. John Amundson could probably tell you better why we use it because it was his testing that made us decide on that value. I forget exactly why we ended up with that value. |
| 15:23 |
* mmorgan |
would thing you could end up with a LOT more holds being retargeted using a soft interval. |
| 15:25 |
Dyrcona |
Our "normal" retarget interval is 48 hours to keep things on pull lists a little bit longer. |
| 15:25 |
Dyrcona |
We'd typically see the running into itself happen for a day or so after an upgrade, then it just kept up (probably because of the soft interval), so we changed the schedule. |
| 15:28 |
|
jihpringle joined #evergreen |
| 15:28 |
mmorgan |
Our retarget interval is currently 72 hours |
| 16:06 |
|
jvwoolf left #evergreen |
| 16:37 |
jeffdavis |
Bootstrap CSS is partially fading the links in our OPAC header and footer - does anyone know offhand how to prevent that? |
| 16:48 |
jeff |
I don't see fading in the few catalogs I just tried. Do you have a public URL that can show what you're seeing? |
| 16:50 |
jihpringle |
jeff: https://opepb.upgrade1.catalogue.libraries.coop |
| 16:54 |
jeffdavis |
there's a CSS rule from _hover.scss "color: rgba(255,255,255,.75);" that is being applied, even though the link color from style.css uses "!important" which I think ought to be overriding that |
| 16:59 |
jeff |
if you add the text-white utility class to the <li> elements that seems to fix it. I don't know if that's the best way or not. |
| 17:01 |
jeff |
in Open-ILS/src/templates-bootstrap/opac/parts/footer.tt2 <li class="nav-item"> would become <li class="nav-item text-white"> |
| 17:03 |
jeff |
by default bootstrap is trying to give them a faded-by-default look until you hover over them. |
| 17:06 |
|
jihpringle joined #evergreen |
| 17:09 |
|
mmorgan left #evergreen |
| 17:14 |
jeffdavis |
hm, that doesn't work for me unfortunately |
| 17:17 |
jeffdavis |
we're using skins, I wonder if that is causing trouble |
| 18:00 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live//archive/2022-06/2022-06-08_16:00:03/test.49.html> |
| 22:45 |
jeff |
jeffdavis: do you see the text-white class in the output html and it isn't working, or does that class not make it to the html seen by the browser? |
