Pre-Built RPMS about zeal-packaging

[benhosmer]

Or has anyone from this project considered appimage ? This could solve the cross-distro packaging problem.

[benhosmer]

I came across this: https://copr.fedoraproject.org/coprs/salimma/zeal/ It looks like the last build was a few months ago.

[trollixx]

As per zealdocs/zeal#414, Zeal should be available from the official repositories. It looks like they haven't updated the last version yet. Perhaps @michel-slm could take a look?

Maybe a separate CORP repo would make sense, since it could also provide packages for different flavours of Enterprise Linux distros. I'll take a look into that.

Regarding https://extensions.gnome.org/, I don't see how it's relevant to Zeal. I cannot find any standalone applications there. Am I missing something?

[benhosmer]

I agree with the Gnome Extensions. My thought was that it was sort of the "app store" but for Gnome users. I built Zeal for Fedora 23 and installed it myself and afterwards, I noticed there automatically was a desktop entry created and it showed in the Gnome search.

You're also right about zeal-0.2.1-1 being in the Fedora 23 repo. I was searching for zealdoc I think.

This can probably be closed out since everything is taken care of already! Thanks for an awesome and useful tool.

[benhosmer]

Oops, I spoke a little too soon - Zeal isn't actually available in the Fedora 23 repos. I mistakenly did a search on the system I'd built the RPM for and it showed up as available.

COPR would definitely be the way to go.

[buschtoens]

Sorry for intruding, but has there been any recent development? We're using CentOS at work and would love to use Zeal. :)

[trollixx]

According to this page Zeal should be available for Fedora 23 or later.

[trollixx]

If someone wants to contribute some time and provide a universal RPM repository that would be great. Such packages could be even hosted in our BinTray account, which supports RPM repositories.

Other than that, I guess the only way would be to rely on packages provided by distributions themselves or third parties. I am not using any RPM-based distro myself, and honestly don't have any extra time for maintaining such packages.

[trollixx]

I'll leave it open just in case.

[abn]

@trollixx I am doing a copr repository to enable a faster cycled build. The source is on github. Looks like the official 0.3.0 release for fedora is slated for f26 as per package builds page.

Once #19 is completed; I can tag a new build and the packages should be available for f24, f25 (post GA) and el7 on x86_64. On Fedora this can be installed by doing the following:

dnf copr enable abn/zeal
dnf install zeal

Hope this helps.

[probonopd]

Can you compile for older distributions such as el6?

[abn]

@probonopd should be do-able if the dependency chain does not require packaging; will give it shot in a little bit.

[trollixx]

For Fedora Zeal will be updated in the official repos, so I am not sure how useful a separate COPR would be?

Also, please keep in mind that 0.3.x is the last version to work with Qt 5.2+, I''ll be switching Zeal to Qt 5.6 in 0.4.

[abn]

@trollixx; from experience, getting versions updated esp. for non-current versions of the distros are hard and a long process more often than not. And as indicated by @probonopd 's request, especially hard for CentOS as it tracks RHEL. A copr repository just provides an unofficial rpm for consumption - for me; its just for personal use - community is more than welcome to use too where required. Not pushing it as an official source for binaries.

As for the Qt 56 dependency in 0.4 - Fedora 24 and up should have 5.6; I have not looked at CentOS yet for the Qt version.

[trollixx]

Okay, no problem. I have little knowledge about all the flavours of RPM distros :)

