Package mariadb-10.3 forked in Debian, patches not upstreamed

See diff: http://ubuntudiff.debian.net/?query=-FPackage+mariadb-10.3

No response from William Grant in 2 months.

@otto we are bootstrapping a new port from scratch, and yes currently there are a lot of things that are patched in less than ideal manner. I'm not quite sure there is anything to upstream really. As above really, is a kludge, rather than a solution.

Thanks @xnox for the reply.

The patches don't need to be perfect. Upstreaming is helpful because it will bring the issue attention, and the fact that you have identified the issue exactly and written a workaround that is proven to work is surely very helpful and that information should flow upstream in some way or another. If it is not the final solution, this level of debugging information with a working patch surely helps upstream devs a lot and is the path towards a more complete solution.

Riscv64 is also a platform most devs don't have any clue about even exists nowadays in Ubuntu. I already filed an issue for Galera upstream at https://github.com/codership/galera/issues/576

I hope you support the effort by filing an issue upstream at jira.mariadb.org about the issues you found (or for RocksDB even upstream upstream at https://github.com/facebook/rocksdb/issues), and if you open a MR on the Debian packaging at least the mariadb-10.3 can continue to sync while we wait for a better solution to be developed for the riscv64 issues.

Thanks!

I agree that we can at least forward things on an informative base, even though not having the perfect solution yet.

#1
Upstream issue for libatomic: https://jira.mariadb.org/browse/MDEV-23051
Which BTW is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933151
(I sent an FYI to that bug as well)

#2
Fixes broken into individual commits for better discussion/consumption.
Stripped changelog and update maintainer.
Added some comments / improved description.
Rebased onto debian/master containing 10.3
Submitted as https://salsa.debian.org/mariadb-team/mariadb-10.3/-/merge_requests/28

Actually looking at https://github.com/riscv/riscv-gcc/commit/2c4857d0981501b7c50bbf228de9e287611f8ae5

It seems like the spec file, on riscv, should auto-add -latomic when linking things. Is gcc not used to link in this case?

Interesting xnox,
if you look here https://buildd.debian.org/status/logs.php?pkg=mariadb-10.3&arch=riscv64 you see the sad build history.

The fail seems to happen with g++:

195782 cd /<<PKGBUILDDIR>>/builddir/storage/perfschema && /usr/bin/riscv64-linux-gnu-g++ -DHAVE_CONFIG_H -DMYSQL_SERVER -D_FILE_OFFSET_BITS=64 -I/<<PKGBUILDDIR>>/builddir/include -I/<<PKGBU
195783 /usr/bin/ld: librocksdblib.a(memtable.cc.o): in function `rocksdb::SpinMutex::try_lock()':
195784 ./builddir/storage/rocksdb/./storage/rocksdb/rocksdb/util/mutexlock.h:106: undefined reference to `__atomic_compare_exchange_1'
195785 /usr/bin/ld: librocksdblib.a(memtable.cc.o): in function `void rocksdb::DynamicBloom::AddHash<rocksdb::DynamicBloom::AddHashConcurrently(unsigned int)::{lambda(std::atomic<unsigned ch
195786 ./builddir/storage/rocksdb/./storage/rocksdb/rocksdb/util/dynamic_bloom.h:181: undefined reference to `__atomic_fetch_or_1'
195787 /usr/bin/ld: ./builddir/storage/rocksdb/./storage/rocksdb/rocksdb/util/dynamic_bloom.h:182: undefined reference to `__atomic_fetch_or_1'
195788 /usr/bin/ld: librocksdblib.a(memtable.cc.o): in function `rocksdb::MemTable::Add(unsigned long, rocksdb::ValueType, rocksdb::Slice const&, rocksdb::Slice const&, bool, rocksdb::MemTab
195789 ./builddir/storage/rocksdb/./storage/rocksdb/rocksdb/db/memtable.cc:583: undefined reference to `__atomic_fetch_or_1'
195790 /usr/bin/ld: ./builddir/storage/rocksdb/./storage/rocksdb/rocksdb/db/memtable.cc:583: undefined reference to `__atomic_fetch_or_1'
195791 /usr/bin/ld: librocksdblib.a(memtable.cc.o): in function `std::__atomic_base<bool>::compare_exchange_weak(bool&, bool, std::memory_order, std::memory_order)':
195792 /usr/include/c++/9/bits/atomic_base.h:457: undefined reference to `__atomic_compare_exchange_1'
195793 /usr/bin/ld: /usr/include/c++/9/bits/atomic_base.h:457: undefined reference to `__atomic_compare_exchange_1'
195794 /usr/bin/ld: /usr/include/c++/9/bits/atomic_base.h:457: undefined reference to `__atomic_compare_exchange_1'
195795 /usr/bin/ld: /usr/include/c++/9/bits/atomic_base.h:457: undefined reference to `__atomic_compare_exchange_1'
195796 /usr/bin/ld: /usr/include/c++/9/bits/atomic_base.h:457: undefined reference to `__atomic_compare_exchange_1'
195797 /usr/bin/ld: librocksdblib.a(memtable.cc.o):/usr/include/c++/9/bits/atomic_base.h:457: more undefined references to `__atomic_compare_exchange_1' follow
195798 collect2: error: ld returned 1 exit status

Currently rocksdb considers to add it to their build at https://github.com/facebook/rocksdb/pull/7060/commits/af4046c6ae81e0e03594921a405717fc3a869119

And in my Debian MP we try that patch instead of the disabling.

Opened https://gitlab.kitware.com/cmake/cmake/-/issues/20895

This will affect a lot of other projects too, basically anything that uses atomics + CMake.

I wonder if we can patch debhelper or dpkg-buildflags to add `-latomic` on RISCV64 by default there too. As it seems like CMake is bypassing gcc frontend, and thus doesn't get `-latomic` auto-added when linking things.

This bug was fixed in the package cmake - 3.16.3-3ubuntu2

---------------
cmake (3.16.3-3ubuntu2) groovy; urgency=medium

  * Append -latomic on RISCV, as some atomics need libatomic support. LP:
    #1876814

 -- Dimitri John Ledkov <email address hidden> Wed, 01 Jul 2020 13:29:05 +0100

Migration of 1:10.3.24-1 from groovy-proposed to groovy currently blocked by https://bugs.launchpad.net/ubuntu/+source/diaspora-installer/+bug/1892623 (autopkgtest failures)

Hello, looks like rocksdb support has been dropped in the debian sync
http://launchpadlibrarian.net/487431800/mariadb-10.3_1%3A10.3.22-1ubuntu1_1%3A10.3.22-1ubuntu2.diff.gz

I asked to drop that package, to let it migrate

and it now migrated.

Related, latest Galera 3 and 4 have not migrated from groovy-proposed to groovy also due to riscv64 build failures. Reported upstream at https://github.com/codership/galera/issues/576

Hello, I'm syncing cmake from Debian, the latomic was the only part left on our delta, and this is now properly addressed on mariadb side.
I don't think we should keep this cmake patch now that riscv is also a Debian port, and we have asneeded default flag there too.

Hi Gianfranco!

What do you mean by keeping the "cmake patch"? Which patch and which package? You mean the one applied in cmake - 3.16.3-3ubuntu2?

MariaDB in Ubuntu is and has been in sync for a long time already:
- mariadb-10.3: https://salsa.debian.org/mariadb-team/mariadb-10.3/-/commits/ubuntu-20.04/
- mariadb-10.6: https://salsa.debian.org/mariadb-team/mariadb-server/-/commits/ubuntu-22.04/
- next mariadb-10.6: https://salsa.debian.org/mariadb-team/mariadb-server/-/commits/debian/latest

Hello Otto, yes, I mean the cmake patch.
It was added to make mariadb build, but mariadb now builds without the need for it.

Thanks