Try to fix issue with vibe-core not being selected instead of vibe-d:core

[schveiguy]

See issue #201. This is a trial to see what happens with CI

[schveiguy]

Well, that spectacularly fails, but I don't see why. Looks like server is refusing connections in some cases? The pattern doesn't make much sense. @Abscissa

[Abscissa]

On October 1, 2019 4:24:11 PM EDT, Steven Schveighoffer ***@***.***> wrote: Well, that spectacularly fails, but I don't see why. Looks like server is refusing connections in some cases? The pattern doesn't make much sense. @Abscissa

Come to think of it, there was another mysqln branch someone had recently that hit what sounds like the same problem. I wonder if there's been some kind of change to the mysql server on travis? I'll restart the last build it green-lit on master and see if it magically changes to the same massive failure.

[Abscissa]

Hmm, still green lights. So much for that theory.

And it's definitely nothing vibe-related because the failures on this pr are happening in the phobos-socket tests.

Only other explanation I can think of offhand is that maybe the travis DB configuration is somehow tied to the main repo's master and is failing on PRs.

Sanity check: Could you rebase this on master/head (if it isn't already), and then add a commit reverting the line deletion? If the problem isn't related to running the travis tests on a PR, then I'm not sure what else could be going on.

[schveiguy]

So this branch is literally created the other day, right off of master. I think rebasing doesn't make sense. I can delete the deletion and push, but one huge difference is, this line forces the library to use vibe-d:core instead of vibe-core. So maybe the difference lies there? I know that I've been using vibe-core for a while with v2.2.1 of mysql-native, and haven't seen the types of problems that are showing up here.

Pushing something momentarily...

[schveiguy]

OK, that kinda sucks. Looking at some OSX tests, they are trying to use apt-get to install mariadb, which does not seem to work. Did OSX tests ever work?

Edit: this is in response to #203 (comment)

[Abscissa]

OK, that kinda sucks. Looking at some OSX tests, they are trying to use apt-get to install mariadb, which does not seem to work. Did OSX tests ever work?

Edit: this is in response to #203 (comment)

Ugh, more weirdness. Believe it or not, those OSX failures are completely unrelated, but only by complete accident (thanks for pointing that out, otherwise I wouldn't have even noticed this). And yes, the OSX tests did work before (but again, only by accident). I know that sounds strange, but here's what's happening on OSX:

1. First, the "mariadb" directives in .travis.yml cause travis to attempt installing mariadb. Travis apparently forgets that it's running on osx and tries to use apt-get. (I'll have to see if that's a known issue, and file a ticket otherwise.) Naturally, the call to apt-get blows up as it doesn't exist on osx.

2. But then, just like on linux, travis treats this apt-get failure as non-fatal. I'm very unhappy about this. I really hope it's a travis bug and not intentional. (Another travis ticket to file...) So the build job keeps going...

3. The mysql-native CI setup script uses osx's "homebrew" packager to install and setup the default version of mysql server because it's not provided by travis's osx by default (or at least, it wasn't at the time a "run tests on osx" PR was contributed by someone more knowledgeable about osx than me. Don't know whether that's still the case.) The CI setup script always does this on OSX regardless of whether mariadb was specified in .travis.yml for the build job. I don't remember whether mysql-native's osx testing predates its mariadb testing and the osx stuff just never got updated to properly test on mariadb, or if there was some reason the osx tests deliberately stuck to mysql server. At the very least, the osx tests need to be much more clear about the fact they are always testing mysql server, never mariadb.

4. Since there's now a working mysql server installed (despite the earlier apt-get failure), The tests get run as usual. They used to run successfully, but then a mysql server update broke it: Support MySQL 8's new default: caching_sha2_password #189 Notice that, in the travis logs for the osx jobs, the apt-get stuff doesn't halt the job, but waaay later on it hits this error: mysql.exceptions.MYX@source/mysql/protocol/comms.d(991): Authentication failure: Client does not support authentication protocol requested by server; consider upgrading MySQL client

[schveiguy]

then a mysql server update broke it: #189

Oh right, I remember that one.

[SingingBush]

I have a branch which fixes the Travis CI problem.
https://travis-ci.org/SingingBush/mysql-native/builds/593871377
I'll create a PR once it's complete.

It would be convenient to drop the builds for outdated compiler versions. There's almost 50 build jobs now. Does anyone really use dmd < 2.080?

[itkfm]

Does anyone really use dmd < 2.080?

Debian 9 Stretch seems to be on LDC 1.2 (DMD-FE 2.072)

[SingingBush]

Does anyone really use dmd < 2.080?

Debian 9 Stretch seems to be on LDC 1.2 (DMD-FE 2.072)

There's already builds that will support older D versions. It would be fine to consider the current stable Debian 10.1 Buster (LDC 1.12.0 - dmd 2.082.1) to be something that should be supported by the current state of master branch.

Even supporting GDC (via gcc 8.* and above) would mean that we can target dmd 2.081.1 as a minimum.

The builds in this projects travis file go all the way back to dmd 2.068.2, which makes for a pretty broad range of compiler versions to support going forward. Especially as dmd versions are released more frequently than mysql-native

[Abscissa]

Now fixed. Mysqln master is now fully switched from "vibe-d:core" to "vibe-core".