I just had to reinstall MacPorts after my upgrade to Yosemite. It was a great opportunity to not install tex-live again, because I prefer to use MacTeX. I believe it got installed as a dependency at one point in time.
What I'm wondering is if there is a way a can prevent it from ever being installed again. A port blacklist if you will, where even if it's a dependency it will not get installed. I'm fine with that port with that dependency failing as well.
Any help would be greatly appreciated.
This may be a stupid question, but why do you prefer MacTeX? Both the MacPorts TeXLive distribution and MacTeX contain exactly the same software anyway.
Nonetheless, for your specific question, no there is no blacklist. For the special case of LaTeX, you can edit your macports.conf and append /usr/texbin to the value of binpath. For most ports that require LaTeX that should satisfy the dependency, because it is written as bin:pdflatex:texlive-latex (e.g. if it needs the pdflatex binary) and bin:-style dependencies search in $PATH (which you've changed by editing the binpath setting).
For the cases where this doesn't help, please file bugs and request the Portfile be adjusted to allow MacTeX to satisfy the dependency.
Related
A FreeBSD update forces me to run Xmonad by cabal-install. After I run "cabal new-update"
I find that it audaciously placed a 636MB file inside the directory "~/.cabal". Having a closer look I noticed that this is the unzipped version of a .tar.gz of 85MB.
Question #1: How can I inhibit to unpack this monster?
Question #2: I am loggin in as two different users. Is there a way to install the zipfile in a global place?
Thanks in advance,
Bertram
You can't inhibit the unpacking of it. Cabal needs it to operate. That said, your solution to how to replace it with a symlink seems fine.
I installed droneapi in the same manner given in the tutorial. However, it's missing all of the important modules that come with MAVProxy, such as console, wx, etc.
Was it supposed to install these modules, or should I move them over from MAVProxy itself instead?
Note: Windows 8 64-bit platform
I apologize that you had to investigate the issue without guidance. Publishing our Windows installer was not well prioritized, and it looks like that choice cost you several hours.
Here is what we will soon to address DroneKit Python installation on Windows:
A dedicated Windows installer generator lives at windows/droneapiWinBuild.bat. This generates a program Output\DroneKitsetup-1.x.x.exe which can be used to install all dependencies.
Yesterday we began testing the installer on Windows on every commit. https://github.com/dronekit/dronekit-python/pull/236
We will now publish the binaries generated by that test and document them in the Windows installation process. https://github.com/dronekit/dronekit-python/issues/164
Thanks for publishing your solution publicly. Hopefully we can address issues like these before they come up in the future.
Tim, DroneKit Engineer
So in a rare spark of intuition I discovered the answer. The modules required by Dronekit Python can be installed in the following ways:
Console- type "pip install console" into the WinPython cmd prompt
WX- http://wiki.wxpython.org/How%20to%20install%20wxPython
OpenCV- Download and install OpenCV version 2.4, then copy/paste the file cv2.pyd from OpenCV\build\python\2.7\x64\ to \python-2.7.6.amd64\Lib\site-packages.
At this point it should load all required modules, although it will throw a few exceptions which aren't important.
As always, 3DR documentation is incomplete. One would think that $800 million dollar profits would mean that they could hire more than 5 programmers for their new platform...
I would like to create an RPM package that applies a Puppet manifest on a server which does not contain Puppet, Facter and Hiera.
Also, and more importantly, I should be able to apply it WITHOUT being obliged to install neither of these tools (Puppet, Facter, Hiera) on the production server.
So basically, the package should run the following command without installing any of the required packages:
puppet apply install.pp --modulepath=./modules --hiera_config=./conf/hiera.yaml
How can I proceed to make such a package ? Is it a good idea to extract the 'binary' files the Puppet/Hiera/Facter RPMs to include them in another one ?
Thanks!
Installing the relevant packages and then removing them would be by far the fastest and safest way to do what you wish. Maybe you can convince your customer that the cost in time for any other solution is not worth the money.
Anyway, if packages are not an option, let's be innovative:
You do not have to install from packages, you can install puppet via ruby gems
In the same way, you can use source tarballs
Those two options might work, but are not innovative enough.
What about installing puppet 'locally' on a disk via the gems or the tarballs, and then mounting this disk via nfs?
While we are here, why not do the same but then mount using sshfs?
still with the idea of a having first a remote install, you could indeed repackage it via fpm (amazing tool, very strongly recommended). You still end up with a package, but a local one which will not require adding a repository, this might alleviate some of your client concerns.
building on this, if the issue is with repositories, not packages, you could download all required packages and install them manually
I guess that the summary of this answer is that the value of doing so is negative compared to using what you distribution provides.
I am attempting to run foswiki on OpenBSD. Things are installed and i am able to open "/bin/Configure" page of foswiki configuration screen. but the page reports few errors, complaining that following files are either not found or outdated and new versions are required.
The Files are : grep, rcs, ci, co,rlog, rcsdiff
I tried commands like "pkg_add -Uu" to upgrade packages installed, but it reports all packages are uptodate.
I also tried "pkg_add rcs" "pkg_add grep" etc but non works.
So my basic question is how to I update above files to their latest version required by foswiki.
Regards
While I’m not familiar with Foswiki, my first thought is your web server is chrooted, as this is the default on OpenBSD, and, as a result, Foswiki cannot find the files it needs. You can copy the files Foswiki needs into the chroot or run the web server without chroot, which is bad from a security perspective.
all programs mentioned are part of a base openbsd install and the above answer is correct. the openbsd documentation on chrooted apache has more info.
if you don't have to stick with foswiki you can try dokuwiki instead which has package support on openbsd and installs easily in very much the same way you tried already:
sudo pkg_add -U dokuwiki
hope the process is pretty much self-descriptive. in addition, the manpage for pkg_add is a good thing to read. good luck!
I have: gstreamer-sdk, gstreamer-ffmpeg, gstreamer-plugins-good, bad, and ugly. I googled everywhere for this error and have found nothing relevant. I'm going a little nuts trying to figure out this error:
Error received from element decodebin20: Your GStreamer installation is missing a plug-in.
Debugging information: gstdecodebin2.c(3576): gst_decode_bin_expose (): /GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin0/GstDecodeBin2:decodebin20:
no suitable plugins found
It throws when I run my gstreamer program. Any ideas on why?
You may not be missing any plugins at all.
This error can be a result of just an unlinked pipeline.
Playbin2(decodebin2) got some changes that made it unable to automatically link up some pipelines that formally worked, for example transcoding a decoder to an encoder. In my case, explicitly adding the ffdec_h264 that it used to add automatically fixed it.
Relying on the Playbin2 can be very frustrating when it does not work. Using the setup below, you can create a .png diagram of the pipeline in various phases of construction. It's very helpful in finding why it isn't linking up.
export GST_DEBUG_DUMP_DOT_DIR=~/gstdump
for f in $GST_DEBUG_DUMP_DOT_DIR/*.dot ; do dot -T png $f >$f.png; done
This tool also lets you learn from it how to link up pipelines, and replace them with explicit ones that are easier to debug and less likely to break.
In Fedora, I resolved this issue removing gstreamer1-vaapi.x86_64:
sudo yum remove gstreamer1-vaapi.x86_64
uridecodebin is part of the "base" plugin set, so make sure you have gstreamer-plugins-base.
Another thing to look into is your LD_LIBRARY_PATH and GST_PLUGIN_PATH. If they point to a different GStreamer installation, it could cause problems like this. Also, if you didn't install GStreamer with a package manager, you may need to set your LD_LIBRARY_PATH to point to it (or better yet, install it with a package manager).
Pleas try to use gst-inspect command to find out if environment is correctly setup.
use gst-launch -v playbin2 uri = "your_uri_here" to find more information to trace this issue.