Bug 247381 - www/gitea: fails to start due to missing locale files
Summary: www/gitea: fails to start due to missing locale files
Status: Closed Feedback Timeout
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Adam Weinberger
URL:
Keywords: needs-patch
Depends on:
Blocks:
 
Reported: 2020-06-18 14:03 UTC by Vincent Bentley
Modified: 2020-09-13 21:11 UTC (History)
3 users (show)

See Also:
fernape: maintainer-feedback? (stb)
koobs: merge-quarterly?


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vincent Bentley 2020-06-18 14:03:20 UTC
Installed gitea from package using the minimal documentation for the FreeBSD installation at:
https://docs.gitea.io/en-us/install-from-package/

The gitea service does not start for root user using
# service gitea start

To find out what went wrong, starting gitea from command line with:
# su git
# gitea web

Produces the following messages:

2020/06/18 14:04:27 cmd/web.go:107:runWeb() [I] Starting Gitea on PID: 36206
2020/06/18 14:04:28 ...dules/setting/git.go:91:newGit() [I] Git Version: 2.26.2, Wire Protocol Version 2 Enabled
2020/06/18 14:04:29 routers/init.go:87:GlobalInit() [T] AppPath: /usr/local/sbin/gitea
2020/06/18 14:04:29 routers/init.go:88:GlobalInit() [T] AppWorkPath: /usr/local/sbin
2020/06/18 14:04:29 routers/init.go:89:GlobalInit() [T] Custom path: /usr/local/sbin/custom
2020/06/18 14:04:29 routers/init.go:90:GlobalInit() [T] Log path: /usr/local/sbin/log
2020/06/18 14:04:29 ...dules/setting/log.go:233:newLogService() [I] Gitea v1.11.6 built with GNU Make 4.2.1, go1.14.1 : pam, sqlite, sqlite_unlock_notify
2020/06/18 14:04:29 ...dules/setting/log.go:276:newLogService() [I] Gitea Log Mode: Console(Console:info)
2020/06/18 14:04:29 ...les/setting/cache.go:45:newCacheService() [I] Cache Service Enabled
2020/06/18 14:04:29 ...s/setting/session.go:44:newSessionService() [I] Session Service Enabled
2020/06/18 14:04:29 routers/init.go:122:GlobalInit() [I] SQLite3 Supported
panic: fail to set message file(en-US): open conf/locale/locale_en-US.ini: no such file or directory

goroutine 1 [running]:
gitea.com/macaron/i18n.initLocales(0x334454b5, 0x0, 0x71eb15, 0xb, 0x330dc140, 0x72fbec, 0x12, 0x330b22c0, 0x16, 0x16, ...)
	/wrkdirs/usr/ports/www/gitea/work/gitea-1.11.6/vendor/gitea.com/macaron/i18n/i18n.go:57 +0x587
gitea.com/macaron/i18n.I18n(0x335b7a60, 0x1, 0x1, 0x0, 0x0)
	/wrkdirs/usr/ports/www/gitea/work/gitea-1.11.6/vendor/gitea.com/macaron/i18n/i18n.go:160 +0x62
code.gitea.io/gitea/routers/routes.NewMacaron(0x9d2b60)
	/wrkdirs/usr/ports/www/gitea/work/gitea-1.11.6/routers/routes/routes.go:187 +0x898
code.gitea.io/gitea/cmd.runWeb(0x330b2dc0, 0x0, 0x0)
	/wrkdirs/usr/ports/www/gitea/work/gitea-1.11.6/cmd/web.go:119 +0x273
github.com/urfave/cli.HandleAction(0x50e2e0, 0x798158, 0x330b2dc0, 0x33075400, 0x0)
	/wrkdirs/usr/ports/www/gitea/work/gitea-1.11.6/vendor/github.com/urfave/cli/app.go:490 +0x9c
github.com/urfave/cli.Command.Run(0x70d71b, 0x3, 0x0, 0x0, 0x0, 0x0, 0x0, 0x7392e0, 0x16, 0x0, ...)
	/wrkdirs/usr/ports/www/gitea/work/gitea-1.11.6/vendor/github.com/urfave/cli/command.go:210 +0x956
github.com/urfave/cli.(*App).Run(0x330f7340, 0x3300e040, 0x2, 0x2, 0x0, 0x0)
	/wrkdirs/usr/ports/www/gitea/work/gitea-1.11.6/vendor/github.com/urfave/cli/app.go:255 +0x617
