#3815 I need to build tk-8.5.8-1.fc13 against tcl-8.5.8-1.fc13 (dist-f13-updates-candidate)
Closed: Fixed None Opened 9 years ago by jskarvad.

I would like to push tcl/tk update through Bodhi for F13, but I cannot build the tk-8.5.8-1.fc13, because it needs tcl-8.5.8-1.fc13 (exact version) and tcl-8.5.8-1.fc13 is tagged as dist-f13-updates-candidate. It seems that there is no other package in the stable repo that depends on exact version of tcl/tk, thus this update should be safe (I hope ;)

Latest build of tcl-8.5.8-1.fc13:
https://koji.fedoraproject.org/koji/buildinfo?buildID=178077

Failed build of tk-8.5.8-1.fc13:
https://koji.fedoraproject.org/koji/buildinfo?buildID=178179

Thanks for help.


Tagged, let me know when the build is done.

Tagged, let me know when the build is done.

This override tag has been left for over 2 weeks without tk being built.

It is prevent ruby and python-mako, etc from building in dist-f13.

Can we please resolve this ASAP.

This override tag has been left for over 2 weeks without tk being built.

It is prevent ruby and python-mako, etc from building in dist-f13.

Can we please resolve this ASAP.

I can't currently build F-13 packages due to the combination of the override and incomplete tk update. See the root.log:

https://koji.fedoraproject.org/koji/taskinfo?taskID=2278881

I can't currently build F-13 packages due to the combination of the override and incomplete tk update. See the root.log:

https://koji.fedoraproject.org/koji/taskinfo?taskID=2278881

Also what is the argument/requirement for upgrading tcltk in F13?
It may break many dependencies and require a lot of rebuilds
of other packages.

Also what is the argument/requirement for upgrading tcltk in F13?
It may break many dependencies and require a lot of rebuilds
of other packages.

By this update I am trying to resolve this one: https://bugzilla.redhat.com/show_bug.cgi?id=560516 and probably more similar issues.
Are you sure it will break more packages? From the repoquery only the tk requires exact N-V-R of tcl.

I asked for the override tag yesterday.

The situation now:
there is tcl-8.5.8-1.fc13 in dist-f13-updates-candidate
and tk-8.5.8-1.fc13 is not build.

I asked previous tcl/tk maintainer about this situation and he replied that he did such a update. In case such update is not possible/risky I can revert/retag/rebuild tcl/tk-8.5.7. Please let me know.

By this update I am trying to resolve this one: https://bugzilla.redhat.com/show_bug.cgi?id=560516 and probably more similar issues.
Are you sure it will break more packages? From the repoquery only the tk requires exact N-V-R of tcl.

I asked for the override tag yesterday.

The situation now:
there is tcl-8.5.8-1.fc13 in dist-f13-updates-candidate
and tk-8.5.8-1.fc13 is not build.

I asked previous tcl/tk maintainer about this situation and he replied that he did such a update. In case such update is not possible/risky I can revert/retag/rebuild tcl/tk-8.5.7. Please let me know.

Ok sorry I guess I was over-reacting... (got confused by the build date)
though it is not good to have the buildroots in a broken state like this, but may be unavoidable with timezones, etc: we really need more release-engineers in different timezones...

Ok sorry I guess I was over-reacting... (got confused by the build date)
though it is not good to have the buildroots in a broken state like this, but may be unavoidable with timezones, etc: we really need more release-engineers in different timezones...

There are a couple problems under discussion. The first is that people (including me) had builds breaking as a result of the override. Apparently tk/tcl gets pulled in to lots of stuff, so we need to coordinate a little better and keep the window tight and minimize disruption to others. A little warning to the fedora-devel list would do. As it stands, some Python and Ruby packaging came to a halt with several packagers affected.

Second, there are concerns that this is an ABI change inside a stable release. That would be very unusual. An ABI change would potentially break user programs linked against tk/tcl as well as force a rebuild of anything inside Fedora 13 that links against them (Requires).

It's also possible that the Requires or something about the spec files in tk and tcl are incorrect and no ABI change is actually happening. I haven't had time to look and see, but something might just be set too strictly. I'm not familiar with tk/tcl, but a patch release from 8.5.7 to 8.5.8 in other projects would rarely if ever include an ABI-incompatible change. We should get additional eyes on that.

There are a couple problems under discussion. The first is that people (including me) had builds breaking as a result of the override. Apparently tk/tcl gets pulled in to lots of stuff, so we need to coordinate a little better and keep the window tight and minimize disruption to others. A little warning to the fedora-devel list would do. As it stands, some Python and Ruby packaging came to a halt with several packagers affected.

Second, there are concerns that this is an ABI change inside a stable release. That would be very unusual. An ABI change would potentially break user programs linked against tk/tcl as well as force a rebuild of anything inside Fedora 13 that links against them (Requires).

It's also possible that the Requires or something about the spec files in tk and tcl are incorrect and no ABI change is actually happening. I haven't had time to look and see, but something might just be set too strictly. I'm not familiar with tk/tcl, but a patch release from 8.5.7 to 8.5.8 in other projects would rarely if ever include an ABI-incompatible change. We should get additional eyes on that.

I poked around in tcl a bit and found this in the devel package:

/usr/lib64/tclConfig.sh

It's a sh file that can be sourced to get all kinds of information about how tcl was compiled. At a glance, it looks like we may want to come up with an RPM recipe to source %{_libdir}/tclConfig.sh and pull out the TCL_VERSION variable for use in the ABI-related Provides line or, more importantly, the ABI version that packages which link against tcl require.

I poked around in tcl a bit and found this in the devel package:

/usr/lib64/tclConfig.sh

It's a sh file that can be sourced to get all kinds of information about how tcl was compiled. At a glance, it looks like we may want to come up with an RPM recipe to source %{_libdir}/tclConfig.sh and pull out the TCL_VERSION variable for use in the ABI-related Provides line or, more importantly, the ABI version that packages which link against tcl require.

I helped jskarvad build tk-8.5.8 last night (in a tight real-time window) so that should be ok now.

Yeah I think the ABI should be ok for subminor tcltk releases, but good to check of course.

Well our tcl rpm already provides "tcl(abi)":

$ rpm -q --provides tcl
libtcl8.5.so()(64bit)
tcl(abi) = 8.5
tcl-tcldict = 8.5.7
tcl = 1:8.5.7-6.fc13
tcl(x86-64) = 1:8.5.7-6.fc13

that should be good enough.

Some kind of SOP for version upgrades might well be a good idea if it doesn't already exist.

I helped jskarvad build tk-8.5.8 last night (in a tight real-time window) so that should be ok now.

Yeah I think the ABI should be ok for subminor tcltk releases, but good to check of course.

Well our tcl rpm already provides "tcl(abi)":

$ rpm -q --provides tcl
libtcl8.5.so()(64bit)
tcl(abi) = 8.5
tcl-tcldict = 8.5.7
tcl = 1:8.5.7-6.fc13
tcl(x86-64) = 1:8.5.7-6.fc13

that should be good enough.

Some kind of SOP for version upgrades might well be a good idea if it doesn't already exist.

Metadata Update from @jskarvad:
- Issue assigned to jkeating

2 years ago

Login to comment on this ticket.

Metadata