Steps for installing Orbfit 4.2 - installation

I'm trying to install Orbfit4.2 on a using linux mint maya edition. I'm trying to follow the on line help. I have unzipped the tared file, configured with $ ./config -0 gfortran and then $ make. Both appears to be successful. I am now trying to create the DE405 data files in the /orbfit/src/jpleph directory. I have downloaded the header.405 and the ascp*date* ascii files into the directory from JPL. I have run $ make ephemerides and get the following;
cat header.405 ascp1960.405 ascp1980.405 ascp2000.405 ascp2020.405> input.430
asc2eph.x < input.430
/bin/sh: 1: asc2eph.x: not found
make: *** [ephemerides] Error 127
(I have also used input value of 405 instead of 430)
I have also tried just running from with in
the directory
$ ./asc2eph.x which was the previous method before the Makefile was included. All I get with this is 'authors' introductory message and the flashing working box-still running 6 hrs later.
If anybody has any experience or advice with installing Orbfit 4.2 from the start or can help me move on from the above blockage I would appreciate.
Note I am a real novice and would appreciate idiot step by step guide- I'm the idiot.
Eric

The Makefile assumes that the current directory "." is in your path. This is a security risk. You can either edit the Makefile to rename these binaries:
$ diff -u Makefile.orig Makefile
--- Makefile.orig 2014-01-09 07:14:10.000000000 -0800
+++ Makefile 2014-10-21 11:40:00.850236839 -0700
## -10,7 +10,7 ##
make clean
ephemerides: input asc2eph.x
- asc2eph.x < input.430
+ ./asc2eph.x < input.430
mv JPLEPH jpleph
make clean
Or you can add . to your path (but this is insecure!) by doing
$ PATH=.:$PATH

Related

on-download-complete can't work with aria2

i am not root user,so i install aria2-1.34.0 with ./configure --prefix=/home/xxx/.local, everything works fine but on-download-complete
i set on-download-complete=/home/xxx/aria2/a.sh
#!/bin/bash
echo 123 > 1.txt
when a task download completed, the log shows everything is ok
2019-10-28 19:04:11.295587 [NOTICE] [RequestGroup.cc:1216] Download complete: /home/xxx/aria2/data/0.png
2019-10-28 19:04:11.295598 [INFO] [DefaultBtProgressInfoFile.cc:415] The segment file /home/xxx/aria2/data/0.png.aria2 does not exist.
2019-10-28 19:04:11.295612 [INFO] [util.cc:2239] Executing user command: /home/xxx/aria2/a.sh b031d9399fb9d93f 1 /home/xxx/aria2/data/0.png
but actually nothing happened, it didn't work!!!
aria2c path:
/home/xxx/.local/aria2c
aria2.conf
enable-rpc=true
rpc-allow-origin-all=true
rpc-listen-all=false
max-concurrent-downloads=1
continue=true
max-connection-per-server=5
min-split-size=5M
split=5
max-overall-download-limit=5M
max-download-limit=2M
max-overall-upload-limit=0
max-upload-limit=0
dir=/home/xxx/aria2/data
file-allocation=prealloc
on-download-complete=/home/xxx/aria2/a.sh
log=/home/xxx/aria2/aria2.log
log-level=info
i don't know how to deal with it, could u give me any suggestions, thanks.
got a solution for me
put --on-download-complete in cmd instead of aria2.conf
just run aria2 like:
aria2c --conf-path=/xxx/xxx/arai2.conf --on-download-complete=/xxx/xxx/xxx.sh -D
and it works
but i have no idea why it didn't work if set --on-download-complete in conf file
Accroding to the official document
-D, --daemon [true|false]
Run as daemon. The current working directory will be changed to / and standard input, standard output and standard error will be redirected to /dev/null. Default: false
You should modify /home/xxx/aria2/a.sh to
#!/bin/bash
echo 123 > $(dirname $0)/1.txt
to write the output to the right place.

Yocto: No recipes available (tegra)

