Bug 1807737

I tried rebuilding lzop against lzo-2.10 but it did not help surprisingly. I am not sure where the version check is being hardcoded.

Correction: rebuilding against lzo-2.10 has taken care of the library version conflict error, but not the lzo_init one.
The error was being highlighted during make check:
https://bugzilla.redhat.com/show_bug.cgi?id=1799624#c4
It appears disabling make check was not the way to go after all.

Compiling lzo with -01 instead of -02 fixes the initialization issue. Together with rebuilding lzop against lzo-2.10 it allows lzop to run:

<mock-chroot> sh-5.0# lzop
                          Lempel-Ziv-Oberhumer Packer
                           Copyright (C) 1996 - 2017
lzop v1.04         Markus Franz Xaver Johannes Oberhumer         Aug 10th 2017

Usage: lzop [-dxlthIVL19] [-qvcfFnNPkUp] [-o file] [-S suffix] [file..]

Commands:
  -1     compress faster                   -9    compress better
  -d     decompress                        -x    extract (same as -dPp)
  -l     list compressed file              -I    display system information
  -t     test compressed file              -V    display version number
  -h     give this help                    -L    display software license
Options:
  -q     be quiet                          -v       be verbose
  -c     write on standard output          -oFILE   write output to 'FILE'
  -p     write output to current dir       -pDIR    write to path 'DIR'
  -f     force overwrite of output files
  -n     do not restore the original file name (default)
  -N     restore the original file name
  -P     restore or save the original path and file name
  -S.suf use suffix .suf on compressed files
  -U     delete input files after successful operation (like gzip and bzip2)
  file.. files to (de)compress. If none given, try standard input.
<mock-chroot> sh-5.0# 

I unfortunately do not have commit access to neither lzo nor lzop.
Jakub, would you be able to investigate why -O2 breaks lzo?

I am running a script trying to determine which of the flags added by -O2 is causing trouble, will report back once the script finishes.

Created attachment 1666748 [details]
patch adding -fno-strict-aliasing to CFLAGS

The attached patch fixes the problem, lzop rebuild is not necessary after all. Could someone with commit access to lzo apply it? Thank you!

gcc bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=1808821

(In reply to Julian Sikorski from comment #5)
> Created attachment 1666748 [details]
> patch adding -fno-strict-aliasing to CFLAGS
> 
> The attached patch fixes the problem, lzop rebuild is not necessary after
> all. Could someone with commit access to lzo apply it? Thank you!

Thanks Julian. I ran fedpkg clone --anonymous lzo, and then I applied the changed in your patch. I built lzo-2.10-2 with fedpkg --release f32 local
and updated lzo with dnf. lzop and openvpn ran correctly with lzo-2.10-2 installed.

I'm pushing out an update with the new CFLAG as this breaks anything trying to use lzo.

Upstream needs to fix their code so I'm leaving this bug open.

Proposing as an FE issue, per Michael Cronenworth's email:

"Hello,

The following update needs some karma so it can be released sooner than 12 days from 
now.

https://bodhi.fedoraproject.org/updates/FEDORA-2020-25291e492f

The lzo package was updated last month from 2.08 (dated 2014) to 2.10 (dated 2017). 
Part of the code in the new version is not properly written to work with gcc 
aliasing and the resulting binary does not work.

I've applied a workaround (disabling gcc strict aliasing) until the maintainer or 
upstream fixes it.

Bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1807737

Thanks,
Michael"

However, note that 'released' is somewhat fuzzy for Branched. updates-testing is enabled by default on Branched installs, so the first time an F32 install with lzo is updated, it will get the fixed lzo even though it has not been pushed to stable yet. We are more likely to grant an FE if lzo may be used during composes, or on live images, or something like that. Is this the case?

+1 FE

Discussed during the 2020-03-09 freeze exception review meeting: [0]

Accepted as a freeze exception issue as we believe it will break LZO-based OpenVPN connections in live sessions.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2020-03-09/f32-blocker-review.2020-03-09-16.01.txt

FEDORA-2020-25291e492f has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-25291e492f

lzo-2.10-2.fc32 has been pushed to the Fedora 32 stable repository. If problems still persist, please make note of it in this bug report.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days