@girish I think in the case of Gitea it probably makes sense to not move from ldap to oidc, but to rather configure both. Their ux seemed quite clear to me even when logging in with oidc for a user which had it not configured beforehand. Instead of creating a completely new user it asked again for the username and password of my existing ldap user to link these two accounts together. When last experimenting with Vikunja it preferred creating new users instead of combining them like Gitea does, so for some apps it makes sense to move to oidc only, while others are good in a combination of ldap and oidc.

@mario install them in the LAMP app.

@ChristopherMag thanks!

@Wirv I did it by setting this to false SERVE_DIRECT = true

@girish Setting [indexer] ISSUE_INDEXER_TYPE=db in app.ini solved the issue immediately. Thanks alot! Now I'm curious to know what db means in this context (but the urgency is gone ). Should the Cloudron package have db as ISSUE_INDEXER_TYPE out of the box, for example? Some Cloudron app config data got alot of legacy files from earlier versions, so sometimes it's hard to know what the true good defaults are.

@jaschaezra there recently was a topic of someone building a custom forgejo app https://forum.cloudron.io/topic/8312/moving-from-packaged-app-to-custom?_=1673347978007

@yusf thanks, fixed in latest package.

It certainly could. Alongside the docker registry app. Another bonus for using gitea for container storage is that you can use access tokens instead of the actual user password.

@LoudLemur possibly because it looks incredibly dated?

Very nice, it’s been a long time coming! That NLnet’s grants list is a bunch of awesomeness btw https://nlnet.nl/project/current.html

@ocelotsloth thanks, merged! will publish shortly.

@girish Thanks for your extremely quick and helpful answer! It worked! Side note: I have been using cloudron for about 2 years now, and I am a happy paying customer. The fact that it is the first question I had to ask so far is a testament to the quality of your work and documentation. Congratulations to the team!

Hi @krschuerman, for me this still works, but as already said in my last post here in this thread the setting needs to be placed in the security block. [security] [..] DISABLE_GIT_HOOKS = false

@girish Yeah, I ran: /home/git/gitea/gitea convert -c /run/gitea/app.ini as user git, and now things seem converted: ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci ROW_FORMAT=DYNAMIC On the downside, the convert tool seems to unconditionally convert, and is quite slow, so I guess it can't easily be run as part of the startup process or something

@murgero Removed the blank template file from the custom folder and it worked without a hitch. I see this is marked as solved already but you can close the internal ticket if you haven't already.

@girish Yes. It's listening on 0.0.0.0:8080 and it's on a remote server as well, so localhost wouldn't work either way. Also, I don't know what happened but even though all tests failed I kept the webhook setting active and when time came for a real event and not a test event, it actually works: [image: 1613550848170-61d4b94d-dc85-4e26-b508-8b4310dbc9c8-bild.png] So, test deliveries don't work but that might be because of how the recieving webhook is set up, I don't know.

@timbo The upload size issue is now fixed with https://github.com/go-gitea/gitea/pull/12024 . When they make a new release, we should get the fix.