~sturm

Ballarat, Australia

https://stumbles.id.au/

Free software activist, software engineer and director of Sturm Software Engineering. Loves riding bikes and flying kites. Co-maintainer of GNU MediaGoblin.


#59 Unable to build v0.14.0 on AlmaLinux 9.5 30 days ago

Comment by ~sturm on ~mediagoblin/mediagoblin

"~jahway603" outgoing@sr.ht writes:

Since rabbitmq-server is not available by default on AlmaLinux 9.x, I was able to get it setup by following RabbitMQ's upstream instructions here.

If you'd prefer, you can also use Redis:

[celery] broker_url = "redis://"

I am stuck on the make step under "Install MediaGoblin".

Below is a PrivateBin link with the stdout/stderr shown when running through this step: https://bin.linux.pizza/?ff1480ed2fa7c694#CCt8FxTXFmut26Q6cc7UoWW7QGE5CrANQ3Zin5XHo8aW

We fixed a similar error "can't copy 'licenses/*'" seen in Debian 11 on the master branch back in October (c70e444c). Could you please try that branch and see if this is resolved for you?

The issue appears to be that slightly older versions of Python, Setuptools, Pip or similar don't support the wildcard syntax in setup.cfg's "options.data_files" config.

For what it's worth, we do have a Fedora CI build which might offer some clues as to what the appropriate OS packages are called:

https://git.sr.ht/~mediagoblin/mediagoblin/tree/master/item/.builds/fedora-39.yml

#59 Unable to build v0.14.0 on AlmaLinux 9.5 30 days ago

Comment by ~sturm on ~mediagoblin/mediagoblin

Those pastebin links will expire in a few days, so here's the key part of that output:

  error: can't copy 'licenses/*': doesn't exist or not a regular file
  ----------------------------------------
  ERROR: Failed building wheel for mediagoblin
Failed to build mediagoblin
ERROR: Could not build wheels for mediagoblin, which is required to install pyproject.toml-based projects
WARNING: You are using pip version 21.3.1; however, version 25.0.1 is available.
You should consider upgrading via the '/srv/mediagoblin.example.org/mediagoblin/bin/python3 -m pip install --upgrade pip' command.
make: *** [Makefile:87: /srv/mediagoblin.example.org/mediagoblin/./lib/python3.9/site-packages/mediagoblin-0.14.0.dist-info/] Error 1

#57 data_basedir in mediagoblin.ini is not updating defaults in config_spec.ini 5 months ago

on ~mediagoblin/mediagoblin

I just ended up copying the config file to /var/lib/mediagoblin on each systemd service start. You can follow the packaging progress at https://github.com/NixOS/nixpkgs/pull/350578

On Mon, 28 Oct 2024 at 00:26, ~sturm outgoing@sr.ht wrote:

Ticket resolved: CLOSED

Hi ~sandro, did I address your needs here regarding packaging MediaGoblin for NixOS? I'll mark this as resolved for now, but I'd love to hear if that worked for you.

-- View on the web: https://todo.sr.ht/~mediagoblin/mediagoblin/57#event-392615

#57 data_basedir in mediagoblin.ini is not updating defaults in config_spec.ini 5 months ago

Comment by ~sturm on ~mediagoblin/mediagoblin

Hi ~sandro, did I address your needs here regarding packaging MediaGoblin for NixOS? I'll mark this as resolved for now, but I'd love to hear if that worked for you.

REPORTED RESOLVED CLOSED

#57 data_basedir in mediagoblin.ini is not updating defaults in config_spec.ini 6 months ago

Comment by ~sturm on ~mediagoblin/mediagoblin

Thanks for your packaging efforts!

MEDIAGOBLIN_CONFIG is only used by the Celery task queuing process, not by the MediaGoblin web application. Your options here are:

a. Specify your config file in paste.ini and run the web application with paster serve paste.ini as per our traditional deployment approach (see https://docs.mediagoblin.org/en/master/siteadmin/deploying.html#run-mediagoblin-as-a-system-service). You'll still need MEDIAGOBLIN_CONFIG for running celery worker. Sorry for the inconsistency here.

b. Use the new gmg -cf CONF_FILE serve and gmg -cf CONF_FILE celery commands. These should be good to go, but we haven't switched our documentation over to use them yet, so haven't been as thoroughly tested.

For what it's worth, it may be useful to check out my work-in-progress Guix package. The inputs section may be relevant to your work. I'm not using the project's make, but rather installing as a Python package: https://git.sr.ht/~mediagoblin/mediagoblin/tree/master/item/.guix/modules/mediagoblin-package.scm

#56 Left-right arrow shortcut keys surprising 9 months ago

Ticket created by ~sturm on ~mediagoblin/mediagoblin

In the age of online video, the left and right arrows typically skip forwards and backwards in a video. In MediaGoblin, they skip to the next item, so if you're watching a video that will stop and instead show the next/previous media item, perhaps another video.

We probably should drop these shortcuts.

#55 Consider switching out waitress? 9 months ago

Ticket created by ~sturm on ~mediagoblin/mediagoblin

We've had a user on IRC having trouble with large file uploads. Turns out waitress has its own internal max file upload max_request_body_size which defaults to 1G.

Waitress seems a bit less commonly used than other WSGI servers. I've had professional experience with gunicorn and uWSGI, but not waitress. All application servers have their own quirks, but I wonder whether gunicorn might be a better choice, simply because it's fairly commonly used.

#54 Deployment: avoid extra "mediagoblin" user 9 months ago

Ticket created by ~sturm on ~mediagoblin/mediagoblin

I ran through the deployment guide last night and frankly, it's complicated. I think we need to do everything we can to simplify the first install experience, but give people the tools to scale if needed.

(Docker is one way to simplify this, but I'd also like to support the traditional install too.)

The guide recommends creating a "mediagoblin" user account to run the application under. I've personally always run MediaGoblin with the default "www-data" user created by installing Nginx on Debian/Ubuntu. I'd suggest we move the separate user creation to the "Further considerations for production deployment" page (along with PostgreSQL).

#53 Install docs use "stable" branch, but upgrade docs use specific tag (inconsistent) 9 months ago

Ticket created by ~sturm on ~mediagoblin/mediagoblin

We should either use the branch ref in both cases, or the tag ref in both cases. See docs/source/siteadmin/deploying.rst (branch) and upgrading.rst (tag).

#52 Separate the source checkout from the install/run 9 months ago

Comment by ~sturm on ~mediagoblin/mediagoblin

What brought this issue up for me is that currently someone installing from our deployment docs gets whatever version is in the "stable" branch, which quite likely isn't an explicit release, just whatever git commit happened to be there at the time.

On the other hand, it means we can just push changes to "stable" and anyone installing will get the latest version without us having to make an explicit release.