Hello!
Boyuan Yang:
Your work in the
https://salsa.debian.org/python-team/packages/python-jsonrpc-server
has been saved as branches with the name obsolete/master,
obsolete/upstream and obsolete/pristine-tar. The main branch
debian/master is now based on Pablo's work.
Pablo Mestre:
Please check
One rather major difference is also the chosen name for the binary package:
-Package: python3-jsonrpc-server
+Package: python3-pyls-jsonrpc
There are currently two attempts to package this package.
One from April 2020 at
https://salsa.debian.org/python-team/packages/python-jsonrpc-server
and one from July 2020 at
https://salsa.debian.org/elMor3no-guest/python-jsonrpc-server
They have no shared history. To complete this, I will need t
Hello!
I am still seeing this error with latest apt 2.1.11:
https://salsa.debian.org/mariadb-team/mariadb-10.5/-/jobs/1117112
E: Could not configure 'libc6:amd64'.
W: Could not perform immediate configuration on 'libnss-nis:amd64'.
Please see man 5 apt.conf under APT::Immediate-Configure for det
Control: retitle -1 mariadb-10.5: FTBFS on armhf: compiler seems to segfault
I compared the latest (still failing) armhf build
https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.5&arch=armhf&ver=1%3A10.5.6-2&stamp=1603737750&raw=0
with the last build that passed
https://buildd.debian.org/st
Hello!
My CI builds at
https://salsa.debian.org/mariadb-team/mariadb-10.5/-/jobs/1108870
still fail.
For some strange reason the Debian mirrors still serve 2.1.10:
Get:18 http://deb.debian.org/debian sid/main amd64 apt amd64 2.1.10 [1459 kB]
However 2.1.11 should be in the repos already:
htt
Tags: forwarded -1 https://jira.mariadb.org/browse/MDEV-23697
Hello!
This has been fixed upstream in 10.3.26.
Hello!
Thanks!
Bullseye is meant to ship with 10.5 and 10.3 should be removed once
10.5 has been in Debian testing for a while (currently still in Debian
unstable due to debci false positive).
Great news!
My faith in humanity and the victory of sanity has been restored.
I've now pushed on mariadb-10.5 master the necessary changes in
https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/ca2574aa88434d1c49456c677b7dcb904902daaf
I will keep this issue open, and start excluding extr
Source: mariadb-10.5
Version: 1:10.5.6-1
Forwarded: https://jira.mariadb.org/browse/MDEV-23993
Tags: upstream, confirmed, help, ftbfs
Severity: normal
Justification: source did not build with libnuma before, so can be reverted
User: debian-...@lists.debian.org
Usertags: armhf, arm
In the Debian pa
Hello!
Just to make sure, what does this say on your system?
dpkg -S /etc/logrotate.d/mysql-server
and
find /etc/logrotate.d/m* -ls
Maybe the problem is not the contents of the file, but that the file
is there at all after an upgrade.
Package: libnss-nis
Version: 3.1-4
In my regular Buster to Sid upgrade testing I noticed that apt upgrade
runs started failing one week ago with the error message:
Processing triggers for libc-bin (2.31-4) ...
E: Could not configure 'libc6:amd64'.
E: Could not perform immediate configuration on '
Thanks!
Merged on master at
https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/ccb7291f11c909f9eb46496d25e8697a9940b742
Source: mariadb-10.5
Version: 1:10.5.6-1
Forwarded: https://jira.mariadb.org/browse/MDEV-23974
Tags: upstream, confirmed, help, ftbfs
Severity: normal
Justification: source does build, and tests pass when this test is skipped
User: debian-powe...@lists.debian.org
Usertags: powerpc
The test main.fl
Control: tags -1 confirmed, moreinfo
Hello!
Yes, technically I could do a backport for Buster. Note however that
doing so would create a package that replaces rdiff-backup 1.0 on the
next 'apt upgrade' and there might be some backwards incompatible
changes.
I'd like to have more people voice in
Hello!
Just to follow up on this topic, the riscv64 build on Debian has
worked perfectly since last upload. The builds and test suites have
never run this well ever before for MariaDB 10.5 on so many platforms:
https://buildd.debian.org/status/package.php?p=mariadb-10.5
Thanks Aurelien!
PS. Plea
Hello!
The status at http://crossqa.debian.net/src/mariadb-10.5 looks now
with mariadb-10.5 release 1:10.5.5-3 much better than before.
Thanks for your help!
If you have further improvement suggestions regarding cross-building
or multiarch issues, please let me know by email or submit Merge
Requ
Source: mariadb-10.5
Version: 1:10.5.5-3
Forwarded: https://jira.mariadb.org/browse/MDEV-23922
Tags: upstream, confirmed, help, ftbfs
Severity: normal
Justification: source does build, and tests pass when this test is skipped
User: debian-al...@lists.debian.org
Usertags: alpha
The test main.alter_
Source: mariadb-10.5
Version: 1:10.5.5-3
Forwarded: https://jira.mariadb.org/browse/MDEV-23916
Tags: upstream, confirmed, help, ftbfs
Severity: normal
Justification: source did not build work before, so nothing regressed,
and this is an unofficial arch in Debian
User: debian-sp...@lists.debian.org
Source: mariadb-10.5
Version: 1:10.5.5-3
Forwarded: https://jira.mariadb.org/browse/MDEV-23920
Tags: upstream, confirmed, help, ftbfs
Severity: normal
Justification: source does build, and tests pass when this test is skipped
User: debian-h...@lists.debian.org
Usertags: hppa
The test repair_symlin
Source: mariadb-10.5
Version: 1:10.5.5-3
Forwarded: https://jira.mariadb.org/browse/MDEV-23922
Tags: upstream, confirmed, help, ftbfs
Severity: normal
Justification: source does build, but tests don't run and binaries are
unvalidated
User: debian-...@lists.debian.org
Usertags: m68k, 68k
As part of
Source: mariadb-10.5
Version: 1:10.5.5-3
Forwarded: https://jira.mariadb.org/browse/MDEV-23915
Tags: upstream, confirmed, help, ftbfs
Severity: normal
Justification: source does build, and tests pass when this test is skipped
User: debian-powe...@lists.debian.org
Usertags: powerpc
The test main.gr
Source: mariadb-10.5
Version: 1:10.5.5-3
Forwarded: https://jira.mariadb.org/browse/MDEV-23921
Tags: upstream, confirmed, help, ftbfs
Severity: normal
Justification: source does build, and tests pass when this test is skipped
User: debian-h...@lists.debian.org
Usertags: hppa
The test main.index_in
Source: mariadb-10.5
Version: 1:10.5.5-3
Forwarded: https://jira.mariadb.org/browse/MDEV-23920
Tags: upstream, confirmed, help, ftbfs
Severity: normal
Justification: source does build, and tests pass when this test is skipped
User: debian-al...@lists.debian.org
Usertags: alpha
The test repair_syml
Control: tags -1 moreinfo
Hello!
If somebody wants to continue working on this issue, please submit
Merge Requests at https://salsa.debian.org/mariadb-team/mariadb-10.5
I promise to review them quickly.
If we don't get any contributions on this topic, I might end up
closing the issue in the com
Control: tags -1 moreinfo
Hello!
If somebody wants to continue working on this issue, please submit
Merge Requests at https://salsa.debian.org/mariadb-team/mariadb-10.5
I promise to review them quickly.
If we don't get any contributions on this topic, I might end up
closing the issue in the com
Hello!
If somebody wants to continue working on this newcomer friendly tagged
bug report, please submit Merge Requests at
https://salsa.debian.org/mariadb-team/mariadb-10.5
I promise to review them quickly.
Control: tags -1 moreinfo
Hello!
If somebody wants to continue working on this issue, please submit
Merge Requests at https://salsa.debian.org/mariadb-team/mariadb-10.5
I promise to review them quickly.
If we don't get any contributions on this topic, I might end up
closing the issue in the com
Control: tags -1 moreinfo
Hello!
If somebody wants to continue working on this issue, please submit
Merge Requests at https://salsa.debian.org/mariadb-team/mariadb-10.5
I promise to review them quickly.
If we don't get any contributions on this topic, I might end up
closing the issue in the com
Control: tags -1 wontfix
Thanks, good to know you solved it for yourself.
I am leaving the bug report open for potential new commenters, but
tagging it as wontfix for now.
Would perhaps using the mariadb-server-core-10.5 package fill the same
purpose fairly easily?
Source: mariadb-10.5
Version: 1:10.5.5-3~exp1
Severity: important
Tags: upstream
Justification: fails to build from source (but built successfully in the past)
User: debian-sup...@lists.debian.org
Usertags: sh4
The MariaDB Server package was building fine on sh4 in version
1:10.5.5-2. However the
Hello!
> Can we use the patch I proposed earlier in this bug report? I have
> tested it on riscv64 and it builds. I can do another try with the
> changes from the latest upload and propose a MR on salsa.
Sorry, I somehow missed this. Also other "subscribers" of this bug
missed it since the Debian
We removed it due to low or no use.
It will s unclear what the use case even is. In an embedded scenario you
most likely are better off compiling yourself a version that only has the
parts your embedded system actually needs?
Let's see if anybody else chips in here and if there was other consumer
Hello!
Thanks for your help with x32!
The x32 build now passes thanks to
https://salsa.debian.org/mariadb-team/mariadb-10.5/-/blob/master/debian/patches/ftbfs-x32.patch
Would you like to submit this upstream at github.com/mariadb/server
branch 10.5 so it will be fixed globally?
- Otto
Hello!
ti 6. lokak. 2020 klo 14.41 Otto Kekäläinen (o...@debian.org) kirjoitti:
>
> Thanks Daniel!
>
> I applied it in
> https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/061acd336f7cdaa16ff0271feafce4a2551ab903
> and tested on Launchpad to ensure that it does no
Thanks Daniel!
I applied it in
https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/061acd336f7cdaa16ff0271feafce4a2551ab903
and tested on Launchpad to ensure that it does not at least regress :)
https://launchpad.net/~otto/+archive/ubuntu/mariadb/+builds?build_text=&build_state=all
I will
Thanks!
That seems to be on the 3.1 branch at
https://github.com/mariadb-corporation/mariadb-connector-c/commit/29720950eeae75f1ea7ef1376a6149cabeb79d13
and will be part of the next 3.1.11 release.
Will you also do the server commit?
/mariadb-team/mariadb-10.5/-/blob/master/debian/patches/933063-client-utf8mb4-by-default.patch
and easily drop it once that upstream commit is eventually imported
into Debian.
su 4. lokak. 2020 klo 12.39 Otto Kekäläinen (o...@debian.org) kirjoitti:
>
> Thanks!
>
> I confirm the patch from
Yes, please change to 'service mariadb start' or 'systemctl start mariadb'
(works also without systemd is systemctl-shim is installed).
Systemd supports aliases while init.d not, so that is why the other works
with both names and the other does not.
Hello!
I already asked this on Zulip but did not get anywhere, so re-posting
here on the mailing list.
The basic test suite run directly after the build fails with the
following test on hppa on Debian:
https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.5&arch=hppa&ver=1%3A10.5.5-1&stamp=1
Hello!
I plan to upload mariadb-10.5 1:10.5.5-2 in a couple of days and I
would be happy to receive merge requests regarding getting riscv64 to
build properly on Debian.
http://bugs.debian.org/933151
https://wiki.debian.org/Teams/MySQL/patches
ti 29. syysk. 2020 klo 16.48 Otto Kekäläinen (o
Control: tags -1 moreinfo
Hello Laurent!
Can you help with testing?
ti 22. syysk. 2020 klo 1.24 Otto Kekäläinen (o...@debian.org) kirjoitti:
>
> Hello!
>
> libnuma has been included since
> https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/2039c2755d0c642718dcc8be8
> On Sun, Oct 04, 2020 at 12:36:30PM +0300, Otto Kekäläinen wrote:
> > Patch slightly refined, tested and pending at
> > https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commits/bugfix/971579-cross-compilation
> > for inclusion to main branch.
>
> I fear your refine
Hello!
Any comments to this
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971255 from anyone?
Should we revert back to shipping /etc/init.d/mysql on fresh installs as well?
> > I did not find any code that would change the username and for recent
> > years the setting has said "user = root", and before that it was
> > "user = debian-sys-maint"
>
> This is (or used to be) the MySQL default. Is MySQL now also using the
> socket authentication and root?
Yes, als
la 3. lokak. 2020 klo 18.17 Matija Nalis (mnalis-debian...@voyager.hr)
kirjoitti:
>
> Yes, I can write a shell test scripts which looks like
> https://salsa.debian.org/mariadb-team/mariadb-10.5/-/blob/master/debian/tests/smoke
>
> and verify that (when run from shell) it fails with non-zero
> error
Hello!
> Keep in mind however what the goal is. Whenever you think about
> multiarching a -dev package, the only use case is cross building. But
> most of the time, cross building never requires marking -dev packages
> multiarch. It just makes it more convenient for developers. So really,
> removi
Thanks!
I confirm the patch from Georg fixes this and the result looks like:
g++ b933063.cpp -l mariadbclient && ./a.out
character_set_client: utf8mb4
character_set_connection: utf8mb4
character_set_database: utf8mb4
character_set_filesystem: binary
character_set_results: utf8mb4
character_set_se
Hello!
Thanks again for the patch!
Patch slightly refined, tested and pending at
https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commits/bugfix/971579-cross-compilation
for inclusion to main branch.
Thanks for researching this!
The /etc/mysql/debian.cnf file is only root-readable, and intended for
root users to be able to access the database console e.g. when the
maintainer scripts run and start/stop the server. The new way of using
socket authentication is a superior way from both security a
Hello!
Thanks for the patch, testing it now.
I didn't know that includes in Makefiles can be "negative", but
apparently they can:
https://www.gnu.org/software/make/manual/html_node/Include.html
and thus the following line is indeed valid syntax:
-include /usr/share/dpkg/buildtools.mk
That build log was from upstream 10.5 "master" branch, just as an
example to illustrate that we "globally" have these contents in
libmariadb-dev and libmariadbd-dev if you want to review that we are
shipping the right files.
The patch about DEFAULT_CHARSET I tested only locally, and local build
lo
I've removed the multi-arch: same for libmariadbd-dev in
https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/173b5ffbd40e448ecc5fc47312fa23ea30e1f0b5
but either way I do it Lintian keeps complaining and I get confused of
what is the final and best solution for mariadb-10.5 on this front.
Me
When libmariadb-dev and libmariadbd-dev are installed one gets:
# grep -rF DEFAULT_CHARSET /usr/include/
/usr/include/mariadb/mariadb_ctype.h:#define MADB_DEFAULT_CHARSET_NAME "latin1"
/usr/include/mariadb/server/my_config.h:#define
MYSQL_DEFAULT_CHARSET_NAME "latin1"
Georg: at the very end of th
Correction to the previous email:
The server builds (apparently statically) with WolfSSL while the
client uses GnuTLS (dynamically):
# mariadb -Bse 'SHOW VARIABLES' | grep -e version_ssl_library
version_ssl_library WolfSSL 4.4.0
# ldd $(which mariadbd) | grep -e crypt -e tls -e ssl
libcrypt.so.1
t: latin1
commit 2e1239cd426dd6bb910363082f57d66c06f71254
Author: Otto Kekäläinen
Date: Tue Sep 29 21:27:02 2020 +0300
Use build flag to enforce default charset as utf8mb4 (Closes: #933063)
diff --git a/debian/patches/933063-client-utf8mb4-by-default.patch
b/debian/patches/933063-client-utf8mb4-by-default.p
Control: forwarded -1 https://jira.mariadb.org/browse/MDEV-21835
Note that the upstream MariaDB uses OpenSSL both for building the
server and the client. In Debian OpenSSL is forbidden in the current
state (or so has e.g. Clint Byrum stated), so in Debian we build using
alternatives, which for the
> $ wget
> http://deb.debian.org/debian/pool/main/m/mariadb-10.5/libmariadbd-dev_10.5.5-1_amd64.deb
> ...
> $ wget
> http://deb.debian.org/debian/pool/main/m/mariadb-10.5/libmariadbd-dev_10.5.5-1_arm64.deb
> ...
> $ dpkg-deb -x libmariadbd-dev_10.5.5-1_amd64.deb amd64
> $ dpkg-deb -x libmariadbd-
Hello!
> Thank you for the background. Let me detail on the security side. The
> issue is not with using wolfssl. The issue is with using a bundled ssl
> library. Doing so means that a single bug in wolfssl must be uploaded
> several times in order to fix it. I think it would be ok to use the
> sy
> > W dependency-is-not-multi-archified libmariadb-dev-compat depends on
> > libmariadb-dev (multi-arch: no)
> > W dependency-is-not-multi-archified libmariadbd-dev depends on
> > libmariadb-dev (multi-arch: no)
> > W dependency-is-not-multi-archified mariadb-plugin-gssapi-client
> > depends on mar
Thanks!
Would you like to test with mariadb-10.5 in unstable as well?
Or perhaps contribute by writing a small autopkgtest extension (the
debian/tests files in the packaging repository at
https://salsa.debian.org/mariadb-team/mariadb-10.5) that runs this
dump and thus ensure forever that this fea
I tested this but it did not at least directly work:
commit b8e537d55b467eb285a82842e73bb22732ef9ad6 (HEAD -> master-next)
Author: Otto Kekäläinen
Date: Tue Sep 29 21:27:02 2020 +0300
Use build flag to enforce default charset as utf8mb4 (Closes: ##933063)
diff --git a/debian/rule
Thanks!
Tested patch in
https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/2a8304051a3107fe828314b66b33aca7ecb863d4
Builds went fine, so I'll add this commit on top of the master branch.
The topic of cross-building tangents the multi-arch definitions in the
control file which currently
Switching to OpenSSL 3.0 would remove the license issue (as 3.0 is Apache
licensed), but it is still alpha and in experimental only.
https://packages.debian.org/source/experimental/openssl
I've suggested upstream they would support system WolfSSL but it hasn't
been a priority so far and I am not
Hello!
Adding Christian and Dimitri to the recipients, since I think it was
Dimitri who patched the Ubuntu version of cmake for this.
ti 29. syysk. 2020 klo 0.22 Aurelien Jarno (aurel...@aurel32.net) kirjoitti:
>
> On 2020-09-28 15:12, Otto Kekäläinen wrote:
> > After uploading ma
Hi!
ti 29. syysk. 2020 klo 7.39 Georg Richter (ge...@mariadb.com) kirjoitti:
>
> Hi,
>
> if server has default charset utf8mb4 on Debian, why don't you build C/C with
> -DDEFAULT_CHARSET=utf8mb4 ?
Yes, that might be a good solution. I wasn't aware of such an option.
The upstream MariaDB 10.5 ha
> I've started looking into it. I noticed a few embedded code copies. I've
> filed #971005 about readline. Bundling an ssl library seems like a very
> bad idea to me. The outcome of these will have significant impact on how
> cross compilation can be implemented.
I've filed issues upstream that th
> On Mon, Sep 28, 2020 at 08:57:11PM +0300, Otto Kekäläinen wrote:
> > I also see that mysql-8.0 added quite a few conflicts on mariadb-*. In
> > mysql-5.7 only the server conflicted with the mariadb equivalent.
>
> [...]
>
> > So having any kind of co-installability
Right now the file /etc/mysql/mariadb.conf.d/50-client.cnf is just an
empty placeholder and mariadb-client would work without depending on
mariadb-common as long as no user adds anything to that config file.
But it would be quite confusing for the user if there is a file
/etc/mysql/mariadb.conf.d/
Control: tags -1 moreinfo
Hello!
pe 26. heinäk. 2019 klo 15.06 Otto Kekäläinen (o...@debian.org) kirjoitti:
>
> Hello!
>
> Thanks for reporting. I don't know it the MariaDB Connector C client
> library reads and follows any settings in /etc/mysql/, we will need to
> c
Package: mariadb-server
Version: 1:10.5.5.-1
Control: tags -1 confirmed
I tested and this still applies to the latest MariaDB version now in Debian.
Suggestions on what to do about it are welcome.
MariaDB [test]> select @@Version;
+--+
| @@Version|
+--+
|
Package: mariadb-10.5
Version: 1:10.5.5-1
Control: tags -1 moreinfo
Hello!
About: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887007
We still have this situation in mariadb-10.5. How do you suggest we
change the current situation to remedy this?
- Otto
Control: -1 tags moreinfo
Hello!
We don't have many users running multi-instance MariaDB nor do we have
any automatic tests for it.
Would you be kind and test out latest MariaDB 10.5 in unstable with
your multi-instance setup and give feedback?
Even better, perhaps contribute by writing an exte
After uploading mariadb-10.5 1:10.5.5-1 to Debian the build still
fails with these:
/usr/bin/ld: /usr/include/c++/10/bits/atomic_base.h:464: undefined
reference to `__atomic_compare_exchange_1'
The odd thing is that an identical build on Ubuntu Groovy passes OK:
https://launchpadlibrarian.net/499
Package: dbconfig-common
Noticed that autopkgtests started failing with the upload of MariaDB
10.5 to unstable.
The command3 seems to be failing on unexpected output from MariaDB (if
I read the output correctly).
>From
>https://ci.debian.net/data/autopkgtest/testing/amd64/d/dbconfig-common/7197
Package: kopanocore
Hello!
I noticed the autopkgtests at
https://ci.debian.net/data/autopkgtest/testing/amd64/k/kopanocore/7197598/log.gz
failed with:
# Restart MariaDB server... #
/tmp/autopkgtest-lxc.eq69zqgi/downtmp/build.no3/src/debian/tests/smoke:
3
Hello!
There is indeed in the sources extra/readline/.
Looking at upstream commit logs it has been there at least since 2014
(and traces of the same are in Oracle mysql sources too). This is not
something new that has been introduced in 10.5, but rather very old
legacy.
The cmake/readline.cmake
With the latest mariadb-10.5 1:10.5.5-1 upload, the hppa build fails
on just one test:
https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.5&arch=hppa&ver=1%3A10.5.5-1&stamp=1601225060&raw=0
**
main.index_intersect w3 [ fail ]
Test ended at 2020-09
After the upload of mariadb-10.5 1:10.5.5-1 the x32 build is still
failing on this same error:
/<>/storage/innobase/ut/ut0crc32.cc:167: Error: operand
size mismatch for `crc32'
Hello!
Just for the record, the perl -w option is to print out warnings and
should not be used in production:
https://manpages.debian.org/buster/perl-base/perl.1.en.html#DIAGNOSTICS
The "use warnings" pragma produces some lovely diagnostics. One
can also use the -w flag,
but its use
Package: lintian
Version: 2.95.0
Severity: normal
I am getting a lot of warnings like:
W: mariadb-10.5 source: globbing-patterns-out-of-order
extra/readline/* */CMakeLists.txt
W: mariadb-10.5 source: globbing-patterns-out-of-order
libmariadb/zlib/* */CMakeLists.txt
W: mariadb-10.5 source: globbing
This is most likely a duplicate of #879099 and will be fixed with the
upload of MariaDB 10.5 into Debian.
Hello Helmut!
Would you be kind and check out mariadb-10.5 currently in Debian
experimental, and report what the status is and what changes would
still be needed?
Thanks!
Hello!
libnuma has been included since
https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/2039c2755d0c642718dcc8be852174205577542b
Please check if mariadb-10.5 in Debian experimental has now usable
numa stuff and report back here so get on top of what the status
currently is.
Thanks!
Control: tags -1 moreinfo
Hello Russel!
Can you reproduce this in a clean installation? Can you provide exact
steps how to reproduce this?
What does `find /etc/mysql -ls` yield?
What it the contents of debian-sys-maint ? Is it for example empty?
What does `mysql -e "SELECT Host,User,plugin,auth
Hello!
Have you tested if this still happens on recent MariaDB versions?
Control: tags -1 moreinfo
Does this still apply for latest MariaDB version?
Control: tags -1 moreinfo
Is this still an issue?
This is difficult to reproduce and thus debug.
Control: tags -1 moreinfo
Hello!
Can you please check with the latest MariaDB version if this bug still applies?
Thanks!
Control: merge -1 930036
control: Forwarded https://jira.mariadb.org/browse/MDEV-12190
control: Tags wontfix
Forwarded: https://jira.mariadb.org/browse/MDEV-12190
Tags: wontfix
This is due to use of YaSSL (nowadays called WolfSSL).
This will not be fixed for MariaDB 10.1 or older.
A summary about various TLS issues for WolfSSL/MariaDB in Debian is
listed at https://jira.mariadb.org/browse/MDEV-23772
Co
Current mariadb-10.5 soon in to be uploaded to Debian unstable:
cat debian/libmariadb3.install
# sha256_password not supported by GnuTLS due to missing OAEP padding
usr/lib/*/libmariadb.so.*
usr/lib/*/libmariadb3/plugin/caching_sha2_password.so
usr/lib/*/libmariadb3/plugin/client_ed25519.so
usr/li
Wikipedia at https://en.wikipedia.org/wiki/OpenSSL#Licensing claims
the OpenSSL license change to Apache 2.0 would be complete, but the
website of openssl.org does not reflect this. Situation is unclear. If
the license change was complete, we could switch back to using OpenSSL
in Debian.
Hello Olaf!
Did you try the tip from Michael Pietsch about converting the
certificate to the correct format?
Source: mariadb-10.5
Version: 1:10.5.5-1~exp1
Severity: serious
Justification: fails to build from source
User: debian-...@lists.debian.org
Usertags: x32
After uploading the latest mariadb-10.5 I noticed it fails to build.
However, mariadb-10.4 built just fine on x32.
The failure is:
Source: mariadb-10.3
Version: 1:10.5.5-1~exp1
Severity: serious
Justification: fails to build from source
User: debian-powe...@lists.debian.org
Usertags: ppc64
After uploading the latest mariadb-10.5 I noticed it fails to build.
However, mariadb-10.4 built just fine on ppc64.
The failure is this
Interestingly alpha built just fine on mariadb-10.5:
https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.5&arch=alpha&ver=1%3A10.5.5-1%7Eexp1&stamp=1600077822&raw=0
Seems mariadbc-10.5 built just fine on ia64:
https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.5&arch=ia64&ver=1%3A10.5.5-1%7Eexp1&stamp=1599939666&raw=0
601 - 700 of 1491 matches
Mail list logo
