In Fedora20, I have OpenWRT buildroot, I also installed qemu-system-ppc.x86_64 successfully. Which files are required in order to run OpenWRT with this emulator? Where can I find that files in buildroot? In this answer they used only kernel image, but what about filesystem image?
Thanks for you time.
You need to create a filesystem image. In menuconfig->Target Images, select tar.gz/ext4 depending on how you want to use qemu. Then generate files will be present inside bin/{ARCH}/*.tar.gz or bin/{ARCH}/*.ext4
Related
I am installing a package manually on my own system because I need to make some changes to it that aren't available in the basic version in my package manager. I also am trying to keep packages installed locally if possible, so I'm installing it with prefix=$HOME/.local instead of the more common prefix=/usr/local.
When I do this, I have no problem executing the program from my terminal, because I added ~/.local/bin to my PATH and the package was installed with relative paths to its shared libraries (i.e. ~/.local/lib/<package>). Executing from the command line is no problem, but I want to be able to access it from the favorites menu in gnome, and for that I need to make use of the <package>.desktop file.
I could hard-code the path to the executable in the .desktop file itself, but when I pull a later version down and re-install it, I'll have to redo those steps. I was wondering if there's a way to avoid that.
I've tried symlinking the executable to a directory where .desktop files do have included in their path, and the application is correctly treated as a GUI option, but launching the executable results in an error trying to find a shared library. I think this has to do with how cmake handles rpaths, which to my understanding is a way of relatively linking executables with their required libraries.
I think what I want to do is have PATH inside a .desktop file include ~/.local/bin, without changing the .desktop file itself. Can I alter the 'default' path used in accessing a .desktop file?
The answer to my question was found in the Archwiki:
Specifically, I needed to add ~/.local/bin to my path in ~/.xinitrc. Now my graphical programs work as expected.
For NVIDIA Collective Communications Library (NCCL) version 2, NVIDIA asks the user to first register as a developer before getting access to the installation files.
This will bring a challenge on how to install NCCL in the containers. For personal use, we can copy the installation file to the container using Dockerfile ADD command. However, this approach does not seem right for a Dockerfile to be used by others (or put in public).
Any idea?
Thanks!
I had a similar problem with oracle installation files, the only way I could think of doing this was to ask the user to manually download the files and then using Dockerfile ONBUILD command along with the Dockerfile ADD command within the dockerfile. Meaning every user will essentially have to build their own image but at least the image can be made public without infringing on NVIDIA's policies.
Something like this:
FROM example/test:latest
....
ONBUILD ADD /example/nvidia /example/nvidia
....
CMD ['./foo.sh']
Then the user would have to use their own dockerfile pulling your public image like so:
FROM myrepo/myimage:nvidia
Provided they have the NVIDIA Collective Communications Library placed in the right folder, they can just run docker build to legally have their own image with Nvidia's libraries.
I'm trying to install casperjs from git by the manual http://docs.casperjs.org/en/latest/installation.html#installing-from-git
but I get the error
ln: failed to create symbolic link ‘/usr/local/bin/casperjs’: No such file or directory
What can I do in this case? My operating system is Windows 8.
You don't need to create symbolic link on Windows. Just add CasperJS bin directory to the %PATH% environment variable
The command "ln -sf pwd/bin/casperjs /usr/local/bin/casperjs" is for linux system valid not for windows.
You have to set the enviroment variable in Windows and add casperjs/bin directory to the path. For further information, this article is the right place https://superuser.com/questions/284342/what-are-path-and-other-environment-variables-and-how-can-i-set-or-use-them
The filesystem where you're trying to create the link (not point to, but the link itself) must support these types of links.
For example, ext3, and btrfs support these links, but ntfs (like what you typically find on a USB stick) does not.
In other words you can have this trouble on Linux just as well as on windows.
Linux server, running suphp with Apache 2.2.22 and PHP5.5.17
When I upload an image using the image widget, it is stored in a date-based path under /file
the path directories are created with properties of -rwx------, and the file is stored with properties of -rw-------
This works fine when I am traversing the directory using shell, but Apache can't see the files, as it runs as not me.
What is a safe file into which I can add umask(002); that will be early enough in the application logic, but won't get overridden by updates? Can I create a Plugin and make it the only thing in the routes.php? Can I put this in my Theme file?
There is no such setting in ImpressPages yet. I guess you have to configure your Linux to use the right mask by default. Have you seen such a setting on other CMSs or Frameworks?
We're developing an app that needs to run on a removable device (e.g. USB stick). On Linux, we're using Gnome launchers to place a shortcut to the app on the root of the device. However, we need to use relative paths for the executable and icon since we don't know in advance where the device will mount. In the .desktop file I have something like:
Exec=../myapp/myexecutable
Icon=../myapp/myicon.png
Neither the executable or icon is found. I read the spec on icon lookup in .desktop files (http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#icon_lookup) but it didn't enlighten me.
Is there a way to get launchers to use a relative path? If not, is there another approach to achieve what I want (i.e. a shortcut with an icon and an executable, specified using relative paths)?
Relative paths are not supported*.
One solution is to have an installer. This script updates the desktop file according to the location the script is run from. Make the script executable, and the user can click it to install. The script requires the desktop file to be writable.
This was done with Linux in mind. The file is named autorun.sh; but that is just a convention, it usually won't run automatically. If you deploy this on something other than Linux, then name the file something else(autorun.linux), or adapt it to do different things according to the platform.
#! /bin/sh
#### Fixup $APPNAME.desktop.
APPNAME=xvscatter
ICONNAME=xv_logo.png
cd $(dirname "$0")
APPDIR="$PWD/$APPNAME"
EXEC="$APPDIR/$APPNAME"
ICON="$APPDIR/$ICONNAME"
sed -i -e "s#^Icon=.*#Icon=$ICON#" \
-e "s#^Exec.*#Exec=$EXEC#" "$APPNAME.desktop"
*The convention for the freedesktop is to have the icons in $HOME/.icons, /usr/share/icons or /usr/share/pixmaps. Under those directories are subdirectories for different icon sizes and types. When using one of those directories to store the icon, only the icon name(without the directory) is listed in the desktop file; otherwise record the full path to the file.
The executable, if in the path, can be listed with no pathname(unsafe). It's best to list the full path. Imagine the wrong program getting launched because the full path isn't specified.
Another possibility is to copy the desktop file to the user's desktop or to /usr/share/applications, and edit it there. Do this when the program is on read-only media.
Because none of the above results in a true install, if possible, use the platform's native installer and packaging tools(rpm,dep,portage, etc.). Those tools provide a framework for complete installation including the proper file permissions(think selinux), and desktop menus. They also provide for easy uninstall.
If the program has to run from the removable media, consider using the system install for just installing symlinks, maybe to /opt/vendor/progname.
What I did and worked perfectly was:
Exec=sh -e -c "exec \\"\\$(dirname \\"\\$0\\")/.sh/server.sh\\";$SHELL" %k
Explaining the command:
The snippet below will get the dir name of who is executing that, therefore the launcher dir name
$(dirname \\"\\$0\\")
So appending the desired path, will make this execute relative path.
Ref: https://askubuntu.com/questions/1144341/execute-shell-on-a-relative-path-on-ubuntu-launcher