There was an existing stub for `gmg serve`, but had never been completed.
This will make it simpler to run the MediaGoblin web interface and media
processing backend.
I moved sphinx to native inputs since if sphinx were to be used it would be used to
build docs instead of as a direct library input to mediagoblin. The patch is attached.
Signed-off-by: Ben Sturmfels <ben@sturm.com.au>
Removed libsndfile and python-soundfile by excluding the relevant audio tests
until core-updates is merged. Updated to latest master branch and removed some
unnecessary dependencies.
Running the Dockerfiles in CI seemed like a good idea, but I'd forgotten that
they pull from the master branch, rather than using local source. Could be
reinstated if we make Dockerfiles use local source as discussed in trac#5574.
This reverts commit 712728c331ea3518b1964bbc7fcf06ff2c567064.
This allows us to use an identical build in CI and in local development. Not the
most optimal for CI, but means less to maintain and no inconsistencies.
Prior to this change, the Celery logging did not include any of the logging
calls within MediaGoblin because `disable_existing_loggers` defaulted to True.
This was unhelpful and inconsistent with the logging behaviour of the web process.
The MediaGoblin web process sets logging output based on the configuration in
paste.ini. This is loaded by the `paster` program, rather than MediaGoblin
itself.
The MediaGoblin celery process manually loads its logging config from paste.ini,
but previously defaulted to `disable_existing_loggers=True`, meaning that none
of the application logging flowed through unless the logger was explicitly added
to paste.ini.
Following the video transcoding work included in v0.10.0, uploading an image and
restarting Celery resulted in the image being marked as failed, even after it
had been initially successfully processed.
The issue was that the initial processing task was not being acknowledged by the task queue following the introduction of the
`CELERY_ACKS_LATE` setting. It's not clear why this is the case, but reverting
the setting fixes this issue and doesn't negatively impact video processing.
This code appears to be unused. I've checked by grepping for "html5" and also by
manually adding an `assert` in the file and running the test suite, just in case
something particularly weird is going on.
