control: forward -1 https://github.com/codership/galera/issues/659
control: forwarded -1 https://github.com/codership/galera/issues/659
Forwarded: https://github.com/codership/galera/issues/659
Bullseye oldstable update request filed in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069802
You can +1 it if you want to show support.
> What about bullseye, which is also a supported distribution?
>
> I have not reached the point where I want to do NMUs for these kind
> of bugs, but if this were my package, I would certainly do an upload
> for bullseye as well. If I can be of any help, please say so.
This bug report was about
I was able to reproduce this for Bookworm both locally and in CI at
https://salsa.debian.org/mariadb-team/galera-4/-/jobs/5620032
After importing latest upstream build/test passes:
https://salsa.debian.org/otto/galera/-/jobs/5624466
Stable upload request filed at
Galera 25.3.37 was last release from upstream in 3.x series. I suspect
the best resolution here is to wait a bit and then just file removal
request for galera-3 in sid/trixie when we are confident there is no
MariaDB 10.1/2/3 users out there anymore.
Control: tag -1 pending
Hello,
Bug #1068404 in mariadb reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
Control: tag -1 pending
Hello,
Bug #1068404 in mariadb reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
Control: tag -1 pending
Hello,
Bug #1068403 in mariadb reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
Control: tag -1 pending
Hello,
Bug #1068403 in mariadb reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
Galera patch releases have been accepted as stable updates before. That is
also what users expect.
Thanks for reminding about this though, I yad forgotten about it. Will do
it next weekend.
Thanks Wouter for reporting this and Michael for submitting a merge
request for a potential fix!
The libcrypto.so.3 is from the OpenSSL package. In your upgrade case
it seems to be switching from
libssl3 [i386] to libssl3t64 [i386]. Your MariaDB packages are amd64.
This makes me wonder what is
] This server doesn't support dates later than 2038
Seems to stem from This is due to
https://github.com/MariaDB/server/blob/11.5/sql/mysqld.cc#L3903-L3908
I am looking into this now as well..
On Sat, 2 Mar 2024 at 16:41, Otto Kekäläinen wrote:
>
> > > Could you Sebastian perhaps
> > Could you Sebastian perhaps quickly skim through the commit that
> > implemented this
> > https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/8194544349982990fb2585c2a8c15c4db3904735
> > and say if there might be something else missing as well?
>
> Did you mean
>
Currently MariaDB is not building[1] at all due to:
**
mariadb build-depends on:
- libcurl4-openssl-dev:amd64
libcurl4-openssl-dev depends on:
- libcurl4t64:amd64 (= 8.6.0-3.1)
mariadb build-depends on:
- cmake:amd64
cmake depends on:
- libcurl4:amd64 (>= 7.16.2)
libcurl4t64 conflicts with:
-
Control: tag -1 pending
Hello,
Bug #1065275 in mariadb reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
Hi Sabastian!
> * The package is built with the wrong ABI.
> * The package migrates to testing before the change is enabled in
> testing and builds there would be produced against the wrong ABI.
>
> Please add dpkg-dev (>= 1.22.5) to Build-Depends and upload the new
> version ASAP.
Thanks for
Control: tag -1 pending
Hello,
Bug #1062841 in mariadb reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
Control: tag -1 pending
Hello,
Bug #1062841 in mariadb reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
Hi!
I did additional testing and converted the attached patch into a MR
ready to be merged on the debian/latest branch and uploaded to
unstable:
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/68
Seems the experimental builds for MariaDB went OK. Let me know when is
the
Control: tag -1 pending
Hello,
Bug #1062841 in mariadb reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
Hi!
Please do not do non-maintainer-uploads. This package is actively
maintained, we can just include your patch in the next upload in a
couple of days.
On Sat, 3 Feb 2024 at 11:57, Graham Inggs wrote:
>
> Source: mariadb
> Version: 1:10.11.6-2
> Severity: serious
> Tags: patch pending sid
Sure, this will be fixed (automatically) with uploading latest upstream
minor release as stable update, and I intend to do it in coming 1-2 weeks.
I restarted the build for powerpc yesterday, and it did not run into
reserved ports issue and build passed. I suspect that this is because
the ppc64 build (which runs on the same builder 'blaauw' was not
running in parallel and thus the two build jobs were not competing for
the same ports on that
I saw this now after 1:10.11.5-2 upload on multiple builders.
Snippets from logs
https://buildd.debian.org/status/fetch.php?pkg=mariadb=powerpc=1%3A10.11.5-2=1696735216=0
main.failed_auth_unixsocket w13 [ fail ]
Test ended at 2023-10-08 03:17:49
CURRENT_TEST:
Hi!
The relevant lines from log seems to be:
> main.bind_address_resolution w4 [ fail ]
...
> 2023-09-26 6:31:03 0 [ERROR] Can't start server: Bind on TCP/IP port. Got
> error: 98: Address already in use
> 2023-09-26 6:31:03 0 [ERROR] Do you already have another server running on
Hi!
I did a bunch of reproducible experiments using Salsa-CI in
https://salsa.debian.org/mariadb-team/mariadb-server/-/pipelines/536587
testing:
## upgrade to Bookworm
* cacti and Bullseye upgrade
- apt install -qq --yes cacti
-> - apt full-upgrade -qq --yes
* default-mysql-server and
Can you attach the full log as an attachment?
The current short log does not show what apt told you in the beginning
about what it plans to do, nor can I see if mariadb-client-10.5 was
uninstalled or what happened.
But it did at least hit a bug where the uninstall fails on
`invoke-rd.c stop
Thanks Frederick for the report!
Do you still have the output of apt? Can you copy-paste here or attach log
to show exactly what happened?
It is likely that you hit this bug, but exact details would help confirm,
and also help build CI test/scenario to ensure we have realistic upgrade
testing.
Hi!
Note that upstream released 10.11.4 today. Import preparation in
progress at
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/50.
I plan to upload this to experimental tomorrow and eventually into
bookworm-pu if the release team approves.
- Otto
Forwarded: https://jira.mariadb.org/browse/MDEV-28640
For reference:
* The upgrade scenario this MR fixed:
https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/15cbf6e691827608636e6ff7f0a50432f50d0c4f
* Release notes mention:
Package: release.debian.org
Severity: serious
Tags. bookworm
User: release.debian@packages.debian.org
Usertags: unblock
Control: affects -1 src:mariadb
This pre-unblock request is to get a decision from the Bookworm
release team if you prefer to have this Bug#1035949 fix:
a) in Bookworm in a
Indeed the transitional mariadb-server-10.5 fixes the issue.
What do you Andreas suggest we do now?
It is already past freeze for Bookworm, and this is not just a small
fix but also introduces a new package (albeit transitional). Let me
know how you want to proceed and I can immediately tomorrow
I adjusted your patch a bit as it didn't apply cleanly and pushed it
to https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/47
to replace the transitional mariadb-client-10.5 I had earlier.
Thanks for diving deep in piuparts testing for MariaDB 10.11 and for the patch!
Ideally
I filed now
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/47
as an exploration to fix this issue.
If we don't fix this in 10.11 the alternative would be to patch 10.5
and 10.3 to simply never fail on missing mariadb-client-10.3/5
package. I already did
Hello!
This is not fixed.
I sampled failing autopkgtests for MariaDB at
https://ci.debian.net/packages/m/mariadb/testing/ppc64el/ between May
7th and 22nd. They still have crashes that include error message
'Database page corruption on disk'. Both failing and passing ones were
running kernel:
I am experimenting the suggestion in
https://salsa.debian.org/otto/mariadb-server/-/commits/bugfix/1035949-upgrade-removes-client
Here is the apt resolver output for debugging:
# apt install default-mysql-server -o Debug::pkgDepCache::Marker=1 -o
Debug::pkgDepCache::AutoInstall=1 -o Debug::pkgProblemResolver=1
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
MarkInstall
I did some more testing in throwaway containers.
In each test starting point was same:
apt-get install default-mysql-server zoph
sed s/bullseye/bookworm/g -i /etc/apt/sources.list
apt update
All cases ran apt 2.6.0.
I only varied the command that followed:
1) apt-get install
This is not a fix, but could help make the situation easier to
detect/debug for users:
* https://salsa.debian.org/mariadb-team/mariadb-10.5/-/merge_requests/14
* https://salsa.debian.org/mariadb-team/mariadb-10.3/-/merge_requests/37
Control: retitle -1 mariadb-plugin-gssapi-server: crash on partial
upgrade of libk5crypto3
Filed now https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036055
for krb5 maintainers to advise on.
Hi Andreas!
Thanks for reporting and looking into this.
> Here apt choses a suboptimal removal order: mariadb-server-10.5 gets
> removed (and therefore stopped, but that fails) only after
> mariadb-client-10.5 and mariadb-client-core-10.5 are already gone.
You are right. The /usr/bin/mysqladmin
After some experimentation I found out that updating libkrb5-3 so that
/usr/lib/x86_64-linux-gnu/libkrb5.so.3 upgrades will stop MariaDB from
crashing.
$ apt install libk5crypto3 libkrb5-3
...
libssl3 amd64 3.0.8-1
libgssapi-krb5-2 amd64 1.20.1-1+b1
libkrb5support0 amd64 1.20.1-1+b1
libkrb5-3
Hi!
I was able to reproduce this with:
apt install mariadb-plugin-gssapi-server mariadb-plugin-gssapi-client
sed s/bullseye/bookworm/g -i /etc/apt/sources.list
apt update
apt-get upgrade
Upgrade only updates mysql-common and mariadb-common:
$ dpkg -l | grep -e mysql -e maria
ii
Thanks for reporting!
Is this sporadic or does it reproduce every time?
We have this upgrade scenario in CI without issues, thus asking about
reproducibility.
> > > Paul Gevers asked if the issues are gone as well with 6.1.12-1
> > > (or later 6.1.y series versions, which will land in bookworm). That
> > > would be valuable information to know as well to exclude we do not
> > > have the issue as well in bookworm.
> >
> > Were you able to verify this?
> > On Sat, Mar 18, 2023 at 11:19:29PM -0700, Otto Kekäläinen wrote:
> > > Any updates on this one?
> > >
> > > I am still seeing the main.index_merge_innodb failure in
> > > https://buildd.debian.org/status/fetch.php?pkg=mariadb=ppc64el=1%3A10.11
Any updates on this one?
I am still seeing the main.index_merge_innodb failure in
https://buildd.debian.org/status/fetch.php?pkg=mariadb=ppc64el=1%3A10.11.2-2%7Eexp1=1678728871=0
and rebuild
https://buildd.debian.org/status/fetch.php?pkg=mariadb=ppc64el=1%3A10.11.2-2%7Eexp1=1679174850=0.
Logs
Forwarded: https://lists.launchpad.net/maria-discuss/msg06508.html
This is most likely a duplicate of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031863
> On Tue, 17 Jan 2023 08:00:00 -0800 =?UTF-8?B?T3R0byBLZWvDpGzDpGluZW4=?=
> wrote:
> > This severity 'serious' bug should prevent the migration
> > automatically. Close this bug when migration is free to proceed.
>
> I believe this has happened now. Do you think it should solve that issue
> I was
Control: found -1 1:10.11.2-1
Control: retitle -1 mariadb breaks mariadb-10.6 autopkgtest: provider
plugins not installed
Control: severity -1 normal
Since https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/36
was merged it fixed Bug#1031116 (apt ordering broke Cacti
For the record, the failing Debian machines run:
Linux ci-worker-s390x-01 5.10.0-21-s390x #1 SMP Debian 5.10.162-1
(2023-01-21) s390x GNU/Linux
The passing Launchpad builders run:
Linux bos02-s390x-013 5.4.0-137-generic #154-Ubuntu SMP Thu Jan 5
17:03:11 UTC 2023 s390x
Control: tag -1 pending
Hello,
Bug #1030604 in mariadb reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
Control: severity -1 normal
Control: tags -1 help
The s390x build is still failing after 5 retries at
https://buildd.debian.org/status/package.php?p=mariadb. The issue
seems to be with Debian buildd, as the Launchpad s390x build passed
just fine without the need to retry anything:
And again same phenomenon in
https://buildd.debian.org/status/fetch.php?pkg=mariadb=s390x=1%3A10.11.1-3=1675697634=0.
Copy-pasting more context to track if the main.xml is the preceding
test other times as well:
main.group_by_innodb 'innodb'w2 [ pass ] 11
Control: retitle -1 mariadb: FTBFS on s390x: crash on munmap(),
free(), aligned_free()
For the record, the latest build
https://buildd.debian.org/status/fetch.php?pkg=mariadb=s390x=1%3A10.11.1-3=1675662468=0
shows other test failures again, but the stack trace seem to have
munmap(), free(),
Hi!
The error message "Variable 'innodb_compression_algorithm' can't be
set to the value of 'lz4'" is from the first test, and it fails.
Actually all tests fail because in MariaDB 10.11 the compression
methods are packaged in separate packages.
The root cause here is that the test in 10.6
After restarting the build there is no longer a timeout, but a crash:
main.plugin_auth 'innodb'w1 [ fail ] Found
warnings/errors in server log file!
Test ended at 2023-02-05 09:41:56
line
Attempting backtrace. You can use the following information to find out
^ Found
> > This is now solved on
> > https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/31
>
> Mangling the maintainers scripts of another package is a delicate issue
> as it's often fragile and can cause hard to debug failures in corner cases.
>
> Personally, I would have turned the
This is now solved on
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/31
Hi!
Here is the situation after 'apt full-upgrade -y':
$ dpkg -l | grep -iE 'maria|mysql|galera' || true # List installed
ii default-mysql-client 1.1.0
all MySQL database client binaries (metapackage)
ii default-mysql-client-core 1.1.0
all
Hi!
I managed now to reproduce this. The purge step is not relevant, but
simply the upgrade itself.
In clean Docker container with Debian unstable:
$ apt install -y mariadb-server-10.6
-> install successful
$ apt full-upgrade -y
-> does nothing
$ service mariadb restart
Stopping MariaDB
Hi!
I have been frantically trying to reproduce the issue you reported.
Would you be able to describe more in detail what was the situation
before and after you upgraded and what commands exactly did you do to
execute the upgrade (apt upgrade, apt full-upgrade, apt-get,
aptitude)?
We might very
Hi!
Thanks for reporting the issue. I saw this earlier and fixed it via
https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/dd3a058ebec877da50aadc9f8909d61ac634430a
- but cleary the fix does not fully work as you ran into this again.
I will dive deeper.
- Otto
Package: mysql-defaults
Version: 1.1.0
Severity: serious
Owner: Otto Kekäläinen
Don't allow mysql-defaults into testing/Bookworm before MariaDB
1:10.11.1-1 has entered it first. There is no package
'mariadb-server-core' in MariaDB 1:10.6.11-2 and thus the defaults
pointer would fail
I did a re-run today and surprisingly it passed:
main.order_by_innodb 'innodb'w2 [ pass ] 84
https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.6=s390x=1%3A10.6.11-1=1670206361=0
Maybe the issue is sporadic? But also the first day I saw this I
re-ran the build and it did
Control: tags -1 moreinfo unreproducible
This bug report lacks details to be able to reproduce it or even to
link it with an upstream bug report.
There is nothing that can be done unless the submitted provides more
information or steps to reproduce.
Source: mariadb-10.6
Version: 1:10.6.11-1
Tags: ftbfs
User: debian-s...@lists.debian.org
Usertags: s390x
X-Debbugs-CC: debian-s...@lists.debian.org
Severity: serious
Justification: fails to build from source on official Debian architecture
After upload of mariadb-10.6 1:10.6.11-1 I noticed that
Hi!
Thanks for looking into this. Can you elaborate why you filed this on
26.4.8 and not latest 26.4.10?
Builds are passing. Thus tests indicate that there is no issue. What is the
broken thing exactly and since tests are passing, how will we verify that
the broken thing is fixed or still
Control: Severity -1 wishlist
Based on replies from Daniel and Marko this code section is indeed
correct. Also, based on git blame the section you suggest to be
removed was not added in a MariaDB version. However, instead of
closing this bug report as invalid, I leave it open as a wishlist item
> On 21-01-2022 21:11, Otto Kekäläinen wrote:
> > Currently mariadb-10.6 is blocked from migrating to testing due to
> > test failure in ruby-mysql2/0.5.3-3
>
> I just uploaded a fix. The bug report already had the solution since
> January 5.
Thanks!
Please submit to
FYI: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004151
Filed skip-test request to release team to get mariadb-10.6 migrate
from unstable to testing.
uery> with backtrace:
> >
> > Our error message changed.
> >
> > ruby-mysql2 already fixed the test upstream -
> > https://github.com/brianmario/mysql2/commit/cca57b97ad6d1b1b985376be110b89d2b487dea6
> >
> >
> > On Thu, Dec 23, 2021 at 4:47 AM Ot
Control: severity -1 wishlist
On Thu, Dec 9, 2021 at 5:00 AM Anthony Bourguignon
wrote:
...
> I’m having an issue with the mariadb-client in bullseye. I can’t connect
> to a local server using the mariadb client.
>
> To reproduce the bug :
> - Install bullseye
> - Install mariadb-server and
Control: severity -1 normal
On Thu, Oct 21, 2021 at 9:24 PM Marc Gallet wrote:
> I've been brought to this bug by apt-listbugs while doing upgrades
> on my buster install, warning me of a grave bug.
We have two users who have experienced a potentially corrupted
database (out of hundreds of
> So maybe I do have a corrupted database or something but I'm unsure what to do
> next (I don't think I have an older backups of the database). Also it still
> works just fine with 10.3.25.
Run it with the old database, make a logical dump (with mysqldump) and
import that logical dump into a
Right. Here is for Buster:
https://salsa.debian.org/mariadb-team/mariadb-10.3/-/commit/8ccf2240960cbb609cedfeb269df22d43ccbba21
https://salsa.debian.org/mariadb-team/mariadb-10.3/-/pipelines/302376
Hello!
On Tue, Oct 12, 2021 at 4:51 AM Yves-Alexis Perez wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Mon, 2021-10-11 at 11:27 +0200, Jan Korbel wrote:
> > Maybe this: https://bugs.freebsd.org/bugzilla//show_bug.cgi?id=257728
>
> If I read the bug correctly, it points to
>
> The problem is in the ibdata1 file (about 450MB). Deleted other database
> directories and it still crashes, deleted ibdata1 and it runs.
>
> How to bisect mariadb from git? Tried:
> $ git bisect good mariadb-10.3.29
> $ git bisect bad mariadb-10.3.31
> the build process showed version 10.2 so
Hello!
Thanks for reporting. Could you please check if this has been reported
upstream at jira.mariadb.org?
There isn't much we can do about InnoDB internals in Debian packaging.
Control: tag -1 pending
Hello,
Bug #990708 in mariadb-10.5 reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
On Sat, Jul 10, 2021 at 12:37 AM Andreas Beckmann wrote:
>
> On 10/07/2021 09.16, Otto Kekäläinen wrote:
> > Seems this issue only happens with apt – not when using apt-get.
>
> Yuck. Can you ask the apt developers whether this is intended? I always
> expected apt-get and a
Hello!
Seems this issue only happens with apt – not when using apt-get.
Olaf's scenario with apt-get upgrades fine:
https://salsa.debian.org/mariadb-team/mariadb-10.5/-/jobs/1748579
The exact same with apt-get -> apt fails:
https://salsa.debian.org/mariadb-team/mariadb-10.5/-/jobs/1748579
Weird. I renamed the test and extended it bit to have logging and be
uniform in general, and now it passes (without your patch):
https://salsa.debian.org/mariadb-team/mariadb-10.5/-/jobs/1748275
I was expecting that adding the new step in Salsa-CI would show
failure, and then adding your patch
On Wed, Jul 7, 2021 at 6:37 AM Andreas Beckmann wrote:
>
> On 06/07/2021 01.25, Otto Kekäläinen wrote:
> > Thanks Andreas for testing potential changes!
>
> So far this looks good, I see no more cases of default-mysql-server
> being held at the buster version (and thus mariad
> Thanks for clarifying. That was not obvious since the filename of the
> plugin library did not change. And another reason that dropping the
> virtual galera package should not do any harm.
> (If the plugin would have changed the name (e.g. used a proper
> SOVERSION), -3 and -4 should be
> BTW, the following apt option might be helpful for debugging upgrade
> issues in your CI jobs:
>
>Debug::pkgProblemResolver "true";
In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988089 we went as
far as running apt with:
apt dist-upgrade -o Debug::pkgDepCache::AutoInstall=1 -o
>
> Some general understanding question: Would mariadb-server-10.5 work with
> galera-3, too? (with only the Depends being relaxed to 'Depends:
> galera-4 | galera-3, ...', without recompilation or similar actions)
> (Bonus question: would mariadb-server-10.3/buster work with
> galera-4/bullseye
> I do have this in a VM so I think we can easily repro this.
>
> // Fresh VM install from debian-10.9.0-i386-netinst.iso
> # history
> 1 visudo
> 2 rm /etc/motd
> 3 poweroff
> 4 apt install mariadb-server
> 5 dpkg -l|grep mariadb
> 6 sed -i 's/buster/bullseye/g'
Thanks Andreas for testing potential changes!
If you file them as MRs at
https://salsa.debian.org/mariadb-team/galera-4 and
https://salsa.debian.org/mariadb-team/mariadb-10.5 you'll get the
additional CI testing run on top of the for free for extra validation.
There is a mariadb-10.5 Bullseye
> How would one use galera-3 in bullseye? There is no mariadb-10.3 in
> buster, only 10.5 which depends on galera-4 which blocks galera-3 from
> being installed.
> (Even if galera-3 gets removed from bullseye, it will stay in buster
> (and sid if you want))
One would use upstream repositories for
On Mon, Jul 5, 2021 at 1:12 PM Olaf van der Spek wrote:
>
> On Mon, Jul 5, 2021 at 9:24 PM Otto Kekäläinen wrote:
> > I wish somebody could contribute with exact steps on how to reproduce
> > the issue. So far I've gotten some half attempts at that but they
> > haven'
Hello!
I was able to reproduce this, and addressed it in
https://salsa.debian.org/mariadb-team/galera-4/-/commit/27a142792b5e02e66b8f1adf9a7b896c5722dd17
+ added Salsa-CI testing for this specific scenario so that it would
not regress again, but seems there is still some second scenario that
does
> Hello!
>
> There is an updated Galera-4 in Debian unstable now. If you want to
> contribute to the effort, you could now do testing and verify that the
> fix delivered works.
I filed now http://bugs.debian.org/989513 but would still welcome
help. There needs to be more testing that the current
Hello!
There is an updated Galera-4 in Debian unstable now. If you want to
contribute to the effort, you could now do testing and verify that the
fix delivered works.
On Sun, May 9, 2021 at 8:41 PM Otto Kekäläinen wrote:
>
> Thanks for running the debug commands. Would you like to als
Control: tag -1 pending
Hello,
Bug #988629 in mariadb-10.5 reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
Hello!
On Sun, May 16, 2021 at 4:18 PM Otto Kekäläinen wrote:
>
>
>> > But as said, the bug #988089 can only be fixed by a change in galera-4
>> > debian/control. Changing the mariadb-10.5 debian/control to
>> > recommends:galera-4 is a separate change.
>>
Control: tag -1 pending
Hello,
Bug #988089 in galera-4 reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
Control: tag -1 pending
Hello,
Bug #988089 in galera-4 reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
Control: tag -1 pending
Hello,
Bug #988089 in galera-4 reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
1 - 100 of 360 matches
Mail list logo
