December 2022 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1200710] New: dracut-initqueue[581]: mount.nfs: No such device
by bugzilla_noreply＠suse.com 27 Mar '23

27 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1200710 Bug ID: 1200710 Summary: dracut-initqueue[581]: mount.nfs: No such device Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: dracut-maintainers(a)suse.de Reporter: schwab(a)suse.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- This appears to be a missing synchronisation with NFS root: [ 10.481118][ T371] mmc_spi spi1.0: SD/MMC host mmc0, no DMA, no WP, no poweroff [ 10.518721][ T17] mmc0: host does not support reading read-only switch, assuming write-enable [ 10.526746][ T17] mmc0: new SDHC card on SPI [ 10.528219][ T368] macb 10090000.ethernet: Registered clk switch 'sifive-gemgxl-mgmt' [ 10.539131][ T368] macb 10090000.ethernet: GEM doesn't support hardware ptp. [ 10.608768][ T373] mmcblk0: mmc0:0000 SD32G 29.9 GiB [ 10.643933][ T373] mmcblk0: p1 p2 p3 p4 p5 [ 10.659954][ T399] MACsec IEEE 802.1AE [ 10.751273][ T368] macb 10090000.ethernet eth0: Cadence GEM rev 0x10070109 at 0x10090000 irq 16 (70:b3:d5:92:f1:07) [ 12.570426][ T441] macb 10090000.ethernet eth0: PHY [10090000.ethernet-ffffffff:00] driver [Microsemi VSC8541 SyncE] (irq=POLL) [ 12.581251][ T441] macb 10090000.ethernet eth0: configuring for phy/gmii link mode [ 16.151411][ T17] macb 10090000.ethernet eth0: Link is Up - 1Gbps/Full - flow control tx [ 16.158934][ T17] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 16.196121] dracut-initqueue[548]: wicked: eth0: Request to acquire DHCPv4 lease with UUID 8a5a9562-2808-0600-2402-000001000000 [ 16.413613][ T549] NET: Registered PF_PACKET protocol family [ 17.110211] dracut-initqueue[548]: wicked: eth0: Committed DHCPv4 lease with address 10.168.4.88 (lease time 1296000 sec, renew in 648000 sec, rebind in 1134000 sec) [ 17.747339][ T582] FS-Cache: Loaded [ 17.939969] dracut-initqueue[581]: mount.nfs: No such device [ 18.855132] dracut-initqueue[602]: mount.nfs: No such device [ 179.792006] dracut-initqueue[384]: Warning: dracut-initqueue: timeout, still waiting for following initqueue hooks: [ 179.797072] dracut-initqueue[384]: Warning: /lib/dracut/hooks/initqueue/finished/nfsroot.sh: "[ -e $NEWROOT/proc ]" [ 179.804241] dracut-initqueue[384]: Warning: dracut-initqueue: starting timeout scripts The only dracut related updates were dracut-kiwi-lib and dracut-kiwi-oem-repart. -- You are receiving this mail because: You are on the CC list for the bug.

1 30

[Bug 1156301] New: Dovecot fails to build with LTO enabled in Tumbleweed
by bugzilla_noreply＠novell.com 27 Mar '23

