Missing packages, 3'rd party repos - best practices

Community Off-Topic
1

There are a few programs I can’t find in the repos, so I probablyhave to build a few my self, &/or make a few custom rpm’s. Just wanted to listen in how you do, and what “best practices” one should stick to.

There are a few I’ve seen in el7, &/or in el9. Can I take one of those and rebuild your own version for el8? Like el7.srpm → el8.rpm.

Then there’s a 3rd party repo I saw, “Raven”, that had a few ones I want/need. I don’t know anything about that repo. Is it good? (ie. can be trusted). In a post on CentOS forum it was brought up in an example, and the site admin didn’t make any remarks (which I assume he would if it was a bad one) - so I guess it’s ok’ish. But, anyone here with experience from the “Raven” repo?

Then, I’d like to install Signal Desktop, but they don’t offer rpm’s. They only have their own apt-repo. There is a version in copr (but, deprecated). and then there is this comment on GitHub, using yarn to make an rpm. Does it look ok? (never used yarn)

There are also these conversions tools, like Debian have this “alien” to convert deb<->rpm, plus other formats. But I don’t know if that’s such a good idea. Or are they usable? (ie. with good results).

The programs I’m looking for, in case someone may know if there is one:

  • (from above) Signal Desktop, Plank
  • Abiword, Xburn, Xarchiver*
  • …and Grub editor would be a “nice-to-have”, but not that important.

 

Any good ideas/pointers? And how do you manage missing packages?

Thanks…

· Eric

* Rocky Linux Xfce comes with the Xfce Thunar archiver plugin, but without a backend. I’ve always used Xarchiver for that.

2

You can pull the Fedora src rpm’s as Fedora tends to have a lot more packages. These can then be built with mock. I’ve pulled Fedora 36 src rpm’s before for building the odd package or two.

For larger things, like cinnamon as a desktop, I used copr for that on Rocky 8 and it worked great. Requests can also be made to EPEL repository for them to add packages. Building yourself is fine, just means you have to rebuild for example when a new version comes out or bug fixes etc.

2 Likes
3

Thanks! :+1:

Yes, mock is perhaps better to use anyway, since I’m going to need to build for both rl8 and rl9.

You took it from Fedora 36… Is it better to take an older version, like f34/35, and the deps and linking maybe match better - or does mock take care of that too? A couple of the files I’ve seen are in el7 (only). Perhaps they are in Fedora as well? (probably)

The version of Signal-Desktop on Copr, he referred to the openSusebuild now, who have packages for both OpenSuse and Fedora. I downloaded the src.rpm and are lookng in the spec file now. I don’t think it needs too many changes. There’s an instance of %{fedora}, which I assume should be replaced with %{rocky} or %{rhel} (both returned “8”), and there’s a font patch for “inter”, that appearently both Fedora and openSuse have. Maybe that patch should be removed. It only removes the installed version and replaces it with the system font instead. Mock can both build from source files and rebuild and rpm, right?

Yes, the desktop. If epel doesn’t upgrade Xfce to 4.18 in el8 later on, but in el9, I think I’ll have to do the same as you there. I’m going to use both RL8/9, and I want/need Xfce to be the same on all computers - especially since 2 of them are my nephews (5 hours away). Easier to help/manage if we all have the same. :slight_smile: (And there are differences in el8 and el9 of what packages are included, or not. Like Xfdashboard is in el8 but not in 9.)

4

Results will vary, I’ve generally had more success with F36 ones, it might be possible with older ones if the newer ones rely on some libs that don’t exist at a particular version in the new Fedora releases.

I didn’t change anything in the src.rpm, just was enough to download, run mock, and get a built rpm ready to use.

There is an Rocky XFCE iso that can be downloaded ready for install. Alternative Images | Rocky Linux

5

That’s what I was thinking. If it’s and older Fedora-release, but otherwise the same program version, perhaps it better to goes safe with that (slighly older) one?

 

Yes, that is the one I used to install RL8. :+1: It’s great, but it has a few (actually quite a few) missing Xfce programs. I found most of them in the repos. Most of them were panel plugins. But then there are a few totally missing, like Xburn. I’d also like to get Xarchiver. Not an Xfce program, but has always been used with/in Xfce. Butm it’s not in (any) epel.

One of the really positive things from installing RL on an old laptop, Except for fixing the popping sound (intel side effect), I haven’t needed to touch or fix anything with the power settings. Fans running normal, doesn’t get too hot, etc. Feels great!

Speaking of the Live Xfce install media… When using that one, it basically installs the live environment onto the disk, right. So, there are some live install leftovers all over the system one would like to get rid of. Like, I’ve seen both anacona and vmware stuff I don’t have installed, need, or want.

