Distribute Appimages

[freddii]

It would be usefull to have some prebuild deb files and Appimages

[MightyCreak]

Related to #38

I agree that would be useful, but I know neither of them. I do intend to have a Flatpak package though. I already have one running, I just needmore time to be comfortable with this new packaging system.

As for Debian, well I'd really like to have a Debian package, and the PR above is actually adding that, but the problem is that I have no idea how to maintain these files, nor the resources. I have seen several app repositories that have a package in Debian/Ubuntu, without having the files tracked in the same repo. I would prefer to go that way. Of course I would help whoever would like to go and maintain a Debian package on their own (or any other distributions for that matter).

As for AppImage, I think Flatpak would perfectly do the job. And overall, Debian packaging is more important than AppImage. But if someone wants to go on and maintain an AppImage (or Snap) package, I'll be pleased to support him or her.

[bongochong]

Rather than opening up a new issue, I thought I'd chime in and echo @freddii's sentiments.

Having this new Python 3 fork of Diffuse available in official or third-party repositories for some major distributions would be great. I would also be willing to lend assistance via maintaining a copr repository for Fedora (and potentially some related RPM-based distros as well). A rudimentary .spec file would help me get going much quicker, though, with a bit of tinkering, I could construct one on my own.

Do reach out if interested, and thank you so much for porting this fantastic diff utility to Python 3. It is much more pleasant to work with than Meld and the other popular options, along with having a very slim amount of dependencies. 🍻

[bongochong]

Update: I put together a working .spec file today, and am now hosting builds of your Diffuse fork in my main copr repo. Tested the resulting package on Fedora 33 and it works perfectly.

Edit - New repo for Diffuse is here: https://copr.fedorainfracloud.org/coprs/niohiani/Diffuse-Python-3/ And I also improved the .spec file structure. Let me know if you'd like me to make any changes. Thanks again for breathing new life into this project.

[debalance]

Hi there! I have been the maintainer for diffuse in Debian until I had no choice left but to get it removed. It is usually not upstream's job to take care of the packaging for different distributions. Please have a look at http://kmkeen.com/maintainers-matter/.
If this fork is in good condition, has no exotic dependencies which are missing from Debian unstable and has no license issues, it would probably be rather simple for me to maintain it for Debian (it will then automatically be synced to all derivates, e.g. Ubuntu).

[MightyCreak]

Thank you @bongochong and @debalance !

I must admit I don't know much about distributions packaging. If you are both willing to maintain the RPM and DEB packages, respectively, I'd be more than happy to help however I can!

What would be nice first would be for you to explain to me how packaging works for Fedora and Debian? and also what would you need me to do in order to support you?

@debalance I think this fork is in rather good condition, I don't invest as much time as I want, but since the code base is rather small and without a lot of dependencies, I feel it's pretty stable for now. The only risks are, first, GTK deprecations, then, Python deprecations.

[MightyCreak]

@bongochong got a few questions on your copr repo here: https://copr.fedorainfracloud.org/coprs/niohiani/Diffuse-Python-3/packages/

• what is the nemo-extensions package?
• where can I see the .spec file you're using for the diffuse packages? do you have a git repo somewhere?

[bongochong]

The current .spec file is located here: https://download.copr.fedorainfracloud.org/results/niohiani/Diffuse-Python-3/fedora-rawhide-x86_64/01749691-diffuse/diffuse3.spec and I fortunately did not have to create an additional git repo for packaging this (though I do have a private one where I keep tarballs and such as a backup). I tried to future proof it for the next release (hence the inclusion of meson in the build requirements). The nemo-extensions package allows users to take advantage of a diff plugin for Nemo which normally requires Meld. I simply took the source and removed references to Meld as a dependency, did the same for the spec, bumped the release number, and uploaded it to copr. Works nicely with diffuse.

Edit: I should note that I'm more than comfortable maintaining the repo, and intend to create a weekly builds repo for it as well. Once I have that worked out, I would attempt to have stable releases of this diffuse fork included in the official Fedora repos (either myself or someone more experienced would maintain the packaging). I'm also going to file a bug report for the nemo-extensions package, pointing out that there is no reason for the compare component to have meld as a dependency.

[debalance]

@MightyCreak: the Debian archive itself only knows source packages (.dsc) and binary packages (.deb).
Binary packages are built from source packages, multiple binary packages can be built from a single source package.
There are 2 types of source packages: native and non-native. The differences are explained at [1].
Most packages are non-native, i.e. they consist of the released upstream source tarball and an additional tarball with the packaging files in the debian/ subdirectory.
Today, most packaging efforts are done in git repositories, but that is not mandatory.
Debian's own GitLab instance is https://salsa.debian.org, this is where I have all my packaging git repositories.
The links to the git repositories are stored in the packages meta data and e.g. visible on the package tracker [2].