27 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1156301 Bug ID: 1156301 Summary: Dovecot fails to build with LTO enabled in Tumbleweed Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: suse+build(a)de-korte.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Since enabling LTO in Tumbleweed, the dovecot23 package fails to build most of the time with [ 133s] libtool: link: gcc -std=gnu99 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto -g -I/usr/lib64 -fpic -DPIC -fstack-protector-strong -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -mfunction-return=thunk -mindirect-branch=thunk -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -fno-builtin-strftime -Wstrict-aliasing=2 -DOPENSSL_LOAD_CONF -flto=auto -o test-iostream-ssl test-iostream-ssl.o -pie ./.libs/libssl_iostream_openssl.so ./.libs/libssl_iostream.a ../lib-test/.libs/libtest.a ../lib/.libs/liblib.a -lssl -lcrypto -ldl -Wl,-rpath -Wl,/home/abuild/rpmbuild/BUILD/dovecot-2.3.8/src/lib-ssl-iostream/.libs -Wl,-rpath -Wl,/usr/lib64/dovecot/modules [ 136s] /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: test-iostream-ssl: hidden symbol `t_str_new' in /tmp/test-iostream-ssl.X2QBZZ.ltrans0.ltrans.o is referenced by DSO [ 136s] /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: final link failed: bad value [ 136s] collect2: error: ld returned 1 exit status [ 136s] make[3]: *** [Makefile:637: test-iostream-ssl] Error 1 Without changing anything, the build completes, but this is a rare occurrence. Disabling LTO solves the build problem. -- You are receiving this mail because: You are on the CC list for the bug.

2 1

[Bug 1204067] New: [Build 20220915] openQA test fails in grub_test since upgrade of qemu-ovmf-x86_64 from 202008-150300.10.14.1 to 202202-150400.3.3
by bugzilla_noreply＠suse.com 27 Mar '23

27 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1204067 Bug ID: 1204067 Summary: [Build 20220915] openQA test fails in grub_test since upgrade of qemu-ovmf-x86_64 from 202008-150300.10.14.1 to 202202-150400.3.3 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other URL: https://openqa.opensuse.org/tests/2675825/modules/grub _test/steps/15 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Bootloader Assignee: screening-team-bugs(a)suse.de Reporter: tina.mueller(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: openQA Blocker: Yes ## Observation openQA test in scenario opensuse-Tumbleweed-DVD-x86_64-nvme@uefi fails in [grub_test](https://openqa.opensuse.org/tests/2675825/modules/grub_test/step… ## Test suite description Maintainer: rbrown(a)suse.de; Basic installation test to confirm that installing and booting to an nvme as your root disk works ## Reproducible Fails since (at least) Build [20220915](https://openqa.opensuse.org/tests/2675825) (current job) ## Expected result Last good: [20220914](https://openqa.opensuse.org/tests/2663884) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensus… We confirmed that the qemu-ovmf-x86_64 upgrade is the culprit, because after downgrading again the test worked as expected. We debugged the test and found out that after the installation in the test, the reboot does show the boot menu of the installation medium again, instead of offering to boot from hard disk, and selecting "Boot from Hard Disk" resulted in showing the same installation medium menu again. Ejecting the CD before reboot resulted in an error message: BdsDxe: failed to load Boot0007 "opensuse-secureboot" from HD(...)/\EFI\opensuse\shim.efi: Not found We also have other tests failing, but in different ways, but this might still be related. The ticket for the mentioned failure can be found here: https://progress.opensuse.org/issues/116704 Our workaround will be to downgrade all openQA workers and add a zypper lock. -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Bug 1205135] New: windows:mingw:win{32|64}: Packages that do not use the macros specific to the use of the cmake build system
by bugzilla_noreply＠suse.com 26 Mar '23

26 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1205135 Bug ID: 1205135 Summary: windows:mingw:win{32|64}: Packages that do not use the macros specific to the use of the cmake build system Classification: openSUSE Product: openSUSE.org Version: unspecified Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: 3rd party software Assignee: fstrba(a)suse.com Reporter: ralf.habacker(a)freenet.de QA Contact: screening-team-bugs(a)suse.de CC: fridrich.strba(a)bluewin.ch, hib(a)hiberis.nl, mkbosmans(a)gmail.com Found By: --- Blocker: --- As documented at https://en.opensuse.org/Build:projects:windows:mingw#Porting_native_cmake_p… there are specific macros for using the cmake build system %_mingw32_cmake[_build|_install] which are not used by the following packages: ./mingw32-ampl-mp ./mingw32-clucene ./mingw32-cmocka ./mingw32-freeocl ./mingw32-glfw ./mingw32-grantlee ./mingw32-hdf5 ./mingw32-kate4-parts ./mingw32-kdewin ./mingw32-kdewin-tools ./mingw32-ktoblzcheck ./mingw32-libattica ./mingw32-libdbusmenu-qt ./mingw32-libechonest ./mingw32-libftdi ./mingw32-libgit2 ./mingw32-libgraphite2 ./mingw32-libjreen ./mingw32-liblastfm ./mingw32-libmodman ./mingw32-libproxy ./mingw32-libqjson ./mingw32-lucene++ ./mingw32-metis ./mingw32-oce ./mingw32-perfectspot ./mingw32-phonon ./mingw32-qt5keychain ./mingw32-qtkeychain ./mingw32-qtsparkle ./mingw32-qtweetlib ./mingw32-quazip ./mingw32-snoregrowl ./mingw32-snorenotify ./mingw32-taglib ./mingw32-win_iconv ./mingw32-zlib -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1197954] New: systemd-cryptsetup: Device root is still in use.
by bugzilla_noreply＠suse.com 26 Mar '23

26 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1197954 Bug ID: 1197954 Summary: systemd-cryptsetup: Device root is still in use. Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs(a)suse.de Reporter: opensuse(a)mike.franken.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Starting with the Tumbleweed snapshot installed on March, 29th I got back an old error systemd-cryptsetup: Device root is still in use. systemd-cryptsetup: Failed to deactivate: Device or resource busy which shows up in the journal after switching root. I am not sure, but I believe that the reason for this is systemd[1]: plymouth-start.service: Unit process 394 (plymouthd) remains running after unit stopped. systemd[1]: Dispatch Password Requests to Console Directory Watch was skipped because of a failed condition check (ConditionPathExists=!/run/plymouth/pid). which shows up in the journal just before the "in use" message. So plymouth didn't stop and the encrypted filesystem couldn't be unmounted. Before the last two snapshots the message looked like this: systemd[1]: Condition check resulted in Dispatch Password Requests to Console Directory Watch being skipped. -- You are receiving this mail because: You are on the CC list for the bug.

1 11

[Bug 1178233] New: zypper up does not report any updates in WSL after longer pause
by bugzilla_noreply＠suse.com 24 Mar '23

24 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1178233 Bug ID: 1178233 Summary: zypper up does not report any updates in WSL after longer pause Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: WSL Assignee: sle-ms(a)suse.de Reporter: lubos.kocman(a)suse.com QA Contact: qa-c(a)suse.de Found By: --- Blocker: --- I do have WSL images with Leap 15.2 and it seems that zypper doesn't register outdated repodata cache. Let's say that I'd start WSL image (bash session) once per two weeks, and if I simply run "zypper up" after these two weeks zypper reports no update, until I clean repodata I didn't call refresh simply up && clean --all && up and that worked fine. However I'd like to avoid situation when zypper simply reports no update with sporadically WSL use and user gets to believe it. My initial thought it's that this is caused by not having any services running inside the "container", however Ludwig things something might be wrong with the date/time inside the image. -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1194723] New: automatically add dkms module after kernel update
by bugzilla_noreply＠suse.com 24 Mar '23

24 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1194723 Bug ID: 1194723 Summary: automatically add dkms module after kernel update Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: m.schenker(a)posteo.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Hi there, for certain scenarios I sometimes rely on kernel modules added via dkms. Initially installing them is as easy as the following. cd module-folder dkms install . From other distributions I am used that the module gets re-added/rebuild during a kernel update. However after a kernel update and reboot on Tumbleweed I just receive a message like the following one. modprobe: FATAL: Module vendor-reset not found in directory /lib/modules/5.16.0-1-default While the module still seems installed. user@computer:~/vendor-reset> sudo dkms install . Error! DKMS tree already contains: vendor-reset-0.1.1 You cannot add the same module/version combo more than once. It is not available to the updated kernel. There were two request for similar problems. 1. https://bugzilla.opensuse.org/show_bug.cgi?id=931175 Which resulted in a `don't care, won't fix 2. https://bugzilla.opensuse.org/show_bug.cgi?id=1184671 Which was ignored. I have not created kernel modules myself, so if there is something that needs to be done to the modules so they themselfs trigger an update I would be glad for a nudge in the right direction. However if there is something I would need to do in Tumbleweed I would be glad for help as well. I still see it as something that needs fixing since other Distributions, Arch, Ubuntu handle this on their own. Thank you! -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 1089823] New: YaST can silently fail to run snapper during installation
by bugzilla_noreply＠novell.com 24 Mar '23