Is there some sort of cleanup script to clean up the leftovers. I guess I could run dnf provide on each file I see if it belongs to a package I can remove, or if I just can remove it in terminal. And there was also a gdm folder somewhere. I don’t remeber I’ve installed it - unless it comes as a dep for another prog that need some gnome stuff. I use LightDM.

· Eric

6

You can use something like:

dnf autoremove

which would work in a similar way to deborphan on Debian/Ubuntu in that it provides a list of packages that don’t depend on anything and can be uninstalled. The difference being that the command above actually allows you to see and remove the list at the same time. With Debian, I have to pipe the output from deborphan to apt/apt-get/aptitude to remove.

It may not remove everything you require, I guess by the vmware thing you mean open-vm-tools, there could be others like the hyperv ones or qemu-guest-agent also - they are normally just for virtual environments and wouldn’t run anyway on a physical machine, but I understand removing them if they are not needed though.

I have a tendency to uninstall the sssd* packages because I don’t need that, I generally get that after a minimal install, so I do a cleanup myself. You could use ansible scripts once you’ve built up a list of the ones you don’t need, that way if you do repeat installs, you can run the ansible playbook against it to remove - saves you having to figure out which ones to remove on each repeated install.

7

No, there’s nothing in autoremove to remove.

I’ll check that open-vm-tools. It’s not a part of cockpit, is it? I will setup kvm/qemu/etc later on. Just not very high on the todo list at the moment.

Never used Ansible, but it sounds very practical. Hard to learn?

One good thing though about the live install… In roots home folder. There I found the kickstart file. Very interesting to see how my partioning looked like in the ks format.

8

No, it’s for VMware ESXi to talk with the virtual machine for providing functionality like being able to reboot from VMware, snapshots, etc, etc. It’s common for these guest tools to be installed.

9

Aah, ok. I think I’ll remove them. I have no need for them.

I went to look for Anaconda, vm-yools and vmware, what was what installed - and they combined for 13 packages.

dnf output… 
$ for pkg in anaconda vm-tools vmware; do dnf ls installed | grep ${pkg} | cut -d ' ' -f 1; done
anaconda.x86_64
anaconda-core.x86_64
anaconda-gui.x86_64
anaconda-install-env-deps.x86_64
anaconda-live.x86_64
anaconda-tui.x86_64
anaconda-user-help.noarch
anaconda-widgets.x86_64
kdump-anaconda-addon.noarch
libreport-anaconda.x86_64
open-vm-tools.x86_64
open-vm-tools-desktop.x86_64
xorg-x11-drv-vmware.x86_64

I assume the xorg file is a part of xorg, so it will stay,

Maybe the live-cd installs should have (and run) some sort of cleanup script, like a post-install script. Or leave a text file behind on the desktop, with a list of packages that can be removed.

 

Mock question.

I have installed mock, but not configured it yet. There was an install error and a warning I wanted to ask first about. I noticed when I installed mock, that when it installed the dep mock-core-cofnig, it generated a warnng:

  Running scriptlet: mock-core-configs-37.8-1.el8.noarch                                        1/2 
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ModuleNotFoundError: No module named 'dnf'
Warning: file /etc/mock/rocky+epel-8-.cfg does not exist.
         unable to update /etc/mock/default.cfg

Seems like the filename is wrong: rocky+epel-8-.cfg. Should be an arch after that - so, of course I don’t have the file. So, I made symlink to x86_64, and it passed. All it did was to create a symlink to that file. No updates in the file itself.

So, now it’s only the ModuleNotFoundError: No module named 'dnf' left to figure out. Any ideas?.

10

Try:

dnf install python3-dnf

although it should have been enough to:

dnf install mock

and then running:

mock src-rpm-file.rpm

should build it - of course, building in mock may also require other things to be done if the package relies on some dependencies outside of repositories that are available, but in most cases it should just work without effort.

Never had that error about the dnf module, so would be better to show all the steps you did on what you were installing, and when the error was generated, during install, or when you tried to run mock, and if so with what parameters.

1 Like
11

No, alreay installed. Then I remebered… I installed python39 and set that one to default with alternatives --config. Tried using aliases to point to 3.6, but when changing it back to 3.6 as default - reinstalled it, without error.

So, one wonder - why isn’t mock hard coded to a specific python version (3.6) if it’s now so version dependent? If I knew if it uses python or python3 I could at least change the other one. Trial’n’error, I guess.

12

I never had this problem, but then I never changed the default version of python so perhaps why it worked for me.

13

