Any updates? Ideally we'd get this sorted out in Fedora 41, and time
is quickly running out...

Check for Fedora 40 system:
# repoquery --whatrequires libtiff.so.5 
InsightToolkit-0:4.13.3-15.fc39.i686

# repoquery --whatrequires 'libtiff.so.5()(64bit)'
Last metadata expiration check: 0:05:35 ago on Tue 30 Jul 2024 11:27:53 AM EDT.
InsightToolkit-0:4.13.3-15.fc39.x86_64
gimp-separate+-0:0.5.8-35.fc39.x86_64
megapixels-0:1.7.0-1.fc39.x86_64
python3-imagecodecs-0:2022.9.26-1.fc39.x86_64

all have .fc39. so they were not rebuild for F40


similar check for rawhide:
# repoquery --whatrequires 'libtiff.so.5()(64bit)'
InsightToolkit-0:4.13.3-15.fc39.x86_64
gimp-separate+-0:0.5.8-35.fc39.x86_64

again .fc39. packages

I'm going to "break" rawhide for now and create buildroot override for f40

rawhide version built:
https://koji.fedoraproject.org/koji/taskinfo?taskID=121250933

for future use:
gimp-separate+ can be rebuild with new libtiff.so.6 only version, just have to add these quick patches to solve FTBFS (not related to libtiff)

