Bug 1807737 - lzo 2.10-1 violates ISO C alias rules [NEEDINFO]
Summary: lzo 2.10-1 violates ISO C alias rules
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: lzo
Version: 32
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Huzaifa S. Sidhpurwala
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedFreezeException
Depends On:
Blocks: F32BetaFreezeException
TreeView+ depends on / blocked
 
Reported: 2020-02-27 05:20 UTC by Matt Fagnani
Modified: 2020-03-10 01:56 UTC (History)
8 users (show)

Fixed In Version: lzo-2.10-2.fc32
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-03-10 01:56:09 UTC
Type: Bug
belegdol: needinfo? (jakub)


Attachments (Terms of Use)
patch adding -fno-strict-aliasing to CFLAGS (1.49 KB, patch)
2020-03-01 12:26 UTC, Julian Sikorski
no flags Details | Diff

Description Matt Fagnani 2020-02-27 05:20:34 UTC
Description of problem:

I installed lzop-1.04-3.fc32.x86_64. Running lzop with or without a input file and lzo-2.10-1 showed that lzo failed to start due to a library version conflict.

lzop
                          Lempel-Ziv-Oberhumer Packer
                           Copyright (C) 1996 - 2017
lzop v1.04         Markus Franz Xaver Johannes Oberhumer         Aug 10th 2017

lzo_init() failed - check your LZO installation !
library version conflict (2080, 20a0) - check your LZO installation !

lzo-2.10-1.fc32 also failed to start when using openvpn with a server with the comp-lzo option specific in the configuration file.

Thu Feb 27 00:12:32 2020 NOTE: --fast-io is disabled since we are not using UDP
Thu Feb 27 00:12:32 2020 Cannot initialize LZO compression library
Thu Feb 27 00:12:32 2020 Exiting due to fatal error

These errors were reported at https://bugzilla.redhat.com/show_bug.cgi?id=1802299

Downgrading to lzo-2.08-16.fc31.x86_64 fixed the openvpn and lzop errors.

Version-Release number of selected component (if applicable):
lzo-2.10-1.fc32.x86_64
lzop-1.04-3.fc32.x86_64
openvpn-2.4.8-2.fc32.x86_64

How reproducible:
I've seen these errors each of several times.

Steps to Reproduce:
1. Boot F32 KDE Plasma spin installation
2. Log in to Plasma on Wayland from sddm
3. sudo dnf install lzop openvpn
4. run konsole
5. lzop
6. use openvpn to connect to an openvpn server with comp-lzo in its configuration file

Actual results:
lzo 2.10-1 failed to start due to a library version conflict when running lzop

Expected results:
lzop and openvpn would run normally

Additional info:
The lzo library version conflict with lzop was reported for patool at https://bugzilla.redhat.com/show_bug.cgi?id=1801248

Comment 1 Julian Sikorski 2020-03-01 10:08:53 UTC
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.

Comment 2 Julian Sikorski 2020-03-01 10:16:30 UTC
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.

Comment 3 Julian Sikorski 2020-03-01 10:41:19 UTC
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?

Comment 4 Julian Sikorski 2020-03-01 11:05:53 UTC
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.

Comment 5 Julian Sikorski 2020-03-01 12:26:02 UTC
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!

Comment 6 Julian Sikorski 2020-03-01 12:32:52 UTC
gcc bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=1808821

Comment 7 Matt Fagnani 2020-03-02 03:30:13 UTC
(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.

Comment 8 Michael Cronenworth 2020-03-02 16:20:54 UTC
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.

Comment 9 Adam Williamson 2020-03-05 21:52:29 UTC
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?

Comment 10 Kalev Lember 2020-03-05 22:18:18 UTC
+1 FE

Comment 11 Adam Williamson 2020-03-10 01:01:37 UTC
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

Comment 12 Fedora Update System 2020-03-10 01:29:49 UTC
FEDORA-2020-25291e492f has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-25291e492f

Comment 13 Fedora Update System 2020-03-10 01:56:09 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.