Just FYI, for supported Fedora versions 0.3.0 should land into official repos as soon as I make an announcement (zealdocs/zeal#602).

[abn]

I can confirm Qt 5.6 is available across el6 and el7 is available via the epel repository - will get the builds up soon-ish. Will wait for the official announcement for the supported packages.

[abn]

@probonopd jfyi; the el6 builds are currently failing due to what I suspect is a GCC version issue in el6. I can investigate this once I do get some time.

The el7 and fc24 builds are now available on the copr repository.

[probonopd]

@benhosmer

Or has anyone from this project considered appimage ? This could solve the cross-distro packaging problem.

I have made an AppImage some time ago: https://bintray.com/probono/AppImages/Zeal#files
Simply download, set the executable bit via the GUI or chmod a+x, and run.

It uses binaries for trusty from zeal-developers/ppa, so it should run on most distributions since 2014.

[benhosmer]

@probonopd I've been a consumer of app images packages and I have to say, I definitely liked what I saw.

I'd reiterate my original comment about it saving a lot of time and work for a project like Zeal.

My packaging experience only lies with building server types of applications, so I can't comment on app image from a maintainer perspective.

I can offer a user perspective though:

1. Dependencies are handled (no more package manager dependency or conflicts)
2. The project has one source to maintain and keep track of
3. A user has one source to get the package
4. The app "just works"

[trollixx]

I don't mind maintaining a package if it takes exactly 5 minutes of my time, and that's the case with AUR. Updating both `zeal` and `zeal-git` takes less than 5 minutes including rebuilding both packages. Unfortunately, with Ubuntu/Debian or Windows things are much more complicated. No idea about time an AppImage package requires to prepare. My plan is to come up with some sort of a continuous delivery system for all my manual packaging tasks. I want everything done automatically when I create a version tag.

[probonopd]

No idea about time an AppImage package requires to prepare.

Close to zero if there is already a ppa for trusty or earlier: Just rerun the script, then it builds a new AppImage from the ppa.

[abn]

The only real concern for AppImage and similar mechanisms is the security aspect, ie. using older dependency binaries etc. Usually, this sort of a deployment is frowned upon for a variety of reasons. But that said, considering this is a local application and the only real concern is the docset APIs themselves, I think it is only pragmatic appImage or flatpack be considered as delivery options.

@trollixx travis can be used to automate the build and upload processes on a project tag. Same applies for the copr rpm project all that requires right now is an update of the tag. This will build and upload the new binaries to the repository.

Also <3 AUR :)

HTH

[David-Else]

Hello,

Can anyone confirm if there is a RPM that will work with no problems on Centos 7.4 (which is now based on Gnome 3.22, the same as Fedora 25)?

I don't really understand packaging and don't want to mess up my install, would be great if it was in the Fedora EPEL 7 repo :)

Is this where I should be looking? I can't find an RPM to download:

https://travis-ci.org/abn/zeal-rpm

Thanks!

[abn]

@David-Else I have not maintained the centos rpm for a while now; if this is something you need I can get it building again. I am using zeal of fedora 27 right now. Adding to the EPEL repository requires a maintainer and jumping some hoops for which I do not have the bandwidth at the moment.

[benhosmer]

@David-Else and @abn this seems ripe to rekindle the Appimage discussion from higher up or use COPR. In fact, I've got some spare cycles and have been looking for another OSS project to give back to. Give me a day or so and I'll at least stand this up in a COPR repo, which will solve @David-Else immediate problem and at least get it available to CentOS/RHEL users quickly. We can then work on getting it into EPEL proper. How does that sound?

[David-Else]

@benhosmer and @abn Thanks for this awesome and speedy feedback!

I wish I knew more about packaging. I am currently using Fedora 27, and have Zeal running on that. I am finding Fedora 27 to be rather crashy and buggy compared to all the past releases, and constant updating in general is making me go a bit OCD. I have decided the new Centos 7.4 is the perfect solution, my happiest Fedora memories were of Fedora 25 too, so Centos 7.4 looks like the long term happy land of eternal Gnome 3.22 and things just working for a very long time :)

Before I heard back from you guys I was thinking of trying to convert the Fedora 27 SRPM to Centos using these instructions I got from some random website:

building el7 packages from Fedora ones is usually pretty trivial.

yum -y install rpm-build
rpm -Uvh http://mirrors.xmission.com/fedora/linux/updates/24/SRPMS/f/flatpak-0.6.7-1.fc24.src.rpm
cd ~/rpmbuild/SPECS
rpmbuild -bb flatpak.spec
[if you are missing dependencies, install them and try again]
cd ../RPMS/x86_64
yum install ./flatpak-what-ever-else.rpm

