I'm unable to install the crossbar.io WAMP router's binary distro on FreeBSD 10.1
I'm doing it step-by-step by the manual (http://crossbar.io/docs/Installation-on-FreeBSD/), but during the pkg install crossbar i get this output:
Updating FreeBSD repository catalogue...
Fetching meta.txz: 100% 944 B 0.9kB/s 00:01
Fetching packagesite.txz: 100% 6 MiB 2.9MB/s 00:02
Processing entries: 100%
FreeBSD repository update completed. 25427 packages processed.
Updating crossbar repository catalogue...
crossbar repository is up-to-date.
Checking integrity... done (0 conflicting)
The following 1 package(s) will be affected (of 0 checked):
New packages to be INSTALLED:
crossbar: 0.13.2 [crossbar]
Number of packages to be installed: 1
The process will require 161 MiB more space.
Proceed with this action? [y/N]: y
[1/1] Installing crossbar-0.13.2...
[1/1] Extracting crossbar-0.13.2: 0%
pkg: Directory /opt/crossbar/lib-python/2.7/plat-mac/lib-scriptpackages/SystemEvents not specified in the manifest
[1/1] Extracting crossbar-0.13.2: 100%
And nothing's get installed only empty folders under /opt/crossbar
Am I doing something wrong?
Any input will be appreciated.
Related
Just realized that these two Python libraries:
colour · PyPI (pip install colour)
colour-science · PyPI (pip install colour-science)
... use the exact same import - and are therefore in conflict:
import colour
In my MSYS2 installation, I have noticed this:
$ pacman -Ss colour
mingw32/mingw-w64-i686-python-colour 1~0.1.5-1
converts and manipulates various color representation (HSL, RVB, web, X11, ...) (mingw-w64)
mingw32/mingw-w64-i686-python-colour-science 0.3.16-1
Python library for a multitude of colour science applications (mingw-w64)
mingw64/mingw-w64-x86_64-python-colour 1~0.1.5-1 [installed]
converts and manipulates various color representation (HSL, RVB, web, X11, ...) (mingw-w64)
mingw64/mingw-w64-x86_64-python-colour-science 0.3.16-1
Python library for a multitude of colour science applications (mingw-w64)
... and my earlier use of colour-science was gone, so I tried this:
$ pacman -S mingw-w64-x86_64-python-colour-science
resolving dependencies...
looking for conflicting packages...
:: mingw-w64-x86_64-python-colour-science and mingw-w64-x86_64-python-colour are in conflict. Remove mingw-w64-x86_64-python-colour? [Y/n] y
Packages (3) mingw-w64-x86_64-python-colour-1~0.1.5-1 [removal] mingw-w64-x86_64-python-imageio-2.9.0-2
mingw-w64-x86_64-python-colour-science-0.3.16-1
Total Download Size: 2.66 MiB
Total Installed Size: 20.19 MiB
Net Upgrade Size: 20.08 MiB
:: Proceed with installation? [Y/n] y
:: Retrieving packages...
mingw-w64-x86_64-python-imageio-2.9.0-2-any 379.3 KiB 1574 KiB/s 00:00 [#################################################] 100% mingw-w64-x86_64-python-colour-science-0.3.16-1-any 2.3 MiB 2.17 MiB/s 00:01 [#################################################] 100% (2/2) checking keys in keyring [#################################################] 100% (2/2) checking package integrity [#################################################] 100% (2/2) loading package files [#################################################] 100% (2/2) checking for file conflicts [#################################################] 100% (3/3) checking available disk space [#################################################] 100% :: Processing package changes...
(1/1) removing mingw-w64-x86_64-python-colour [#################################################] 100% (1/2) installing mingw-w64-x86_64-python-imageio [#################################################] 100% Optional dependencies for mingw-w64-x86_64-python-imageio
mingw-w64-x86_64-freeimage [installed]
mingw-w64-x86_64-python-tifffile
(2/2) installing mingw-w64-x86_64-python-colour-science [#################################################] 100%
So, I cannot use both colour and colour-science libraries via pacman in MSYS2, which does make sense ...
But in principle - is there any way I could use both of these libraries at the same time, even if not via the package manager?
I am following the steps on for unix like systems https://elixir-lang.org/install.html#unix-and-unix-like
this is the error that I am getting
sudo apt-get install esl-erlang
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
esl-erlang : Depends: libncurses5 but it is not installable
Depends: libsctp1 but it is not installable
Recommends: erlang-mode but it is not going to be installed
E: Unable to correct problems, you have held broken packages
I tried using asdf-vm as well but still the same libcurses5 issue is there
asdf install erlang 21.1
asdf_21.1 is not a kerl-managed Erlang/OTP installation
No build named asdf_21.1
Downloading OTP-21.1.tar.gz to /home/superuser/.asdf/plugins/erlang/kerl-home/archives
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 120 100 120 0 0 241 0 --:--:-- --:--:-- --:--:-- 241
100 51.3M 0 51.3M 0 0 4747k 0 --:--:-- 0:00:11 --:--:-- 3990k
Extracting source code
Building Erlang/OTP 21.1 (asdf_21.1), please wait...
WARNING: It appears that a required development package 'libncurses5-dev' is not installed.
Configure failed.
checking whether lock counters should be enabled... no
checking whether dlopen() needs to be called before first call to dlerror()... no
checking for kstat_open in -lkstat... (cached) no
checking for tgetent in -ltinfo... no
checking for tgetent in -lncurses... no
checking for tgetent in -lcurses... no
checking for tgetent in -ltermcap... no
checking for tgetent in -ltermlib... no
configure: error: No curses library functions found
The problem was that with cosmic the repositories were not available on http://archive.ubuntu.com.
changing them in /etc/apt/sources.list i.e replacing all occurences of http://archive.ubuntu.com with http://old-releases.ubuntu.com did the trick.
I am using IntelliJ's rust plugin (version 0.2.0.2114-182) with IDEA (2018.2.3).
There is a yellow bar at the top of my editor window that says "cannot attach stdlib sources automatically without rustup". This is not surprising since gentoo does not use rustup. It compiles rust from source.
There is an option to "attach manually", but I have no idea what directory it wants me to pick; or even what I should look for to figure out what the proper directory is; and I'm not even sure the gentoo ebuild created a directory with the necessary stdlib sources.
How can I provide the stdlib sources to the rust plugin in a way that is compatible with gentoo's package management system? It seems like answers to How to provide standard library sources for IntelliJ IDEA's Rust project? bypass gentoo's ebuilds and might cause the accumulation of cruft over time.
The dev-lang/rust Gentoo package has an rls use-flag (standing for Rust Language Server), which has a side-effect of installing Rust sources to /usr/lib/rustlib/src:
$ equery files dev-lang/rust | grep lib.rs
/usr/lib/rustlib/src/rust/src/libcore/lib.rs
/usr/lib/rustlib/src/rust/src/libstd/lib.rs
(...)
The solution is therefore to enable the rls use-flag and then point Intellij IDEA to /usr/lib/rustlib/src/rust/src:
I believe this is a more idiomatic solution on Gentoo than to bypass portage and/or use rustup.
Note that dev-lang/rust-bin package currently does not have the rls use-flag and I haven't found a way to install Rust lib sources with it.
Contributions regarding dev-lang/rust use-flags (and their docs) in Gentoo would be probably appreciated.
I have an experimental technique that has different warts from the solution Sven found:
I installed rustup in addition to having the gentoo-managed rust ebuild.
$ wget -O sh.rustup.rs https://sh.rustup.rs
--2019-09-24 10:28:49-- https://sh.rustup.rs/
Resolving sh.rustup.rs... 13.249.122.62, 13.249.122.9, 13.249.122.96, ...
Connecting to sh.rustup.rs|13.249.122.62|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 10782 (11K) [text/x-sh]
Saving to: 'sh.rustup.rs'
sh.rustup.rs 100%[===================>] 10.53K --.-KB/s in 0.001s
2019-09-24 10:28:49 (10.4 MB/s) - 'sh.rustup.rs' saved [10782/10782]
However, rustup is sad that I already have rust installed in /usr/bin
$ sh sh.rustup.rs
info: downloading installer
error: it looks like you have an existing installation of Rust at:
error: /usr/bin
error: rustup cannot be installed alongside Rust. Please uninstall first
error: if this is what you want, restart the installation with `-y'
error: cannot install while Rust is installed
Brute force "solves" this problem:
$ sh sh.rustup.rs -y
info: downloading installer
info: syncing channel updates for 'stable-x86_64-unknown-linux-gnu'
info: latest update on 2019-08-15, rust version 1.37.0 (eae3437df 2019-08-13)
info: downloading component 'rustc'
85.3 MiB / 85.3 MiB (100 %) 9.6 MiB/s in 9s ETA: 0s
info: downloading component 'rust-std'
61.2 MiB / 61.2 MiB (100 %) 8.2 MiB/s in 8s ETA: 0s
info: downloading component 'cargo'
info: downloading component 'rust-docs'
11.3 MiB / 11.3 MiB (100 %) 8.4 MiB/s in 1s ETA: 0s
info: installing component 'rustc'
85.3 MiB / 85.3 MiB (100 %) 18.4 MiB/s in 4s ETA: 0s
info: installing component 'rust-std'
61.2 MiB / 61.2 MiB (100 %) 20.9 MiB/s in 5s ETA: 0s
info: installing component 'cargo'
info: installing component 'rust-docs'
11.3 MiB / 11.3 MiB (100 %) 606.4 KiB/s in 9s ETA: 0s
info: default toolchain set to 'stable'
stable installed - rustc 1.37.0 (eae3437df 2019-08-13)
Rust is installed now. Great!
To get started you need Cargo's bin directory ($HOME/.cargo/bin) in your PATH
environment variable. Next time you log in this will be done automatically.
To configure your current shell run source $HOME/.cargo/env
After that you might want to rig rustup to use the same version the ebuild installed (or maybe you want to leave it tracking the latest stable, your choice)
$ equery list rust
* Searching for rust ...
[IP-] [ ] dev-lang/rust-1.34.2:stable/1.34
$ rustup default 1.34.2
info: using existing install for '1.34.2-x86_64-unknown-linux-gnu'
info: default toolchain set to '1.34.2-x86_64-unknown-linux-gnu'
1.34.2-x86_64-unknown-linux-gnu unchanged - rustc 1.34.2 (6c2484dc3 2019-05-13)
But you definitely want the rust-src component
$ rustup component add rust-src
info: downloading component 'rust-src'
info: installing component 'rust-src'
After that, the rust stdlib sources should be in $HOME/.rustup/toolchains/$VERSION-$ARCH/lib/rustlib/src/rust/src and you should be able to enter that path into the settings for the rust plugin.
You may also use that settings dialog to choose your toolchain (/usr/bin, $HOME/.cargo/bin, or $HOME/.rustup/toolchains/$VERSION-$ARCH/bin; I'm just guessing that .cargo/bin points to whatever rustup default you have set at the moment).
The drawback to this solution is that you now have 2 (or more) installations of rust. The system ebuild, plus any versions you have installed into $HOME/.cargo and $HOME/.rustup using rustup. There may be more problems, considering that I've only been using this for an hour or so.
Had the same problem. The solution I settled for is to use rustup and remove portage's rust from my system. You can then tell portage to assume rust is provided by using /etc/portage/package.provided to make emerges like firefox work with rustup's version.
Here is a short article describing the process: https://laumann.xyz/gentoo/2018/05/01/gentoo-package-provided.html
Iirc you don't need everything he puts in bash.profile at the end, but right now I can't tell you what exactly you can leave out
The paths mentioned by the other posts are correct:
"/usr/bin" for the "toolchain location".
"/usr/lib/rustlib/src/rust/library" for the "standard library".
After having set them the plugin was able to work correctly but the "autocomplete" for methods/functions that belong to Rust's standard library was still not working (same problem on all my 3 Gentoo notebooks, reproduced with CLion 2021.2 & 2021.3 + Rust plugin 0.4.164 and some other older versions + Rust 1.58.1 & 1.56.1).
For example, when typing "String::" I didn't get the list that shows its functions/methods (e.g. "from()", "as_bytes()", etc...).
To be exact, I that functionality was working the very first time that I set the correct paths, but not anymore after an explicit restart of CLion (it took me a while to realize this, made me crazy).
The root cause of the problem seems to be that the rust-plugin wants to be able to write to the stdlib-directories (I didn't analyze what it writes nor I'm going to speculate).
Example of an error message:
error: failed to write /opt/rust-bin-1.58.1/lib/rustlib/src/rust/library/unwind/Cargo.lock
Until CLion changes this behaviour the workaround would obviously be to make the location of Rust's standard library writeable by the user which is running CLion.
Doing that directly would of course trigger a lot of problems (security + pkg management), thererfore I decided to look for alternatives.
I decided to use OverlayFS to be able to still use Gentoo's original installation of Rust and at the same time to reroute the changes written by CLion to a separate directory.
In my case the details are:
1-
Created the 3 custom dirs needed by OverlayFS:
mkdir /opt/stecustom/clion/clion-rust_stdlib-overlay_upperdir
mkdir /opt/stecustom/clion/clion-rust_stdlib-overlay_workdir
mkdir /mnt/clion-rust_stdlib-overlay-result
2- Did an initial manual "mount":
mount -v -t overlay overlay -o noatime,lowerdir=/usr/lib/rustlib,upperdir=/opt/stecustom/clion/clion-rust_stdlib-overlay_upperdir,workdir=/opt/stecustom/clion/clion-rust_stdlib-overlay_workdir /mnt/clion-rust_stdlib-overlay-result
(the contents of "/usr/lib/rustlib" get on top the additional layer "/opt/stecustom/clion/clion-rust_stdlib-overlay_upperdir" to which all changes will be written - I don't know what "workdir" is supposed to host but it's a required parameter - and the merged layers are made available in " /mnt/clion-rust_stdlib-overlay-result":)
3- Changed in the overlay the ownership of all files:
cd /mnt/clion-rust_stdlib-overlay-result
chown -R MY_NON_ROOT_USER /mnt/clion-rust_stdlib-overlay-result/*
4- Made CLion's Rust plugin use the new overlayed dir:
"/usr/bin" for the "toolchain location" (same as before).
"/mnt/clion-rust_stdlib-overlay-result/src/rust/library" for the "standard library" (new!).
5- Restarted CLion and checked that everything worked
6- Made the overlayfs permanent in "/etc/fstab":
overlay /mnt/clion-rust_stdlib-overlay-result overlay noatime,lowerdir=/usr/lib/rustlib,upperdir=/opt/stecustom/clion/clion-rust_stdlib-overlay_upperdir,workdir=/opt/stecustom/clion/clion-rust_stdlib-overlay_workdir 0 2
7- Rebooted and checked again in CLion.
On a FreeBSD system, when executing "pkg upgrade", there is a message indicating the number of candidates. The pkg documentation does not clarify what these candidates are, or any way to list them.
Example output on a new system...
pkg upgrade
Checking for upgrades (1 candidates): 100%
Processing candidates (1 candidates): 100%
Checking integrity... done (0 conflicting)
Your packages are up to date.
Since the candidates remain after running the command, they cannot be an indication of upgradable packages. So what is a "candidate"? Is there any way to list the candidates?
A 'candidate' is an equivalent of 'potentially affected package'. Life example shows:
# pkg upgrade -n
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
Checking for upgrades (251 candidates): 100%
Processing candidates (251 candidates): 100%
The following 250 package(s) will be affected (of 0 checked):
Installed packages to be REMOVED:
ImageMagick-6.9.9.28_2,1
New packages to be INSTALLED:
xkeyboard-config: 2.24_1
...
Number of packages to be removed: 1
Number of packages to be installed: 9
Number of packages to be upgraded: 195
Number of packages to be reinstalled: 45
tl;dr: I tried to install node.js on my ARMv7-based Cubox running Ubuntu 12.10 (quantal). When compiling node.js from source (see "Second attempt" below), node produces a segmentation fault. What can I do here?
First attempt
First of all, I tried to install node.js via the package manager, following the instructions for Ubuntu that are given here: Installing Node.js via package manager: Ubuntu, Mint
Adding the repository mentioned there using sudo add-apt-repository ppa:chris-lea/node.js seems to work fine:
You are about to add the following PPA to your system:
Evented I/O for V8 javascript. Node's goal is to provide an easy way to build scalable network programs
More info: https://launchpad.net/~chris-lea/+archive/node.js
Press [ENTER] to continue or ctrl-c to cancel adding it
gpg: keyring `/tmp/tmpp0owib/secring.gpg' created
gpg: keyring `/tmp/tmpp0owib/pubring.gpg' created
gpg: requesting key C7917B12 from hkp server keyserver.ubuntu.com
gpg: /tmp/tmpp0owib/trustdb.gpg: trustdb created
gpg: key C7917B12: public key "Launchpad chrislea" imported
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)
OK
However, sudo apt-get install nodejs gives me the error:
E: Unable to locate package nodejs
I assume this is because I have an ARM-based system. As far as I can tell from the package details, the repo only contains builds for i386 and amd64. Is my assumption right?
Second attempt
So my next attempt was to install node.js from source. I used the instructions given in the following gist: Node.js and NPM in 30 seconds. Everything seems to work, including make install. But the execution of the install.sh script in the last line of the gist fails since node produces a segmentation fault. Now I wonder what I can do to properly install node.js on my machine?
In order to illustrate my problem, here is some output:
install.sh output
This is the ouput of install.sh after running make install, as described in the gist installation instructions mentioned above.
cyroxx#cubox:~/node-latest-install$ curl https://npmjs.org/install.sh | sh
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 7882 100 7882 0 0 11251 0 --:--:-- --:--:-- --:--:-- 14984
tar=/bin/tar
version:
tar (GNU tar) 1.26
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by John Gilmore and Jay Fenlason.
install npm#latest
fetching: http://registry.npmjs.org/npm/-/npm-1.2.21.tgz
Segmentation fault
Segmentation fault
You need node to run this program.
node --version reports: v0.10.7
Please upgrade node before continuing.
It failed
node output
cyroxx#cubox:~/node-latest-install$ node
Segmentation fault
make Debug build
Running make with BUILDTYPE=Debug produces this output:
cyroxx#cubox:~/node-latest-install$ make -C out BUILDTYPE=Debug
make: Entering directory `/home/cyroxx/node-latest-install/out'
CXX(target) /home/cyroxx/node-latest-install/out/Debug/obj.target/v8_base/deps/v8/src/arm/stub-cache-arm.o
../deps/v8/src/arm/stub-cache-arm.cc: In function 'void v8::internal::ProbeTable(v8::internal::Isolate*, v8::internal::MacroAssembler*, v8::internal::Code::Flags, v8::internal::StubCache::Table, v8::internal::Register, v8::internal::Register, v8::internal::Register, v8::internal::Register, v8::internal::Register, v8::internal::Register)':
../deps/v8/src/arm/stub-cache-arm.cc:106:15: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits]
cc1plus: all warnings being treated as errors
make: *** [/home/cyroxx/node-latest-install/out/Debug/obj.target/v8_base/deps/v8/src/arm/stub-cache-arm.o] Error 1
make: Leaving directory `/home/cyroxx/node-latest-install/out'
What's wrong here? Is this a bug in the ARM implementation of V8? Maybe any compiler flags that are not (properly) set? Anything else? I am totally stuck.
I had this problem too on a few different ARM computers. Compiling without the snapshot feature worked for me. Snapshot is a V8 feature that allows node to start faster, and there seems to be a bug for ARM.
./configure --without-snapshot
make
sudo make install
http://www.armhf.com/index.php/node-js-for-the-beaglebone-black/
I had trouble building on a Samsung Chromebook XE303C12I with Crouton running Unity, even with --without-snapshot and --with-arm-float-abi=hard, so I used the precompiled binaries for Linux ARM devices.
Binaries can be found in the release directory at nodejs.org/dist/{version number}
For example, the ARM binary for v0.10.24 can be downloaded [here].(http://nodejs.org/dist/v0.10.24/node-v0.10.24-linux-arm-pi.tar.gz)
Here's a script to download and install a binary. Once you have node installed, make sure to add path/to/bin/node to your $PATH.