24 Mar '23

http://bugzilla.suse.com/show_bug.cgi?id=1089823 Bug ID: 1089823 Summary: YaST can silently fail to run snapper during installation Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.0 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Installation Assignee: yast2-maintainers(a)suse.de Reporter: fvogt(a)suse.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- Created attachment 767377 --> http://bugzilla.suse.com/attachment.cgi?id=767377&action=edit y2logs Installation with the live media and snapshots enabled fails: https://openqa.opensuse.org/tests/657353#step/await_install/21 This is because snapper is not installed in the installation system, so the snapper installation-helper is missing. So YaST needs to add a hard dependency there. The bigger issue is that YaST didn't care that the binary is not present though (found in y2log-3): [libstorage] ActiongraphImpl.cc:584 Commit Action "Mounting /dev/vda2 at /" [sid:59, first] [libstorage] SystemCmd.cc:67 constructor SystemCmd("/usr/lib/snapper/installation-helper --step '1' --device '/dev/vda2' --description 'first root filesystem'") [libstorage] SystemCmd.cc:186 SystemCmd Executing:"/usr/lib/snapper/installation-helper --step '1' --device '/dev/vda2' --description 'first root filesystem'" [libstorage] SystemCmd.cc:187 timestamp [295.985073], 2018-04-17 02:15:45 GMT, 2018-04-16 22:15:45 EDT [libstorage] SystemCmd.cc:660 Adding Line 1 "/bin/sh: /usr/lib/snapper/installation-helper: No such file or directory" [libstorage] SystemCmd.cc:626 pid:4219 added lines:1 stderr:true [libstorage] SystemCmd.cc:492 THROW: Command not found: "/usr/lib/snapper/installation-helper --step '1' --device '/dev/vda2' --description 'first root filesystem'" [libstorage] SystemCmd.cc:416 stopwatch 0.010977s for "/usr/lib/snapper/installation-helper --step '1' --device '/dev/vda2' --description 'first root filesystem'" [libstorage] SystemCmd.cc:436 system() Returns:127 [libstorage] SystemCmd.cc:678 stderr:/bin/sh: /usr/lib/snapper/installation-helper: No such file or directory [libstorage] SystemCmd.cc:67 constructor SystemCmd("/sbin/udevadm settle --timeout=20") As can be seen, YaST notices the error but ignores it. Similar output for step 2. -- You are receiving this mail because: You are on the CC list for the bug.