I use git-buildpackage for all my packages, and for all except the ones I maintain inside the Debian Python team I use gbp's default branch structure:

• upstream releases are imported into the branch "upstream"
• "upstream" is merged into "master", which additionally contains the debian/ subdirectory for packaging created by me
• the "pristine-tar" branch contains deltas to re-create the original upstream source tarball when preparing the source package

As for "building" diffuse: the old package did not use the non-standard install.py but simply executed [3].
It seems you decided to ditch install.py and use meson instead - that's good! debhelper supports the meson buildsystem,
so chances are high this makes packaging it even easier.

[1] https://wiki.debian.org/DebianMentorsFaq#What_is_the_difference_between_a_native_Debian_package_and_a_non-native_package.3F
[2] https://tracker.debian.org/pkg/diffuse
[3] https://salsa.debian.org/debian/diffuse/-/blob/master/debian/rules#L13-18

[MightyCreak]

So! I finally got a bit of time to spare on Diffuse!

@bongochong Thanks for the .spec file, know that yesterday I created a metainfo.xml file (for Flatpak), which I think is exactly the same as the appdata.xml you're creating in the spec file, so you should no longer need to create your own and simply take the one in the repo: https://github.com/MightyCreak/diffuse/blob/flatpak/src/usr/share/metainfo/io.github.mightycreak.Diffuse.metainfo.xml

@debalance Thanks for the explanations! Very useful!

I indeed decided to ditch install.py as it was doing very non-standard operations on the source files, and also because Meson will help a lot once I'll manage to split the code into modules (because right now, one big source file of 3000 lines is not good).

---

As mentioned in #38, I feel uncomfortable adding file in this repo since I might push changes that could break the packaging files without me noticing it. That said, I do understand that centralizing everything in the same repo might be a lot easier to maintain.. especially if several people are taking charge of their designated platform.

So, how would you see that? I'm truly opened to suggestions (probably more so than when @likema proposed its PR, sorry). What would be your ideal way of dealing with packaging @bongochong and @debalance, repectively for Fedora and Debian?

[MightyCreak]

I read this Debian documentation section about packaging: https://wiki.debian.org/DebianMentorsFaq#What.27s_wrong_with_upstream_shipping_a_debian.2F_directory.3F

And they don't recommend that we add the debian/ directory directly upstream. From what I understand, the main reason is to decouple the source code from the Debian specific stuff.

Edit: it's more within the release tarballs that they advise not to add the debian/ directory. But they acknowledge that the directory could be directly within the upstream repo, although they foresee that this directory might eventually desync from downstream's own debian/ directory, at least that's what I understand from this paragraph:

If upstream has a debian/ directory in their releases, you should contact them and ask if they can remove the debian/ directory from their tarball releases. There's no need to remove the debian/ directory from their revision control system (although if it's out of date they may decide to do so anyway), but at the very least the directory shouldn't appear in releases. If you are upstream yourself, well, you can ask yourself to do it.

[debalance]

I read this Debian documentation section about packaging: https://wiki.debian.org/DebianMentorsFaq#What.27s_wrong_with_upstream_shipping_a_debian.2F_directory.3F

And they don't recommend that we add the debian/ directory directly upstream. From what I understand, the main reason is to decouple the source code from the Debian specific stuff.

Exactly.

[bongochong]

@MightyCreak Thanks back at you! I'll get to putting up the new release of Diffuse this coming week, and will incorporate the data from metainfo.xml as well.

[bongochong]

Initially had some trouble with the switch to meson, so I decided to build diffuse locally, while amending your meson.build file according to the instructions for RPM spec file template generation at mesonbuild.com.

Then I replaced the standard python build instructions from 0.5.0 with the meson-specific lines from the resulting 0.6.0 spec file, and everything went off without a hitch. Here is the latest build of Diffuse for Fedora and the working spec file.

Now that I'm a little more comfy with the packaging procedures, I have also filed a bug for your fork of Diffuse to be included in Fedora's official repositories.

[debalance]

I intend to package+upload this fork for Debian over the x-mas holidays, so it can become part of Debian 11 a.k.a. "Bullseye".

[debalance]

