You should be able to use mock with the srpm and it should build it.
Well, I looked a bit clorer on the deps, and there are a few one missing that needs to be build first, and then the spec file is full of if/else and what depends on what. Need to take a closer at it later.
But I decided to see if I could update seahorse. Version in rl8 is 3.20 and in rl9 40. There was only 1 dep missing: libhandy-1 …and then: Welcome to dep-he||. 
Using mock or rpmbuild… if mock is a wrapper for rpmbuild it’ll still need to check for deps, right? Anyway, going through the deps there are about 7 packages I need to build first. And that’s ok - I don’t mind the xtra effort. But, when deps start do depend on each other of never versions. -_-
So, down the line, gtk±3.0 needs a newer glib, who needs missing sysprof, who needs an even newer glib2
Spoiler w simple layout of that
# /dependency/he||
- seahorse-40
- libhandy-1 # missing
- gtk+-3.0 # needs: 3.24.1 (rl8: 3.22.30)
- tracker-sparql-3.0 # missing
- atk-devel # needs: 2.35.1 (rl8: 2.28.1)
- glib2-devel # needs: 2.57.2 (rl8: 2.56.1)
- sysprof # missing
- glib2-devel # needs: 2.67.4 (rl8: 2.56.1)
So, basically… <catch-22>To build a newer version of glib2 I need to build sysprof, which also needs a newer version (of glib2) than I have.</catch-22>
It starts to feel a bit frustrating, to be honest. To get to finish my desktop - it seems there are few too many pkgs missing. And while some of them are in rl9 (wich my nephews computors will run), I really need to make this work in rl8. So, I’m in a bit of a downer-mode at the moment. I really love this distro/system, docs/infra, the community [!], and I really want this to work, but I kind of start doubting it will. But, I guess being RHEL 1:1, is not ideal for full desktop setups (if you want the programs you want, &/or need, or used to).
Basically what’s left is: Seahorse, SIgnal, Fontmanager and Gimp. And Gimp btw… rl8: 2.8.*, rl9: 2.99.* (the devel version). A recent version, like >= 2.10.28 (lastest is 2.10.34, I think) would be ok. Of course there is the “Flatpak” solution for some of them, but I don’t want to go there if I don’t have to. Not sure I want my nephews to install a bunch of stuff I’ve seen there. The idea is that I have on this computer, what they have - so I can remotely help them (&/or manage their updates) from here (eg. takes 5hrs to drive there). And then I’ve also planned to manually (rpm)build latest Xfce, to get all Xfce pkgs, and no diffs between rl{8,9}. But, that’s for later.
I’ve managed to (re)build a quite a few packages using either some Fedora pkgs or rl9. While most of them are easy to rebuild/manage, but… when it starts to struggle, it reeeaaally does.
Guess I have some thinking to do. Feel a bit drained on energy at the moment, but I’ll get there.
// Sorry if it got a little long.
GnuRadio is in epel
$ dnf ls available gnuradio*
Available Packages
gnuradio.x86_64 3.8.0.0-6.el8 epel
gnuradio-devel.x86_64 3.8.0.0-6.el8 epel
gnuradio-doc.x86_64 3.8.0.0-6.el8 epel
gnuradio-examples.x86_64 3.8.0.0-6.el8 epel
Success with FreeDV, downloaded source and compiled.
Gnuradio is not available for Rocky9.2 as I see it:
No match for argument: gnuradio
Yeah, I see that now. Forgot they (el8/9) don’t always match - which is one of my problems, since I need both.
You could always put in a request for gnuradio - or take the files from 8 (»») and rebuild it locally, or maybe use mock.
Enabling an EPEL 8 repo
dnf -y install gnuradio
Problem: conflicting requests
- nothing provides libboost_atomic.so.1.66.0()(64bit) needed by gnuradio-3.8.0.0-6.el8.x86_64
- nothing provides libboost_chrono.so.1.66.0()(64bit) needed by gnuradio-3.8.0.0-6.el8.x86_64
and lots more, So, not an option.
I don’t have these problems with libboost - where have you installed these packages from? They aren’t dependencies for gnuradio when I try to install from EPEL.
I also don’t have libboost packages for atomic or chrono either when I search for them, so I’m curious where you got them from.
Did you enable EPEL8 on Rocky 9? As you mentioned Rocky 9 before, and now EPEL8. If you did, then that is obviously not going to work, since EPEL8 is for EL8 distros like Rocky 8 - not for Rocky 9 or EL9 distros.
No, that won’t work, like iWalker explained.
Sorry, if I was unclear. What I meant was, you could take the files from 8 - the files in that link, inlnuding the spec-file, etc - and then (re)build it for 9 using rpmbuild for example. Or If you download the “src.rpm”, you could use a tool called mock. If there are missing deps, you’d have to do the simular thing with those. (For the dep-chain… I think it’s easier to take a pkg from 8 → 9, than the other way around - since newer packages (in 9) sometimes need higher versions.)
I downloaded gnuradio el8 source. After installing dependancies, all sorts of errors:
volk: function ‘posix_memalign’ missing
Package name issues ie. is 0MQ same as ZeroMQ, THRIFT _ issue.
Then: block.cc:64:78: error: ‘_1’ was not declared, a C++ metafunction issue.
(I’m not a C guru)
Not easy
Looks like the c++ “metafunctions” that were in “boost” are now to be in “std”.
Package “mpir” has to be compiled and mpir.pc created. then MPIRXX_LIBRARY
not found by rpmbuild but package mpir is found??
Any thoughts on what appears, “boost::” is now “std::” and the gnuradio source
is not el9 updated?
Well, “dnf upgrade” to go to 9.3 bombs. 9.2 baseos has been moved to
Index of /vault/rocky/9.2/
So, why do all the “help” sites say: it works!
True, I haven’t done a “dnf update” in a month maybe.
Anyway, it’s working with first removing bad packages, flatpak.
and adding flags to the dnf line.
On reboot, still 9,2 and “dnf update” lots of problems.
dnf --allowerasing --skip-broken --nobest upgrade
comes back with “Nothing to do”.
Please tell us how to upgrade ANY 9.2 from the DVD ISO file?
You need to be more clear on what’s failing. You can’t say “it bombs” and not provide any terminal output. Without further information, what myself and others will come to the conclusion with is you have incompatible packages installed that is preventing you from updating. Without any information, it is impossible to help.
Understand. My Rocky 9.2 was installed from minimal DVD on September 1 2023.
Yesterday I tried “dnf update” and this failed with No servers can be found with the
baseos package file. (sorry, forgot the name).
I then find 9.2 baseos repo is now at:
baseurl=http://dl.rockylinux.org/vault/rocky/9.2/BaseOS/$basearch/os/
So I change it in /etc/yum.repos.d/rocky.repo and yes, “dnf upgrade” worked.
But on reboot we are still at 9.2.
I then changed rocky.repo to:
baseurl=http://dl.rockylinux.org/$contentdir/9.3/BaseOS/$basearch/os/
and after disabling all other repos, succeded with “dnf upgrade”.
And on reboot, 9.3 is up.
So, I ask again, instructions on upgrading ANY 9.2 please?
(that is tried and tested)
If you have not modified the repo files in any form, you would be using the mirrorlist by default. A dnf update will get you to 9.3 immediately. If you have modified the repo files (which you have essentially shown that you have), we cannot make guesses or provide proper advisement to get to 9.3. It is on you to figure out how to do updates on your own systems at this point.
Only advice I can provide you is that since you are insisting on using baseurl, do not use 9.3. You should be using 9 or $releasever as 9 will always be a symlink to the latest available. In this case, it points to 9.3. Only time you should be hardcoding is if you are using the vault (which we do not ever recommend).
From what I remember, my rocky.repo file was not changed by me
until I had to when, No Servers provided the, now expired, package database.
Now that you’ve mentioned it, I’ll change rocky.repo to just look to “9” not “9.3”.
That is done.
A simple instruction on making sure “rocky.repo” points to just “9” and not “9.x”
would have helped.
baseurl=http://dl.rockylinux.org/$contentdir/$releasever/BaseOS/$basearch/os/
I suspect the problem is here: What does “$releasever” refer to?
You may want to look at how the repo file is configured by default then if it was not modified by you: SOURCES/rocky.repo · r9 · staging / src / rocky-release · GitLab - The defaults typically suffice in almost all cases.
$releasever is determined by the dnf python function dnf.rpm.detect_releasever. This determines the releasever value by looking for what provides system-release and system-release(releasever).
[root@xmpp01 ~]# rpm -q --whatprovides 'system-release(releasever)'
rocky-release-9.3-1.1.el9.noarch
[root@xmpp01 ~]# rpm -q --whatprovides 'system-release(releasever)' --provides
base-module(platform:el9)
centos-release = 9.3-1.1.el9
centos-release(upstream) = 9.3
centos-release-eula = 9.3-1.1.el9
config(rocky-release) = 9.3-1.1.el9
redhat-release = 9.3-1.1.el9
redhat-release-eula = 9.3-1.1.el9
rocky-release = 9.3-1.1.el9
rocky-release(upstream) = 9.3
rocky-release-eula = 9.3-1.1.el9
system-release = 9.3-1.1.el9
system-release(releasever) = 9
That is currently true, but I’m not convinced with what I had in my September load of 9.2.
That comes under the “best practices” part of the thread title.
The repo definition files, /etc/yum.repos.d/*.repo are configuration files.
If they are modified when dnf updates package (that provides such file), then
dnf should add the new version as *.rpmnew file rather than replace the modified file.
You can check whether you have any /etc/yum.repos.d/*.repo.rpmnew and use information within.
The only edit that I do to base repos is of type dnf config-manager --disable baseos
I do have my own *.repo file(s) with unique repoids.
This way I don’t mess with/lose the repo definitions offered by packages, but they are not used either;
the enabled repos are what I have defined and I can easily swicth back to system defaults:
dnf config-manager --disable my-baseos
dnf config-manager --enable baseos
(Have to check for *.rpmnew’s, obviously.)
Whether one uses the method above, or some other approach, a magic word is : version control
Have config files that you do create or modify under version control. If you do that diligently, then
you do possess the information of what did change, how, when, what it was before, and – if commit messages are good – why.
I do configuration with Ansible. It is one of configuration management systems. I have thus a logical copy of the configuration “outside” of the configured system, and that copy is in version control. Rocky has Ansible in package ansible-core
If dnf cannot reach a repo, then there can be multiple reasons. The network might simply have a hizzy fit. The mirrorlist server could (temporarily) give list of invalid url’s. A repository mirror could have a problem. The repo definitions are not likely to be the problem, unless they have been messed with.