Packaging: Create RPM package task for Fedora, etc. #33
Comments
binwiederhier
modified the milestones:
Release 0.2 (public beta),
Release 0.1 (developer alpha)
|
There is currently no demand for rpm packages. As soon as there is another request, we can re-open this issue. |
|
We would like to test syncany but we run only Fedora/RHEL/Centos so an rpm would be appreciated. |
|
We could help configuring and testing it, no problem. |
|
Feel free to package it yourself :D |
|
You can always test it with the Docker instance: |
binwiederhier
changed the title
|
@Conan-Kudo |
|
@binwiederhier Working on figuring out how to use Gradle in an RPM specfile consistent with Fedora guidelines right now, actually. So yes, I do. |
|
Have you seen the Debian stuff yet? It might/will really help. See #261. |
|
Yeah, I checked it out. I've made a variant of the dependency chart to show what is and what isn't in Fedora right now. I'd appreciate a double-check on the dependencies to be sure that the list is complete. Missing dependencies will need to be packaged first before tackling syncany itself, of course. Build Dependencies
Test Dependencies
Application Dependencies
I'm a bit concerned about bouncycastle
Edit: Gradle is F22+ only, so Syncany will be introduced as an F22+ package. |
|
Thanks for the great work. This goes hand to hand of what @ReAzem is doing for Debian in #261. Here's what I think:
|
|
Fedora's policy states that the package must be buildable from source, so using Gradle is mandatory as a build requirement (which is a special type of requirement for RPMs). As for bouncycastle, I'll see if I can poke the maintainer of the package to push an update to 1.51. Is there a similar issue with undertow? |
|
Apologies for forgetting Undertow: I remember that we had some tiny issues with Undertow, and upgrading fixed it. I can't remember what it was though. Can you test it and see if it works? |
|
I'll give it a go if the package maintainer for undertow is unable to update it after I request it. |
|
Undertow is already in the process of being upgraded to 1.1.0.Final, so I've added the Red Hat Bugzilla reference for that. Gradle (and building Java packages from source code that use it) is a new feature for Fedora 22, so it won't be backported to Fedora 21. |
|
I've now submitted the package for jsemver for review. |
|
@Conan-Kudo nice! |
|
@binwiederhier I wasn't aware that apache httpcomponents-client and google-gson are required for syncany to function. What are the minimum versions for those that can be used with syncany? And if they are required, then @ReAzem needs to know for #261. |
|
Apparently, Undertow 1.1.0.Final was introduced into Fedora 22+ last month, and has filtered down to repositories already. |
|
@Conan-Kudo HttpComponents and Gson were added recently. I must have forgotten to add it here and in #261.
|
|
Undertow definitely has a HTTP client library. As always, though, it's completely undocumented, but there is an example: https://github.com/undertow-io/undertow/blob/master/core/src/test/java/io/undertow/client/http/HttpClientTestCase.java |
|
@binwiederhier: We're okay on httpcomponents, but the version of gson provided in Fedora is 2.2.4, not 2.3. Also, I didn't know about mockito and htmlunit until 3 days ago, and it turns out the versions you require aren't in Fedora yet, either. Are you using anything specific that requires versions newer than mockito 1.9 and htmlunit 2.9? If not, could you downgrade the required versions in the gradle files? Also, keep an eye on the chart. I do update it with state of dependency availability. |
|
As an alternative you could patch the gradle files via the RPM spec file (assuming syncany runs with the lower versions) |
|
@Conan-Kudo htmlunit and mockito are test dependencies. I don't think you need to worry about them. |
|
@binwiederhier As a rule, Java packages being built for Fedora (and most distros, actually) require that the test frameworks are used at build time to ensure correctness of the code. The reason for it is because in the event there's some patching that may have to be done to syncany or its dependencies, the tests verify the code doesn't break from it. So unfortunately, I do have to worry about them. @jaltek I'd really, really, really want to avoid doing that if I can. Patching the build system is uncomfortable because it's a brittle fix. And specifically with gson, it's not even being used yet, so that's a dependency version that could be lowered now. As for mockito and htmlunit, I would prefer if the actual people writing the code lowered the version requirement because they'd know if it'd work or not. I'm still working on getting bouncycastle updated in Fedora 22... |
|
I introduced both, gson and htmlunit, as dependencies. I need to evaluate if we can lower the deps. |
|
@cr0 Apparently, per Fedora's updates policy, now that Fedora 22 is on its way to becoming the next stable release (it releases at the end of this month), gson cannot be updated from 2.2.4. I imagine this will also apply to mockito and htmlunit too. All but htmlunit have already been updated in rawhide to the newer releases, but that code is intended to become Fedora 23 this fall. @binwiederhier I'm trying to use the specific bug in 1.50 you've identified to push for fc22 to receive an update for bouncycastle (or at least a backported fix). Hopefully I'll be successful. I've filed a bug in the Red Hat Bugzilla about it, and I appreciate if you would post clarifications there if I didn't do a great job explaining the issue. |
|
https://sites.google.com/site/gson/gson-roadmap (probably downgradable) I'll try to downgrade them tonight while watching the cl ;) |
|
@cr0 mockito moved to GitHub and development started all over again, which is why most distros don't have a newer version of mockito than 1.9: https://github.com/mockito/mockito/blob/master/doc/release-notes/official.md Thanks for trying this! |
|
@binwiederhier So apparently the fix from bouncycastle-1.51 was backported to 1.50 for Fedora 22. I should be able to build against 1.50, right? |
|
@Conan-Kudo awesome! Building against it is no problem. This was just a runtime issue with encrypting small files iirc. |
|
Some update: We can downgrade gson, however, it is not possible to downgrade htmlunit to 2.9 since it missing some essential javascript features which are used during the I cannot say anything about mockito because I don't know what it's doing... |
|
@cr0 Well, downgrading gson will make all runtime dependencies in a state where Syncany will function in Fedora 22, so that helps a lot. I'm going to check and see if there's precedent for making exceptions because the test suites won't work... @binwiederhier Apparently, there's yet another test framework (system-rules) that's required. At least this one isn't packaged, so I can take a look at packaging it at the newest version. |
|
@binwiederhier Apparently, system-rules uses dependencies not available in Fedora. Version 1.7 and lower is not doable because one of the dependencies requires non-OSS code to build. Version 1.8 and up require the newer mockito version instead, which is also not in Fedora 22 (but it is in Fedora Rawhide for Fedora 23). I'm not too up to date on Debian Packaging Policy, but it sounds like this will hurt efforts on that side too. But, as I mention below, I'm not too worried about it for Fedora 22. @cr0 It turns out that I can indeed disable tests due to unmet dependencies, so as long as syncany's google-gson dependency requirement is lowered to 2.2.4, then I can start working on packaging it for Fedora. I'll just disable tests for Fedora 22 and enable them for rawhide (Fedora 23+) once dependencies for that can be satisfied. |
|
Ok then, downgrade will happen this evening. On 7. Mai 2015 16:19:52 MESZ, Conan-Kudo notifications@github.com wrote:@binwiederhier Apparently, system-rules uses dependencies not available in Fedora. Version 1.7 and lower is not doable because one of the dependencies requires non-OSS code to build. Version 1.8 and up require the newer mockito version instead, which is also not in Fedora 22 (but it is in Fedora Rawhide for Fedora 23). I'm not too up to date on Debian Packaging Policy, but it sounds like this will hurt efforts on that side too. @cr0 It turns out that I can indeed disable tests due to unmet dependencies, so as long as gson's dependency requirement is lowered to 2.2.4, then I can start working on packaging it for Fedora. —Reply to this email directly or view it on GitHub. |
|
GSON has been downgraded. |
|
@cr0 Thank you very much! pops knuckles Time to get cracking! 📝 |
|
With Fedora 23 on the way, and more dependencies upgraded, I'm retargeting for Fedora 23. Here's the dependency chart for F23 (with new, more user-friendly links that's to the Fedora Packages site.) Build Dependencies
Test Dependencies
Application Dependencies
|
|
Hi, I have packaged Syncany for Fedora 22+: Feedback welcome! |
|
@adrienverge It's a good, basic package, but it cannot be included in Fedora. I'm working towards actually having the package in Fedora's repositories, meaning that it'll fully comply with Fedora's guidelines and policies on packaging Java based applications. That said, I'll give it shot later to see how well it works. |
|
@Conan-Kudo, thanks. You're right: this package includes all .jar dependencies and weights 13 MB. But it works, and can be a temporary solution. I first tried to package it a better way (relying on system .jar and using %jpackage_script): the package was 760 kB. But Syncany plugin subsystem didn't work because of how the starter script looks for plugin .jar. I'd be glad to help you have your package in Fedora repos. But before packaging mine, I haven't seen any entry in the Red Hat bugzilla. Feel free to send me any pointer so I can support your request. |
|
Any update on this? You could perhaps consider flatpak which is distro-agnostic. |
We're looking for someone to create a *.rpm package for the Syncany command line client (syncany-cli) and packages for the plugins (including the GUI).
Old stuff:
The syncany-cli debian package is built by Effing package manager (FPM). For Syncany, I use the FPM plugin for Gradle. Also check out the detailed description about how Syncany uses FPM.FPM can (among other things) also build *.rpm-packages, so it'd be really easy to do so. In fact, I started with a general deb/rpm packaging task.The *.deb package works perfectly, I think, but the *.rpm is completely untested.The text was updated successfully, but these errors were encountered: