[SOLVED] Building or obtaining newer packages than available in current or slackbuilds

This all started by seeking a current/secure rdp client for Slackware (64 current). I know we have rdesktop-1.9 which is current release of rdesktop but this seems to be lagging in seciurity issues (wont connect to my Win machine using NTLM). I went to slcakbuilds and found freerdp. I was able to build install and use just fine. however, I see from free rdp website that 2.0.0 has quite a few security issues.

So, as a slacker, what is the best way to use the latest version of freerdp-2.2.0 (or any software for that matter)?

Can I simply download the source for 2.2.0 and change the slackbuild script? Admittedly I tried this and it built but the install file produced a bunch of errors when installing so suspect there is more to this.

Is it better to download source and build on my own? The question here is then it is managed outside slackpkg - not sure of the implications for this in regards to upgrades and such.

Do I need to wait for someone else who has the experience to bring the current package forward?

Other?

I can get around slack fairly well but admittedly do not have much experience in package land as between current, slackbuilds and alien have been finding mostly what I need.

Any thoughst/direction would be appreciated.

When using Slackware-current, the best source for the most recent SlackBuild script is https://github.com/Ponce/slackbuilds. At this time, the build is for freerdp 2.0.0.
As freerdp is not an official Slackware package, it is not managed by slackpkg.
When a new program version is released, then it requires community support to identify any problems with the SlackBuild script and/or the resulting build. Please provide more details of your issues with freerdp 2.2.0 to this thread.

I feel your pain with RDP support. I got cranky with rdesktop on Slackware 14.2(stable), when after many years, it dropped support for connections to Windows XP (NTLM authentication) and could not support connection to Windows servers with NLA (network level authentication) enabled without PAM. I switched to freerdp on Slackware 14.2 and forced the Windows XP machines to use NTLMv2 authentication.

Originally Posted by krakanut Can I simply download the source for 2.2.0 and change the slackbuild script? Admittedly I tried this and it built but the install file produced a bunch of errors when installing so suspect there is more to this.

FWIW I actually just built it fine like this (just a version-bump to 2.2.0) on a clean and full installation of slackware64-current.

Originally Posted by krakanut however, I see from free rdp website that 2.0.0 has quite a few security issues. [...] Any thoughst/direction would be appreciated.

an alternative could be also to ping the maintainer asking him the courtesy of pushing an update to SBo because of the security enhancements of the new versions.

Thank you guys for the responses. I did try changing the build script to 2.2.0 and it did build but when I tried installing it was giving me a bunch of odd parsing errors (sorry I do not recall details). I tried building with the Ponce script as he confirmed it worked (added -fcommon on line 88) and it built and installed fine. I was thinking the one small change was it so wanted to test. I remove the program, deleted the install file and tried building again using the regular Slackbuild script and low and behold it compiled and installed fine. Not sure what I did wrong in the first place but thank you for helping me along.

I will mark this as solved in that you should at least try changing the version number and run the Slackbuild script against the newer source code.

Originally Posted by krakanut I will mark this as solved in that you should at least try changing the version number and run the Slackbuild script against the newer source code.

It's good fun to try this and then to try fixing any problems that pop up. Just did this trying to get the newest zstd, 1.4.5, to build.

What I wonder though is when it is useful to share what you find and when it is better to leave the slackbuild maintainer alone. In my case there's a trivial makefile problem created by an upstream change I didn't fully investigate involving the lib-release target in the lib dir and the shared library not being built for the parallel version build. I hacked around it with an explicit make lib run in the slackbuild script but the Makefile patch should probably be adjusted instead for the real thing.

Probably the maintainer will quickly handle this when he gets to it and in less time and trouble than he'd take to deal with a patch from me, so I opt not to send one. But where do you draw the line between offering useful help and being possibly annoying?