The err’s are gone now so it should work now. Thanks for the help/assistans! :+1: I try to see if I can get some time over in the weekend, and can start testing it a bit. :crossed_fingers:

1 Like
14

Still haven’t tried mock, but I’ve built a few programs now with rpmbuild. Yaay… I think that’s the best way - for now - and then later use mock to take my own builds and turn them into el9 ones for my other computer(s). If they’re missing, that is. Half of the programs are missing in both (8/9), and the other half seems to be just missing just in 8. (There are a lot of programs for both el7 and el9, but are skipped in el8.)

So, that made it possible for me to use som ready made spec files, and then build locally - and sometimes also update the version a bit.

  • Mousepad needed a newer version. I thought that rebuilding it on my machine would help the problem with the segfault crashing. But, it still crashed good on that version. Using a newer one helped. Now I can scroll again. :slight_smile:
  • Xarchiver, latest. Works really great - and also, now Xfce/Thunar works with creating/extreacting archives - since it’s is the backend for that.
  • Bluefish was missing, so that one is also made.
  • Then the Plank dock… It required a bit more. A couple of xtra deps needed to be built, and upgrading another dep with an older version in Rocky, to something newer. Didn’t like that at first, but the good thing was that it ran all the tests, and passed. And then I used the same Plank code as Fedora - ie the version from Elementary. And, of course, they had removed the zoom-effect, so I had to redo it - using the same commit, and then just run git revert <commit> to undo the commit that removed it. :smirk: (The original plank isn’t maintained anymore, but the one in Elementary is - but I also found another one that is (kindof maint). I think that’s the one Arch is taking its code from. And it’s not using granite. Well, it’s done now, and I won’t change to that one. It works - which is the important part.)
  • And links. I know there’s elinks, but it’s not the same …and, links is kind of special to me. (I think) it was the very first program I compiled myself, on an old Mac. Searching, reading, learning, figuring out how to do it, etc.

There were a few progr that didn’t want to play nice. Still working on those - or if I skip them. Not, essential one - more nice to have. And then there are a few ones I’m still looking at, to add. I guess Signal and getting latest Gimp, will prob be best to find one made and run it with mock. They’re too big.

Anyway… If anyone wants/need the spec-files - &/or the rpm’s, I can send them.

· Eric

1 Like
15

Hi - just found this post and noticed your offer to provide RPM files for Plank. Can you please send to me? I’ve started trying to use a RHEL base as a desktop, but I miss plank dock…

Thanks
John

16

Yes, of course.

Are you on RHEL8? …because my files are made for RL8.7. If you’re on RHEL9, you need to “mock” them, &/or build them (bamf, granite, plank, vala) on your machine with rpmbuild (spec-file and sources are included).

Don’t know if I can post it here as an attachment to the post - if there are any board rules maybe. (@iwalker ?) Or you can PM me you mail.

· Eric

17

oh, darn. I’m running 9.2 :frowning:

Not sure why they changed so much with the 9 series but a lot of stuff that used to work no longer does.

Thanks anyway

18

(Not directly relaated to above)

@iwalker, I saw a post about Signal. And it seems that openSuse have a version for Fedora. Has anyone installed Signal app's desktop version in Fedora? - #16 by fasulia - Fedora Discussion

So, I looked at the openSuse page, and looked in the spec file. There’s a lot of build requirements, but only 2 requirements. One is the signal_ringrtc, which they also have, and then the Inter font. And that one’s easy to get.

Do you think it would work downloading the rpm, or maybe use the repo they have?

Alternativley, there was a post about installing apt/dpgk, and use the official Debian repo (from the same post): Has anyone installed Signal app's desktop version in Fedora? - #6 by sergiomb - Fedora Discussion

I didn’t know that worked, or maybe it doesn’t?

Or anyone else tried to install Signal that way? …with the openSuse/Fedora version, that is.

19

TBH I wouldn’t personally use RPM’s from any other distro it can just cause problems in the future. Best to see if Fedora has a source RPM available, and if not, check flatpak or similar alternatives for installing via flatpak/snap (although I hate snap personally, would prefer flatpak).

I wouldn’t even attempt to install deb’s either. At best, convert it to rpm via alien if it’s not relying on dependencies.

1 Like
20

Thanks! :+1: Yes, I downloaded the srpm earlier, to have look att the spec file. It was on that page with all the rpms.

There are quite a few BuildRequires, and then 2 Requires: signal-desktop.spec

Haven’t checked them all, but most of them look recognizable/normal pkgs, and without any spec version one must have.

There are also 22 patches in the sprm. I guess it’s to make it work on non-Debian - which I assume rules out the alien way.