When I run rebar generate to generate a node using reltool, it fails with this error message:
ERROR: Unable to generate spec: read file info /usr/lib/erlang/man/man1/gserialver.1.gz failed
Why does that happen, and what can I do about it?
I'm running Debian squeeze (6.0.6), if that helps.
rebar prints Unable to generate spec when it gets an error message from reltool; the rest of the message comes directly from reltool. In this case, reltool is trying to get file info for various files in the Erlang directory, but fails because gserialver.1.gz is a dangling symlink.
You might wonder why gserialver.1.gz is installed under /usr/lib/erlang. It actually isn't, but Debian creates /usr/lib/erlang/man as a symlink to /usr/share/man:
$ ls -l /usr/lib/erlang/man
lrwxrwxrwx 1 root root 15 Nov 15 12:19 /usr/lib/erlang/man -> ../../share/man
So the real culprit is /usr/share/man/man1/gserialver.1.gz, which is installed by the package gcj-jre-headless. There is a bug report about that which claims that this has been fixed; however if that's not the case on your box, here is a command that will move the file out of the way and make rebar happy:
sudo dpkg-divert --divert /var/gserialver.1.gz --rename /usr/share/man/man1/gserialver.1.gz
Related
I want to run valgrind to monitor a program binary named contextBroker this way:
valgrind -v --leak-check=full --track-origins=yes --trace-children=yes contextBroker
but I get this error message:
valgrind: /usr/bin/contextBroker: Operation not permitted
(It happens that the contextBroker binary is in /usr/bin/)
First thing I though was some kind of problem with permissions. However:
I run the valgrind command as root user
The permissions of the /usr/bin/contextBroker are even wider:
ls /usr/bin/contextBroker -l
-rwxr-xr-x 1 root root 7108992 Jun 3 18:15 /usr/bin/contextBroker
Additional facts:
The contextBroker binary works fine, e.g. if I run it using contextBroker it works.
valgrind version is 3.16.0
I'm running the valgrind command within a docker container. The same command in the hosting system works (although the valgrind version in the host is slightly different: 3.12.0.SVN)
How I can solve this problem and run valgrind on my process? Thanks!
Using --privileged in the docker run command line solved this issue.
Thanks Nick ODell for the hint! :)
I've been trying for a few hours now solve this problem and I looked everywhere for a solution and I did not find one. I'm trying to run a spec test for my project and I have the following error coming up:
RuntimeError:
Ghostscript not found in your system environment (linux-gnu).
Install it and set the variable RGhost::Config::GS[:path] with the executable.
Example: RGhost::Config::GS[:path]='/path/to/my/gs' #unix-style
RGhost::Config::GS[:path]="C:\\gs\\bin\\gswin32c.exe" #windows-style
And I do try to put RGhost::Config::GS[:path]='/usr/local/bin/gs' and it returns:
bash: RGhost::Config::GS[:path]=/usr/local/bin/gs: No such file or directory
but ghostscript is installed, I did everything (make, sudo make install, etc etc) and when I run gs -v it returns:
GPL Ghostscript 9.26 (2018-11-20)
Copyright (C) 2018 Artifex Software, Inc. All rights reserved.
When I use the user interface and search for "gs" in the "Files" application, it is found in /home/marcelle/projects/ghostscript-9.26/bin/gs and I also tried:
RGhost::Config::GS[:path]='/home/marcelle/projects/ghostscript-9.26/bin/gs'
and it returns the same error:
bash: RGhost::Config::GS[:path]=/home/marcelle/projects/ghostscript-9.26/bin/gs: No such file or directory
I also tried to delete ghostscript from my notebook with autoremove and purge and installed it again using what I mentioned before (./configure, make, sudo make install), restarted the notebook, the terminal and nothing.
PS: I'm using Ubuntu 20.04.
I managed to figure out a solution. Looking for the code for the Rghost, what I saw in its spec is that the path expected was different than the path the ghostscript really is.
When I run whereis or which on my terminal, it returns:
which gs
/usr/local/bin/gs
So I was trying to point to this path. But seeing the spec test for Rghost which I found on github for Rghost, we can see that it expects /usr/bin/gs:
it 'should detect linux env properly' do
RbConfig::CONFIG.should_receive(:[]).twice.with('host_os').and_return('linux')
File.should_receive(:exists?).with('/usr/bin/gs').and_return(true)
RGhost::Config.config_platform
RGhost::Config::GS[:path].should == '/usr/bin/gs'
end
So it expects /usr/bin and not /usr/local/bin.
Then I just copied to that path and the spec ran with no problems anymore:
sudo cp /usr/local/bin/gs /usr/bin
I've no experience with Ruby at all, but I also got this error when using asciidoctor, which uses rghost for the PDF generation.
The command RGhost::Config::GS[:path]='/path/to/my/gs' mentioned in the error is not a shell command, which is why bash couldn't handle it. However, to me it wasn't immediately clear what to do with this command either. I expected an easy way to set this variable somewhere, but couldn't find it.
What worked for me was searching the rghost.rb file, which is where this variable is set and can be changed. In Windows, it was located in C:\Ruby30-x64\lib\ruby\gems\3.0.0\gems\rghost-0.9.7\lib\rghost.rb.
In this file, I added the following line, which solved the problem:
RGhost::Config::GS[:path]="C:\\Program Files\\gs\\gs9.55.0\\bin\\gswin64c.exe"
NB: the mentioned paths can be different for everyone, so make sure to use that paths that are valid for your system.
I'm attempting to learn how to create a Laravel Docker image by following a tutorial on DigitalOcean using WSL. Following the instructions on the Docker Hub page, however, yields an error:
❯ docker run --rm --interactive --tty -v $(pwd):/app composer install
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 94 installs, 0 updates, 0 removals
- Installing voku/portable-ascii (1.4.10): Failed to download voku/portable-ascii from dist: Could not delete /app/vendor/voku/portable-ascii/src/voku/helper:
Now trying to download from source
- Installing voku/portable-ascii (1.4.10):
[RuntimeException]
Could not delete /app/vendor/voku/portable-ascii/src/voku/helper:
install [--prefer-source] [--prefer-dist] [--dry-run] [--dev] [--no-dev] [--no-custom-installers] [--no-autoloader] [--no-scripts] [--no-progress] [--no-suggest] [-v|vv|vvv|--verbose] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--apcu-autoloader] [--ignore-platform-reqs] [--] [<packages>]...
How can I diagnose what I'm doing wrong?
It turns out that the underlying problem had nothing to do with Docker at all. In fact, Composer was trying to tell me what the problem was all along, but I dismissed it as just a symptom of a deeper issue:
[RuntimeException]
Could not delete /app/vendor/voku/portable-ascii/src/voku/helper:
This message was the crux of it all. I noticed that the directory mentioned, [...]/helper, was empty, so I tried to remove it by hand with rmdir. Instead, I got a No such file or directory error message. I attempted many other was to kill this directory, the entire project directory with rm -rf ~/laravel-app from the home folder, etc. Nothing worked.
Some digging around on the internet suggested that it could be an NTFS corruption if I was running into this issue on Windows. Since I am, indeed, attempting this on WSL (Windows Subsystem for Linux), I gave their suggested fix a try: running chkdsk /F in CMD/PowerShell. A reboot was necessary to complete this task, but after getting everything back up and trying those first few tutorial steps again, I was able to get composer to install the Laravel dependencies without a hitch.
Bottom line: If you run into this sort of issue on WSL, please try running chkdsk /F and reboot. You might just have a similar file system corruption.
We have two possibilities for this error:
1 - You did not execute the command inside the directory :
cd ~/laravel-app
2 - I'm sure there is an internal proxy that is blocking the download of packages.
Using this docker image:
docker build -t batocera-docker https://github.com/batocera-linux/batocera.docker.git
I launch a container this way, so that the sources are available in F:\docker Windows folder for browsing.
docker run -it -v F:\docker:/build batocera-docker
The following commands start the build process:
git clone git://git.buildroot.net/buildroot
cd buildroot/
make pc_x86_64_bios_defconfig
make
Which fails when processing the "host-gmp" component:
>>> host-gmp 6.1.2 Building
The build fails with the following error (but from experiment, it seems it does not always fail on the same files).
m4: cannot open `invert_limb_table.asm': No such file or directory
This is a "strange" because, the following command shows the file exists where it should (and issuing the "cat" command shows a valid file content!).
root#fe9bc1b08539:/build/buildroot# ls -la
/build/buildroot/output/build/host-gmp-6.1.2/mpn/invert_limb_table.asm lrwxrwxrwx 1 root root 35 Feb 12 22:01 /build/buildroot/output/build/host-gmp-6.1.2/mpn/invert_limb_table.asm -> ../mpn/x86_64/invert_limb_table.asm
Sometimes, the error states "File handle stale".
However, such errors always occur on symbolic links files (symlinks or hardlinks?)
I'm confused because creating a symbolic link in the mounted folder seems to work (it works using the ln command), but then it fails at some point, as if the overlay file system of the container was not synchronizing its content with the mounted folder "fast enough"?
Would there be any work around?
(I could build in a container folder, but that is trivial and not much useful to me as the sources are not available from outside).
I'm trying to install Yaws on my Ubuntu 11.01 system via apt-get install yaws. But when I call the shell script yaws from the command line I get the following error: Yaws: Bad conf: "Can't find config file "
Unless my aging eyes are missing something, I can't find enlightenment in either the Yaws website or Zachery Kessin's book.
I can find configuration files in /etc/yaws. But is there something else I need to know/do?
Thanks,
LRP
If you installed yaws with the package manager then it's controlled by an init script (and you should work with that instead of running yaws manually, I'll add).
You're most likely running yaws as a non-privileged user, and if you look closely, the directory /etc/yaws is:
drwxr-x--- 4 root yaws 4096 Aug 7 10:36 yaws
You're probably trying to run yaws under a user other than root, and without membership in the yaws group.
I would venture a guess that this is a bug in the distro's packaging rather than in yaws since the man page clearly states that running it as a non-privileged user it falls back to reading /etc/yaws/yaws.conf, except that under Debian/Ubuntu (I'm on Debian 6) the permissions on /etc/yaws/ do not live up to the claim in the map page.
But, if you work through the distro's init script and daemon management facilities your problem goes away magically. That I think is preferable to tapping the Debian packager on the shoulder and having a long conversation about config directory permissions. :)
Try doing the following.
$ touch yaws.conf
$ yaws
Hit the enter key to bring up the prompt. Works on Debian 7 (wheezy).
You may also want to do the following to place your username in the yaws group.
$ adduser USERNAME yaws
To one of the maintainers of this package found in the readme file, I have pointed them to here.
$ dpkg -L yaws | grep -i readme
My system is Debian 7 or often called wheezy distro. It's actually kali-linux but that's just fyi stuff. I browsed to /etc/yaws as root with nautilus otherwise it's locked.
~$ sudo su
[sudo] password for username:
# nautilus
Initializing nautilus-gdu extension
Now you may look in the /etc/yaws directory.
The yaws.conf should be in there. Josef would be correct as this is what yaws will try to use if the user has access to this file. But not being root you don't.
My solution is to just get ideas out of that file and the others within the same directory. Take this next answer from Van and make your home/user have a yaws.conf and play around with different configurations from what you found in the etc one. Not that hard to copy and paste if you just have access to the files. Enjoy! :-D