I'm attempting to create an image with
bitbake core-image-minimal
For my jetson nano (nvidia tegra). I've added the meta-layer for tegra devices from https://github.com/madisongh/meta-tegra
and added it to bblayer.conf. I have also added lines
IMAGE_CLASSES += "image_types_tegra"
IMAGE_FSTYPES = "tegraflash"
to the local.conf file to be able to flash it later.
When I attempt to run the bitbake command to create the image, I get the error message:
ERROR: No recipes available for:
/home/mci/yocto/jetson-nano/meta-tegra/recipes-graphics/vulkan/vulkan-loader_1.1.%.bbappend
/home/mci/yocto/jetson-nano/meta-tegra/recipes-graphics/vulkan/vulkan-tools_1.1.%.bbappend
/home/mci/yocto/jetson-nano/meta-tegra/recipes-graphics/wayland/weston_7.0.0.bbappend
But aren't the files it says there is no recipes for the same recipes it's looking for? Isn't "vulkan-loader_1.1.%.bbappend" a recipe?
How do I solve this problem? Is it because it can't find the files or is the bbappend not the recipes but something else?
Michael,
I don't have an answer for the vulkan pieces but I do have a few pointers since we seem to be going down a similar path with the nano.
Use the warrior branch of yocto
You'll need to download the binary pieces of the nvidia sdk through the SDK manager
Point to these sdk packages in your local.conf with the NVIDIA_DEVNET_MIRROR variable. ex: "file:///home/nvidia/yocto/git/poky/devnet/nano-dev"
Because of the binary pieces in step 2, you need to use an older gcc version which isn't really supported in warrior. I used the linaro-7.2 layer.
Since gcc7 is not supported in warrior, yocto / openembedded will attempt to pass flags to gcc which will make the build fail. Here's a summary, which I hope is complete, to help you through this.
Add DEBUG_PREFIX_MAP="" to local.conf and apply the following patch.
diff --git a/meta/recipes-core/busybox/busybox.inc b/meta/recipes-core/busybox/busybox.inc
index 174ce5a8c0..e8d651a010 100644
--- a/meta/recipes-core/busybox/busybox.inc
+++ b/meta/recipes-core/busybox/busybox.inc
## -128,7 +128,7 ## do_prepare_config () {
${S}/.config.oe-tmp > ${S}/.config
fi
sed -i 's/CONFIG_IFUPDOWN_UDHCPC_CMD_OPTIONS="-R -n"/CONFIG_IFUPDOWN_UDHCPC_CMD_OPTIONS="-R -b"/' ${S}/.config
- sed -i 's|${DEBUG_PREFIX_MAP}||g' ${S}/.config
+ #sed -i 's|${DEBUG_PREFIX_MAP}||g' ${S}/.config
}
# returns all the elements from the src uri that are .cfg files
diff --git a/meta/recipes-core/libxcrypt/libxcrypt.bb b/meta/recipes-core/libxcrypt/libxcrypt.bb
index 3b9af6d739..350f7807a7 100644
--- a/meta/recipes-core/libxcrypt/libxcrypt.bb
+++ b/meta/recipes-core/libxcrypt/libxcrypt.bb
## -24,7 +24,7 ## FILES_${PN} = "${libdir}/libcrypt*.so.* ${libdir}/libcrypt-*.so ${libdir}/libowc
S = "${WORKDIR}/git"
BUILD_CPPFLAGS = "-I${STAGING_INCDIR_NATIVE} -std=gnu99"
-TARGET_CPPFLAGS = "-I${STAGING_DIR_TARGET}${includedir} -Wno-error=missing-attributes"
-CPPFLAGS_append_class-nativesdk = " -Wno-error=missing-attributes"
+TARGET_CPPFLAGS = "-I${STAGING_DIR_TARGET}${includedir} "
+CPPFLAGS_append_class-nativesdk = " "
BBCLASSEXTEND = "nativesdk"
Best of luck! I apologize if this is a bit rough, but I'm just getting through this myself.
I deleted everything and started with a fresh build, did the EXACT same procedure and added all the same lines to the local.conf and bblayer.conf... But this time, bitbake command is running with no errors at all.

Cef Compilation 64 bit Binaries not generated for Cocoa