but i really have no idea what I am doing. For future reference, if I did this in a VM and copied over the RPM and installed it, could it still overwrite libraries and damage my install?

@benhosmer would be fantastic to get the copr RPM for Centos 7.4 :)

[benhosmer]

@David-Else :

To answer your question, yes, if you build the rpm on a VM and then install it somewhere else, it could overwrite other things. I'm not sure what the flatpak.spec is doing, or even why rpmbuild is being used to build a flatpack. If you wanted to wet your teeth and build a flatpack from zeal, I would recommend trying it because it's a fairly simple app to build.

[David-Else]

@benhosmer I have been trying to get flatpak to just install something from https://flathub.org/apps.html , but it does not work. I filed a bug report. I don't think I will be able to build anything if I can't even download anything?

flatpak/flatpak#1264

I have spent most of the day on this now, amazing how time flies trying to make Linux work! I think I will hang on and see if the copr RPM appears :)

[benhosmer]

@David-Else I was able to install dolphon using the commands you posted in flatpak/flatpak#1264 I can't offer much more advice though.

@trollixx I just re-read this whole thread, I'd like to help out and it sounds like flatpak or appimage might be the best way to get a cross-distro rpm solution. I'll build it in both and see which one is simpler.

[David-Else]

@benhosmer Thanks for looking at the report. Interesting that you could install Dolphin using those commands. Are you using Centos/RHEL 7.4?

I was using Gnome Boxes as a virtual machine for Centos 7.4, maybe that was causing some kind of error, it is very buggy software. Really should use Virt Manager. Strange.

[trollixx]

@benhosmer Thanks for looking into this!

Some time ago I found the packpack project, and thought of using it to provide RPMs and DEBs not tied to a specific distribution, but never actually got to do anything.

We are about to get snap packages. They are supposed to work on RPM based distros too, but a lot of people don't like anything created by Canonical :)

[abn]

@benhosmer I already have a copr available at https://copr.fedorainfracloud.org/coprs/abn/zeal/ however, it is maintained outside of the project as per a previous discussion. The EL support for the current rpm spec has a few issues, #32 resolves one of them, but the other is got to do with the linked libraries - I have not dug into it yet. I suspect its a compilation issue or gcc version issue.

@David-Else if you are running Fedora 27, you can get it via dnf -y install flatpack. But if you are on CentOS, you can use this COPR repository. The instructions for enabling the repo is linked in the overview page.

@trollixx for what it is worth; projects like packpack etc produce RPMs that are not suitable for getting upstream into the distro repositories so, if that is a factor then I'd assess it carefully.

I should also point out that Fedora's official repositories now maintain 0.4.0 release (rpms/zeal) and maintaining RPM(s) outside of that would be counter productive imho. Focusing efforts on a flatpack image might be of better use for the community, especially for an application like Zeal.

@benhosmer if you are working on the flatpack packaging and I can help anywhere, let me know.

[trollixx]

@abn That's right about packpack, and I definitely don't have time for it now. Plus Fedora and Debian both already have Zeal in their official repositories. COPR and PPA also provide a way to distribute updated versions. Although while there is an "official" PPA, we don't have a similar COPR repository.

[benhosmer]

@abn and @trollixx I echo the thoughts too about tools like packpack and fpm. They work for personal things, but won't get accepted to official repos because of their non-standard packaging. Effort is more likely better spent packaging properly.

So, if COPR repo does already exist, it sounds like it just needs a little love. @David-Else original post, which sparked this activity, was because he's using CentOS. If the COPR repo works for him, great.

I'd still like to pursue the flatpak option as well and I'll work on that. I assume it could be integrated along with the existing build system, and hosted in flathub?

[trollixx]

@benhosmer Let me know if you need anything for pushing Zeal to Flathub. I have no idea what the process is.

Regarding COPR, it would be nice to add installation instructions to our webpage. Also I remember COPR lacked concept of organizations, but now they seem to have groups. So it should be possible to create a zealdocs group to make our COPR repo look more official. @abn would you be willing to maintain it?

[abn]

@trollixx happy to help on that front. Will take a look at getting the group setup done soon (might be a few days delay on that one) and get some documentation prepped.

In the meantime, I have gone ahead and updated the COPR package to v0.5.0 and ready for both CentOS 7 and Fedora 26/27.

https://copr.fedorainfracloud.org/coprs/abn/zeal/

@David-Else if you could follow the instructions to enable copr repository to try out the package in the above copr and let me know if you encounter any issues; that would be a great help.

[trollixx]

@abn great, thank you!

I did file a ticket for the group to be created, but there were no updates on it since Tuesday.

[David-Else]

@abn I followed the instructions using a virtual machine running Centos 7.4, and it all installed fine. All the dependencies came from Centos base, apart from:

qt5-qtwebkit x86_64 5.6.2-1.el7 epel

I downloaded the JS docset and had a quick browse around, all seems great!

I downloaded (https://github.com/deerawan/vscode-dash) and zeal launches from VS Code as expected, excellent work! :)

Is there a link to the RPM on COPR rather than having to install the COPR plugin?

Thanks everyone for your help, and thanks for this great bit of software!

[benhosmer]

@David-Else you can find it here: https://copr-be.cloud.fedoraproject.org/results/abn/zeal/epel-7-x86_64/00690412-zeal/ but not using the COPR plugin or the repo might cause issues if there are dependencies.

@trollixx @abn I'm working on flatpak right now. Once I can build it locally, I'll look into pushing it to flathub. I'm working through the missing qt5 dependencies now.

[probonopd]

The download page shows download buttons for Windows, Linux, and macOS:

If you are a Windows or a Mac user, clicking that button brings you to straigtforward instructions on how to download and run Zeal:

However, if you are a Linux user, you get this long list of technical gibberish that is dependent on your distribution, on whether it has the latest version of Zeal or not, and involves messing around with ppas and the command line.

Providing an AppImage would have, among others, these advantages:

• Applications packaged as an AppImage can run on many distributions (including Ubuntu, Fedora, openSUSE, CentOS, elementaryOS, Linux Mint, and others)
• One app = one file = super simple for users: just download one AppImage file, make it executable, and run
• No unpacking or installation necessary
• No root needed
• No system libraries changed
• Works out of the box, no installation of runtimes needed
• Optional desktop integration with appimaged
• Optional binary delta updates, e.g., for continuous builds (only download the binary diff) using AppImageUpdate
• Can optionally GPG2-sign your AppImages (inside the file)
• Works on Live ISOs
• Can use the same AppImages when dual-booting multiple distributions
• Can be listed in the AppImageHub central directory of available AppImages
• Can double as a self-extracting compressed archive with the --appimage-extract parameter

As a result, you would get the eqivalent of the "portable" application for Windows, but for Linux.

Here is an overview of projects that are already distributing upstream-provided, official AppImages.

I have made an AppImage some time ago: https://bintray.com/probono/AppImages/Zeal#files
Simply download, set the executable bit via the GUI or chmod a+x, and run.

If you have questions, AppImage developers are on #AppImage on irc.freenode.net.

[trollixx]

@David-Else I am not a Fedora user, but I'd assume without COPR you loose automatic updates.

@benhosmer sounds great, please let me know if you need anything from my side.

@probonopd I know about AppImage, but unfortunately I don't have time to maintain packages myself. Even creating MSI for Windows takes quite a while (reason I haven't announced v0.5.0 yet). So someone needs to be willing to volunteer their time to be an AppImage package maintainer. Once we have Snap and/or Flathub, I'll make them the default suggestion for Linux users. Anyway, it's a bit off topic in this ticket.

[probonopd]

Once we have Snap and/or Flathub, I'll make them the default suggestion for Linux users.

They are not the equivalent of your "portable" Windows version. Plus they don't run on all systems.

[trollixx]

@probonopd Right, but they can run on a bunch of systems as well. Also they can (and probably should) be built with the portable flag on. And don't get me wrong, I am all for having "official" AppImage packages as well, if someone steps forward. I don't even use Linux lately :(

[benhosmer]

I'm closing this issue, since it was originally for pre-built RPMS. We can continue the discussion here: #34