Nothing provides libgnat-10.so()(64bit)

[Miro Hrončok]

Hello. Apparently, many packages in rawhide require libgnat-10.so()(64bit):

$ repoquery --repo=rawhide --whatrequires 'libgnat-10.so()(64bit)'
GtkAda3-devel-0:2020-1.fc34.x86_64
PragmARC-0:20130728-22.fc33.x86_64
ahven-0:2.7-7.fc33.x86_64
aunit-0:2017-10.fc33.x86_64
aws-0:2019-3.fc33.x86_64
aws-devel-0:2019-3.fc33.x86_64
aws-tools-0:2019-3.fc33.x86_64
florist-0:2017-7.fc33.x86_64
ghdl-0:0.38~dev-9.20200827git4ce9925.fc34.x86_64
ghdl-llvm-0:0.38~dev-9.20200827git4ce9925.fc34.x86_64
ghdl-mcode-0:0.38~dev-9.20200827git4ce9925.fc34.x86_64
gnatcoll-core-0:2018-6.fc33.x86_64
gnatcoll-db-devel-0:2018-7.fc33.x86_64
gnatcoll-gmp-0:2018-7.fc33.x86_64
gnatcoll-iconv-0:2018-7.fc33.x86_64
gnatcoll-postgres-0:2018-7.fc33.x86_64
gnatcoll-readline-0:2018-7.fc33.x86_64
gnatcoll-sql-0:2018-7.fc33.x86_64
gnatcoll-sqlite-0:2018-7.fc33.x86_64
gnatcoll-syslog-0:2018-7.fc33.x86_64
gnatcoll-xref-0:2018-7.fc33.x86_64
matreshka-0:20.1-3.fc33.x86_64
matreshka-amf-0:20.1-3.fc33.x86_64
matreshka-amf-dd-0:20.1-3.fc33.x86_64
matreshka-amf-mofext-0:20.1-3.fc33.x86_64
matreshka-amf-ocl-0:20.1-3.fc33.x86_64
matreshka-amf-uml-0:20.1-3.fc33.x86_64
matreshka-amf-utp-0:20.1-3.fc33.x86_64
matreshka-fastcgi-0:20.1-3.fc33.x86_64
matreshka-servlet-lib-0:20.1-3.fc33.x86_64
matreshka-soap-core-0:20.1-3.fc33.x86_64
matreshka-soap-wsse-0:20.1-3.fc33.x86_64
matreshka-spikedog-api-lib-0:20.1-3.fc33.x86_64
matreshka-spikedog-awsd-0:20.1-3.fc33.x86_64
matreshka-spikedog-core-lib-0:20.1-3.fc33.x86_64
matreshka-sql-core-0:20.1-3.fc33.x86_64
matreshka-sql-mysql-0:20.1-3.fc33.x86_64
matreshka-sql-postgresql-0:20.1-3.fc33.x86_64
matreshka-sql-sqlite-0:20.1-3.fc33.x86_64
matreshka-xml-0:20.1-3.fc33.x86_64
mine_detector-0:6.0-38.fc33.x86_64
plplot-ada-0:5.15.0-22.fc34.x86_64
templates_parser-0:11.8.0-23.fc33.x86_64
templates_parser-tools-0:11.8.0-23.fc33.x86_64
xmlada-0:2019-3.fc33.x86_64
zeromq-ada-0:2.1.0-30.24032011git.fc32.x86_64
zlib-ada-0:1.4-0.26.20120830CVS.fc33.x86_64

But gcc was updated and bumped the soname to 11, hence nothing provides it.

Could you please rebuild the affected packages?

It would also be really appreciated if side tag was used to coordinate the 
rebuilds, instead of shipping the update directly.

Thanks.
-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Jakub Jelinek]

On Mon, Dec 07, 2020 at 06:29:51PM +0100, Miro Hrončok wrote:
>  Hello. Apparently, many packages in rawhide require
> libgnat-10.so()(64bit): 
I'm not a provenpackager, so I'm afraid I can't do that myself.
Perhaps the maintainers can just rebuild them themselves?

	Jakub

[Jeff Law]

On 12/7/20 11:07 AM, Jakub Jelinek wrote:
>  On Mon, Dec 07, 2020 at 06:29:51PM +0100, Miro Hrončok wrote:
> > Hello. Apparently, many packages in rawhide require libgnat-10.so()(64bit):
>  I'm not a provenpackager, so I'm afraid I can't do that myself.
>  Perhaps the maintainers can just rebuild them themselves? 
And note that some of
these are going to require fixes to the packages
themselves as the Ada front-end changed and some of them no longer
build.  IIRC zlib and templates_parser are the most important to get
rebuilt and I think those "just work".

