Bug 1395127

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

The issue is temporarily solved by use of compat-openssl10-devel package.

This workaround allow mariadb package to be build in rawhide.

Upstream support is not expected sooner, than in MariaDB 10.2.x release.

Tests revealed, that compat-openssl packade didn't solved that issue.

$ mysql --ssl-mode REQUIRED
ERROR 2026 (HY000): SSL connection error: SSL is required but the server doesn't support it
______________

MariaDB package can be built, but does not support SSL communication.

mariadb fails in rawhide now because GCC 7 has new warnings:

/builddir/build/BUILD/mariadb-10.1.21/storage/tokudb/PerconaFT/util/dbt.cc: In function 'int toku_dbt_set(uint32_t, const void*, DBT*, simple_dbt*)':
/builddir/build/BUILD/mariadb-10.1.21/storage/tokudb/PerconaFT/util/dbt.cc:201:21: error: this statement may fall through [-Werror=implicit-fallthrough=]
             d->ulen = 0;
             ~~~~~~~~^~~
/builddir/build/BUILD/mariadb-10.1.21/storage/tokudb/PerconaFT/util/dbt.cc:203:9: note: here
         case (DB_DBT_REALLOC):
         ^~~~
cc1plus: all warnings being treated as errors
make[2]: Leaving directory '/builddir/build/BUILD/mariadb-10.1.21'

Packages that use -Werror in release tarballs should be incinerated. Please fix the mariadb.spec to remove -Werror so fedora packagers don't have to waste time and energy debugging spurious failures.

Johnathan, thanks for the report.

