In D1687#66940, @elexis wrote:

Not few flags, libCURLs ./configure --help | grep without yields

@trompetin17 It looks like you have yet another system lib which tries to sneak into the build 😠 Can you try --without-brotli? Just like we did with nghttp2.

Clarifying a small thing in Stan's answer (which is correct): when D1687 is committed (tonight probably, as trompetin is testing it as we speak), mod.io will work for everyone, regardless of who built the game.

@elexis Yeah, it's the clock_gettime thing...

@vladislavbelov In the staff discussions, it seemed that we had reached a consensus on creating this new room, but leaving the other version numbers intact (in order to push people into upgrading, without forcing them). On top of what elexis said, we are legally obliged to push the lobby users into using A23b, so that they can accept the new terms.
The consensus in that topic is the reason why I asked user1 to commit this, but if you want I can formally accept this revision.

The patch is currently useless, because xcodebuildsettings was added in premake5 alpha12 (we have alpha10): see https://github.com/premake/premake-core/wiki/xcodebuildsettings.

I agree, but I think you didn't test this? The option must be accessed with _OPTIONS (see the other use of it in the file for an example) and I suggest running the whole premake script with and without the parameter passed.

In D1669#66853, @Stan wrote:

I see. Won't be hard to keep track of all the patches we apply ? For now we only have one but we might have more in the future, no ?

In D1669#66846, @Stan wrote:

Might I suggest to save this as a patch and apply it on premake when updating update workspaces on OsX ?

Yet another lib that might be detected by configure even though we don't have it and we don't need it. Disabling it explicitly is needed to link pyrogenesis.

Instead of abandoning this revision which was superseded by D1610, D1609 and D1685 (in order of committing), I take the liberty to commandeer it to include yet another manual disabling of a library we do not use.

This should use premake5.lua's macosx-version-min variable in order to avoid hardcoding. With D1685, this will actually be 10.9.

Final version.

Final version.

In D1679#66719, @Stan wrote:

I understand your point. My concern was mainly about people who don't report bugs because it's not a common thing to do :)

First of all, I can reproduce the crash on Fedora, and the current patch does fix it when the TLS box is unticked. So the C++ change is good 👍

Looks good to me! Please commit it if this allows Fedora users to work around the crash.

With this fix, the detection from gnutls' configure script will be overridden.

So the big flaw of rP19669 is that the Phabricator Jenkins plugin has this issue: https://github.com/uber/phabricator-jenkins-plugin/issues/224

Thank you for the patch! Unfortunately those checks are the same as what is checked by build/jenkins/lint-translations.sh. The thing that is missing from this is a check for broken custom tags (like [font] ones, typically).

In D1676#66386, @vladislavbelov wrote:

Isn't the flag needed in the premake4.lua too?

@trompetin17 Could you test this? I added -UCLOCK_REALTIME, this should work (see this piece of the GnuTLS code).

Regarding the premake5 change, it looks good, you could remove the offending line from build/premake/premake5/premake5.lua for completeness. I hope to get a quick answer on issue 1154.

In D1654#66152, @elexis wrote:

It was just that it shouldn't be possible to obtain the stacktrace that Tobbi received, where the macro says 10.8 and the compiler says 10.7:

Couldn't it come from what @trompetin17 has discovered, that premake5 itself has a hardcoded 10.4 minimum version? See this line and others, all coming from this code in p5 a10.

In D1671#66080, @trompetin17 wrote:

Itms, could you point me where do you see about drop 10.9 to 10.11, because when i tried sdl2.0.9 i didnt change minimal osx version and builded normally

Yes, like Vlad says, we should change our own defaults in the premake scripts, but we mustn't touch premake source (it's easier to maintain when we match upstream).

Small changes to the macOS scripts.

• date update based on previous patch
• the --enable-64bit flag is needed for nspr when developing on recent versions (we are already building 64bit only)
• the --without-libpsl precision is needed to avoid issues when libpsl is installed and detected

@Stan If you don't mind, I'm commandeering this one to have all the small changes to macOS scripts in one diff! :slight_smile:

Apart from that, I cannot reproduce my mod.io bug, so this patch should be fine (tested on a clean repo).

@elexis: I have looked around about this issue, and I might have misunderstood a few remarks from you that were unclear to me, but I think I know what is bugging you. I also know why certain version numbers are 8, others 9, and why the reason for dropping 7 was unclear (thanks to some attempts by trompetin).

In D1659#65921, @Vulcan wrote:

Build failure - The Moirai have given mortals hearts that can endure.

After a more careful testing, indeed this commit doesn't introduce the issue. It might come from D1654 after all. However,

In D1654#65543, @Itms wrote:

Yes, I think we should have 10.9 in the bundle generation script, and we should add a comment "keep in sync with build-libs" in build-bundle.

In rP21913#31478, @Stan wrote:

I'm pretty sure we can't have letters in mod versions.

Wrong place? 😛 This is unrelated to mods, but if the bundle version cannot have letters, it should still be 23, not 24.

