Bill, Please READ My emails …. On first reading it can appear that you have a deep misunderstanding of Linux
* there are no issues when building from source on Ubuntu 20.04. users are building on 20.04 and several other Linux distributions and versions with issues. There are no issues if you have a fully deployed development environ (and set of libraries). But there are SIGNIFICANT issues using the supplied .DEB IF you basically do not have the programming environment deployed…. You are building packages from fully “specced-out” Linux development distros (i.e. all the required libraries are there). i.e. The OOB (Out Of The Box) Libraries ARE deployed OR you have made the Libraries available via deploying the Qt SDK. By far the majority of users – especially newbies (and I work with newbies quite a lot being an AR Licence Assessor too) - are using Linux OOB and do not have all the required development libraries deployed. I challenge you to do a FRESH install of the packages and then try to deploy … You will very quickly see my point ! * > The Qt5 packages are NOT NATIVELY delivered in Ubuntu and many other Linux distros as they are large and volatile. I started with 18.04.4 “oob”…. My pedigree with Linux is such that I am an early Kernel Developer (via an early “handle”) … and I am one that that has built OS’s from scratch using Andy Tannenbaum’s guides … * I don't understand your comments here. Almost all Linux distributions have the Qt tools and libraries in their repositories, including the development packages if needed. You have a strong history; so do I. There are no people in this conversation that are unqualified to participate …. That is the point here. Yes they do have the Qt 5 Libraries available. But you have to manually ask for these to be deployed…i.e. Refer to the base of the post at https://groups.io/g/JTSDK/topic/some_dependencies_requisites/75311015?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,75311015 (and repeated a few sentences below) Bill, you are put up as one of the most competent programmers around … I am gravely concerned if you do not understand what I am saying here … Repeated again, unless you deploy the following then there is no way that MOST of the distributions listed at https://physics.princeton.edu/pulsar/K1JT/wsjtx.html will deploy !!!! i.e. steps for Ubuntu 18.04.x and 20.04.x (and similar for many other Debian-based distros) although the -dev packages and perhaps the first line need not be deployed: sudo apt install build-essential gfortran cmake sudo apt install git automake subversion sudo apt install qtcreator sudo apt install libusb-1.0-0-dev libfftw3-dev sudo apt install texinfo asciidoc sudo apt install qtmultimedia5-dev qttools5-dev qttools5-dev-tools libqt5serialport5-dev libqt5multimedia5-plugins sudo apt install libtool libudev-dev sudo apt install packagekit sudo usermod -a -G adm,tty,disk,dialout,audio,video,plugdev <user> <-- This guidance is completely ignored !!!!! * We list the required dependencies at the top of the INSTALL documentation. Accepted…. But there is very POOR to ZERO guidance on how to deploy required dependencies ! There I simply and easily listed dependencies (as a guide) so that people can compile WSJT-X on their Ubuntu 18.04.1 or 20.04.1 distros … Perhaps similar example guidance (maybe even scripts ???) should be provided that should be executed before the prepackaged distros are launched? [ and that I can help with ]. * No special "environment" is required, just installing the required packages using the distribution package management tool (apt, aptitude, dnf, yum, ...). I disagree and you contradict yourself in your discussion. You need the “user libraries” [ or the “dev” libraries]. You need to have your environ PREPARED to be able to take the software first. No guidance is provided for individual release distros. Many man many comments on this forum relates to this !!! Many of us would gladly assist in providing such release-specific documentation…. As that is the HAM (Help All Mankind) way that many of us subscribe to ! Additionally there are significant out of date examples, errors and inconsistencies across the Multiple INSTALL files i.e. INSTALL in wsjtx-2.2.2.tgz\wsjtx-2.2.2.tar\wsjtx-2.2.2\ (one “Small” example from Line 75 – but more identified) : $ cmake -D WSJTX_TAG=wsjtx-2.0.0 <source-dir-path> [ LINE 75, 111, 128, 131 ] – Deprecated version referred to ! [ Line 131 is important as it refers to the NEXT error in the install file ] These as examples are DEFINITELY not correct for the source distros and need modification so that CLEAR GUIDANCE is provided. More serious misdirection exist in the following: i.e. INSTALL in wsjtx-2.2.2.tgz\wsjtx-2.2.2.tar\wsjtx-2.2.2\src\wsjtx.tgz\wsjtx.tar\wsjtx\ References: Line 92 $ cmake -D CMAKE_PREFIX_PATH=~/hamlib-prefix ../src SHOULD BE: $ cmake -D -DWSJT_SKIP_MANPAGES=ON -DWSJT_GENERATE_DOCS=OFF CMAKE_PREFIX_PATH=~/hamlib-prefix ../src <-- [ Better than the example you provided later in your email ] [ there is also the error/inconsistencies at the “top level” INSTALL file where the “sudo” is included before cmake --build . --target install … but in the wsjtx.tar version of install no SUDO appears before this !!! Minor I know but important to teach others !!! Compare this to Line 94 in the wsjtx.tar INSTALL file !!!!! ] This error in documentation is SIGNIFICANT as it has generated considerable comment already in this place ! Many of us have been pointing this out for some time … and for a long time (since 2.0.0). So please fix this…. That has been all I have been asking for a long time. Perhaps there should only be ONE INSTALL in the entire source distro????? * Debian packages do not "pull" dependencies, that is the job of the package management software. The Debian packages list the requirements, as do RPM package on RedHat style systems. If packages are not in the distribution repositories the dependencies can be "pulled" using different tools, gdebi for example. So provide BETTER instructions for people to ensure that they have the appropriate Qt5 etc. dependencies loaded. There are scripted ways of fixing this …. I deal with maybe 10 PM’s relating to this a week – people too scared to post here for fear that they will be belittled by a big name in AR. * INSTALL files were mostly correct at the time of release, yes there are a couple of errors which this thread started with by someone pointing them out, and as I noted in reply to them, they are fixed for the next release. You could have done the same rather than throw all your derogatory comments at the WSJT-X development team. Yes; My point is that SOME of us have been pointing this out for a while BUT CHANGES ARE NOT MAKING IT THROUGH; is it because some of us are ignored and not responded to because we are troublesome? It appears to many – and there is lots of background email that supports this – that some are ignored “just because you do not like them”….. But that is contrary to the HAM – Help All Mankind – Principle. It is HAM that will ensure that AR is still around long after we are all dead. * We have a release schedule, … Where When? Where is the cycle? And again how can we observe if interim changes have been made to solve issues? Where do I find this on Joe’s release site? There are ways of using SourceForge and other GIT-repos to show dynamic changes without releasing everything as a GIT PULL …. Perhaps the development cycle needs to be partially reopened again??? * we do not make releases to fix minor issues that can wait until the next release. The stability of Hamlib pre-release versions has been an issue due to the high volume of changes. Yes: much of the stability issues in Hamlib has been caused by changes forced onto it to do things that its not really intended to do. THE CORE WSJT_X DEVELOPMENT TEAM have forced changes. User software should solely work to interfaces and their specification. It should NEVER drive interfaces. Yet there is this almost mad passion to work with inconsistently hardware manufacturer-applied split functionality !!!!! Hamlib is not just for WSJT-X !!!! Many are commenting how badly some developing Hamlib appear to be being treated… This may or may not be the case/intent ! yet it is the appearance ! I’ll say this clearly again … Software MUST work to Interfaces and their specification. Software should never DRIVE interfaces. [ Perhaps a rethink – with regards to simplicity – is required around the “split functionality” and use of “split functions” ???? ] * .. Note that I am not throwing complaints at the Hamlib team here, I am a member of that team and fully understand the release cycle for that package too. Well that is not the appearance to a significant number of us in the AR World. I get asked all the time if there is a war going on – with salvos being fired at some Hamlib developers ! I have to answer to many … ummm… I think so !!! So FIX THIS APPEARANCE !!!! * If I was to use steps documented inside the wsjtx.tar tarball inside the INSTALL file steps will not compile as it lacks the MANPAGE switches. This is EXACTLY the same issue that I am raising if I was to use the .deb files distributed on Joe’s site ! i.e. Things do not work well and properly ! …… You just repeated EVERYTHING that I have been saying – so you DO understand !!!!! Hmmm…… As for misquoting … It comes down to understanding. You have heavily misquoted me – and many are concerned as it appears to have been personally targeted (i.e. Put Steve VK3VM/VK3SIR back in his place) ! It is clear that you have not been understanding – some suggest ignoring - what I am trying to communicate. It is also clear that on occasion comments are being made without Scientific method being properly applies (i.e. TESTING … Assumptions just have been made). I am sorry, but much of what I am reporting confirms this. Yes I have done the testing … Very thoroughly … Otherwise I’d be a fool posting here ! Here is a summary of NECESSARY tasks/changes that I have been putting forward: * You cannot just install from the “packages” listed at https://physics.princeton.edu/pulsar/K1JT/wsjtx.html unless you have all the prerequisite libraries loaded. * Better guidance for pre-requisites is required * If you have a full development environ loaded then you will meet the requisites * If not … Inadequate guidance is provided… * It is actually simpler and easier in most cases – because of missing requisite issues – to guide interested people into compiling their own source. * Being a heavy contributor (if not the only current contributor) to the JTSDK that is within my brief ! * Content across all the INSTALL files needs reviewing, updating and standardising. * That you have acknowledged ! As I said I am here to help and advance AR. I am not about playing ego games or playing “who can pee highest up a wall”…. That is ego. Its ego that is the greatest enemy of AR at the moment. 73, and if I am unclear in any respect please PM me and I’ll give you my Skype Address so we can chat via text or voice. Steve I VK3VM / VK3SIR
_______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
