Minicom version in Rocky 9 - can we go from 2.7 to the current version (2.8 or above?)

I am new to Rocky Linux and am using it in industrial automation server applications. The latest version of minicom on Rocky 9 is 2.7. In 2.8 options for using minicom with RS-485 was added - would we be able to see this version (or later) added to Rocky 9?

Rocky 9 has package minicom-2.7.1-17-el9, because that is what RHEL 9 has.
The style for Enterprise Linux is to take a version and then backport fixes to it, rather than rebase. See What is backporting and how does it affect Red Hat Enterprise Linux? - Red Hat Customer Portal
It is Red Hat, who does decide when to rebase and what to backport.

Anyway, the minicom in Rocky 9 is therefore not quite the “2.7” of upstream (minicom developers).


Put other way, Rocky 9 may – or most likely not – get in future package with that feature.


The minicom seems to be just four simple programs: ascii-xfr, minicom, runscript, xminicom.

You can probably fetch the source code of the project and compile them as regular user.
Then install to $HOME/.local or /usr/local

That is not as convenient as managed packages since it will be up to you to re-fetch and re-install, whenever the source gets important fixes.

You could make a package request to EPEL to see if someone would be willing to build it and add it to EPEL repository. Other alternatives, are for you visiting Fedora Source RPM’s page and downloading the minicom source and use mock to build it. This will then provide you with an rpm you can install yourself. Fedora Source RPM for minicom: Making sure you're not a bot!

There are some posts on this forum already on how to use mock, or probably tutorials also easy to find with google.

Thanks for the tip! Looks like my version of autoconf is also too old - not sure if there is a way to fix that using mock. It is probably due to my inexperience.

configure.ac:9: error: Autoconf version 2.71 or higher is required
configure.ac:9: the top level
autom4te: /usr/bin/m4 failed with exit status: 63
aclocal: error: echo failed with exit status: 63
autoreconf: aclocal failed with exit status: 63

RPM build errors:
error: Bad exit status from /var/tmp/rpm-tmp.AGeB5f (%build)
Bad exit status from /var/tmp/rpm-tmp.AGeB5f (%build)
Finish: rpmbuild minicom-2.9-5.fc43.src.rpm
Finish: build phase for minicom-2.9-5.fc43.src.rpm
ERROR: Exception(minicom-2.9-5.fc43.src.rpm) Config(rocky+epel-9-x86_64) 0 minutes 18 seconds
INFO: Results and/or logs in: /var/lib/mock/rocky+epel-9-x86_64/result
ERROR: Command failed:

/usr/bin/systemd-nspawn -q -M 83da6622d5b84a568b36feb87b02f40f -D /var/lib/mock/rocky+epel-9-x86_64/root -a -u mockbuild --capability=cap_ipc_lock --suppress-sync=yes --bind=/tmp/mock-resolv.f8kytivb:/etc/resolv.conf --bind=/dev/mapper/control --bind=/dev/fuse --bind=/dev/loop-control --bind=/dev/loop0 --bind=/dev/loop1 --bind=/dev/loop2 --bind=/dev/loop3 --bind=/dev/loop4 --bind=/dev/loop5 --bind=/dev/loop6 --bind=/dev/loop7 --bind=/dev/loop8 --bind=/dev/loop9 --bind=/dev/loop10 --bind=/dev/loop11 --console=pipe --setenv=TERM=vt100 --setenv=SHELL=/bin/bash --setenv=HOME=/builddir --setenv=HOSTNAME=mock --setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin ‘–setenv=PROMPT_COMMAND=printf “\033]0;\007”’ '–setenv=PS1= \s-\v$ ’ --setenv=LANG=C.UTF-8 --resolv-conf=off bash --login -c ‘/usr/bin/rpmbuild -bb --noclean --target x86_64 --nodeps /builddir/build/SPECS/minicom.spec’

My command was simply mock minicom-2.9-5.fc43.src.rpm - am I missing args?

What if you try fc41 or fc42 version?
(Even the sources of newer Fedora can have unreachable requirements for EL.)

FC41 also requires autoconf 2.71 or greater :frowning:

