[MDEV-12693] FTBFS, download of Libarchive Created: 2017-05-04  Updated: 2017-05-05  Resolved: 2017-05-05

Status: Closed
Project: MariaDB Server
Component/s: Server
Affects Version/s: 10.1.23
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Michal Schorm Assignee: Sergei Golubchik
Resolution: Not a Bug Votes: 0
Labels: None
Environment:

Fedora - all


 Description   

Hello,
I got a trouble building MariaDB for Fedora.
The compilation process fails at this point:

-- downloading...
 
       src='http://www.libarchive.org/downloads/libarchive-3.2.2.tar.gz'
 
       dst='/builddir/build/BUILD/mariadb-10.1.23/extra/mariabackup/libarchive/libarchive-3.2.2.tar.gz'
 
       timeout='none'
 
error: downloading 'http://www.libarchive.org/downloads/libarchive-3.2.2.tar.gz' failed
 
  status_code: 6
 
  status_string: "Couldn't resolve host name"
 
  log:
 
  --- LOG BEGIN ---
 
  Could not resolve host: www.libarchive.org
 
Closing connection 0
 
  --- LOG END ---
 
CMake Error at libarchive-stamp/download-libarchive.cmake:161 (message):
 
  Downloading failed
 
extra/mariabackup/CMakeFiles/libarchive.dir/build.make:92: recipe for target 'extra/mariabackup/libarchive/src/libarchive-stamp/libarchive-download' failed

It is caused by settings of our buildservers - which does not allow connection to the internet in the build process, to prevent application download uknown or malicious code.

Which is exactly this case.
In Fedora, we already have Libarchive, and I would want to use it instead
https://admin.fedoraproject.org/pkgdb/package/rpms/libarchive/

 Comments   
Comment by Sergei Golubchik [ 2017-05-04 ]

The logic on the cmake file is:

  • try to find system libarchive
    • if found and the user has not disabled libarchive, use system
    • if not found and the user requested libarchive to be used, download and built it

Did you have libarchive (and libarchive-devel, I'd guess) installed when you got that error above?

Comment by Vladislav Vaintroub [ 2017-05-04 ]

well, the logic can be more complicated if someone if using -DBUILD_CONFIG=mysql_release.
then, if it is neither DEB or RPM, we assume WITH_LIBARCHIVE=STATIC, and then if static library is not found, we download and build.
Maybe we need to change this static lookup logic.
Or Maybe Fedora should not be using -DBUILD_CONFIG=mysql_release.
Or maybe Fedora should use -DWITH_LIBARCHIVE=ON to lookup for shared libraries first.
Or maybe Fedora should use -DWITH_LIBARCHIVE=OFF, and then there is no libarchive dependency.
Or maybe Fedora should be using -DRPM=1 and have libarchive-dev /devel installed

There is a lot of options, I'm not sure which one is right here. But it is definitely possible to avoid static linking, and this is what is done by default, in case people are not using -DBUILD_CONFIG=mysql_release

Comment by Vladislav Vaintroub [ 2017-05-04 ]

And no, it is not unknown or malicious code

Comment by Michal Schorm [ 2017-05-05 ]

Thanks, Sergei.
I solved it just by adding it as a BuildRequires.

Vladislav:
Seems solved now, but I'll check your comment about CMake flags again, if I encounter some issue with it.

Vladislav:
Depends. Surely not malicious But that is exactly what I call 'unknown' code, when it is just downloaded by the build time

That's why I checked the website as the first step and then Fedora packages databse as a second step.
For Fedora, if I wouldn't find the package already packed, the correct process would be me beginning to pack it as a new package and maintain it.

Comment by Sergei Golubchik [ 2017-05-05 ]

Thanks, closing.

mschorm, you might still want to double check that only mariabackup package has got libarchive run-time dependency, all other packages should be unaffected. We've had users complaining when on upgrade an rpm (our rpm, I mean) suddenly gets new dependency in a GA version. Your users are probably picky too

Generated at Thu Feb 08 07:59:42 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.