I'll try to get those rebuilt so that the downstream things have a
better chance of working :-)

jeff

[Pavel Zhukov]

Hi Jeff.
Thank you for rebuilding xmlada. I'll continue from there as I want to
use this bootstrap to update packages to newest upstream version
anyway .

On Mon, Dec 7, 2020 at 7:25 PM Jeff Law <law(a)redhat.com&gt; wrote:
>  On 12/7/20 11:07 AM, Jakub Jelinek wrote:
>  > On Mon, Dec 07, 2020 at 06:29:51PM +0100, Miro Hrončok wrote:
>  >> Hello. Apparently, many packages in rawhide require libgnat-10.so()(64bit):
>  > I'm not a provenpackager, so I'm afraid I can't do that myself.
>  > Perhaps the maintainers can just rebuild them themselves?
>  And note that some of these are going to require fixes to the packages
>  themselves as the Ada front-end changed and some of them no longer
>  build.  IIRC zlib and templates_parser are the most important to get
>  rebuilt and I think those "just work".
>
>  I'll try to get those rebuilt so that the downstream things have a
>  better chance of working :-)
>
>  jeff
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail] 


-- 
Pavel Zhukov
Software Engineer
IRC: landgraf

[Jeff Law]

On 12/7/20 1:48 PM, Pavel Zhukov wrote:
>  Hi Jeff.
>  Thank you for rebuilding xmlada. I'll continue from there as I want to
>  use this bootstrap to update packages to newest upstream version
>  anyway . 
ACK.  That'll definitely help.  I'll keep my gprbuild bits here
(they
aren't complete/working anyway)

jeff

[Björn Persson]

Jeff Law wrote:
>  On 12/7/20 11:07 AM, Jakub Jelinek wrote:
>  > On Mon, Dec 07, 2020 at 06:29:51PM +0100, Miro Hrončok wrote:  
>  >> Hello. Apparently, many packages in rawhide require libgnat-10.so()(64bit):  
>  > I'm not a provenpackager, so I'm afraid I can't do that myself.
>  > Perhaps the maintainers can just rebuild them themselves?  
>  And note that some of these are going to require fixes to the packages
>  themselves as the Ada front-end changed and some of them no longer
>  build.  IIRC zlib and templates_parser are the most important to get
>  rebuilt and I think those "just work".
>  
>  I'll try to get those rebuilt so that the downstream things have a
>  better chance of working :-) 
I'm rebuilding my packages now. Generally speaking, if someone who is
involved in GCC maintenance, and also has the necessary privileges,
would rebuild the Ada packages when GCC is upgraded, that would be
helpful.

I can also set off the rebuilds myself, but it really helps to be
notified when it's time. Some years I haven't noticed when a new GCC
landed in Rawhide, until the following mass rebuild started reporting
failures (because mass rebuilds aren't done in dependency order).

Long ago I used to get email notifications about uninstallable
packages. That was better than not being notified, but one email per
package was a little unnecessary. A single email would suffice.

This time I got eight separate Bugzilla issues, which all essentially
just served as notification that GCC has been upgraded, and each one
needs to be closed manually. That's manageable as long as the number of
Ada packages is small, but it still feels like unnecessary work.

Of course, if one of my packages is unbuildable (and it's not just
because its dependencies haven't been rebuilt yet), notify me and I'll
look into it. For that purpose a bug report in Bugzilla is appropriate.

Björn Persson

[Miro Hrončok]

On 12/8/20 10:26 AM, Björn Persson wrote:
>  This time I got eight separate Bugzilla issues, which all
> essentially
>  just served as notification that GCC has been upgraded, and each one
>  needs to be closed manually. That's manageable as long as the number of
>  Ada packages is small, but it still feels like unnecessary work. 
Note that the bugzillas also close automatically.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Björn Persson]

Miro Hrončok wrote:
>  On 12/8/20 10:26 AM, Björn Persson wrote:
>  > This time I got eight separate Bugzilla issues, which all essentially
>  > just served as notification that GCC has been upgraded, and each one
>  > needs to be closed manually. That's manageable as long as the number of
>  > Ada packages is small, but it still feels like unnecessary work.  
>  
>  Note that the bugzillas also close automatically. 
OK, that's better then. Apparently I've gotten used to automation not
doing that.

Björn Persson