feedback-bot needs to be updated and restarted after this is pushed to
prod for these changes to take effect.
(imported from commit fcabd2f4bb26c794454e096242a8073805fc786c)
We leave the stuff under api/ alone for now, since we need to be able to ship
it as a standalone thing.
tools/post-receive wasn't using the function anyway.
For push to master: Push this commit, update post-receive per instructions at
the top of that file, then push the rest of the branch to confirm that the hook
still works.
No manual instructions for prod.
(imported from commit 9bcbe14c08d15eda47d82f0b702bad33e217a074)
At Ksplice we used /usr/bin/python because we shipped dependencies as Debian /
Red Hat packages, which would be installed against the system Python. We were
also very careful to use only Python 2.3 features so that even old system
Python would still work.
None of that is true at Humbug. We expect users to install dependencies
themselves, so it's more likely that the Python in $PATH is correct. On OS X
in particular, it's common to have five broken Python installs and there's no
expectation that /usr/bin/python is the right one.
The files which aren't marked executable are not interesting to run as scripts,
so we just remove the line there. (In general it's common to have libraries
that can also be executed, to run test cases or whatever, but that's not the
case here.)
(imported from commit 437d4aee2c6e66601ad3334eefd50749cce2eca6)
Realistically, if the bot crashes once, it'll probably crash the next
time too, so I'm not convinced we need this loop at all, but in the
interests of avoiding churn on an extensively tested script, I'm going
to err on the side of the minimal change here.
(imported from commit e2bbd3700395ba4d0b181a4616e816e8f1231669)
This change adds a copyright notice and moves our site-specific bits
to global constants at the top of the file.
(imported from commit ccc8cf10f2d0d70c7500b12c7849406268313bae)
This adds two characters to the length of our default format field, but
based on a conversation I had with kcr, I think this should probably be
okay. If it's a problem, the symptom we'll see is that certain people
will be unable to send zephyrs with this default format (so, certain
Humbug users will have their forwarding consistently fail).
We need to remember to, in a future commit (once everyone has started
using the updated version), remove the:
> or notice.format.endswith("@(@color(blue))")
(imported from commit 703ef60f524646bca8d5099c9066efabd365be43)
Fixes#602.
I replaced the SIGKILL with a SIGINT, and then catch SIGINT with a
handler. This handler calls cancelSubs if necessary, and can later be
edited to perform other clean-up operations, too. I thought about, in
this same commit, changing the SIGTERM in
maybe_restart_mirroring_script to a SIGINT, but after tracing out the
code paths, I realized that isn't necessary. (The SIGTERM is
necessarily performed on a process that has not subscribed to any
zephyr classes, so cancelSubs is unnecessary. If we do think that we
may want to add additional clean-up operations in the future, though,
then it might be worth investigating changing this SIGTERM.)
(imported from commit 692b295be6cb40b0e4ec2ca0bc58c58056ed9bd9)
Bots are not part of what we distribute, so put them in the repo root.
We also updated some of the bots to use relative path names.
(imported from commit 0471d863450712fd0cdb651f39f32e9041df52ba)
Previously, if users of our code put the API folder in their pyshared
they would have to import it as "humbug.humbug". By moving Humbug's API
into a directory named "humbug" and moving the API into __init__, you
can just "import humbug".
(imported from commit 1d2654ae57f8ecbbfe76559de267ec4889708ee8)
This was causing about 10% of the time, personals being forwarded by
tabbott/extra@ATHENA.MIT.EDU to get this error:
zwrite: Field too long for buffer while sending notice to
tabbott/extra@ATHENA.MIT.EDU
We don't fully understand the cause of the problem, but this fixes it.
(imported from commit 22c39a1061cde9ad6973ef07aee7227623a3d47d)
