Hallo,
I always find it a pity to be “discriminated” as Linux user. For Windows and Mac, ready-made program installation files always appear immediately. A native .deb is often only weeks later.
I am not a programmer and am not familiar with compiling 
Is there a chance to use the new Gramps nativ on Linux soon?
Thanks to everyone involved in the Gramps project. You do a great job!!!
It is just a matter of when a volunteer who has both the knowledge and spare time is available to make a package. They might already be working long hours at their job. Also, due to the use of different versions of libraries between distributions, sometimes .deb files are not fully compatible for both Debian-based and Ubuntu-based distributions. I would not be surprised if some troubleshooting is required if the volunteer is trying to package a .deb file that will work on both Debian and Ubuntu. So there are multiple possible reasons for the delay, but nothing specifically against users of the debian branch of distributions. By the way, there is no .rpm package available for 5.2 at the Gramps github page, either as of the morning of 29 Feb. If a Fedora user wants to install Gramps through Gnome Software right now, they have to use the 5.1.6 rpm or the 5.2 flatpak.
Of course installing from source is an option, if you want to try manually installing all the dependencies first. There are some Ubuntu specific details here gramps/INSTALL at master · gramps-project/gramps · GitHub as well as the list at the github readme GitHub - gramps-project/gramps: Source code for Gramps Genealogical program
For prequisite names if you install them manually, it depends on your distro.
Debian-based package names can be found at Debian -- Packages
Ubuntu-based package names at https://packages.ubuntu.com/
If you are upgrading from a previous version then the dependencies will already be installed.
When installing use pip3 as follows:
sudo pip3 install .
The old-style deprecated command shown in the documentation still works, but now requires the --root=/ option to prevent Gramps installing as a Python egg.
This is only partially true with respect to dependencies. Once I got
the installation to work, I discovered the Narrative Web plugin wasn’t
working. I managed to track it down and was able to resolve it by
installing the python3-icu package. An attempt had been made in the
source to work without this package, but apparently it hadn’t been tested.
That is a good point for source installs. However, there is a surprisingly common scenario in the debian branch due to quirks of apt, where this might not be the case. (I don’t have enough experience with dnf or pacman to know if the Red Hat branch is affected too.) If a user uses apt (either in terminal or using a gui like Gnome Software or Discovery) to install and then remove an app, I have noticed that some of the dependencies may also be removed with “apt remove” or “apt purge” (even though the description for those commands only mention it removing the app with remove or the app and config files with purge). I do not know how to predict which dependencies get removed with “apt remove” and in which situations, but it has something to do with whether they got pulled in with the “apt install” command and whether other apps use those dependencies too. Furthermore, even when any missing dependencies get reinstalled between “apt remove gramps” and the source or dpkg install of a newer version of Gramps, then possibly months later if a user has separate root and home partitions, a user might use “apt autoremove” to remove old kernels when the root partition fills up from all the old kernels. However, “apt autoremove” will also remove all dependencies that were pulled in during an app install but are no longer marked by apt as being used by an app. In the past, a source or dpkg install that bypassed apt would not mark a dependency as being used by an app. So in the case of a user installing an app (like Gramps) with apt, then removing the app with apt, then using dpkg or a source install to install a newer version of the same app, then it is hard to predict when certain dependencies will get removed. Users should check over the list of removed packages when using autoremove, but after several months a user can easily forget which packages were required for their source or dpkg installs. Since in this scenario the root partition is full there can be no updates and occasionally the failed apt update has broken something important so that the user is desparate enough to type “y” in an effort to make progress in resolving the issue. Does this sound very specific and detailed as if I have dealt with this problem repeatedly over the years? Now I make my root partitions 100 GB instead of just 20 or 30 GB just to prevent this, and I am thinking of upping it to 150 or 200 GB on future installs since not just kernels but flatpak runtimes can fill up a root partition.
One workaround is to change all dependencies to a manual install rather than automatic in apt. I don’t remember the command to change a dependency previously set in apt to automatic over to manual install, but using the command below on each relevant dependency will set them to manual and prevent autoremove from removing them at a later date.
apt install --reinstall (dependency name)
And what about an AppImage?
I am concerned with general and simple access to a updated version or an update as a interested and normal user.
New versions or updates do not use anything if you do not have the possibility to use or only make it difficult.
Why not keep it simple?
Hi
GFor Fedora user you can rebuild the binary package for Fedora 39 by using the source package of rawhide.
it works like a charm
Here you go, an easy and simple updated Gramps 5.2 is available for any linux distribution
The problem is that there are different “simple” ways in the linux world and each has its own group of dedicated fans (like Appimages, snaps, flatpaks, etc). It is fine for people to have their own preferences. If a volunteer is willing and able to maintain an AppImage, I am sure that the gramps-project would be interested in hearing from them.
UBuntu 22 Mate installed the Flatpak to have a look at 5.2
reports 2 modules failed to load, appmenu-gtk and canberra-gtk does not
seem fatal but thought I would report it.
? Can I install Card View onto the Flatpak and if so where
Phil
I’ve seen the canberra-gtk notification show up when using the flatpak run command in terminal while doing diagnostics, but not the appmenu-gtk (maybe it started with a Gramps update after I started ignoring the gtk notifications). It isn’t actually a problem. Did you see those notifications in terminal? With some distributions, any freshly installed flatpak icon in the menu won’t show up until you log out and then log back in.
Regarding Card View, I don’t know the prerequisites, sorry. This does lead to the weakness of using a simplified distro-agnostic package for linux like flatpak. All add-on prerequisites have to be added manually to the script that compiles the flatpak, which then have to be checked for updates, diagnosed when they cause conflicts or other upstream changes, and then resolved before release. So there is a trade off between adding the prerequisites for commonly used add ons vs the time needed for the lone maintainer to test and troubleshoot problems for each individual prerequisite when an update is needed. For example, I currently have health problems that prevent me from sitting at a computer very long, so I dropped pygraphviz in 5.2 until I can resolve the problems from a pygraphviz update. The pygraphviz maintainers changed the install method in an update, so I would have to either resolve errors between that system and flatpak or find and test an older version of pygraphviz that uses an install method compatible with both flatpak and the newer version of graphviz that I put into 5.2 flatpak. So the flatpak is fine for users who use common add-ons that I use, but for some users who want different add-ons and can install the prerequisites themselves, a source or deb/rpm install would be better.
@cdhorn says that various category Card Views should not be bundled with the core yet. This is so design decisions can be made by the architect, so certain features can be included, and so that some fundamental code is not redundant.
It will remain an addon until some accommodations are made in the core code. CardView has no additional pre-requisites outside the core.
Sorry to read that you are having health challenges.
Hi
Yes in Terminal not desperate about Card View merely interested.
Phil
Is a deb file going to be available for Gramps 5.2?
Alternatively, is there a simple guide on how to install from source on Linux? I’m using Kubuntu (and building from source sounds like too much risk of dependancy problems for me).
The content on the wiki about building from source refers to Gramps versions 3 and 4, so I wonder if it is current.
https://gramps-project.org/wiki/index.php/Linux:Build_from_source
Thank you
Hello,
I made a pull request with few modifications allowing the deb file to be built:
https://github.com/gramps-project/gramps/pull/1662
and the resulting unofficial deb file is available here:
https://github.com/jmichault/gramps/releases
Great! Works! Thank you very much!!! 
The new module manager is a real benefit. The installation of a combined view also worked smoothly. So all I can say after a short trial, it runs
@Nick-Hall
Can this .deb file be added to the Assets on the 5.2.0 release page?
Or does Ross have to do that Build until the .deb file building automation goes through testing? (Like the AIO build automation just did.)
Great! New Version 5.2.1!
Will there be an official .deb installation file soon? I would really like to make use of error-adjusted versions. But the focus on Win and Mac as well as Flatpack makes it impossible to use.
Maybe just remember, Gramps is also used by simple users and not programmers
Thanks for all the successful work around Gramps!!!
The installers exhibit a commitment to this awareness.
The build from master (or the ‘source’ assets in a release) is for Developers/Programmers. Then, as the installer package Maintainer volunteers find time, they add installers.
Remember they don’t need installers. Installers are strictly a courtesy and gift to the non-techie users of the community. And there are dozens of different packages that have to be built. Note that this release did not have a pre-announcement so that volunteers could clear time on their schedule. So updated installer packages are likely to tickle in more slowly.
The .deb package maintainer posted that his time has been over-allocated in other projects for the the last year. So we might need another volunteer to help him out.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.