CEF :
Branch : 2987
Terminal Commands for Generating binary distrib files after all the data gets downloaded
$ export GYP_DEFINES=proprietary_codecs=1 ffmpeg_branding=Chrome
$ python /Users/imfinity/Documents/CEF_2987/automate/automate-git.py --download-dir=/Users/imfinity/Documents/CEF_2987/download --branch=2987 --x64-build --force-config --force-build
$ cd /Users/imfinity/-dir/chromium/src/cef/tools
$ ./make_distrib.sh --ninja-build
ERROR : Traceback (most recent call last):
File "make_distrib.py", line 468, in
raise Exception('Missing generated header file: %s' % include)
Exception: Missing generated header file: cef_pack_resources.h
This leads to creation of : Incomplete Folder : cef_binary_3.2987.1574.g4232c4c_macosx32
Any help is appreciated!!
I tried this command
$ export GYP_DEFINES=proprietary_codecs=1 ffmpeg_branding=Chrome
$ python /Users/imfinity/Documents/CEF_20March/automate/automate-git.py --download-dir /Users/imfinity/Documents/CEF_20March/download --branch=2987 --x64-build --force-config
and finally it worked and 64 bit binaries were generated
still surprised it worked after 5 different attempts!!!

Vowpal Wabbit: make test failing for me at test 59