main.main()
	/wrkdirs/usr/ports/www/gitea/work/gitea-1.11.6/main.go:110 +0x608

The error message in this lot is:
panic: fail to set message file(en-US): open conf/locale/locale_en-US.ini: no such file or directory. The missing files appear to be in /usr/local/share/gitea/options/locale

This package suprised me by polluting /usr/local/sbin with config files in /usr/local/sbin/custom/conf . I assume it is expecting the missing locale files to be in /usr/local/sbin/custom/conf/locale .

Possible fix during building is to build with TAGS=bindata
See https://docs.gitea.io/en-us/install-from-source/
I successfully managed to build the backend from source to get the service to start, but I had problems with the current FreeBSD npm package when building the frontend.

The Custom Path is currently /usr/local/sbin/custom which puts the config files under this heirarchy. In my opinion this should be /usr/local/gitea to fit in with FreeBSD standards or /usr/local/go/src/gitea (in GOROOT) or in a dedicated go Project Heirarchy /usr/local/go-apps/src/gitea , setting GOPATH accordingly.
https://medium.com/golang-learn/go-project-layout-e5213cdcfaa2

I am not a go developer and I have no intention of becoming one, the little that I have learned about go while debugging this problem is that go appears to need some 'house' standards regarding go apps. It is my opinion that FreeBSD could benefit from some more detailed standards document for building and packaging go applications. The following was all I could find:

https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/go-libs.html
https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/uses-go.html
https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/building.html#using-go

From what I understand, when go projects are properly installed in a consistent manner, modules can be reused between projects under a single GOPATH.
Comment 1 Fernando Apesteguía freebsd_committer 2020-06-19 06:09:49 UTC
^Triage: notifying MAINTAINER

Thanks for such detailed report!
Comment 2 Vincent Bentley 2020-06-22 09:16:18 UTC
I have successfully built the gitea 1.11.6_1 port with the BINDATA option set using Poudriere. Building with BINDATA on fixes the missing locale problem. The gitea package in the FreeBSD repo is not built with BINDATA on as default.

Unfortunately, after installing the freshly built package (with BINDATA) and setting gitea_enable="YES" in /etc/rc.conf it will not start as a service. However, when gitea is started from the command line it appears that gitea will create config in /usr/local/sbin. I must have started it as root at least once to do this. When su'd as git, the /usr/local/etc/gitea/conf directory and app.ini need to be writable for the git user for gitea to start.

I am currently working through combinations of command line arguments and app.ini config to try to get gitea to start properly.
Comment 3 Vincent Bentley 2020-06-22 10:29:20 UTC
Changing ownership of the following directory trees to git:git fixed the problem starting the gitea service:

chown -R git:git /usr/local/etc/gitea
chown -R git:git /var/db/gitea
chown -R git:git /var/log/gitea

The startup script /usr/local/etc/rc.d/gitea sets GITEA_WORK_DIR to /usr/local/share/gitea but this directory does not exist. I assume that it does not get created if BINDATA is set. It does not appear to cause any problems.
Comment 4 stb 2020-06-28 10:00:58 UTC
Please take alook at the startup script in /usr/local/etc/rc.d/gitea. WThe way the Gitea project builds the binary, it is not possible to just run `gitea web`; you will need to set some command line options and environment variables to point gitea to where things live in FreeBSD (as opposed to the Docker-centric model Gitea seems to be preferring).

If you're having trouble starting service, please check the syslog output for hints. If all else fails, running the start script like so might give an indication why it might be failing:

  sh -vx /usr/local/etc/rc.d/gitea start

I would love to have a default configuration of the gitea binary that points at the right locations by default, but so far I haven't been successful in supplying the right options to the build. I'd be very happy to have somebody else figure that out!
Comment 5 stb 2020-06-28 10:09:35 UTC
I've just built and tested the gitea port with the bindata option enabled, and it seems to be working just fine for me (12.1-RELEASE-p3). I'm not getting error messages, and the permissions for the directories all seem to be correct out of the box.
Comment 6 stb 2020-08-02 18:07:29 UTC
Is this still an issue? I was not able to reproduce your observations. If you're still having a problem, please let me know.
Comment 7 Adam Weinberger freebsd_committer 2020-09-04 02:06:43 UTC
It's been a month since you asked for more feedback. Would you like me to close out this PR?
Comment 8 Adam Weinberger freebsd_committer 2020-09-13 21:11:22 UTC
Closing as submitter has disappeared, and maintainer cannot reproduce.