SBo scripts not building on current (read 1st post, pls)

ennepath · 06-06-2020, 12:44 PM

Quote:

Originally Posted by ponce

you should have a look at google-go-lang's README, it mentions some files in /etc/profile.d that are loaded when you login.
so you should logout from your user session and login again, then become root with "su -" (so that you have a root login shell) and try to build it again.

Nevermind, I posted the issue multiple hours ago. While was waiting for premoderation I found what was wrong. It's not about relogin - I did that. I've found two go binaries in my system. The first one in /usr/bin/go and the second one in /usr/lib64/go1.13.10/go/bin/go. I have no idea what is the source of such problem. My user doesn't have /usr/lib64/go1.13.10 in PATH, so I just removed /usr/bin/go and added symlink from /usr/lib64/go1.13.10/go/bin/go to /usr/bin/go. Now it's OK.

My 2 cents about "then become root with "su -" (so that you have a root login shell) and try to build it again." I will never do such thing because I don't want to make my system a mess. I usually build everything I need as unprivileged user, then create a packages with makepkg and install it with installpkg.

ponce · 06-06-2020, 12:52 PM

Quote:

Originally Posted by ennepath

Nevermind, I posted the issue multiple hours ago. While was waiting for premoderation I found what was wrong. It's not about relogin - I did that. I've found two go binaries in my system. The first one in /usr/bin/go and the second one in /usr/lib64/go1.13.10/go/bin/go. I have no idea what is the source of such problem. My user doesn't have /usr/lib64/go1.13.10 in PATH, so I just removed /usr/bin/go and added symlink from /usr/lib64/go1.13.10/go/bin/go to /usr/bin/go. Now it's OK.

sorry, but that is wrong: doing this you have removed a file installed by the gcc-go package (that will also be re-installed again when you will upgrade this package).
you don't need to do that because the files in /etc/profile.d/ should take care to set the correct paths at the next login: check again then and you will see that you will use the correct interpreter.
remember to always read the READMEs of stuff you install from SBo.

Quote:

My 2 cents about "then become root with "su -" (so that you have a root login shell) and try to build it again." I will never do such thing because I don't want to make my system a mess. I usually build everything I need as unprivileged user, then create a packages with makepkg and install it with installpkg.

you shouldn't fear that as the scripts from SBo should be tested for non-proper behaviour: for this refer to FAQ #11.
also, if you do what you just wrote, the directories and files created as an unprivileged user will be packaged and then installed with that user ownerships and permissions, and *that* will actually wreck your system.

ennepath · 06-06-2020, 01:38 PM

Quote:

Originally Posted by ponce

sorry, but that is wrong: doing this you have removed a file installed by the gcc-go package (that will also be re-installed again when you will upgrade this package).
you don't need to do that because the files in /etc/profile.d/ should take care to set the correct paths at the next login: check again then and you will see that you will use the correct interpreter.

Probably, wrong. But relogin didn't solve the problem of having two conflicting versions of go binary.

Quote:

remember to always read the READMEs of stuff you install from SBo.

Always do.

Quote:

you shouldn't fear that as the scripts from SBo should be tested for non-proper behaviour: for this refer to FAQ #11.
also

I'm not talking about SBo scripts since they require to be executed as root. I'm talking about building packages from source.

Quote:

if you do what you just wrote, the directories and files created as an unprivileged user will be packaged and then installed with that user ownerships and permissions, and *that* will actually wreck your system.

I didn't mean I use makepkg as unprivileged user. Just build programs as non root. The other stuff from makepkg to installpkg I do as root of course. makepkg provides an opportunity to change permissions and ownership of files to be packaged.

Anyway, thanks for response.

ponce · 06-06-2020, 01:55 PM

Quote:

Originally Posted by ennepath

Probably, wrong. But relogin didn't solve the problem of having two conflicting versions of go binary.

but they are actually not conflicting as you can use one or the other, depending on what you need and the environment variables you set (PATH, GOROOT, etc.).

Quote:

I'm not talking about SBo scripts since they require to be executed as root. I'm talking about building packages from source.

