hyperion

Looking at libraries/clean-source-libs.sh I think I know what went wrong. From the base directory run git checkout libraries to restore the extra files deleted by ./libraries/clean-source-libs.sh, then try again. if you pass --with-system-cxxtest to ./libraries/build-source-libs.sh, then you have to do the same to build/workspaces/update-workspaces.sh and have the cxxtest package installed via package manager. Edit: https://gitea.wildfiregames.com/0ad/0ad/pulls/7130

Unlikely to be sdl related, for the sake of it I tested against 2.18 and there I can also reproduce the issue, resetting hotkeys doesn't work either. As for when more then 4 hotkeys get assigned I haven't figured out a minimal reproducer yet, it just sometimes happens.

On Debian you have to have the package python-is-python3 installed if you us the bundled copy. Or you can pass --with-system-cxxtest to update-workspace.sh if you have the cxxtest package installed.

What is the failure message you get? If you have system cxxtest you also might want to use that as this configuration is now supported.

Nice to see some toolkit love dropdowns are rendered behind other items horizontal scrolling is missing, and we can see that there should be a way to specify the size of the scrolled panel, so items resizing themself based on parent don't end up like the following. The only other thing I noticed is scrolling with mouse wheel when placing the courser anywhere in the scrollpanel isn't implemented yet.

The nightly-build repo is meant to provide Windows users a prebuilt binary. I doubt it was anticipated that someone would use it to build pyrogenesis. Some scripts expect to be living in a git repo. Check https://gitea.wildfiregames.com/0ad/0ad/wiki/BuildInstructionsGettingTheCode

1.21.1.4 looks to be older than the gpu, which might or might not be an issue.

"pull/216/head:pr216" is a called a refspec https://git-scm.com/book/en/v2/Git-Internals-The-Refspec while you don't have to checkout main first, a dirty branch won't work indeed, either commit or stash https://git-scm.com/book/en/v2/Git-Tools-Stashing-and-Cleaning or reset https://git-scm.com/book/en/v2/Git-Tools-Reset-Demystified first.

There are many ways to setup remotes. As for rebase-ing the active branch a simple: git fetch git rebase origin/main will do. Here I obviously assumed origin points to 0ad/0ad. Also demonstrates why you probably never will use pull. Actually you will even find plenty on "git pull evil" on the net. The term local fork can also be misleading/confusing. There are three repositories in the pr workflow: 0ad/0ad, <user>/0ad, and local. The term fork I'd only ever use for meaning <user>/0ad, just to avoid possible conceptual issues. A simple setup could be having only one remote configured in your local repo but setting url to 0ad/0ad and pushurl <user>/0ad. Let's assume the sole configured remote is origin. git remote set-url origin https://gitea.wildfiregames.com/0ad/0ad.git git remote set-url --push origin https://gitea.wildfiregames.com/<user>/0ad.git This makes commands simple stupid, but has it's own drawbacks. Recommended reading https://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes

You could start with testing the build instruction https://gitea.wildfiregames.com/0ad/0ad/wiki/BuildInstructions Should have all info you need, but might need some refinement still.

Add 0ad/0ad repo as a (default) remote and you never have to update your fork

I don't know zulip but it seems to offer threadding over irc, but for that we have the forum and I think important topics can and should live here just as before. Also seems to need self-hosting. For casual development chat I don't think irc is lacking at all. Has the advantage to run even if our infra is down. And joining a network/channel is really simple for most everyone. Migrating to a different irc networks isn't that big of a deal either so freegamedev is fine by me if that feels like the natural choice, worst case we just migrate again.

There are also plenty of moldy dds textures where to source files are missing, if you are into restoration that might be something worth looking into as well

Well, semantics if you want, but in a dvcs unlike the cvcs there is no real "upstream"

Submodules are probably best described as pointers and are at least as hard to work with as pointers in C. The repository pointed at is a normal independent git repo.