configure.ac:9: error: Autoconf version 2.71 or higher is required
configure.ac:9: the top level
autom4te: /usr/bin/m4 failed with exit status: 63
aclocal: error: echo failed with exit status: 63
autoreconf: aclocal failed with exit status: 63
error: Bad exit status from /var/tmp/rpm-tmp.2lk0oA (%build)
Bad exit status from /var/tmp/rpm-tmp.2lk0oA (%build)

RPM build errors:
Finish: rpmbuild minicom-2.9-3.fc41.src.rpm
Finish: build phase for minicom-2.9-3.fc41.src.rpm
ERROR: Exception(minicom-2.9-3.fc41.src.rpm) Config(rocky+epel-9-x86_64) 0 minutes 21 seconds
INFO: Results and/or logs in: /var/lib/mock/rocky+epel-9-x86_64/result
ERROR: Command failed:

/usr/bin/systemd-nspawn -q -M 9ed5e32548ba4eb7b3eff66bb48bbd2a -D /var/lib/mock/rocky+epel-9-x86_64/root -a -u mockbuild --capability=cap_ipc_lock --suppress-sync=yes --bind=/tmp/mock-resolv.o2mslj4l:/etc/resolv.conf --bind=/dev/mapper/control --bind=/dev/fuse --bind=/dev/loop-control --bind=/dev/loop0 --bind=/dev/loop1 --bind=/dev/loop2 --bind=/dev/loop3 --bind=/dev/loop4 --bind=/dev/loop5 --bind=/dev/loop6 --bind=/dev/loop7 --bind=/dev/loop8 --bind=/dev/loop9 --bind=/dev/loop10 --bind=/dev/loop11 --console=pipe --setenv=TERM=vt100 --setenv=SHELL=/bin/bash --setenv=HOME=/builddir --setenv=HOSTNAME=mock --setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin ‘–setenv=PROMPT_COMMAND=printf “\033]0;\007”’ '–setenv=PS1= \s-\v$ ’ --setenv=LANG=C.UTF-8 --resolv-conf=off bash --login -c ‘/usr/bin/rpmbuild -bb --noclean --target x86_64 --nodeps /builddir/build/SPECS/minicom.spec’

No, that’s basically due to the fact they are Fedora source rpms and they don’t always work when building against Rocky 9 or whatever. If you take into account that the equivalent Fedora version for RHEL9 is Fedora 34, then it’s not really surprising. Sometimes you can be lucky, sometimes not.

For example:

or:

both show it was possible to build a Fedora 41 on Rocky 8 or 9. If it relies on something more specific in terms of versions, then if that newer package doesn’t get installed as a dependency from EPEL or wherever because it doesn’t exist, then we are out of luck.

Someone could potentially edit, fix and repackage the source rpm and make it work with an older version of autoconf but that would require far more advanced knowledge. Either that or download the minicom source, and just configure, make, make install etc assuming also that it doesn’t have strict dependency requirements.

One could “install” the src.rpm (that mock tried to use) with rpm (as regular user). That unpacks the source (tarball?) from that package under rpmbuild subdirectory. The open sources from tarball.

Just for info, I have built the Fedora 43 minicom source rpm on Rocky 10:

Finish: rpmbuild minicom-2.9-5.fc43.src.rpm
Finish: build phase for minicom-2.9-5.fc43.src.rpm
INFO: Done(minicom-2.9-5.fc43.src.rpm) Config(rocky+epel-10-x86_64) 1 minutes 46 seconds
INFO: Results and/or logs in: /var/lib/mock/rocky+epel-10-x86_64/result
Finish: run

[root@rocky10 minicom]# tree /var/lib/mock/rocky+epel-10-x86_64/result/
/var/lib/mock/rocky+epel-10-x86_64/result/
├── build.log
├── hw_info.log
├── installed_pkgs.log
├── minicom-2.9-5.el10.src.rpm
├── minicom-2.9-5.el10.x86_64.rpm
├── minicom-debuginfo-2.9-5.el10.x86_64.rpm
├── minicom-debugsource-2.9-5.el10.x86_64.rpm
├── root.log
└── state.log

