Hi!
> > > When there are failures, it's not bad when this is immediately visible
> > > to the administrator.
> >
> > If the server is not fully dedicated to just running Bacula, then
> > preventing dpkg/apt from doing anything is a bit overkill just for the
> > sake of notifying the user.
>
> It i
> When there are failures, it's not bad when this is immediately visible
> to the administrator.
If the server is not fully dedicated to just running Bacula, then
preventing dpkg/apt from doing anything is a bit overkill just for the
sake of notifying the user.
> The postinst will restart the ser
Hi!
I skimmed through https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1109499
quickly and my initial thought here is that Bacula (or any other program)
should not rely on dpkg maintainer scripts to upgrade the database as there
isn't any guarantees about what the initial state is, and if anythin
Control: tag -1 pending
Hello,
Bug #1109265 in python-hpilo 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:
https://salsa.debian.org/python-team/packages/python-hpilo/-/commit/7edca6db8
Control: tag -1 pending
Hello,
Bug #1109265 in python-hpilo 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:
https://salsa.debian.org/python-team/packages/python-hpilo/-/commit/190265463
Thanks for the source code pointer, but there is no "API" documentation
there, so you should give the exact "API call" you want the script to run.
I assume it is something more complex than `(sudo) akonadi stop`.
> but `akonadictl stop` for each user after connecting to their dbus session
> should do it from a technical point of view.
> Maybe first diverting some files to prevent the user from starting them up
> again, and then diverting back once upgraded.
>
>
> But all of this is a bit euww.
If you ship
In Debian packaging we can't do anything about upstream capability to
recover from crashes. Please suggest what exact Akonadi service
starts/stops the database and how we can ask Akonadi to shutdown before
server upgrade. At least it would cover the common case if regular upgrades.
H!,
I just found this issue
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032240) when
browsing the list of release critical issues for Trixie (although it
is from 2023 and was open also when Bookworm was released, so not
really a Trixie issue).
A variant of it was
https://bugs.debian.org/c
> > MariaDB 11.10.13 is now out and ready for upload in MR!119.
> >
> > Should we make this a security upload or put into stable-updates?
> > Does the security team have a preference?
> >
> > I am fine either way.
>
> I think the no-dsa marked CVEs can still be done in the 12.12 point
> release.
W
Hi!
> Hi,
>
> FYI: The new upstream minor version have been ready for review for 10+
> days, and they include these CVE fixes. There are however potential
> regressions so I am holding back from uploading yet.
>
> * https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/119
> * http
Control: tag -1 pending
Hello,
Bug #1084293 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:
https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/4b0d676b19433a12f0e4
Forwarded: https://jira.mariadb.org/browse/MDEV-34788
Control: retitle -1 mariadb: FTBFS multiple archs: Post-build tests
fail on reserved port
In
https://buildd.debian.org/status/fetch.php?pkg=mariadb&arch=amd64&ver=1%3A11.4.5-2%7Eexp1&stamp=1740281411&raw=0
these were passing:
main.bind_addres
Hi!
This is already fixed at
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/112
but upload pending another person to review/approve.
Hi,
On a tanget to this bug: this package is maintained in Salsa, and the
original build failure is visible when CI runs in
https://salsa.debian.org/otto/mat2/-/pipelines/850962, and the fact
that the new change fixed the first issue but revealed another is
visible in https://salsa.debian.org/ott
Control: tag -1 pending
Hello,
Bug #1084293 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:
https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/4b0d676b19433a12f0e4
I don't see any progress in upstream https://jira.mariadb.org/browse/MDEV-35424
You might consider contributing directly upstream additional debugging
information, volunteer to do testing etc to advance this.
Hi,
Related: Bug#1084293
We need to figure out if something changed in tzdata(-legacy) transition
again. Seems MariaDB is working "correctly", environment just changed to
force new tz or something.
Control: forwarded -1 https://jira.mariadb.org/browse/MDEV-35424
Thanks for reporting! This will hopefully be fixed in next upstream release.
Hi,
Thanks all for investigating this. Seems it is affecting a large
amount packages as use of 'adduser' is very common. This also breaks a
lot of Debian CI and Salsa CI. If it is not easy to figure out a fix,
please consider reverting to previous behavior as an alternative.
Pasting example of er
Thanks Christian for fixing this quickly!
This may help to prevent similar issues in the future:
https://salsa.debian.org/debian/libcap2/-/merge_requests/2
Control: tag -1 pending
Hello,
Bug #1095286 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:
https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/661664bffdee368f4d05
Control: tag -1 pending
Hello,
Bug #1095286 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:
https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/661664bffdee368f4d05
Control: tag -1 pending
Hello,
Bug #1095286 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:
https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/661664bffdee368f4d05
Forwarded: https://jira.mariadb.org/browse/MDEV-36078
Thanks Matthew for discovering this. I submitted this now upstream as
we need to coordinate with upstream how to avoid behavior change in
MariaDB 11.4 series.
Control: tag -1 pending
Hello,
Bug #1091811 in golang-github-caarlos0-env 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:
https://salsa.debian.org/go-team/packages/golang-github-caarlos
Santiago RR is actually working on running sbuild inside containers in
Salsa CI, so the build envs will be cleaner soon.
I've tested building the 11.3.1-1 sources on a clean container with
tzdata 2024b-5, and then immediately with 2025a-1, and both passed
without errors with default timezone 'Etc/UTC'. Changing timezone to
Berlin like the reproducible builds has didn't change the outcome.
$ dpkg -l | grep tzdata
ii
On a second thought, Ubuntu Plucky differences are probably due to
their tzdata having a lot of modifications and maybe not yet the
tzdata-legacy split:
https://patches.ubuntu.com/t/tzdata/tzdata_2024b-6ubuntu1.patch
> > You might want to ensure (as maintainer of Salsa CI) that such thing
> > does not happen (or, at the very minimum, document the differences
> > between a completely clean chroot and the one used by Salsa CI).
>
> Simple question: Does it help if I open an issue in Salsa CI for that?
Thanks San
Nobuhiro, would you like to approve
https://salsa.debian.org/go-team/packages/golang-github-caarlos0-env/-/merge_requests/1?
Tracker https://tracker.debian.org/pkg/golang-github-caarlos0-env
currently says package is marked for autoremoval on Feb 13th.
Thanks for report! I can fix this later today
Hi!
Sorry for the long delay, I didn't have time to import new RocksDB
until yesterday and today. I have now a MR pending at
https://salsa.debian.org/debian/rocksdb/-/merge_requests/9 for
co-maintainer review and will upload to unstable hopefully soon, with
high likelihood that this fixes #1088523
Hi Maytham!
I don't see any updates at
https://salsa.debian.org/go-team/packages/golang-golang-x-net/-/commits/debian/sid
since I posted my feedback, so I assume I should continue waiting?
On Sun, 5 Jan 2025 at 11:51, Otto Kekäläinen wrote:
> Hi!
>
> (I am cc'ing Anthony
I can try importing latest upstream and run reverse builds for all
dependants.
One challenge I have at the moment is that upstream is not responding on
GitHub PRs and ignoring fixes and also not publishing any policy of which
RocksDB version is likely good for long-term maintenance. Thus there is
For additional context, the build log
https://people.debian.org/~sanvila/build-logs/202412/golang-golang-x-net_0.27.0-1_amd64-20241206T201010.312Z
contains the error (which was missing from this bug report):
...
--- PASS: TestNodeLabel (0.00s)
=== RUN TestFind
--- PASS: TestFind (0.00s)
=== RUN
Hi!
(I am cc'ing Anthony so he is aware that this is going on, and can
chime in if he does not want the package to be uploaded)
> I've updated the CI in a fork so I don't conflict with any CI changes
> that are being discussed in the Go team. CI passes with flying colours.
> https://salsa.debian.
Hi!
I am happy to sponsor the upload of any package that has prior to
upload been proven to not have any easily testable regressions by
running Salsa CI on it. Would you be willing to put a bit of extra
work in and adopt Salsa CI as it is in the latest pkg-go-tools?
See https://salsa.debian.org/g
Forwarded: https://github.com/cli/cli/pull/10151
Hi!
I submitted fix upstream in https://github.com/cli/cli/pull/10151 and will
backport into Debian and coming days.
This could be a bit faster if the existing package maintainer replies to
email this week. I don't feel confident doing changes in
Forwarded: https://jira.mariadb.org/browse/MDEV-34788?
This seems to be flaky tests and not inherently a blocker for the i386 rebuild.
These issues seem like a duplicate of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052838 "mariadb:
FTBFS multiple archs: Post-build tests randomly fail on
Fix pending review at https://github.com/Debian/dh-make-golang/pull/235
Hi!
This was discussed on Go team mailing list a couple weeks ago before
uploading. I will submit a fix for this and also gh in a couple of days.
Potential fix posted at
https://salsa.debian.org/agx/git-buildpackage/-/merge_requests/19
Hi,
...
> But I suppose this is an issue because other versions don't have
> the versioning tag and the linker accidentally picked a symbol that
> I don't know, doesn't really exist? I don't know how this happens.
Thanks for looking into this issue and filing follow-up against gcc14!
I see that
Perhaps some pre-depends relationship is missing and upgrades fail due
to mismatching ABI..?
I am only seeing this issue on upgrades. Bootstrapping a system from
scratch does not have this issue.
Source: python-apt
Version: 2.9.1
Severity: serious
Seems the latest version of python-apt has some serious regressions as
https://tracker.debian.org/pkg/python-apt shows wide-spread
autopkgtest failures.
In a clean Debian unstable container a simple installation is failing with:
Hit:1 http://de
Hi Paul!
Thanks for reporting. This is actually already fixed but upload is
pending a second pair of eyes to say LGTM on
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/97
and later
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/98
if no bugs surface i
>From https://peps.python.org/pep-0594/#pipes
> The pipes module provides helpers to pipe the input of one command into the
> output of another
> command. The module is built on top of os.popen. Users are encouraged to use
> the subprocess
> module instead.
For the record, this issue is no longer visible on amd64 autopkgtests
at https://salsa.debian.org/mariadb-team/mariadb-server/-/pipelines/756431
nor at https://ci.debian.net/packages/m/mariadb/, only armhf and that
probably only because the arch is dropping jobs and no rerunning the
test despite th
On Sun, 27 Oct 2024 at 20:58, Santiago Vila wrote:
>
> El 27/10/24 a las 21:09, Otto Kekäläinen escribió:
> > Do you Faustin want to dive into why the timezone started to behave
> > differently recently in Debian?
> >
> > Sergei and Daniel already looked at
>
Do you Faustin want to dive into why the timezone started to behave
differently recently in Debian?
Sergei and Daniel already looked at
https://jira.mariadb.org/browse/MDEV-35088, but you could help find
out what changed in Debian Sid recently.
On Tue, 8 Oct 2024 at 06:45, Otto Kekäläinen wrote
Forwarded: https://jira.mariadb.org/browse/MDEV-35088
Hi,
I did notice this already a couple days ago. It is visible both in
Debian CI and in Salsa CI. I don't know what changed in Debian (it is
not a change in MariaDB), and I don't know if the MariaDB test should
be adapted/updated to be more ro
Hi!
Thanks for reporting. The failures are highlighted below. These issues
seem like a duplicate of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052838 "mariadb:
FTBFS multiple archs: Post-build tests randomly fail on reserved port
due to lacking builder isolation" and are sporadic by nature
Hi!
This https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074670 is a
result of the MariaDB build with the embedded server using excessive
disk space.
I have filed reverting MR at
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/89
and asked upstream for advice in
https://l
Thanks for reporting this!
There were Breaks/Replaces in place but they had a typo in version string.
Fixed now, and also ran the check_for_missing_breaks.py script to with all
previous versions ever released of MariaDB to ensure all scenarios are
covered:
https://salsa.debian.org/mariadb-team/mar
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 Bo
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
https://bugs.debian.org/cgi-bin/b
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:
https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/cd90d81520fd2211bd4b
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:
https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/cd90d81520fd2211bd4b
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:
https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/cd90d81520fd2211bd4b
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:
https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/cd90d81520fd2211bd4b
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 act
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 per
> > 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
> https://salsa.debian.
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:
https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/d2a0784f1e01b6613fef
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 f
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:
https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/8194544349982990fb25
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:
https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/f526df0a0921a55097d9
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 cor
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:
https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/063109a306a016974a46
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 trixi
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 h
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&arch=powerpc&ver=1%3A10.11.5-2&stamp=1696735216&raw=0
main.failed_auth_unixsocket w13 [ fail ]
Test ended at 2023-10-08 03:17:49
CURRENT_TES
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 Bu
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 maria
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:
https://salsa.debian.org/ddp-team/release-notes/-/merge_reques
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 t
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
https://salsa.debian
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: Lin
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 defau
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 default-mysql-serv
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 amd6
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 libdbd-mariadb-
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.
1 - 100 of 415 matches
Mail list logo