For some reason I am having trouble with the make test statement while installing ```Vowpal Wabbit``. I am getting the following error:
RunTests: test 59: '/usr/bin/timeout 20 ../vowpalwabbit/vw -d train-sets/argmax_data -k -c --passes 20 --search_rollout oracle --search_alpha 1e-8 --search_task argmax --search 2 --holdout_off' failed (exitcode=1)
Anyone have a clue what this could be?
Just run the command which failed (in single quotes) directly from the test directory, and the reason would become obvious.
It is missing data file:
Reading datafile = test/train-sets/argmax_data
can't open: test/train-sets/argmax_data, error = No such file or directory
vw: std::exception
The issue was introduced in a recent check-in and should soon be fixed (hopefully).
Update (2014-05-31): fixed in the most recent commit.

system(): why do I not have the same permissions when using R in EMACS as I do in the bash terminal?

update: the error only occurs when logged into R from within emacs
what works:
When I ssh into a remote server and run
$ ./foo.rb
from the bash shell, it works. Furthermore, if I launch R and execute
$ R
system('./foo.rb')
I am in a group with permission to read/write/execute the file. File permissions are -rwxrwx---
what doesn't work:
Launch emacs and start an R session:
M-x R
ssh-myserver:.
system('./foo.rb')
I get the following error:
ruby: Permission denied -- foo.rb (LoadError)
why is this? Is there a way to work around this?
I can not find any information from ?system or ?system2
Here is the output from sessionInfo()
> sessionInfo()
R version 2.12.2 (2011-02-25)
Platform: x86_64-redhat-linux-gnu (64-bit)
locale:
[1] C
attached base packages:
[1] grid stats graphics grDevices utils datasets methods
[8] base
other attached packages:
[1] PECAn_0.1.1 xtable_1.5-6 gridExtra_0.7 RMySQL_0.7-5
[5] DBI_0.2-5 ggplot2_0.8.9 proto_0.3-8 reshape_0.8.3
[9] plyr_1.6 rjags_2.2.0-2 coda_0.13-5 lattice_0.19-17
[13] randtoolbox_1.09 rngWELL_0.9 MASS_7.3-11 XML_3.2-0
loaded via a namespace (and not attached):
[1] digest_0.4.2
Warning message:
'DESCRIPTION' file has 'Encoding' field and re-encoding is not possible
output of 'id' and 'env' from ssh and emacs, per comment by #sarnold (changed user names, group names, and ip addresses)
1. server
1.1 'id'
uid=1668(dleb) gid=1668(dleb) groups=117(ebusers),159(lab_admin),166(lab),1340(pal_web),1668(dleb)
1.2 'env'
LC_PAPER=en_US.UTF-8
LC_ADDRESS=en_US.UTF-8
LC_MONETARY=en_US.UTF-8
SHELL=/usr/local/bin/system-specific
KDE_NO_IPV6=1
SSH_CLIENT=888.888.888.88 51857 22
NCARG_FONTCAPS=/usr/lib64/ncarg/fontcaps
LC_NUMERIC=en_US.UTF-8
USER=dleb
LS_COLORS=
LC_TELEPHONE=en_US.UTF-8
KDEDIR=/usr
NCARG_GRAPHCAPS=/usr/lib64/ncarg/graphcaps
MAIL=/var/mail/dleb
PATH=/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/opt/dell/srvadmin/bin
LC_IDENTIFICATION=en_US.UTF-8
LC_COLLATE=en_US.UTF-8
R_LIBS=/home/a-m/dleb/lib/R
PWD=/home/dleb
NCARG_ROOT=/usr
KDE_IS_PRELINKED=1
LANG=en_US.UTF-8
NCARG_DATABASE=/usr/lib64/ncarg/database
MODULEPATH=/usr/share/Modules/modulefiles:/etc/modulefiles
LOADEDMODULES=
LC_MEASUREMENT=en_US.UTF-8
NCARG_LIB=/usr/lib64/ncarg
SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass
NCARG_NCARG=/usr/share/ncarg
SHLVL=1
HOME=/home/a-m/dleb
LOGNAME=dleb
CVS_RSH=ssh
SSH_CONNECTION=888.888.888.88 51857 999.999.999.99 22
LC_CTYPE=en_US.UTF-8
MODULESHOME=/usr/share/Modules
LESSOPEN=|/usr/bin/lesspipe.sh %s
DISPLAY=localhost:15.0
LC_TIME=en_US.UTF-8
G_BROKEN_FILENAMES=1
LC_NAME=en_US.UTF-8
_=/bin/env
emacs/ess R session
2.1 system('id')
uid=1668(dleb) gid=1668(dleb) groups=117(ebusers),159(lab_admin),166(lab),1340(pal_web),1668(dleb)
2.2 system('env')
LN_S=ln -s
R_TEXI2DVICMD=/usr/bin/texi2dvi
LC_PAPER=en_US.UTF-8
SED=/bin/sed
LC_ADDRESS=en_US.UTF-8
R_PDFVIEWER=/usr/bin/xdg-open
LC_MONETARY=en_US.UTF-8
HOSTNAME=ebi-forecast
R_INCLUDE_DIR=/usr/include/R
R_PRINTCMD=lpr
SHELL=/usr/local/bin/system-specific
TERM=dumb
AWK=gawk
HISTSIZE=1
R_RD4DVI=ae
SSH_CLIENT=888.888.888.88 51159 22
KDE_NO_IPV6=1
R_RD4PDF=times,hyper
R_PAPERSIZE=a4
NCARG_FONTCAPS=/usr/lib64/ncarg/fontcaps
PERL=/usr/bin/perl
LC_NUMERIC=en_US.UTF-8
SSH_TTY=/dev/pts/14
LC_ALL=C
EMACS=t
USER=dleb
LC_TELEPHONE=en_US.UTF-8
LS_COLORS=
LD_LIBRARY_PATH=/usr/lib64/R/lib:/usr/local/lib64:/usr/lib/jvm/jre/lib/amd64/server:/usr/lib/jvm/jre/lib/amd64:/usr/lib/jvm/java/lib/amd64:/usr/java/packages/lib/amd64:/lib:/usr/lib
TAR=/bin/gtar
ENV=
R_ZIPCMD=/usr/bin/zip
KDEDIR=/usr
PAGER=/usr/bin/less
NCARG_GRAPHCAPS=/usr/lib64/ncarg/graphcaps
R_GZIPCMD=/usr/bin/gzip
PATH=/bin:/usr/bin:/usr/sbin:/usr/local/bin
LC_COLLATE=en_US.UTF-8
LC_IDENTIFICATION=en_US.UTF-8
EGREP=/bin/grep -E
PWD=/home/a-m/dleb/pecan
INPUTRC=/etc/inputrc
R_LIBS=/home/a-m/dleb/lib/R
NCARG_ROOT=/usr
R_SHARE_DIR=/usr/share/R
WHICH=/usr/bin/which
EDITOR=vi
LANG=en_US.UTF-8
KDE_IS_PRELINKED=1
R_LIBS_SITE=/usr/local/lib/R/site-library:/usr/local/lib/R/library:/usr/lib64/R/library:/usr/share/R/library
M ODULEPATH=/usr/share/Modules/modulefiles:/etc/modulefiles
NCARG_DATABASE=/usr/lib64/ncarg/database
LC_MEASUREMENT=en_US.UTF-8
LOADEDMODULES=
PS3=
R_BROWSER=/usr/bin/xdg-open
SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass
NCARG_LIB=/usr/lib64/ncarg
HOME=/home/a-m/dleb
SHLVL=1
NCARG_NCARG=/usr/share/ncarg
R_ARCH=
TR=/usr/bin/tr
MAKE=make
R_UNZIPCMD=/usr/bin/unzip
LOGNAME=dleb
CVS_RSH=ssh
LC_CTYPE=en_US.UTF-8
SSH_CONNECTION=888.888.888.88 51159 999.999.999.99 22
R_BZIPCMD=/usr/bin/bzip2
MODULESHOME=/usr/share/Modules
LESSOPEN=|/usr/bin/lesspipe.sh %s
PROMPT_COMMAND=
R_HOME=/usr/lib64/R
DISPLAY=localhost:22.0
R_PLATFORM=x86_64-redhat-linux-gnu
INSIDE_EMACS=23.2.1,tramp:2.1.18-23.2
R_LIBS_USER=~/R/x86_64-redhat-linux-gnu-library/2.12
LC_TIME=en_US.UTF-8
R_DOC_DIR=/usr/share/doc/R-2.12.2
R_SESSION_TMPDIR=/tmp/RtmpqA6bpJ
HISTFILE=/home/a-m/dleb/.tramp_history
G_BROKEN_FILENAMES=1
LC_NAME=en_US.UTF-8
_=/bin/env
Assuming you started up R as the same user, you do. You error is not coming from a permissions problem for foo.rb, however, or else your shell would be giving the error. (i.e. sh: ./test.rb: Permission denied; see example below). Here, ruby itself is giving the error. Without knowing exactly what is in your foo.rb, I would suggest digging in there to see what it is trying to load/source, and checking the permissions on those.
#!/usr/bin/env ruby
puts 'Hello world'
Now in R....
> system('ls -l test.rb')
-rw-r--r-- 1 jcolby staff 40 Oct 21 08:23 test.rb
> system('./test.rb')
sh: ./test.rb: Permission denied
> system('chmod a+x test.rb')
> system('./test.rb')
Hello world
I presume the M ODULEPATH in the Emacs-derived output is simply a copy and paste typo.
The differences between the two env outputs is much greater than I expected; I've selected the ones that look slightly suspicious to me:
$ diff -u works fails
--- works 2011-10-24 15:04:02.000000000 -0700
+++ fails 2011-10-24 15:12:36.000000000 -0700
...
+LD_LIBRARY_PATH=/usr/lib64/R/lib:/usr/local/lib64:/usr/lib/jvm/jre/lib/amd64/server:/usr/lib/jvm/jre/lib/amd64:/usr/lib/jvm/java/lib/amd64:/usr/java/packages/lib/amd64:/lib:/usr/lib
...
-PATH=/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/opt/dell/srvadmin/bin
-PWD=/home/dleb
...
+PATH=/bin:/usr/bin:/usr/sbin:/usr/local/bin
...
+PWD=/home/a-m/dleb/pecan
...
In the emacs-derived session, your LD_LIBRARY_PATH environment variable may be changing specifics of which dynamically linked libraries are being used when executing ruby. If you ssh in to your server and execute your foo.rb with the changed LD_LIBRARY_PATH, does it work or fail?
LD_LIBRARY_PATH=/usr/lib64/R/lib:/usr/local/lib64:/usr/lib/jvm/jre/lib/amd64/server:/usr/lib/jvm/jre/lib/amd64:/usr/lib/jvm/java/lib/amd64:/usr/java/packages/lib/amd64:/lib:/usr/lib ./foo.rb
The PATH environment variable between the two sessions is different; perhaps you have permission to execute /usr/local/bin/ruby (or the libraries in /usr/local/lib/ruby/) but not /usr/bin/ruby (or the libraries in /usr/lib/ruby/). Does your script use #!env ruby or does it use #!/usr/bin/ruby (or some other fixed path)?
Your pwd in one instance is /home/dleb, the other /home/a-m/dleb/pecan -- but HOME is set to /home/a-m/dleb on both systems. Is /home/dleb a symbolic link or does it actually exist separate from /home/a-m/dleb? (This really is grasping at straws -- I don't think this is it, but this problem is baffling.)
One last thing to consider: is your server confined with a tool such as AppArmor, SELinux, TOMOYO, or SMACK? Any of these mandatory access control tools can prevent an application from writing in specific locations, perhaps they aren't yet configured for your site. Check dmesg(1) output to see if there are any rejection messages, most or all these tools log to dmesg(1) if auditd(8) isn't running.

Resources