1 directory, 9 files

so if you could change from Rocky 9 to 10, then it would be pretty easy. If you are not wanting to upgrade from Rocky 9, then it won’t be as straightforward. Build finished in about 5-8 mins for me in total time from when I started after logging in, downloading source rpms with wget and running the commands.

I did (on AlmaLinux 9 host):

$ wget https://kojipkgs.fedoraproject.org//packages/minicom/2.9/5.fc43/src/minicom-2.9-5.fc43.src.rpm
$ rpm -ivh minicom-2.9-5.fc43.src.rpm
$ cd /home/jlehtone/rpmbuild/SOURCES
$ tar xf minicom-2.9.tar.gz
$ ./configure --prefix=/home/jlehtone/.local
$ make -j8
$ make install
$ ls -ltr /home/jlehtone/.local/bin | tail -4
-rwxr-xr-x. 1 jlehtone jlehtone   621296 Nov  4 12:06 minicom
-rwxr-xr-x. 1 jlehtone jlehtone    78184 Nov  4 12:06 runscript
-rwxr-xr-x. 1 jlehtone jlehtone    29528 Nov  4 12:06 ascii-xfr
-rwxr-xr-x. 1 jlehtone jlehtone     1506 Nov  4 12:06 xminicom

The twist is that the /home/jlehtone/rpmbuild/SPECS/minicom.spec has:

%build
#./autogen.sh
autoreconf --verbose --force --install

# Remove unused files to make sure we've got the License tag right.
# It seems this needs to be done after autoreconf, otherwise it will fail.
rm -f lib/snprintf.c

and running autoreconf does indeed spit the “configure.ac:9: error: Autoconf version 2.71 or higher is required”.
Apparently, the ./configure does not check those bits.

Then again, the configure merely checks for must have and may have bits, while the
mock obeys the minicom.spec’s:

BuildRequires: make
BuildRequires: lockdev-devel ncurses-devel autoconf automake gettext-devel
BuildRequires: gcc
# For %%autosetup -S git:
BuildRequires: git
Requires: lockdev lrzsz

Of which my system does lack one:

$ rpm -q make lockdev-devel ncurses-devel autoconf automake gettext-devel gcc git lockdev lrzsz
make-4.3-8.el9.x86_64
package lockdev-devel is not installed
ncurses-devel-6.2-10.20210508.el9_6.2.x86_64
autoconf-2.69-39.el9.noarch
automake-1.16.2-8.el9.noarch
gettext-devel-0.21-8.el9.x86_64
gcc-11.5.0-5.el9_5.alma.1.x86_64
git-2.47.3-1.el9_6.x86_64
lockdev-1.0.4-0.38.20111007git.el9_6.x86_64
lrzsz-0.12.20-55.el9.x86_64

I could install that lockdev-devel and rebuild.

1 Like

Using some of the info you posted, I did slightly different. After extracting the source, I edited configure.ac and changed the value 2.71 to 2.69 so that it would use the autoconf version in Rocky 9 and repackaged the source file. Then I just did:

cd SPECS
rpmbuild -ba minicom.spec

after which:

root@rocky9:~/rpmbuild# tree RPMS
RPMS
└── x86_64
    ├── minicom-2.9-5.el9.x86_64.rpm
    ├── minicom-debuginfo-2.9-5.el9.x86_64.rpm
    └── minicom-debugsource-2.9-5.el9.x86_64.rpm

1 directory, 3 files

at which point, I could do:

dnf install ./RPMS/x86_64/minicom-2.9-5.el9.x86_64.rpm

and checked/verified:

root@rocky9:~/rpmbuild# rpm -qa | grep minicom
minicom-2.9-5.el9.x86_64

root@rocky9:~/rpmbuild# minicom --version
minicom version 2.9 (compiled Jul 24 2025)
Copyright (C) Miquel van Smoorenburg.

obviously shouldn’t really do that as root, but it’s a test system so I’m not that fussed about it. I could also use mock with the generated srpm as well if required.

There may be a better way to delete and regenerate configure.ac than manually editing, but it worked in this instance.

1 Like