Love the digi portserver 16’s that I have. Also, the response on this forum has been invaluable. With it, I was able to finally get the realport software working with Fedora (the docs in the most recent RPM are useless).
It turns out that this has been a pain, and after much hunting, searching and reading, it all boils down to a fairly simple set of steps. I’m offering these in the hopes of saving some other poor soul some time.
If you see lots of the following errors during compilation, then this is for you:
… structure has no member named `flip’…
This is the magic rebuild line:
rpmbuild --rebuild --define=FEDORA --define NEW_TTY_BUFFERING=Yes dgrp-1.9-17.src.rpm
The FEDORA line is somewhat optional. But the NEW_TTY_BUFFERING isn’t.
That’s it. Hope that helps.
P.S. It would be trivial to put this into the .spec file. I’m surprised that it isn’t there already. If the folks at Digi want such a patch, let me know.
Yes, it would be trivial to put into the spec file. However, it would not work with anything besides Fedora, which is why the --define flag was implemented. It accomodates the different Red Hat, Fedora and SuSE kernels.
The same applies to the NEW_TTY_BUFFERING, as it is only needed with specific Fedora kernels.
Actually, this could be still be put into the spec file. The different sections are basically shell scripts, and all one has to do is to grep /etc/redhat-release for Fedora. If the string returned isn’t null, then just set the appropriate variable.
I’m just thinking off the top of my head here, but I don’t see why that couldn’t be put into the .spec file. The RPM architecture, though somewhat painful at times, should be flexible enough to do this.
Talk is cheap, though. If you want a proposed patch, just let me know.
Oh, its trivial enough to add that to the .spec file.
However, Fedora has many different kernels even for the same version of Fedora.
Some require that --define flag, others don’t.
It all depends what Fedora backported from the main kernel.org kernels, and what they didn’t.
Now, you don’t mention what version of Fedora you are on.
But in the case where the kernel version is detected to be above 2.6.16, the flag will be turned on automatically.
(See driver/include/linux_ver_fix.h)
/* Linux 2.6.16+ all have the new Alan Cox tty buffer changes in it... */
# if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,16)
# define NEW_TTY_BUFFERING
# endif
Well, that’s not completely accurate about different kernels for the same release of Fedora. The ISO images don’t change for the same release, and those are quite standard. If you’re talking about what happens with upgrades, then yes, the kernel can change. But that can happen with any distro. And yes, that can make things very difficult.
But the standard release kernels are pretty well-defined apriori.
I would also submit that supporting the standard releases is better than mysteriously failing, with no indication of what recourse one might have. Even a mention in the release notes would be helpful. Especially when it is claimed that RealPort works on a specific distro and release.
In my case, I was running on Fedora Core 5. The kernel version is 2.6.15; specifically built from the kernel-2.6.15-1.2054_FC5.src.rpm
Hopefully this thread will help someone in the future should they come across this problem.