Invalid symlinks for libungif.so and libungif.a

Status changed to 'Confirmed' because the bug affects multiple users.

This bug was fixed in the package giflib - 5.1.1-0ubuntu1

---------------
giflib (5.1.1-0ubuntu1) xenial; urgency=medium

  * New upstream version.
  * Enable parallel builds.
  * Build-depend on xmlto.
  * Don't ship broken libungif symlinks. Closes: #732272. LP: #1337898.

 -- Matthias Klose <email address hidden> Wed, 21 Oct 2015 16:28:17 +0200

Are there any plans to backport this change to giflib-4.1.6-11 on trusty? Considering that trusty is still going to be supported for more than three years, it might make sense to backport this bugfix.

I see

# ls -l libung*
0 lrwxrwxrwx 1 root root 8 Dec 16 2013 libungif.a -> libgif.a
0 lrwxrwxrwx 1 root root 9 Dec 16 2013 libungif.la -> libgif.la
0 lrwxrwxrwx 1 root root 15 Dec 16 2013 libungif.so -> libgif.so.4.1.6

after

# aptitude reinstall libgif-dev
The following packages will be REINSTALLED:
  libgif-dev
0 packages upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 4 not upgraded.
Need to get 0 B/20.3 kB of archives. After unpacking 0 B will be used.
(Reading database ... 260156 files and directories currently installed.)
Preparing to unpack .../libgif-dev_4.1.6-11_amd64.deb ...
Unpacking libgif-dev (4.1.6-11) over (4.1.6-11) ...
Setting up libgif-dev (4.1.6-11) ...

@sds: Yes, they exist, but in /usr/lib, while they should be in /usr/lib/x86_64-linux-gnu (depending on the platform). As libgif.* is not in /usr/lib, the symbol links point to files that do not exist.

debdiff attached for sponsoring

Is there any actual impact to Trusty users, please? Or is this just tidying up some dangling symlinks for the sake of it?

The "Impact" section in the bug whiteboard is supposed to contain this information for an SRU, but right now it seems to contain a technical description of what is wrong rather than describing any actual impact to users.

I updated the Impact and Test Case sections of this bug's description. I hope this better fits the purpose of describing the actual impact on users.

Uploaded, thanks!

I made the following minor changes:

1. I ran update-maintainer. Please see https://wiki.ubuntu.com/DebianMaintainerField

2. I adjusted the package version string to 4.1.6-11ubuntu0.14.04.1 because 4.1.6-11 also exists in Vivid. Though that's EOL on desktop, it lives on phone at the moment (and so does appear on Launchpad's summary page for the package). I don't want to make it awkward to update giflib on Vivid for the phone side. Though it seems unlikely and it probably doesn't use that package, at least this way we're consistent. See https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging.

Convention is to use a "-p1" patch, which is what debdiffs produce. Please try to do this when submitting patches, since it makes sponsoring a little easier.

Now awaiting SRU team review.

Hello Sebastian, or anyone else affected,

Accepted giflib into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/giflib/4.1.6-11ubuntu0.14.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

I tested the package from trusty-proposed, but I am not sure whether the issue can be considered fixed.

In fact, the dangling symlinks have been removed, but they have not been added in the right place. This means that software depending on libungif will still not compile.

The question is, whether this is by intention: Should libgif provide an alias for libungif (because it effectively provides the functionality of libungif) or is it an intentional choice not to provide libungif and should all software depending on it be changed to depend on libgif instead?

Thank you for testing this.

I accepted the SRU on the assumption that "Linking programs that need libungif ("-lungif") will fail" would be fixed. In other words, that "-lungif" in the test case would now succeed. If this is not the case, then I think the SRU is pointless and that we shouldn't release it.

Jeremy, any opinion?

> I accepted the SRU

I forgot which hat I was wearing. I sponsored it and Brian SRU-reviewed/accepted it. But my opinion is still the same.

Oh, maybe the test case is wrong. This SRU is the same fix as was done in Debian's 5.1.1 (present in Xenial) to "not ship broken symlinks".

See https://bugs.debian.org/732272 and comment #2

On Mon, Mar 06, 2017 at 12:47:20PM -0000, Jeremy Bicha wrote:
> Oh, maybe the test case is wrong. This SRU is the same fix as was done
> in Debian's 5.1.1 (present in Xenial) to "not ship broken symlinks".
>
> See https://bugs.debian.org/732272 and comment #2

Different considerations apply to the development release, of course.

But if that is what is proposed to be done in Trusty, why is the SRU
needed at all? This "fix" won't solve anything for the user, will it?

Let's treat this as verification-failed, unless someone can give us a good reason that this does need to land in Trusty.

I guess there is only one case where the current "fix" would help. If someone had some library providing libungif in a different place, the broken symlinks in /usr/lib might take precedence, thus hiding the correct files.

In my opinion, removing the dangling symlinks is a slight improvement on the current situation and the risk of breaking something is very low. On the hand, I do not know whethere there are other considerations regarding a SRU in addition to the potential for regressions (which is low in this case).

Oh, now I know why the test case looked funny to me. The bug was updated because you didn't like the original, accurate impact and test case.

https://bugs.launchpad.net/ubuntu/+source/giflib/+bug/1337898/+activity

Sure, it's low priority but the fix isn't wrong.

On Mon, Mar 06, 2017 at 01:27:14PM -0000, Sebastian Marsching wrote:
> I guess there is only one case where the current "fix" would help. If
> someone had some library providing libungif in a different place, the
> broken symlinks in /usr/lib might take precedence, thus hiding the
> correct files.

Do we know if anyone has reported this case?

> In my opinion, removing the dangling symlinks is a slight improvement on
> the current situation and the risk of breaking something is very low. On
> the hand, I do not know whethere there are other considerations
> regarding a SRU in addition to the potential for regressions (which is
> low in this case).

The risk may be low but it is non-zero. If we don't know of any user
impacted, I don't think there is any justification for an SRU.

> Sure, it's low priority but the fix isn't wrong.

Sure, but that's something for the development release. In the stable
release, I think we need a better reason (such as non-hypothetical
affected users).

As part of a recent change in the Stable Release Update verification policy we would like to inform that for a bug to be considered verified for a given release a verification-done-$RELEASE tag needs to be added to the bug where $RELEASE is the name of the series the package that was tested (e.g. verification-done-xenial). Please note that the global 'verification-done' tag can no longer be used for this purpose.

Thank you!

> Oh, now I know why the test case looked funny to me.
> The bug was updated because you didn't like the original,
> accurate impact and test case.

But I don't see that anyone has taken the initiative to correct that test case, and the bug is still marked verification-failed.

I'm therefore removing this package from trusty-proposed, after 4 months with no further activity.