Thanks Nick.. I completely understand the "time suck" doing that patch into 0.9.14 might be for you folks.
I can wait for v1.0 :-) brian On Sat, Sep 1, 2018 at 10:16 AM Nick Couchman <[email protected]> wrote: > On Sat, Sep 1, 2018 at 9:22 AM bmullan <[email protected]> wrote: > >> Nick >> >> So I read your response and this is fixed in v1.0 master or branch but as >> users we don't know when that might become available. >> > > We're nearing completion on 1.0.0. It has a couple of outstanding issues > that need to be completed/fixed, and then some documentation to wrap up. I > hope it's a matter of weeks, but most of us that contribute to the project > have day jobs that don't involve actively contributing to the project, so > we can only work so fast. Unfortunately for me it's a hobby, not a career > :-). > > You can check the 1.0.0 version out from the Github mirror repo > (staging/1.0.0 branch): > > https://github.com/apache/guacamole-server > > if you go this route you'll also need to build the guacamole client code > of the same version due to the number of changes made: > > https://github.com/apache/guacamole-client > > >> >> Is there anyway to get this "fix" included into the current 0.9.14 >> release ? >> > > I'm sure you could patch the 0.9.14 source with this fix - the code for > the fix is relatively simple: > > https://github.com/apache/guacamole-server/pull/150 > > It should be pretty easy to patch the 0.9.14 code. The Guacamole project > will not release an official fix for it, though (aside from the 1.0.0 > version) - we do not go do any official back-ports of patches to > already-released code. > > >> >> /usr/include/x86_64-linux-gnu/bits/stdio2.h:33:10: note: >> ‘__builtin___sprintf_chk’ output between 8 and 2055 bytes into a >> destination >> of size 2048 >> >> There are a lot of 3rd party "build" scripts for Guacamole which I assume >> fail now due to this and may be causing new users of Guacamole alot of >> frustration trying to install it. >> > > Probably so - there's a reason we don't claim or support those third party > scripts. The build process is well-documented within the project, and we > fix issues like this within the repository. We definitely do not want the > process to be frustrating for people; however, sometimes those third party > build scripts only compound the frustration. They're fine when they work, > but when they don't you have the added steps of having to debug the build > script on top of what might actually be broken in code. The only thing we > officially support in that area is the Dockerfile build that is part of the > repositories - Docker is the way the project has decided to take to > automate Guacamole builds. > > Beginning with 1.0.0 we have/will take(n) a new approach to versions in > Guacamole that should allow us to release patches and minor version > increments much more quickly, which will enable us to respond better to > scenarios like this. 1.0.0 is nearing completion, and, after that we will > probably have another version out relatively quickly as we're already > accumulating quite a list of fixed issues in the master version of the > repo. Looking beyond 1.0.0 we want to be able to quickly/easily release > patch versions (e.g. 1.0.1) and minor versions (1.1.0) more quickly and > maintain compatibility across major versions of Guacamole (1.x.x). > Hopefully this will mean more than one release per year, which, as a > long-time user of open source projects, I fully understand can be > frustrating - I've experienced it myself more than once. > > >> >> Searching for a solution myself I saw a long thread about this error on a >> redhat user forum where they were blaming the failure to build guacamole >> on >> the gcc compiler version and several other wrong conclusions. >> >> Same thing with ubuntu users trying to build guacamole for the 1st time (I >> use ubuntu 18.04 but know its not the gcc ver and was aware of your fix >> for >> v1.0 Guacamole whenever it gets released. >> > > Yeah, and this particular change is a hotly-debated issue among many > software developers. The change in GCC has caused many, many issues with > various software builds, and a lot of people are not happy about it, but > the GNU Compiler folks have stuck to their guns and there are fixes > available. Sometimes they just take a while to come out. > > >> >> Many of those people may not know to how or want to /"check out either the >> master or staging/1.0.0 branch and build from there" / >> > > I certainly understand this, and we want to get 1.0.0 out as quickly as we > can. For the time being, your options are: > - Check out the Git repos for 1.0.0 or master and build that way. > - Grab the code from the pull request above and patch the 0.9.14 version > of the code. > - Stick with 0.9.14 and install with a compiler that is known to work. > This may mean using Ubuntu 16.04 or CentOS7 or some other combination of > known-good platforms. There are several that still work and compile > correctly. I use CentOS7, and, while it means I have to compile newer > versions of FreeRDP manually because the packages are so old, it's stable > and works well long-term. Ubuntu 16.04 is a LTS version, is stable where > it is, is known to compile Guacamole correctly, and is still supported and > active. > - Use the Docker images (available in Docker hub). > > - Nick >
