Version 1.12(.0_rc1) supposedly fixes https://github.com/go-gitea/gitea/issues/9347, which is an issue bugging current versions available in Gentoo.
Hi Dennis, As a proxy-maintainer, the process to do a version bump can be quite long and as it requires the review of gentoo devs, that are already overbooked, I'm not gonna give them extra work with RC releases. You can eventually use the live ebuild www-apps/gitea-9999, or I've attached to this bug a working ebuild you can use.
Created attachment 641490 [details] gitea-1.12.0_rc1.ebuild
It appears that something is wrong in the rc1 tarball: >>> Compiling source in /dev/shm/portage/www-apps/gitea-1.12.0_rc1/work/gitea-1.12.0_rc1/src/code.gitea.io/gitea ... make -j5 -j1 backend go: inconsistent vendoring in /dev/shm/portage/www-apps/gitea-1.12.0_rc1/work/gitea-1.12.0_rc1/src/code.gitea.io/gitea: src.techknowlogick.com/xgo@v0.0.0-20200514233805-209a5cf70012: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt run 'go mod vendor' to sync, or use -mod=mod or -mod=readonly to ignore the vendor directory
(In reply to Pierre-Olivier Mercier from comment #1) > As a proxy-maintainer, the process to do a version bump can be quite long > and as it requires the review of gentoo devs, that are already overbooked, > I'm not gonna give them extra work with RC releases. > > I've attached to this bug a working ebuild you can use. Thank you for your work on this!
Created attachment 643136 [details] gitea-1.12.0_rc1.ebuild All, here is an updated version of this ebuild that works with go-module instead of the golang-* eclasses. Something like this should be used going forward, so can you test it and let me know what you think? I also have a couple of questions. 1. Why do we have an "acct" use flag? It seems that this should be required rather than optional and on by default. 2. wrt the logflags patch. Do we need this? If so, is there a reason we don't have a pr for it upstream? Thanks, William
hi william, here is a try to answer your questions: 1. acct useflag: actually you could install e.g. gitolite with git user (secure private git) and gitea with gitea as user (a bit less secure but web interface). (it would block otherwise acct-user/git[gitea] vs acct-user/git[gitolite]) 2. logfile patch -> fail2ban/sshguart/logcheck compatiblity now app.ini is installed and dispatch-conf could be used, that the user is aware of that. so in the sections log.{x,console,file,..}, the entry FLAGS = date,time,levelinitial, should be the default (sedcmd array ). 3. the ebuild you attached does not work, the reason is the source directory (therefore golang-vcs-snapshot is used // EGIT_CHECKOUT_DIR="${WORKDIR}/${P}/src/${EGO_PN}" is set) felix
Created attachment 643452 [details] gitea-1.12.0_rc1.ebuild Here is a patched ebuild that should work with future releases (but not with rc1, for the same reason as stated above), based on the work of WilliamH. As the logs' patch doesn't apply anymore due to the new unpack location, it is certainly the right time to try to fix this through app.ini instead, as Felix recommend on IRC.
Hi again all, I just looked upstream and found this documentation on fail2ban setup, so I don't think we need to patch anything to work with fail2ban. https://docs.gitea.io/en-us/fail2ban-setup/
yes as stated before the patch can be dropped. the same can be achieved by configurations in app.ini. the point was the it could "break" existing fail2ban/sshguard configurations. however the `new` regex with ".*" in the beginning is not really nice (and it not terminate by "$") - so false positive might be generated easily.
