Package Details: octoprint-venv 1.3.11-1

Git Clone URL: (read-only)
Package Base: octoprint-venv
Description: The snappy snappy web interface for your 3D printer! (virtualenv installation type)
Upstream URL:
Licenses: AGPL3
Conflicts: octoprint
Provides: octoprint
Submitter: Jake
Maintainer: Jake
Last Packager: Jake
Votes: 18
Popularity: 0.021045
First Submitted: 2017-01-15 12:46
Last Updated: 2019-05-27 09:48

Pinned Comments

Jake commented on 2017-10-24 16:03

If the hashsum is incorrect please just flag it out of date (also when there is no real new release, but the changed the old archive for some reason).

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 ... Next › Last »

Jake commented on 2018-06-27 19:16

Octoprint writes in it's own virtualenv to install plugins (which is possible through the web interface). Moving executables into /var/lib seems also wrong imho... I have looked into the --user config option, that would install the plugins into the home directory of the octoprint user, but that does not work if it is installed in a virtualenv. Maybe with --system-site-packages flag, but that could cause other issues and requires further investigation.

Niklas commented on 2018-06-19 20:32

Depends on whether OctoPrint actually wants to write in its own code. I doubt that, so the octoprint user shouldn't have write permissions for security reasons. If OctoPrint writes in the venv it should be in /var/lib/octoprint, since everything in /opt should only be touched by package managers/installers.

Jake commented on 2018-06-19 17:42

I was not aware that this is possible with tmpfiles.d, thank you for sharing the knowledge. Yes i agree that this is a better solution and i have changed it with pkgrel=4. Still not sure though if it is a good practice to use it on /opt, because the man page mentions only /run and /var?

Niklas commented on 2018-06-18 22:10

That is not a great solution. Use a tmpfiles.d configuration (it sounds like it is just used for temporary files/folders but that is misleading) which can be used to create folders with the right permissions at installation.

For example:

Jake commented on 2018-06-17 14:58

You are right JPW, thanks for the notice. The .install gets executed before the pacman hooks, so the user is not existing at this time on a fresh installation. I have fixed it with running sysusers also in the install script now.

JPW commented on 2018-06-17 12:45

I get a permission denied when starting octoprint because the chown(s) fail during install (I think the user has not been created at that point yet). Executing chown -R octoprint:octoprint /var/lib/octoprint && chown -R octoprint:octoprint /opt/octoprint-venv manually fixes the issue.

pa314159 commented on 2018-05-24 15:51

@jake, I wasn't aware of any wiki page (where is that?) and, obviously, nobody likes duplicated packages.

I wanted separate configuration for host and port (and use --host and --port) in order to not mix it with the actual configuration which belongs to the user. I also don't like user files linked to etc, that's why I came with the wrapper.

Or put it in a different way, the listener should be configured by the system admin (i.e. the root), while the rest of configuration belongs to the user (i.e. octoprint).

I agree with the variables - indeed, people could ask themselves where is that ${etcdir} pointing to :)

Jake commented on 2018-05-24 01:35

@pa314159, just to clarify, after Niklas disowned the package i edited this wiki page to mention octoprint-venv and describe why the octoprint package was broken. Everyone can edit the public wiki and we have to update it now again to the changed packaging situation here. It is correct though that a virtualenv is recommended in the official readme, they are also aware that it still depends on some pretty outdated modules. As i have written before, i think a venv installation is the only way to get this reliably to work, but we really don't need duplicate packages. So is someone interested in doing this patchwork (i would call it almost a fork), or should we merge?

Also this package seems more complicated than necessary now. The server host + port can be configured through the standard config.yaml (documented here:, so why that additional conf and octoprint-serve wrapper? I also dont't quite see the reasons for the config.yaml with firstRun, when it automatically does the firstrun procedure and creates the config file if no file exists. Then something from the packaging standards: "Do not introduce new variables or functions into PKGBUILD build scripts, unless the package cannot be built without doing so", these path variables make it imho anyway harder to read, because it requires to look above everytime to understand where they point. Utilizing systemd sysusers is a really nice solution though, i never particularly liked the user creation in the .install before. I use sysusers also in octoprint-venv now.

pa314159 commented on 2018-05-15 07:10

"The recommended way of building Arch packages is to follow the packaging guidelines": agreed, so both recommendations are fulfilled...

eschwartz commented on 2018-04-30 20:14

"The recommended way of building OctoPrint on ARCH is to use virtualenv, see [...]"

Wrong. The recommended way of building Arch packages is to follow the packaging guidelines. Please fix this to use proper dependencies again, especially seeing as how it used to work.