I am exploring a production-stable proxy for redis cluster called codis . It is a mentioned as a great alternative to twemproxy, especially as one of my needs is pipelining and twemproxy does not offer that.
However the documentation in English is still a WIP and the replies to github issues are in mandarin.
I am trying to install this on
Linux version 3.13.0-74-generic (buildd#lcy01-07) (gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) ) #118-Ubuntu SMP
I have installed go version 1.8 and I can see the folder /usr/local/go/bin. I have added this to the PATH variable as well.
However, when on executing the command go get -u -d github.com/CodisLabs/codis, I am getting the following :
package github.com/CodisLabs/codis:
no buildable Go source files in /home/ubuntu/go/src/github.com/CodisLabs/codis
You probably want to use the updated install outlined at https://github.com/CodisLabs/codis/issues/1180#issuecomment-286660086
seems the English docs might be out of date https://github.com/CodisLabs/codis/issues/1179#issuecomment-286662505
Related
I am trying to use the latest version of the appImage-builder because appimages of my application built with the old version of appImage-builder do not run on ubuntu 22.04 anymore. So I got the order to try and see if it works with the new appImage-builder.
Currently (June 2022), only versions below 1.0 which are based on ubuntu 18.04 are available on docker (which we previously used to build our appimage).
The newer versions are available via github (https://github.com/AppImageCrafters/appimage-builder/releases).
However, I seem to be unable to execute:
appimage-builder --generate
or
appimage-builder --recipe AppImageBuilder.yml
Is there any documentation available on how to correctly use the .appimage version of appImage-builder? All I could find in https://appimage-builder.readthedocs.io/en/latest/ seems to refer to the docker version or a manually built version of appImage-builder.
Depending on the error message you get, there could be a couple of issues at play here.
If you got an error related to FUSE, then you need to install the libfuse2 package with apt install libfuse2. AppImages rely on libfuse2, but Ubuntu has stopped including it since 22.04, in favor of libfuse3.
If you get an error related to "file not found", then it could be that you do not have AppImageLauncher installed. Sadly, with type 2 AppImages the design decision was taken to modify the ELF header of the executable with 3 magic bytes at offset 8 of the executable. This means that Linux linkers will not run the file. AppImageLauncher actually copies the file to a temporary directory and zeroes out the magic number in order to be able to execute it.
A good starting point for debugging issues like this is to run the strace command, which will let you see which system call likely cause the error. Keep in mind that if you try to execute a file and you get File not found, it might mean that the linker specified by the file can not be found on the system or the ELF header is not valid. You can also run the executable by using the linker directly, which might give you more clues. For example with: /lib64/ld-linux-x86-64.so.2 <NAME-OF-YOUR-EXECUTABLE>.
I have installed the go language in my ubuntu using sudo apt install golang-go.
It was successfully installed. When i run go version I am getting go version go1.10.4 linux/amd64
but when i tried running go mod init projectName I am getting the following error go: unknown subcommand "mod"
Do I need to install mod package or am i missing something? I have implemented the solution given by christophe in this forum but it didn't work for me.
Preliminary module support was added in Go 1.11, so Go 1.10 knows no mod subcommand.
You need to install a newer, preferably the newest 1.14 version of Go. Get it from the official downloads page. Go 1.10 is not even supported anymore (doesn't receive security patches).
The prepared packages of OSes usually lag behind new releases. I'd advise to always get Go from the official page.
Because preliminary support for go-modules came in version 1.11 and 1.12.
More here
I suggest that you install using the linux build directly from golang
When I try to run any Go script it show me this error
I installed go lang step by step from this link
https://www.tecmint.com/install-go-in-linux/
When I setup go script like this
go get github.com/tomnomnom/waybackurls
I got error like this
github.com/tomnomnom/waybackurls
src/github.com/tomnomnom/waybackurls/main.go:191: u.Hostname undefined
(type *url.URL has no field or method Hostname)
If you are following the guide you linked by copy-pasting commands, you will have installed Go 1.7.3. The function url.Hostname() was added in Go 1.8.
I suggest completely ignoring that guide. Remove /usr/local/go, remove ~/go_projects and undo the path related stuff.
Instead, use the package manager of your OS to install Go.
Most likely, this means you should do either sudo apt install golang (for Ubuntu, Debian, ...) or sudo dnf install golang (Fedora, CentOS, ...).
That will give you the latest version that is supported by distro maintainer (which at the moment is probably 1.11 or 1.12, depending on your distro).
As an alternative to the packagemanager, download the latest version from https://golang.org/dl/.
This approach also gives you an installation that follows the Go ecosystem their conventions for paths (I'm not sure if ~/go_projects was ever a think, but it isn't today).
I'm trying to compile the libxkbcommon library for kodi for my Raspberry Pi 2.
The host machine is a dedicated Server running Ubuntu 16.04 x64.
Now there are two errors when I'm trying to compile libxkbcommon, depending on what yacc I'm using:
byacc:
YACC src/xkbcomp/parser.c
yacc: e - line 219 of
"/opt/kodi/xbmc/tools/depends/target/libxkbcommon/raspberry-pi2-release/src/xkbcomp/parser.y", syntax error
%destructor { FreeStmt((ParseCommon *) $$); }
^
Makefile:1637: recipe for target 'src/xkbcomp/parser.c' failed
btyacc:
parser.y:85: syntax error
Here is the source code of libxkbcommon:
https://github.com/xkbcommon/libxkbcommon
The xbcomp/parser.y file requires a number of (very useful) bison extensions, so it can't be processed by all yacc variants.
btyacc does not support bison-compatible pure-parser declarations. (It has a different, not entirely compatible mechanism which implements the same feature.) So it fails on the first instance of one of those declarations.
It should be possible to use byacc, but not the version which is available in the Ubuntu package repository. Although the Ubuntu package repository change history seems to suggest that the intention was to include the build option which allows %destructor, the actual binary currently available in the byacc repository was built without that option. (It is also several years old, and I think it would be useful to use a more recent version.) I reported this as launchpad bug 1776270, along with a suggestion for a possible fix.
I'm sure you'll be able to build the software using Gnu bison, which is available as the Ubuntu package bison. Since that's the most popular yacc version installed on developer machines, a failure to build with bison would probably have been noticed long ago.
If you would prefer to use byacc, for whatever reason, you'll have to download and build it yourself. You can get the most recent version from Thomas Dickey's byacc page, and then build it with the usual procedure: untar, configure, make, make install. When I tested this, I used the following configure line:
./configure --enable-btyacc --program-prefix=b --prefix=/usr
Only the first option is mandatory
* --program-prefix=b Install it as `byacc` rather than `yacc`
* --enable-btyacc Necessary for %destructor support
* --prefix=/usr Install it in /usr/bin and /usr/man. The default
is /usr/local/bin and /usr/local/man, which failed on
my Ubuntu install because of a missing -D option in the
install command in the Makefile.
I am following the doc (http://mesos.apache.org/gettingstarted/) and trying to install Mesos on my mac. When I try to configure it, it gives me the error:
checking python extra linking flags... -u _PyMac_Error Python.framework/Versions/2.7/Python
checking consistency of all components of python development environment... no
configure: error: in `/Users/syang/Desktop/git/mesos/build':
configure: error:
Could not link test program to Python. Maybe the main Python library has been
installed in some non-standard library path. If so, pass it to configure,
via the LDFLAGS environment variable.
Example: ./configure LDFLAGS="-L/usr/non-standard-path/python/lib"
============================================================================
ERROR!
You probably have to install the development version of the Python package
for your distribution. The exact name of this package varies among them.
============================================================================
I use Python 2.7.8 and I am trying to install Mesos 0.23.0. I did some search, it looks like after installing command tools using xcode, the linking problem should get handled. However, it doesn't look like that to me. Is there anyone who has similar experience and can help me?
Thank you.
The easiest way of running Mesos on local machine is to use https://github.com/bobrik/mesos-compose (Docker) or https://github.com/mesosphere/playa-mesos (Vagrant)
There are a bit different when build it in OSX. You could use "brew install mesos" to install it directly. https://github.com/Homebrew/homebrew/tree/master/Library/Formula/mesos.rb also show how to build mesos in osx.
I dont know if you have resolved this issue but for future reference I would like to suggest the below steps based on this blog http://gwikis.blogspot.com/2015/08/building-mesos-0230-on-os-x-yosemite.html
$ cd mesos-0.x./build/
$ PYTHON=/usr/bin/python ../configure
Moreover in case that you receive any errors like libapr-1 is required for mesos to build. or libsubversion-1 is required for mesos to build. then you could do the following, assuming that apr and subversion libs are installed with brew.
$ PYTHON=/usr/bin/python ../configure -with-svn=/usr/local/Cellar/subversion/1.8.13/ -with-apr=/usr/local/Cellar/apr/1.5.2/libexec/
To verify why the Python path is not correct and the compile fails in the first place please go once through the blogpost.