I was under the impression that Google retired the “app password” workflow and moved to Gmail API within Google Cloud. I have the API set up and that’s what I’m using in the Vikunja configs but like I mentioned in the post, at this point I don’t care if its Gmail or something else. I just need the email functionality to work so I will use whatever service works well with Vikunja.

Hahahahaha didn’t even realize the typo. But yea I made them maaaaad!

Thank you! Easy fix

Upsetting the mirrors did it for me.

Yup! Working peachy now

Did the trick for me too

How does this happen? This is my first EOS system. Ever since I finished up the setup and customization, I’ve not changed anything outside of updating it and using the system… I guess I’m just trying to understand the why

I will give this a shot when I get back home and report back

Okay I’ll give this a try when I got back to the house.

Done. I uploaded a screenshot

I don’t have an answer for you but I have one instead. When I attempted to do swarm my biggest challenge was shared storage. I was attempting to run a swarm with shared storage on a NAS. Literally could not run apps, ran into a ton of problems running stacks (NAS share tried SMB and NFS). How did you get around this problem?

Not quiet. I was running gitea before so my mount was ./gitea:/data but since switching over to forgejo, I renamed my ./gitea directory to ./forgejo. Adjusted my compose file to have a mount of ./forgejo:/data.

Now inside of that renamed forgejo directory, there are a bunch of gitea references and even one more directory called gitea. When I migrated everything worked right away but since I wanted a cleaner transition, I renamed and switched all gitea references to forgejo but went I brought the stack back online, it went belly up.

As a troubleshooting step, I recreated my compose file and created a new empty ./forgejo on a different machine just to see what a new and fresh install would look like and the forgejo stack itself created all kinds of gitea references and gitea directory once I brought it up. So to fix my original deployment, I reverted all the references back from forgejo to gitea and everything worked again.

For fun, I went out to codeberg to look at the Dockerfile and saw that they had a bunch of gitea things within their own Dockerfile so nothing I can do for now

This looks interesting too

Love that username tho!! Yeah might just do RSS. I already run FreshRSS and it’s ability to filter stuff would probably come in handy too

This sounds like the simplest and most effective solution. Thanks!

Interesting… do you like this way more or the rss route more?

Was not aware of Diun, will check out!

After you mentioned it, I looked it up too and stumbled on a similar answer to that link. Thanks!

Simple solution. I like it! Although I think it will get lost in the sea of daily emails….

Okay so your post inspired me to make the switch. All I had to do was switch out the image to the forgejo one. Everything worked right away. To try to make things as clean as possible, I went ahead and renamed my bind volume paths and app.ini stuff from gitea to forgejo but no matter what I tried, once I started the container, the container would create a gitea directory with a new app.ini. I even tried to run the forgejo compose on another host and the app still creates a gitea directory within the bind mount. Am I doing something wrong. I understand it’s a drop in replacement but I’m sure there’s a way to get a cleaner cut over.

compose.yml

volumes:

• ./data:/data

Host directories

~/forgejo

• data - forgejo - renamed for the migration - git - ssh - gitea - gets created by the app no matter what I do or what paths are set in app.ini
• compose.yml

How do I keep forgejo from creating this gitea directory? Why doesn’t it create a forgejo directory???

Edit: gitea version was - 1.21.7 and forgejo replacement image is 1.21.7-0