In rP21913#31475, @elexis wrote:

It does ask for ssl since it complains about ssl not being available. (It should ask for ssl if and only if the default.cfg mod.io url starts with https://)

I was talking about the compilation of curl, not the request made to mod.io.

In D1654#65539, @elexis wrote:

sw_vers -productVersion yields 10.13.6

Should we commit the 10.7 drop

I really don't have a clue about the share of our users (both players and people who build the game) who use a given version of macOS. If Tobbi needs to drop 10.7 to build on his machine, I think we have to do that. If somebody has 10.7 and wants to play, we can help them build it themselves.

In rP21913#31472, @elexis wrote:

• What is the error message?
• Sure it is this commit and not rP21914, or a forgotton cleaning of buildfiles, if so how do you know?

It looks like this commit breaks mod.io on macOS (no https support anymore, whereas it worked on the previous revision), but I can't understand why.

This builds and works!

I am progressing on this but not there yet. Hopefully tomorrow!

The build fails on OSX: gnutls needs libnettle. 🙁

Sorry, I just googled what it is! Balancing test assessments are not called like this in GDPR itself, are they? I believe the missing piece is not a comma, but a "through" then.

Apart from the point 14 (actually 13) of WFG obligations, which I believe needs a rephrasing, I am on board with this document! Thanks for all the hard work.

Yes this is good! As soon as it's committed, I'll run the translation bot.

In D1598#65212, @elexis wrote:

Currently at 40 of maybe 80 inline comments, seeking to commit an updated version of the UserReporter terms, unless you want to review it again.

As I said, I was happy with the terms I made a pull request on, so I trust you to commit something that I'm happy with. It's up to you to ask a review from me if you want one 🙂 I'll let you know if I have remarks anyways.

About https://github.com/elexis1/0ad/pull/1, do you have any comments on my suggestions? I really liked this iteration, with generalized mention of the relevant GDPR articles, so I tried to make improvements where I saw fit, but the work was definitely good enough to replace the different Phabricator patches, if you want to finish the review here rather than on GitHub.

In D1617#64735, @andy5995 wrote:

I tried. Travis apparently has a 50-minute limit on tests. It terminates the build.

Hi @andy5995, thanks for the proposal!

Posted some input on the Trac ticket, but I am not reviewing this code :)

In D1601#64362, @elexis wrote:

Hold on,

bb wrote a patch to add a terms UI that works for all 3 current online services. This way this patch doesnt have to introduce a new file.

All current active revision proposals with regards to GDPR are currently in https://github.com/bb-bb/0ad/tree/terms (except D1590, but that will come later)

On it!

ERROR: JavaScript error: simulation/components/Capturable.js line 28
ReferenceError: IID_CaptureManager is not defined
Capturable.prototype.GetCapturePoints@simulation/components/Capturable.js:28:6
@simulation/components/tests/test_Capturable.js:96:26
testCapturable@simulation/components/tests/test_Capturable.js:86:2
@simulation/components/tests/test_Capturable.js:91:1

ERROR: JavaScript error: simulation/components/GuiInterface.js line 246
TypeError: cmpIdentity.CanUseSomeFormation is not a function
GuiInterface.prototype.GetEntityState@simulation/components/GuiInterface.js:246:23
@simulation/components/tests/test_GuiInterface.js:566:25

In D1598#64094, @Vulcan wrote:

Build failure - The Moirai have given mortals hearts that can endure.

Link to build: https://jenkins.wildfiregames.com/job/differential/687/display/redirect

Here are a couple comments on the privacy policy itself. I haven't tested the code, I can find some time for that if needed.

One more batch of comments :) Thanks again for the work on that.

One extra thing that should be tested on that patch is whether a saved game with AIs can be re-loaded without issues.

Damnit. I cannot look into fixing this in the immediate future. Based on the things this commit changes, there is a very small chance that the wrong simulation state is the one of the rejoining player, i.e. fixing/reverting this would not change the sim state, and people with the bug and people without would not go OOS. If that is the case re-releasing with the fix would be less of a problem.

Updated: https://github.com/na-Itms/0ad/tree/osx-fix.

In rP21814#30593, @elexis wrote:

The code in rP21131 calling CFileUnpacker::Read in FileIo.cpp, implementing rmgen being able to load terrain pmp files fixing #4816 looks like it should be compatible, but can someone (ping @Imarok @Itms) verify that Jebel Barkal starts up too with the release candidate? (hint: chose tiny mapsize)

Not really accepted by elexis, and since you seem to be AFK I restarted packaging for a second RC.

rP21812

What I mean is: if you really think this patch is half-baked and shouldn't be committed in a hurry, let's just not commit it and yell at the people who use outdated SVNs without a clue. I wouldn't disagree.

To be fair I'm not sure how someone managed to log in the lobby with an outdated SVN by mistake. Probably using the development PPA, but once again, who would install that by mistake? What are the odds...