2 19

[Bug 1191220] New: New Let's Encrypt certificate cannot be verify in Mono
by bugzilla_noreply＠suse.com 23 Mar '23

23 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1191220 Bug ID: 1191220 Summary: New Let's Encrypt certificate cannot be verify in Mono Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs(a)suse.de Reporter: martin.liska(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- The following fails: $ csharp -e 'new System.Net.WebClient ().DownloadString ("https://seznam.cz")' System.Net.WebException: Error: TrustFailure (Authentication failed, see inner exception.) ---> System.Security.Authentication.AuthenticationException: Authentication failed, see inner exception. ---> Mono.Btls.MonoBtlsException: Ssl error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED at /home/abuild/rpmbuild/BUILD/mono-6.12.0.107/external/boringssl/ssl/handshake_client.c:1132 at Mono.Btls.MonoBtlsContext.ProcessHandshake () [0x00048] in <83dd749384734033afca92f4cfac782c>:0 at Mono.Net.Security.MobileAuthenticatedStream.ProcessHandshake (Mono.Net.Security.AsyncOperationStatus status, System.Boolean renegotiate) [0x000da] in <83dd749384734033afca92f4cfac782c>:0 at (wrapper remoting-invoke-with-check) Mono.Net.Security.MobileAuthenticatedStream.ProcessHandshake(Mono.Net.Security.AsyncOperationStatus,bool) at Mono.Net.Security.AsyncHandshakeRequest.Run (Mono.Net.Security.AsyncOperationStatus status) [0x00006] in <83dd749384734033afca92f4cfac782c>:0 at Mono.Net.Security.AsyncProtocolRequest.ProcessOperation (System.Threading.CancellationToken cancellationToken) [0x000fc] in <83dd749384734033afca92f4cfac782c>:0 --- End of inner exception stack trace --- at Mono.Net.Security.MobileAuthenticatedStream.ProcessAuthentication (System.Boolean runSynchronously, Mono.Net.Security.MonoSslAuthenticationOptions options, System.Threading.CancellationToken cancellationToken) [0x00262] in <83dd749384734033afca92f4cfac782c>:0 at Mono.Net.Security.MonoTlsStream.CreateStream (System.Net.WebConnectionTunnel tunnel, System.Threading.CancellationToken cancellationToken) [0x0016a] in <83dd749384734033afca92f4cfac782c>:0 at System.Net.WebConnection.CreateStream (System.Net.WebOperation operation, System.Boolean reused, System.Threading.CancellationToken cancellationToken) [0x001ba] in <83dd749384734033afca92f4cfac782c>:0 --- End of inner exception stack trace --- at System.Net.WebConnection.CreateStream (System.Net.WebOperation operation, System.Boolean reused, System.Threading.CancellationToken cancellationToken) [0x0021a] in <83dd749384734033afca92f4cfac782c>:0 at System.Net.WebConnection.InitConnection (System.Net.WebOperation operation, System.Threading.CancellationToken cancellationToken) [0x00141] in <83dd749384734033afca92f4cfac782c>:0 at System.Net.WebOperation.Run () [0x0009a] in <83dd749384734033afca92f4cfac782c>:0 at System.Net.WebCompletionSource`1[T].WaitForCompletion () [0x00094] in <83dd749384734033afca92f4cfac782c>:0 at System.Net.HttpWebRequest.RunWithTimeoutWorker[T] (System.Threading.Tasks.Task`1[TResult] workerTask, System.Int32 timeout, System.Action abort, System.Func`1[TResult] aborted, System.Threading.CancellationTokenSource cts) [0x000f8] in <83dd749384734033afca92f4cfac782c>:0 at System.Net.HttpWebRequest.GetResponse () [0x00016] in <83dd749384734033afca92f4cfac782c>:0 at System.Net.WebClient.GetWebResponse (System.Net.WebRequest request) [0x00000] in <83dd749384734033afca92f4cfac782c>:0 at System.Net.WebClient.DownloadBits (System.Net.WebRequest request, System.IO.Stream writeStream) [0x000e6] in <83dd749384734033afca92f4cfac782c>:0 at System.Net.WebClient.DownloadDataInternal (System.Uri address, System.Net.WebRequest& request) [0x00061] in <83dd749384734033afca92f4cfac782c>:0 at System.Net.WebClient.DownloadString (System.Uri address) [0x00011] in <83dd749384734033afca92f4cfac782c>:0 at System.Net.WebClient.DownloadString (System.String address) [0x00008] in <83dd749384734033afca92f4cfac782c>:0 at <InteractiveExpressionClass>.Host (System.Object& $retval) [0x00006] in <bab8bbbe52954fd79168395f7636506e>:0 at Mono.CSharp.Evaluator.Evaluate (System.String input, System.Object& result, System.Boolean& result_set) [0x00038] in <dc18f8c1f3e14d9a83758fe12bb22a10>:0 at Mono.CSharpShell.Evaluate (System.String input) [0x00000] in <a01f5168c3824ddfb7cf74041d74890a>:0 It's discussed in the upstream issue: https://github.com/mono/mono/issues/12406 But I cannot fix it with: sudo cert-sync /etc/ssl/certs/ca-certificates.crt -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 1135095] New: LTO: xtrabackup build fails
by bugzilla_noreply＠novell.com 23 Mar '23

