Hello, for testing, I have released FMW 4.0.95. To accommodate the changes I'll list below you can use that, however I'd like to ship 4.1.0 (when it's done) as the release for F26.
Homebrew ( https://brew.sh/ ) or an other package manager is required. Use it to install xz (to provide /usr/lib/liblzma.dylib and the required headers).
It's then necessary to include the liblzma.dylib file inside the package (in Contents/Frameworks) and change the rpath pointing at it with install_name_tool. See https://github.com/MartinBriza/MediaWriter/blob/master/dist/mac/build.sh#L38 to see how it's done. No special signing is required for this file. If you're using macdeployqt with the --always-overwrite argument, you need to stop using it or the compose will fail.
It's necessary to build using F26 or Rawhide. There is a multitude of bugs solved by updating to Qt 5.7.1 which is now included only in F26 and above.
No extra build steps are required, however there's more dynamic libraries to include in the package. See https://github.com/MartinBriza/MediaWriter/blob/master/dist/win/build.sh#L34 .
Also please note that when your code signing certificate for Windows expires, it's now necessary to get a "secure flash drive" from Unizeto with a new one, making it now more than €100 instead of €14 - we should probably change the certificate provider.
I really thinkwWe need to build xz as part of the osx build. I am not comfortable pulling down random bits from the internet.
Well that's a possibility too. We can just build it once and leave it anywhere, updating it only if there's a new bugfix version. Actually, I think if you install the library to the default prefix, qmake will find it without any modification.
@mbriza The xz libraries are provided by macOS, aren't they? I see liblzma.5.dylib on my macOS 10.12 machine.
liblzma.5.dylib
Hmm, I'd have to check but I'm pretty sure they're not.
So I checked on my system and yes, there's a liblzma.dylib file. However, it's an old version and I don't see a way how to get the headers for it. If we could be sure there's the same version everywhere and they won't update it, we could go for it, however it seems a bit safer to go with our own version from my point of view.
To revisit this problem. I checked it and I think brew usage is fine - it does build the actual package on your machine. It works a lot like AUR. To be completely sure we can set HOMEBREW_BUILD_FROM_SOURCE=1 . See http://docs.brew.sh/FAQ.html for a bit more detail on this.
For Windows, there can also be a change to the way the binaries are signed:
osslsigncode sign -pkcs12 $CERTIFICATE_PFX -readpass "$PASSPHRASE" -h sha256 -n "Fedora Media Writer" -i https://getfedora.org -t http://timestamp.verisign.com/scripts/timstamp.dll -in "$BINARY" -out "$BINARY.signed"
looking at brew it defaults to pulling prebuilt binaries in.
there is a --build-from-source flag to have it build from source
--build-from-source
I made a change
Fedoras-Mac-mini:homebrew-core fedorareleng$ cd /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/ Fedoras-Mac-mini:homebrew-core fedorareleng$ git diff diff --git a/Formula/xz.rb b/Formula/xz.rb index ade1e54..ae8c62a 100644 --- a/Formula/xz.rb +++ b/Formula/xz.rb @@ -3,9 +3,9 @@ class Xz < Formula desc "General-purpose data compression with high compression ratio" homepage "https://tukaani.org/xz/" - url "https://downloads.sourceforge.net/project/lzmautils/xz-5.2.3.tar.gz" - mirror "https://tukaani.org/xz/xz-5.2.3.tar.gz" - sha256 "71928b357d0a09a12a4b4c5fafca8c31c19b0e7d3b8ebb19622e96f26dbf28cb" + url "https://src.fedoraproject.org/lookaside/pkgs/xz/xz-5.2.3.tar.xz/sha512/a5b8f3c402ec3df5c1875a32081136606dd7701190d8b8091bae1bac36553ebe3480985c8069bf5d9e24f374ea64b1fe22614d3eebac1c10e5d609701bceca95/xz-5.2.3.tar.xz" + mirror "https://src.fedoraproject.org/lookaside/pkgs/xz/xz-5.2.3.tar.xz/sha512/a5b8f3c402ec3df5c1875a32081136606dd7701190d8b8091bae1bac36553ebe3480985c8069bf5d9e24f374ea64b1fe22614d3eebac1c10e5d609701bceca95/xz-5.2.3.tar.xz" + sha256 "7876096b053ad598c31f6df35f7de5cd9ff2ba3162e5a5554e4fc198447e0347" bottle do cellar :any
and verified that it built the binaries from sources pulled from Fedora. I am not sure it is a completely suitable long term solution
To me, this still seems easier than fetching it as a part of the build script and building it manually.
@dgregor I would like to sit down and figure out our long term mac build strategy
Metadata Update from @ausil: - Issue assigned to dgregor
@dgregor, @mohanboddu will talk to you about this.
Metadata Update from @syeghiay: - Issue assigned to mohanboddu (was: dgregor)
Closing this ticket. Infrastructure is taking over this responsibility for now.
Metadata Update from @syeghiay: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)