That can be taken as an argument against an svn source-libs repo and using individual git repos if you want. There is no difference who hosts it, except that one hoster may be down while the other currently isn't. Basically, the use of submodules as described so far is just replacing a repo uri and a hash in "update-workspace.sh" with a submodule and that is definitely not worth the associated pain.

The point is not how to make submodules less cumbersome for some people but not others but if they offer anything at all in our case. We already have such a script, it's called update-workspace.sh for Linux, and any dep that can reasonably be un-vendored has a --with-system-* switch. Debian won't gain anything new at all by using submodules instead of plain old fetch everyone understands.

NIST banned the use of sha1 and I expect a strong push to migrate to sha256 object format the next couple years. The git object format is no longer labeled experimental and gitea supports it properly for all I know. Suggest to at least consider it.

Working with submodules is terribly difficult. A web search will give you plenty of blog post of how people thought it's a good idea for there use case and shot themself in the foot. And there was even an argument for using svn because of difficulty earlier in this thread. There are situations where submodules make sense but to use it to pretend it's not part of the repo isn't one. If you want to have it linked just put it in directly as was done in the past. Though simply fetching as part of the build process is a far better approach imho. The svn source-libs repo as a stop gap solution I'm fine with, even tho individual git repos for each source lib would be better.

Which doesn't make sense to me, also I have seen it in the wild. To render scoped labels as they call it as scoped labels only if they are also exclusive is counterintuitive. I'm not alone thinking such https://github.com/go-gitea/gitea/pull/23164/commits/c278def8e3441783b1c07c67bd4bf208d487950b There are open bugs for broken/bad contrast algorithm, so for now choosing colors that work is what one can do. The activity labels are pointless. "reviewer-needed" is true for any open pull request by virtue of being open. Does "under-review" have any connotation other than I grabbed that PR and anyone else should stfu? "work-in-progress" is just the unsafe way to mark a PR as WIP. The "resolved" are also not ideal as it stands for closed, however needs-info could just as well be kept open and only if we don't hear from a user over a certain time close it. Also fixed is closed without any tag. I think it would also make sense to merge priority labels 4 and 5. Basically low medium high and bricked are enough.

7-char will blow up on us, 10-char is just about acceptable, rough approximation: $ bc <<< "scale=15; commits=25000; digits=10; commits^2 / (2*(16^digits))" .000284217094304 Whatever should be added to gitconfig, also remember commands like revert will pre-populate the commit message with full hash. Well, white on light gray I have trouble reading. Help! Component instead of theme maybe, also make them key value pair labels? Coloring the value portion of the label is separate from coloring the key portion, I only suggest the key portion to be the same across a label type. White space would be fine me thinks. An indicator that there are just to many. Let's say open/closed for status is enough *runs*

https://gitea.itms.ovh/issues should list a logged in users issues instance wide. I almost always use git log from cli. That one works, tho the one I had in mind was a tweaked version of the one on play0ad IIRC. Use what you deem fit. While we are discussing UI, the labels are somewhat messy. The color scheme makes it a bit hard to read them, maybe a bit more muted would be better. Those theme/.. labels should be changed to some more meaningful text, theme/core-engine feels just wrong. The type portion of labels should probably have same color for labels of the same type. The priority labels using kebab case feels meh, also starting with a number is not needed. The time tracking feature for issues probably should be disabled, don't think we will use it.

Similar but better looking if I'm not completely wrong I meant the gitea instance hosted at git.wildfiregames.com at some point. I think it was based off of the one on play0ad.com

I guess that is what the adriane tool mentioned is meant for but a draft document outlining the plan would allow us to actually comment on not just guesses @Itms , I remember @Stan` had a header header which look quite slick for his PoC, maybe you could reuse it (didn't screenshot it). Would give the instance a cooperate branding / personal touch and would give the links leaving the instance a separate place to live as having them mixed feels not that great tbh.

np Can't edit the wiki with the new account, same for bugs and I just assume I can't push either. About bugs guess we need a group as well, @Langbart's work would be a good example for the bug-wrangler role. The path is documented on the page Phabricator. Guess an acceptable compromise. Is there a similar document for trac becoming read-only?