fine, but I was answering about your syncthing inquiry: as I explained, to load scripts from /etc/profile.d, you need to open a root shell with "su -" (if you don't source them manually).

Quote:

Originally Posted by ennepath

makepkg provides an opportunity to change permissions and ownership of files to be packaged.

some packages (actually not just a few) might need to have special permissions and ownerships for directories and files they install, so be advised that the workflow you propose won't always work.

ennepath · 06-06-2020, 02:07 PM

Quote:

Originally Posted by ponce

but they are actually not conflicting as you can use one or the other, depending on what you need and the environment variables you set (PATH, GOROOT, etc.).

fine, but I was answering about your syncthing inquiry: as I explained, to load script from /etc/profile.d, you need to open a root shell with "su -".

AFAIK, when there are two binaries in PATH with the same name the one you call by name is the binary that closer to start of PATH value. Since relogin (I confess I didn't know about this function of /etc/profile.d/* scripts) didn't do the trick, it ended up for me with two different binaries in PATH. I was unable to use the right one by calling it by name without full path. You absolutely right about I "fixed" it in a wrong way. I've already reinstall gcc-go and set up necessary paths manually. Now it works as expected. Thank you.

P.S. Seems like I offended you. Don't take it personally. My english skills are far from good and my messages might (but should not) be treated as rough. Sorry for that.

ponce · 06-06-2020, 02:18 PM

Quote:

Originally Posted by ennepath

Seems like I offended you. Don't take it personally. My english skills are far from good and my messages might (but should not) be treated as rough. Sorry for that.

no prob at all, I didn't get it that way!
please use the same care with my messages as I'm not a native english speaker too and, trying to give short answers to do the less errors possible, I might result in a tone different from the intended one

bassmadrigal · 06-07-2020, 12:09 AM

@ennepath, I'm not sure if you realized it yet, but the system will execute the first go it comes across based on the PATH variable. When you don't run the /etc/profile.d/go.sh script, it will use the /usr/bin/go binary. But when it runs the go.sh script, it will add the /usr/lib64/go1.13.8/go/bin location to the beginning of the PATH variable, which will make it run the go found in /usr/lib64/go1.13.8/go/bin over the one found in /usr/bin/

Code:

jbhansen@craven-moorhead:~$ sudo su
root@craven-moorhead:/home/jbhansen# which go
/usr/bin/go
root@craven-moorhead:/home/jbhansen# echo $PATH
/usr/local/sbin:/usr/local/bin:/sbin:/usr/sbin:/bin:/usr/bin
root@craven-moorhead:/home/jbhansen# su -
--snip fortune--
root@craven-moorhead:~# which go
/usr/lib64/go1.13.8/go/bin/go
root@craven-moorhead:~# echo $PATH
/usr/lib64/go1.13.8/go/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/games:.:/usr/lib64/java/bin:/usr/lib64/java/jre/bin:/usr/lib64/kde4/libexec:/usr/lib64/qt/bin:/usr/lib64/qt5/bin:/usr/share/texmf/bin

qunying · 06-09-2020, 12:00 PM

I could not get 0ad compiled, after adding the 2 lines below, it seems compiled fine.

Code:

sed -i '/include <sstream>/a #include <deque>' ./source/third_party/cppformat/format.h
sed -i '/include "ps\/Profiler2.h"/a #include <stack>' ./source/ps/Profiler2GPU.cpp

ponce · 06-09-2020, 12:29 PM

Quote:

Originally Posted by qunying

I could not get 0ad compiled, after adding the 2 lines below, it seems compiled fine.

Code:

sed -i '/include <sstream>/a #include <deque>' ./source/third_party/cppformat/format.h
sed -i '/include "ps\/Profiler2.h"/a #include <stack>' ./source/ps/Profiler2GPU.cpp

thanks, pushed!

hpfeil · 06-12-2020, 03:34 PM

When I wget jdk-8u251-linux-x64.tar.gz using the link in development/jdk/jdk.info, I get an html file that upon further examination is the signon page, https://login.oracle.com/mysso/signon.jsp. Jdk14 builds correctly using jdk-14.0.1_linux-x64_bin.tar.gz.

ponce · 06-12-2020, 04:00 PM

Quote:

Originally Posted by hpfeil

When I wget jdk-8u251-linux-x64.tar.gz using the link in development/jdk/jdk.info, I get an html file that upon further examination is the signon page, https://login.oracle.com/mysso/signon.jsp.

please read jdk's README.

lioh · 06-14-2020, 10:11 AM

owncloud-client fails to build with the following errors:

Code:

/tmp/SBo/owncloudclient-2.5.4.11654/src/libsync/networkjobs.cpp: In static member function 'static QImage OCC::AvatarJob::makeCircularAvatar(const QImage&)':
/tmp/SBo/owncloudclient-2.5.4.11654/src/libsync/networkjobs.cpp:653:18: error: aggregate 'QPainterPath path' has incomplete type and cannot be defined
  653 |     QPainterPath path;
      |                  ^~~~
At global scope:
cc1plus: warning: unrecognized command line option '-Wno-gnu-zero-variadic-macro-arguments'
make[2]: *** [src/libsync/CMakeFiles/owncloudsync.dir/build.make:226: src/libsync/CMakeFiles/owncloudsync.dir/networkjobs.cpp.o] Error 1
make[2]: Leaving directory '/tmp/SBo/owncloudclient-2.5.4.11654/build'
make[1]: *** [CMakeFiles/Makefile2:439: src/libsync/CMakeFiles/owncloudsync.dir/all] Error 2
make[1]: Leaving directory '/tmp/SBo/owncloudclient-2.5.4.11654/build'
make: *** [Makefile:172: all] Error 2

BrunoLafleur · 06-14-2020, 11:11 AM

It is due to the upgrade of qt5.13 towards qt5.15
You should add :
#include <QPainterPath>

In the file :
owncloudclient-2.5.4.11654/src/libsync/networkjobs.cpp

You can do a patch and add it to the SBo package.

You can also suggest the fix to the author of owncloudclient but maybe they saw it and it is on the master branch ?
The fix is compatible with the 5.13 version of qt5.

RadicalDreamer · 06-14-2020, 12:58 PM

chromaprint-1.4.3 wouldn't install for me if I had my customized FFMPEG 4.2.3 installed which has chromaprint as a dependency. chromaprint-1.5.0 could be built too if FFMPEG was removed first. The Slackbuild had to be modified a little because the directory is called chromaprint-1.5.0 now with the v removed before the version number.

ponce · 06-14-2020, 02:32 PM

Quote:

Originally Posted by RadicalDreamer

chromaprint-1.4.3 wouldn't install for me if I had my customized FFMPEG 4.2.3 installed which has chromaprint as a dependency. chromaprint-1.5.0 could be built too if FFMPEG was removed first. The Slackbuild had to be modified a little because the directory is called chromaprint-1.5.0 now with the v removed before the version number.

well, I am not able to reproduce it.
I have tested it like this:
- first I built chromaprint against the stock ffmpeg in Slackware and installed it at the end;
- then I rebuilt ffmpeg with most of the optional dependencies enabled, included chromaprint, and upgraded with the new package the stock ffmpeg;
- then I rebuilt chromaprint against the new ffmpeg.
everything went fine here...

BTW, I'll have a look ASAP at the newer chromaprint...