23 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1135095 Bug ID: 1135095 Summary: LTO: xtrabackup build fails Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: martin.liska(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Fails here: https://build.opensuse.org/build/openSUSE:Factory:Staging:N/standard/x86_64… due to: [ 313s] /home/abuild/rpmbuild/BUILD/percona-xtrabackup-2.4.12/build/libmysql/libmysql_exports_file.cc:106:15: error: function 'mysql_load_plugin' redeclared as variable [ 313s] 106 | extern void* mysql_load_plugin; [ 313s] | ^ [ 313s] /home/abuild/rpmbuild/BUILD/percona-xtrabackup-2.4.12/sql-common/client_plugin.c:541:1: note: previously declared here [ 313s] 541 | mysql_load_plugin(MYSQL *mysql, const char *name, int type, int argc, ...) [ 313s] | ^ [ 313s] /home/abuild/rpmbuild/BUILD/percona-xtrabackup-2.4.12/build/libmysql/libmysql_exports_file.cc:105:15: error: function 'mysql_client_register_plugin' redeclared as variable [ 313s] 105 | extern void* mysql_client_register_plugin; [ 313s] | ^ [ 313s] /home/abuild/rpmbuild/BUILD/percona-xtrabackup-2.4.12/sql-common/client_plugin.c:395:1: note: previously declared here [ 313s] 395 | mysql_client_register_plugin(MYSQL *mysql, [ 313s] | ^ [ 313s] /home/abuild/rpmbuild/BUILD/percona-xtrabackup-2.4.12/build/libmysql/libmysql_exports_file.cc:104:15: error: function 'mysql_client_find_plugin' redeclared as variable [ 313s] 104 | extern void* mysql_client_find_plugin; [ 313s] | ^ [ 313s] /home/abuild/rpmbuild/BUILD/percona-xtrabackup-2.4.12/sql-common/client_plugin.c:553:1: note: previously declared here -- You are receiving this mail because: You are on the CC list for the bug.

2 6