Happy new year: I took care of the packaging in https://salsa.debian.org/debian/diffuse and uploaded the built source+binary packages, it will show up after the next full hour on https://ftp-master.debian.org/new.html
Should be accepted and migrate from unstable to testing in time before the freeze of the next Debian release.

[MightyCreak]

Thank you so much @debalance ! And happy new year to you too ;)

[MightyCreak]

@bongochong Have you been able to use the metainfo.xml instead of injecting the appdata.xml in the spec file? From what I gathered, metainfo.xml and appdata.xml are interchangeable.

[bongochong]

I've been using COPR to build via .spec files, which isn't that flexible, but I could change things around for your next release (and experiment in the mean time). I also still need to make sure this gets into the official Fedora repos, and I have the right instructions for doing so. Some life developments have created a little delay.

[MightyCreak]

@bongochong haha no worries, take the time you need! your work is really appreciated nonetheless! 😉

[bongochong]

Thanks @MightyCreak! I'll make sure to keep you updated.

[debalance]

It's in! https://tracker.debian.org/news/1222973/accepted-diffuse-060-1-source-all-into-unstable-unstable/

[debalance]

BTW, @MightyCreak If you want to be kept up to date you can use the "subscribe" feature on https://tracker.debian.org/pkg/diffuse

[MightyCreak]

Thank you very much @debalance !

So now we have Debian and Flatpak, and soon officially in Fedora. Not bad at all!

[bongochong]

@MightyCreak, you will be happy to hear that I have officially begun the process of getting this package reviewed for re-inclusion in the default Fedora repos. It may take some time, but I believe I am going about it in the correct order this time around.

[MightyCreak]

Yessss!!!! Thank you so much @bongochong !

[bongochong]

@MightyCreak This is a wonderful FOSS project that I have used for a number of years across several different distributions. Thank YOU for reviving its development. Fedora's standards are not surprisingly quite high. Being relatively new to packaging for it, this will take a bit of time and work, but the ball's finally rolling. I'm addressing the feedback I've received from more experienced packagers in the community, and this will make its way into the repos.

[bongochong]

Another update: Some life circumstances have been slowing me down a bit, but the package has been reviewed twice so far, and it's almost up to snuff. After this round of corrections, it should be ready to go. Will update you again when it's finally accepted.

[bongochong]

Package approved! Will make it into the Fedora repos very soon. A more experienced packager also noted the physical address for the FSF in your GPL license is out of date, so I'll make a pull request to update those lines as well. Hope you're doing well.

[bongochong]

Finally made its way into the repos! Rawhide is here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-60c58d5596 and other branches are on the way.

You can keep track of its status across different releases of Fedora here: https://bodhi.fedoraproject.org/updates/?packages=diffuse

Seeing as Diffuse has made its way into the official repos again, I have also repurposed the original COPR for your fork, into one which hosts builds based on the latest commit: https://copr.fedorainfracloud.org/coprs/niohiani/Diffuse-Python-3/

[MightyCreak]

Yey! Thanks a lot @bongochong !

[wpwoodjr]

I installed Diffuse on the Debian distro that comes with WSL. I'm getting this error when I run Diffuse:

$ diffuse
Traceback (most recent call last):
  File "/usr/bin/diffuse", line 125, in <module>
    gi.require_version('Gtk', '3.0')
  File "/usr/lib/python3/dist-packages/gi/__init__.py", line 126, in require_version
    raise ValueError('Namespace %s not available' % namespace)
ValueError: Namespace Gtk not available

Any ideas how to resolve this dependency?

[wpwoodjr]

I found this dependency which allows Diffuse to run under WSL Debian: gir1.2-gtk-3.0. I guess this should be added to the apt dependency list.

[wpwoodjr]

In WSL Ubuntu 22.04, in addition to gir1.2-gtk-3.0 ,I found an additional dependency: gnome-icon-theme

[debalance]

Thx @wpwoodjr, I will fix this for future releases.

[MightyCreak]

I guess the dependency on gnome-icon-theme is linked to this issue as well: #157 (comment)

TL;DR: it's a GTK issue that has been fixed and should be in the next GTK 3 release.

[bongochong]

Definitely related. Thanks @MightyCreak.

[MightyCreak]

Renamed this issue, deb package is kindly maintained by @debalance. As for AppImage, I will not take care of that myself, but it anyone wants to stand up, I'll be please to help them.

[wpwoodjr]

On WSL, Ubuntu 22.04, I'm still seeing these dependencies for diffuse (version 0.7.3): gir1.2-gtk-3.0 and gnome-icon-theme