Time |
Nick |
Message |
07:01 |
|
collum joined #evergreen |
07:05 |
|
rjackson_isl_hom joined #evergreen |
07:36 |
|
mantis1 joined #evergreen |
07:46 |
|
BDorsey joined #evergreen |
08:07 |
|
rfrasur joined #evergreen |
08:32 |
|
rjackson_isl_hom joined #evergreen |
08:38 |
|
mmorgan joined #evergreen |
09:39 |
|
Dyrcona joined #evergreen |
10:41 |
|
tlittle joined #evergreen |
11:06 |
|
jihpringle joined #evergreen |
11:14 |
|
mixo joined #evergreen |
11:14 |
mixo |
Hello |
11:15 |
mixo |
I am trying to install evergreen on debian 11 |
11:16 |
mixo |
I get an error: Package python-nose is not available, but is referred to by another package. |
11:16 |
mixo |
This may mean that the package is missing, has been obsoleted, or |
11:16 |
mixo |
is only available from another source |
11:16 |
mixo |
E: Unable to locate package python-coverage |
11:16 |
mixo |
E: Unable to locate package python-libxml2 |
11:16 |
mixo |
E: Unable to locate package python-memcache |
11:17 |
mixo |
what can I do? |
11:29 |
Dyrcona |
Install a more recent version of Evergreen. It looks like the one you're trying to install is missing the commit to remove the Python dependencies. |
11:48 |
mixo |
Sorry more precisely I get this error when I try to install opensrf-3.2.2 |
11:49 |
mixo |
There is no later version |
11:50 |
Dyrcona |
mixo: Oh, OK. Install OpenSRF from a git clone. I don't think that has made it to a tarball, yet. |
11:50 |
mixo |
OK. Thank you. |
11:51 |
Dyrcona |
Yeah, the fix is in the rel_3_2 branch in git. |
11:51 |
Bmagic |
mixo: what Dyrcona said. Those python packages that you mention are still referenced in the OpenSRF install code, but are no longer available in the debian repo's |
11:51 |
Dyrcona |
Or, you can install the master branch. It works with all current Evergreen releases. |
11:52 |
Bmagic |
we use this trick sed -i '/python-memcache/ s/python-memcache//' src/extras/Makefile.install && sed -i '/python-pyxmpp/ s/python-pyxmpp//' src/extras/Makefile.install |
11:53 |
* Dyrcona |
uses Git. |
11:56 |
mixo |
Thank you very much |
12:22 |
Dyrcona |
@decide cheesecake or peach pie |
12:22 |
pinesol |
Dyrcona: go with peach pie |
12:22 |
Dyrcona |
pinesol: I believe I will. |
12:22 |
pinesol |
Dyrcona: Your computer account is overdrawn. Please reauthorize. |
12:22 |
* mmorgan |
will take the cheesecake! |
12:26 |
* Dyrcona |
totally forgot about the Bertucci's pizza dough rolls! |
12:26 |
Dyrcona |
@dessert mmorgan |
12:26 |
* pinesol |
grabs some Browser Cookies for mmorgan |
12:26 |
Dyrcona |
heh |
12:26 |
mmorgan |
:) |
12:26 |
mmorgan |
Thanks for the thought, anyway! |
12:27 |
mmorgan |
Those pizza dough rolls are the best! |
12:28 |
Dyrcona |
Yeah we went to Bertucci's last night and they gave us some to take home with out leftovers. |
12:29 |
Dyrcona |
mmorgan: It's caramel turtle cheesecake from last weekend. It's probably still good. :) |
12:29 |
Dyrcona |
The peach pie is from Mann's Orchard in Methuen, and it's only a couple of days old. |
12:29 |
mmorgan |
Dyrcona: Have some of each! |
12:30 |
Dyrcona |
:) |
12:30 |
Dyrcona |
Maybe I'll have some cheesecake later. |
13:02 |
|
collum joined #evergreen |
13:10 |
|
jihpringle joined #evergreen |
13:15 |
Dyrcona |
So, I'm going to recommend against a self-hosted GitLab for the community. I've had some minor problems with it before, but after updating yesterday, I can't access repositories, gitlab-ctl status says everything is OK. I've searched the various error messages and nothing suggested works so far. |
13:16 |
Dyrcona |
I'm going to see if I can dump/backup the repos. I doubt it because GitAly seems to be the busted component.--Good thing we (CWMARS) are moving to GitHub. |
13:17 |
Dyrcona |
gitlab-ctl fixit doesn't exist. :) |
13:19 |
Dyrcona |
Looks like a GitLab backup would be useless without another GitLab instance anyway. |
13:20 |
Dyrcona |
And then there is this: Backup::Error: gitaly-backup exit status 1 |
13:33 |
Dyrcona |
There's too much going on for a Friday.... |
13:42 |
Dyrcona |
typos-- |
13:42 |
Dyrcona |
@karma typos |
13:42 |
pinesol |
Dyrcona: Karma for "typos" has been increased 0 times and decreased 2 times for a total karma of -2. |
13:43 |
Dyrcona |
The typos-- is not related to the GitLab thing, by the way. IDK what's wrong there.... |
13:50 |
Dyrcona |
Hmm. Be nice if git had a remote command to disable skip or ignore a remote so that I could leave it configured but just ignore it for a while. |
14:00 |
Dyrcona |
mmorgan++ # For linking an "old" email chain to a bug. I had forgotten that discussion. |
14:16 |
mmorgan |
@karma tyops |
14:16 |
pinesol |
mmorgan: tyops has neutral karma. |
14:16 |
mmorgan |
worth a shot. |
14:21 |
Dyrcona |
:) |
14:34 |
Dyrcona |
OK. Whatever you say, GitHb: "Great repository names are short and memorable. Need inspiration? How about upgraded-succotash?" |
14:35 |
Dyrcona |
Here, I was gonna go with vmsetup. |
14:35 |
berick |
sufferin-succotash |
14:39 |
Dyrcona |
berick++ |
15:15 |
* Dyrcona |
hears thunder and smells rain. |
15:16 |
mmorgan |
Rain? What's that? |
15:18 |
Dyrcona |
Yeah, I know.... |
15:18 |
* Dyrcona |
waits for the dog to wake up and go nuts over the ear-shplitten-louden-boomers. |
15:18 |
* mmorgan |
hears the thunder, too, now. |
15:19 |
Dyrcona |
Ah, well, back to updating local git repos to point to GitHub. |
15:19 |
Dyrcona |
too_many_servers-- |
15:19 |
mmorgan |
The pond behind our office building is almost dry. I've never seen it so low. |
15:21 |
Dyrcona |
Yeah.... |
15:21 |
Dyrcona |
Pointed one repo at the wrong remote..... |
15:37 |
|
Christineb joined #evergreen |
15:54 |
Dyrcona |
So, even if you lose your main git repository, all of the local clones are basically backups. You can "recover" some lost branches from the local clones if the branches are still hanging around. |
16:00 |
berick |
git clone --mirror and git remote update are also pretty handy for full backups |
16:02 |
Dyrcona |
berick++ I'll look into those commands later. |
16:08 |
Dyrcona |
cssh++ |
17:08 |
|
mmorgan left #evergreen |
17:19 |
Bmagic |
berick: since the autorenewals essentially are two triggers, one for the renewal and one for the notice. How do you handle that with messagebee? I let your code do the whole thing, but it's looking like when it runs, it only runs the renewal but not the notice |
17:20 |
Bmagic |
the notice trigger runs the next day, and for items that could not be renewed, the message about it not getting renewed is a bit stale |
17:21 |
Bmagic |
I'm thinking about setting up a cron to run a few hours before your code does, to take care of the renewal and trigger the message be reactor to queue up. Then your code would run those maybe? |
17:22 |
berick |
we autorenew at 2am and generate the notices at 8am currently. |
17:22 |
berick |
generate-notices.sh --send-xml --granularity Auto-Renew-Email --end-date $(date --date '+1 day' +'\%F') --file-date $(date +'\%F') |
17:22 |
berick |
escaped for cron |
17:22 |
Bmagic |
ok, so, are both handled by ./generate-notices.sh ? |
17:23 |
berick |
no, autorenew is just a regular A/T |
17:23 |
Bmagic |
there we go, thanks! That's what I was thinking |
17:24 |
Bmagic |
so, just to be safe, I might put a delay on those secondary triggers, like an hour? So that the regular A/T doesn't end up running them before generate-notices.sh gets a chance |
17:28 |
berick |
Bmagic: probably better to make sure the notice generator only ever runs after all auto renew processing is complete |
17:28 |
berick |
assuming you notify daily, a delay would just push notices back a day for any that took too long. |
17:30 |
Bmagic |
right, makes sense. the timing of the cron is the main thing, if I set delay='3 hours' for the trigger with hook='autorenew' then the standard A/T will insert a row with a future run_time of 3 hours from now. And as long as the generate_notices.sh is run more than 3 hours from then, we're good |
17:30 |
berick |
ah i give all my notices of this type a '5 second' delay so that can't happen |
17:30 |
berick |
and just set the script to run when I know it's OK to send all the notices |
17:31 |
Bmagic |
and with 5 seconds delay, the original A/T trigger doesn't run it? |
17:31 |
Bmagic |
it just makes the entry in action_trigger.event but leaves it for another cron to pick it up? |
17:31 |
berick |
not if you give the notice A/T a granularity |
17:31 |
berick |
the generic A/T runner skips events that have a granularity |
17:32 |
berick |
s/events/event defs/ |
17:32 |
Bmagic |
they have granularity |
17:32 |
berick |
then they won't fire until you run generate-notices.sh --granularity XYZ ... |
17:32 |
Bmagic |
action_trigger_runner.pl --process-hooks --run-pending --granularity messagebee-autorenew --granularity-only |
17:33 |
Bmagic |
for example ^^^^ would both run the renewal AND any hook='autorenewal' at the same time? |
17:34 |
Bmagic |
I should take run-pending out of that? |
17:34 |
berick |
don't give them the same granularity |
17:34 |
berick |
e.g. i have Auto-Renew-Processor and Auto-Renew-Email granularities |
17:34 |
Bmagic |
I learned a couple of years ago that you can't connect two triggers together with two different granularities |
17:35 |
Bmagic |
at least that's what I think* I remember. |
17:36 |
berick |
hm, not ringing any bells |
17:36 |
berick |
maybe if you wanted to run them at the same time? not sure |
17:36 |
Bmagic |
When the first one fires, it looks for other definitions within the same granularity. So the original trigger def is hook='Circ::AutoRenew' and the secondary is hook='autorenewal'. Both of those definitions don't have to be the same granularity? |
17:38 |
berick |
yes, different granularities. I think what makes it OK is the 2nd event-def is not running in real time, we're just creating events for it |
17:38 |
berick |
that will run later w/ generate-notices.sh |
17:38 |
Bmagic |
I'll give it a whirl! |
17:38 |
Bmagic |
berick++ |