Re: openSUSE:Factory - gcc7 - Build problem notification
On Thu, 22 Jun 2023, DimStar / Dominique Leuenberger wrote:
Dear Richard Biener,
Following-up the reminder of one week ago, we have to inform you that 'gcc7' is still showing a problem in openSUSE:Factory. See https://build.opensuse.org/package/show/openSUSE:Factory/gcc7
Since Wed Jun 7 23:04:05 2023 we noticed the following problem: Uninstallable: package bash-5.2.15.x86_64 requires libreadline.so.8()(64bit), but none of the providers can be installed
Please find the time to make this package usable again. If needed, also reach out to the broader community, trying to find somebody to help you fix this package.
I've filed boo#1212435 about this new behavior of install-check but nobody feels responsible. It seems install-check changed how it tries installing packages, forcing things even when there's a better provider already installed on the system. But it's hard to tell since there are no sophisticated logs on what it actually does nor do these reminders tell you where the sources of the scripts are. Any hints? Thanks, Richard.
On Fri, 2023-06-23 at 06:38 +0000, Richard Biener wrote:
On Thu, 22 Jun 2023, DimStar / Dominique Leuenberger wrote:
Dear Richard Biener,
Following-up the reminder of one week ago, we have to inform you that 'gcc7' is still showing a problem in openSUSE:Factory. See https://build.opensuse.org/package/show/openSUSE:Factory/gcc7
Since Wed Jun 7 23:04:05 2023 we noticed the following problem: Uninstallable: package bash-5.2.15.x86_64 requires libreadline.so.8()(64bit), but none of the providers can be installed
Please find the time to make this package usable again. If needed, also reach out to the broader community, trying to find somebody to help you fix this package.
I've filed boo#1212435 about this new behavior of install-check but nobody feels responsible.
It seems install-check changed how it tries installing packages, forcing things even when there's a better provider already installed on the system. But it's hard to tell since there are no sophisticated logs on what it actually does nor do these reminders tell you where the sources of the scripts are.
Hi Richard, Seems install-check was not really changing - but different glibc version symbols came in a bit trickier 'better alternatives' available is no argument for the one package: the check wants to be sure that the package in question is installable - after all, so we believe, that is why we ship the package :) the 'fun' thing in the dep chain is that 'bash' via libreadline / libtinfo requires libstdc++.so.6(GLIBCXX_3.4.32) - which is only provided by libstdc++.so.6 as built by gcc13 (the gcc12 and gcc7 flavors do not add the symbol) installcheck has been modified in the last week to support a list of packages to ignore: https://github.com/openSUSE/openSUSE-release-tools/commit/6b1a26be30afc05ed5... and libstdc++6-gcc7 and -gcc12 have been added to the list to be ignored (of course, that does not make the shipped packages installable - the dep chain simply cannot be made valid) This in turn answers the last question: where does the installcheck code live: https://github.com/openSUSE/openSUSE-release-tools/blob/master/project-insta... With this, I'd say the bug has actually been 'fixed' (worked around) for that package - even though we missed the bug report Cheers, Dominique
On Fri, 23 Jun 2023, Dominique Leuenberger wrote:
On Fri, 2023-06-23 at 06:38 +0000, Richard Biener wrote:
On Thu, 22 Jun 2023, DimStar / Dominique Leuenberger wrote:
Dear Richard Biener,
Following-up the reminder of one week ago, we have to inform you that 'gcc7' is still showing a problem in openSUSE:Factory. See https://build.opensuse.org/package/show/openSUSE:Factory/gcc7
Since Wed Jun 7 23:04:05 2023 we noticed the following problem: Uninstallable: package bash-5.2.15.x86_64 requires libreadline.so.8()(64bit), but none of the providers can be installed
Please find the time to make this package usable again. If needed, also reach out to the broader community, trying to find somebody to help you fix this package.
I've filed boo#1212435 about this new behavior of install-check but nobody feels responsible.
It seems install-check changed how it tries installing packages, forcing things even when there's a better provider already installed on the system. But it's hard to tell since there are no sophisticated logs on what it actually does nor do these reminders tell you where the sources of the scripts are.
Hi Richard,
Seems install-check was not really changing - but different glibc version symbols came in a bit trickier
'better alternatives' available is no argument for the one package: the check wants to be sure that the package in question is installable - after all, so we believe, that is why we ship the package :)
the 'fun' thing in the dep chain is that 'bash' via libreadline / libtinfo requires libstdc++.so.6(GLIBCXX_3.4.32) - which is only provided by libstdc++.so.6 as built by gcc13 (the gcc12 and gcc7 flavors do not add the symbol)
Yep.
installcheck has been modified in the last week to support a list of packages to ignore: https://github.com/openSUSE/openSUSE-release-tools/commit/6b1a26be30afc05ed5...
and libstdc++6-gcc7 and -gcc12 have been added to the list to be ignored (of course, that does not make the shipped packages installable - the dep chain simply cannot be made valid)
Appending -gcc7 or -gcc12 to the canonical shlib name libstdc++6 (which is now provided by gcc13) was the least hackish way to deal with implementation details in the former autobuild and todays build service. ISTR that for some obscure update to a very old tree we resorted to rm the built rpms from magic places in a carefully chosen spec file part to prevent autobuild/OBS from picking them up. As you can imagine the gcc spec files are already very complex and simply _not_ building some packages depending on configury (we append -gcc7/12 based on configury, so that's there) is going to uglify things a lot since we have to prune all the otherwise packaged files or else rpmbuild complains about unpackaged files. It would be really nice to be able to mark some %package as "ghost" or so, either to simply make rpmbuild _not_ build the package but treat the %packages file list as _not_ unpackaged or to make OBS not pick them up. I'm at least not aware that such things are possible now, are they?
This in turn answers the last question: where does the installcheck code live: https://github.com/openSUSE/openSUSE-release-tools/blob/master/project-insta...
With this, I'd say the bug has actually been 'fixed' (worked around) for that package - even though we missed the bug report
Thanks! Richard. -- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman; HRB 36809 (AG Nuernberg)
participants (2)
-
Dominique Leuenberger -
Richard Biener