diff -up separate+-0.5.8/jpeg.c.signess separate+-0.5.8/jpeg.c
--- separate+-0.5.8/jpeg.c.signess      2024-07-30 12:01:14.475243571 -0400
+++ separate+-0.5.8/jpeg.c      2024-07-30 12:02:15.648243571 -0400
@@ -170,7 +170,7 @@ jpeg_write_image_data (j_compress_ptr ci
   gint i, x, y;
   GimpDrawable *drw[4];
   GimpPixelRgn region[4];
-  gchar *src_buf[4], *dst_buf[64];
+  guchar *src_buf[4], *dst_buf[64];
 
   drw[0] = separate_find_channel (imageID,sep_C);
   drw[1] = separate_find_channel (imageID,sep_M);
diff -up separate+-0.5.8/Makefile.linkmath separate+-0.5.8/Makefile
--- separate+-0.5.8/Makefile.linkmath   2024-07-30 12:07:44.112243571 -0400
+++ separate+-0.5.8/Makefile    2024-07-30 12:07:55.693243571 -0400
@@ -87,7 +87,7 @@ separate_import: $(IMPORT_OBJECTS)
        $(CC) $(LDFLAGS) $(IMPORT_OBJECTS) -o $@ $(LIBS)
 
 icc_colorspace: $(ICC_COLORSPACE_OBJECTS)
-       $(CC) $(LDFLAGS) $(ICC_COLORSPACE_OBJECTS) -o $@ $(LIBS)
+       $(CC) $(LDFLAGS) $(ICC_COLORSPACE_OBJECTS) -o $@ $(LIBS) -lm
 
 install-catalogs:
        cd po && $(MAKE) install

With buildroot override complete for Fedora 40, I've tried to run scratch builds:

gimp-separate+ will rebuild with libtiff unrelated FTBFS fix

megapixels will rebuild just fine https://koji.fedoraproject.org/koji/taskinfo?taskID=121259586

python-imagecodecs fails to rebuild, seems unrelated to libtiff
https://koji.fedoraproject.org/koji/taskinfo?taskID=121259691 
https://kojipkgs.fedoraproject.org//work/tasks/9810/121259810/build.log

InsightToolkit fails to rebuild, seems unrelated to libtiff
https://koji.fedoraproject.org/koji/taskinfo?taskID=121259587
https://kojipkgs.fedoraproject.org//work/tasks/9901/121259901/build.log

I see libtiff-4.6.0-5.fc40 was built and added as a buildroot override in https://bodhi.fedoraproject.org/overrides/libtiff-4.6.0-5.fc40

Please DO NOT push that update to Fedora 40. Please expire the override ASAP.

The update violates the update policy and breaks gimp-separate+ and InsightToolkit on a stable Fedora release and any users using the old .so.5* libraries.
Such disruptive change can only be done in Rawhide (or pre-beta Branched).

https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases


If you intend to proceed anyway, please get an ack from FESCo and use a side tag, not a buildroot override.

https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#updating_inter_dependent_packages

(In reply to Michal Hlavinka from comment #2)
> I'm going to "break" rawhide for now and create buildroot override for f40

Miro already commented on the F40 part.

While the rules for rawhide are less strict, dropping so.5 from libtiff should still have been announced on the devel mailing list with maintainers of dependent packages in cc. I could only find [1], which resulted in this bug. But that's not a proper soname bump notification.

This is essentially a (retroactive) soname bump, for which [2] applies.  

[1] Discussion titled "libtiff-4.6.0-2.fc40 continues to ship old .so.5* libraries", started on 29 May. Since Hyperkitty search is currently disabled, I cannot provide a link to the archive. 
[2] https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#_rawhide

I've removed buildroot override for now until the discussion is over.

Just a few notes:

The most important bit is that this does not replaces libtiff.so.5 with libtiff.so.6 in live fedora. This shipped both for a long time and this drops the .so.5 

libtiff updated to 4.5.0 on 2023-10 and kept .so.5 for transition period by previous maintainer.

This means that libtiff shipped .so.6 long before Fedora 40 was released, the lowest (dnf downgrade and what is present on ISOs) is 4.6.0 with .so.6
Anything that had a new build during F40 development cycle is fine. 

Anything that was/is/will be build using the libtiff from buildroot override is fine as it builds with .so.6 and that is what was in Fedora 40 a half a year before it was released.

The above is also a reason why side tag is not necessary because we don't switch from .so.5 to .so.6, the latter is present in all F40s and packages does not have to wait for new libtiff to land in F40, new builds are build using .so.6 anyway. There is no need to synchronize the updates. Actually it's not even needed to use build override except for showing intention in advance.

More about "why":
libtiff shipped  .so.5 for transition period that should had been much shorter. It does not build .so.5, it just carries binary blobs which is not ideal as it does not allow any fixes. Even security fixes that were fixed in libtiff are fixed only in .so.6 and packages using .so.5 still use old version that does not include fixes for CVE-2022-3570, CVE-2022-2867, CVE-2022-2868, CVE-2022-2869, CVE-2022-2519, CVE-2022-2953, CVE-2022-3597, CVE-2022-3598, CVE-2022-3599, CVE-2022-3626, CVE-2022-3627, CVE-2022-3970. Quite a lot, right? And that's just from .so.5(4.4.0) to .so.6(4.5.0) not including 4.6.0 update. This is really not ideal state and should be resolved.

Sandro: please see my comment above, this is not a soname bump. It was present in rawhide for a looong time. Anything that was hit with any mass rebuild is fine, .so.6 was in rawhide +- since start of F40 development cycle. Only FTBFS are affected. You can see that those two packages in rawhide are still .fc39.

I'm not saying the brokenness of libtiff shouldn't be fixed. I was suggesting to coordinate it better by creating awareness.

Your findings from comment 2 and comment 3 is what should have been sent to the mailing list to create that awareness. Instead, bugs like bug 2301800 were filed, which made me scratch my head when I saw it passing by. Only when stumbling upon this bug did it start to make sense.

That said, all the packages that haven't been rebuilt since F39, like InsightToolkit, do indeed need some attention.

gimp-separate+ ftbfs fix is easy, so I've created pull request with the fix
https://src.fedoraproject.org/rpms/gimp-separate+/pull-request/1 (rawhide)
https://src.fedoraproject.org/rpms/gimp-separate+/pull-request/2 (f40)

megapixels (f40) needs just a rebuild

I will look at python-imagecodecs ftbfs which seems it could be easy to fix

for InsightToolkit that will need maintainer's attention, I may have some more time to look into it later, but can't give specific timeframe nor promise

(In reply to Michal Hlavinka from comment #10)
> for InsightToolkit that will need maintainer's attention, I may have some
> more time to look into it later, but can't give specific timeframe nor
> promise

If possible, ITK should be updated to latest upstream release (5.4.0), which will be a major update and entails compatibility checks for the two consumers: alizams and petpvc.

I'm not the main admin of the package, but I'll take a shot at it as a member of neuro-sig. No promises from me either. But, one way or another, we should get this package fixed or retire it.

(In reply to Michal Hlavinka from comment #7)
> I've removed buildroot override for now until the discussion is over.

Thank you.

> The most important bit is that this does not replaces libtiff.so.5 with
> libtiff.so.6 in live fedora. This shipped both for a long time and this
> drops the .so.5 

This makes no difference. This *removes* libtiff.so.5 from a stable Fedora release. That should not be done.

> ...
> The above is also a reason why side tag is not necessary because we don't
> switch from .so.5 to .so.6, the latter is present in all F40s and packages
> does not have to wait for new libtiff to land in F40, new builds are build
> using .so.6 anyway. There is no need to synchronize the updates. Actually
> it's not even needed to use build override except for showing intention in
> advance.

I respectfully disagree. As long as 1 or more dependent packages need to be rebuilt/fixed/updated, this is a case of https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#updating_inter_dependent_packages and a side tag is necessary.

Of course, there are cases where some packages are inevitably broken and the update needs to be shipped anyway. Maybe even this is the case. However:

 - such cases are not acceptable for stable Fedora releases
 - such cases must be communicated loudly even in rawhide

> More about "why":
> libtiff shipped  .so.5 for transition period that should had been much
> shorter. It does not build .so.5, it just carries binary blobs which is not
> ideal as it does not allow any fixes. Even security fixes that were fixed in
> libtiff are fixed only in .so.6 and packages using .so.5 still use old
> version that does not include fixes for CVE-2022-3570, CVE-2022-2867,
> CVE-2022-2868, CVE-2022-2869, CVE-2022-2519, CVE-2022-2953, CVE-2022-3597,
> CVE-2022-3598, CVE-2022-3599, CVE-2022-3626, CVE-2022-3627, CVE-2022-3970.
> Quite a lot, right? And that's just from .so.5(4.4.0) to .so.6(4.5.0) not
> including 4.6.0 update. This is really not ideal state and should be
> resolved.

Security fixes are one of the reasons listed as a common case to grant a FESCo exception to break the update policy. It is however not a reason to go and violate the policy freely.

Also, note that the old .so.5 is available in the "fedora" repository in Feodra Linux 40 until the end of time, so removing it from the package in an update does not make it any more secure.

I agree this should have been done a long time ago. But Fedora 40 has sailed. I highly recommend biting the bullet and keeping the old so.5 there. If you disagree, please follow the procedure and request an exception from FESCo.

(In reply to Miro Hrončok from comment #12)
> I respectfully disagree. As long as 1 or more dependent packages need to be
> rebuilt/fixed/updated, this is a case of
> https://docs.fedoraproject.org/en-US/package-maintainers/
> Package_Update_Guide/#updating_inter_dependent_packages and a side tag is
> necessary.

To clarify: If the dependent packages were rebuilt to use .so.6 and shipped in separate updates landing in stable before this change was made, the side tag would have indeed not been necessary.

Let me state it again - fedora 40 as shipped on first day contained both .so.5 and .so.6 any package built in last half a year automatically uses .so.6 version. It does not have to wait for new libtiff build, it does not have to wait for other packages. If someone rebuilt the affected packages a week ago, they would use .so.6 without even being aware that there were shipped both. Same thing if someone rebuilds them week from now. Also if anyone build any piece of private sw using f40 sources even when it was still called rawhide half a year before F40 GA, it's using .so.6 too, so no impact here either. I agree with the part that side tag would be useful half a year ago as better solution than carrying old .so.5 but I was not libtiff maintainer back then and don't even know all reasons why this solution was used instead.

Anyway, while I disagree both on policy interpretation and technical details, I'm going to revert this change and keep fedora 40 as was before. The change will be resolved in rawhide only. For rawhide, I've created ftbfs fix pull requests for gimp-separate+ for maintainer/provenpackager. Only InsightToolkit needs to be fixed now.

As it seems this change is not allowed, closing as cantfix
previous change reverted in libtiff-4.6.0-6.fc40

https://koji.fedoraproject.org/koji/taskinfo?taskID=121286378
$ rpm -qlp libtiff-4.6.0-6.fc40.x86_64.rpm | grep .so.5
/usr/lib64/libtiff.so.5
/usr/lib64/libtiff.so.5.8.0
/usr/lib64/libtiffxx.so.5
/usr/lib64/libtiffxx.so.5.8.0

(In reply to Michal Hlavinka from comment #14)
> Let me state it again - fedora 40 as shipped on first day contained both
> .so.5 and .so.6 any package built in last half a year automatically uses
> .so.6 version.

Agreed.

> It does not have to wait for new libtiff build, it does not
> have to wait for other packages.

What does not have to wait?

> If someone rebuilt the affected packages a
> week ago, they would use .so.6 without even being aware that there were
> shipped both.

Agreed.

> Same thing if someone rebuilds them week from now.

Agreed.

> Also if
> anyone build any piece of private sw using f40 sources even when it was
> still called rawhide half a year before F40 GA, it's using .so.6 too, so no
> impact here either.

Agreed.

> I agree with the part that side tag would be useful half
> a year ago as better solution than carrying old .so.5 but I was not libtiff
> maintainer back then and don't even know all reasons why this solution was
> used instead.

Understood.

> Anyway, while I disagree both on policy interpretation and technical
> details...

I don't really understand where is the disagreement coming from. I agree with every technical aspect you said. Why do you disagree with what I say?

Anyway, I might be wrong. I am not the arbiter of the policy. I am merely presenting my opinion based on 10+ years of experience following the policy and 5 years of experience maintaining it. When in doubt, ask FESCo.

> I'm going to revert this change and keep fedora 40 as was before.

Thank you.

> The change will be resolved in rawhide only. For rawhide, I've created ftbfs
> fix pull requests for gimp-separate+ for maintainer/provenpackager. Only
> InsightToolkit needs to be fixed now.

Ok then. Let's say this BZ was actually fixed, but only for rawhide, OK?