(In reply to Jonathan Wakely from comment #4)
> Packages that use -Werror in release tarballs should be incinerated.

While I agree that -Werror in upstream tarball is unlucky, I wouldn't
be that offensive.  That's unfortunate upstream issue, and our maintainer
are innocent.

> Please fix the mariadb.spec to remove -Werror so fedora packagers don't
> have to waste time and energy debugging spurious failures.

I think it is fair to report such issue, so again thanks.  It would be
really wasting of resources if you burned your own time with fixing this,
that's something which should be resolved by mariadb maintainer.

(In reply to Pavel Raiskup from comment #5)
> Johnathan, thanks for the report.
> 
> (In reply to Jonathan Wakely from comment #4)
> > Packages that use -Werror in release tarballs should be incinerated.
> 
> While I agree that -Werror in upstream tarball is unlucky, I wouldn't
> be that offensive.  That's unfortunate upstream issue, and our maintainer
> are innocent.

Right, the flaming arrows should be fired at upstream :-)

> > Please fix the mariadb.spec to remove -Werror so fedora packagers don't
> > have to waste time and energy debugging spurious failures.
> 
> I think it is fair to report such issue, so again thanks.  It would be
> really wasting of resources if you burned your own time with fixing this,
> that's something which should be resolved by mariadb maintainer.

It's already wasted two people's time, following a test mass rebuild for gcc 7, and then my own rebuilds for boost 1.63, and soon there will be a mass rebuild for the whole of f26. If it still fails then it will also waste someone in the releng team's time as they also investigate why it failed. That will be three people having to investigate the same "error".

(In reply to Jonathan Wakely from comment #6)
> It's already wasted two people's time, following a test mass rebuild for gcc
> 7, and then my own rebuilds for boost 1.63, and soon there will be a mass
> rebuild for the whole of f26.

Seriously, it _is_ wasting of time to even look at build logs for packages
which already _have_ FTBFS filed (and not fixed).  Why would you do this?
This is OT, but what's your proposal for this in general?

What I'm saying is that it is not possible to assume that _no package_ has
unfixed FTBFS  bug in general at the time of any mass rebuild.

Also, I don't think this is a case where anybody should waste much time,
except for the package maintainers while *fixing* it ... because it is still
obvious -Werror issue.

(In reply to Pavel Raiskup from comment #7)
> (In reply to Jonathan Wakely from comment #6)
> > It's already wasted two people's time, following a test mass rebuild for gcc
> > 7, and then my own rebuilds for boost 1.63, and soon there will be a mass
> > rebuild for the whole of f26.
> 
> Seriously, it _is_ wasting of time to even look at build logs for packages
> which already _have_ FTBFS filed (and not fixed).  Why would you do this?

From the discussion above it looked like this package was no longer failing to build, so the failure I saw is presumably due to the gcc 7 update or the boost update.

> This is OT, but what's your proposal for this in general?

Remove -Werror now, so it doesn't cause spurious failures again in future.
 
> What I'm saying is that it is not possible to assume that _no package_ has
> unfixed FTBFS  bug in general at the time of any mass rebuild.

But this package *was* building before the gcc 7 update:
https://koji.fedoraproject.org/koji/buildinfo?buildID=836099

So it's necessary to look at the logs and see what the new failure is, and decide if it's due to the update I'm working on.

> Also, I don't think this is a case where anybody should waste much time,
> except for the package maintainers while *fixing* it ... because it is still
> obvious -Werror issue.

Which you can't know until doing the scratch build and looking at the logs.

(In reply to Jonathan Wakely from comment #8)
> From the discussion above it looked like this package was no longer
> failing to build, so the failure I saw is presumably due to the gcc 7
> update or the boost update.

I missed this, sorry.  Yes, this wasn't proper FTBFS before, it is now,
thanks _again_ for reporting this.  So far it was useful bugreport then,
nobody wasted a time, as you are the first reporter, right?

But please don't ignore my question.

(In reply to Jonathan Wakely from comment #6)
> It's already wasted two people's time, following a test mass rebuild for gcc
> 7, and then my own rebuilds for boost 1.63,

Suppose that you aren't running this discussion, how we should let you know
that observing mariadb's build logs for Boost mass build is wasting of your
time (even building actually is..).  Please propose a solution, so this never
happens again.

Some of my ideas:
* Please create a tracker where deps are going to be added/removed
  realtime.

* Please look at Koschei, not only at production builds:
  https://apps.fedoraproject.org/koschei/package/mariadb?collection=f26

(In reply to Pavel Raiskup from comment #9)
> But please don't ignore my question.

I didn't ignore it, I said that -Werror should be removed from the build. Time *was* wasted, by two different people so far, analysing build logs because of a new failure (one of those was before gcc7 was in the buildroot, so koschei would not have helped). That new failure was not a real problem, it was caused by -Werror. Removing it will stop that happening again in future.

A general solution for dealing with failures during mass rebuilds is off-topic here.

(In reply to Jonathan Wakely from comment #10)
> (In reply to Pavel Raiskup from comment #9)
> > But please don't ignore my question.
> 
> I didn't ignore it,

Yes you do, sorry.  See the last statement.

> I said that -Werror should be removed from the build.

Yes, I'm sure mariadb maintainers are the guys who will solve this.  There
are rules to use provenpackager's power in such situations.

> Time *was* wasted, by two different people so far

... first time person (reporter's) time is not wasting of time (unless you
are brave enough to claim that bugs don't happen).

So I'm asking why the second person's time was wasted and how to avoid
that in future - because certainly this is an issue.  And you told that
even other man power could be wasted, how?

What I'm trying here is to be constructive, but I'll probably stop continuing
with this, because it isn't not.

I'm just sad that something made you upset enough to say that any such
package (unintentional release tarball with -Werror, which succeeded the
build! some day) should be incinerated.

Created attachment 1246439 [details]
Proposed (not tested) change.

For the issue reported by Johnathan.  Very blind, but it avoids FTBFS
probably (tests are still running on my box).

Disabling maintainer mode in autotooled packages is mostly a wrong thing,
so I'm not sure whether something similar applies to mariadb source.  The
remaining question would be why the default is AUTO, and what that mans
for us (as consumers of upstream tarball).

Same for the (seemingly?) bundled stuff, I'm not the expert.  This needs
to be raised upstream.  Also I maybe haven't killed every -Werror
occurrence in mariadb sources.

Doing some ultimate '-Wno-error' solution "forever" as requested is hard
problem.  If distribution (or anybody) cared enough about "that's the wrong
thing in general!" point, at the same time it should spend some efforts to
have this fixed in general.

The errors I've seen are all in the PerconaFT sub-directory, so it's possible that just editing storage/tokudb/PerconaFT/cmake_modules/TokuSetupCompiler.cmake is sufficient. Either that or modifying the "//Fall through to xxx" comments so that they match patterns GCC recognizes, e.g. "//Fall through" or "//Fall through..." would work, if upstream insist that -Werror is important.

Guys

*
My bad, I forgot to mark this tracker as FTBFS.
The current state about OpenSSL 1.1 is that, I believe, upstream will release 10.2.x version, which will solve it. Until that day, MariaDB can't move to stable F26 either way.

*
I informed upstream about the issue:
https://jira.mariadb.org/browse/MDEV-11965

I'll take appropriate steps, once a decission is made, which way upstream wants to go.

This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.

MariaDB 10.2.7 is currently in Rawhide, and it contains OpenSSL 1.1