I use a Raspberry Pi 1 model B with Raspbian, but when I try to do cabal update, the process gets stuck when it is "Updating the index cache file" and I have to force it to stop. I'm trying to install the latest version of pandoc here, but I cannot use cabal install pandoc either because of the same problem.
I tried to leave it running all night long, but when I returned there was a "kill process" line showing up.
Thanks in advance, and sorry for my poor english :)
If cabal update performance is particularly slow, it may be that you are using an old cabal version prior to the merge of an important patch.
The description explains:
This patch improves cabal update performance by 10x(!) on my system.
Due to this issue, cabal update was using an extreme amount of CPU,
while it should be I/O-bound. The reverse was taking 79s, now it
takes 0.01s.
Related
I have some problems trying to test "needs-restarting -r ; echo $?" inside a RedHat distribution. The command works for cases where a reboot is not required, but I have not been able to voluntarily generate the need to reboot in the operating system, which has made it impossible for me to know if the response to the command works. That is to say the output in 1 of the needs-restarting. Do you know of any way to generate the need to reboot in a controlled manner in RedHat?
You can find which packages require a system reboot after the update to Redhat KB. If you can downgrade one of these packages, you can generate reboot required state. But this is not recommended in production systems. glibc and kernel downgrades can cause problems. You can try it at new installed Rhel server after "yum update".
I need to install SUMO 0.30.0 to be used with the VEINS_INET subproject in veins 4.6. I have tried following the instructions here and suggestions from forums but haven't had any luck being able to install sumo. I run ./configure (trying various tool/library options) then run sudo make but all I get is target marouter failed or nothing to be done for 'install-exec-am' 'install-data-am'.
Does anyone know how to install sumo-0.30.0 from source and/or make the veins_inet subproject work with the latest version of sumo-0.32.0?
Don't run sudo make.
Don't run sudo make.
Your problem is probably related to a dependency/packaging change in 16.04, which is explicitly pointed out in the veins tutorial:
Note that Ubuntu 16.04 no longer includes libproj0; this can be worked around by temporarily adding the packet repository of, e.g., Ubuntu Vivid when installing this package.
Short answer: Unfortunately this means that long-term, you're going to either have to package SUMO yourself, use the versions someone else compiled (see this launchpad for example) or rely on an old version.
Long answer:
In general, I would recommend building SUMO from source by building its' dependencies from source, since I've encountered this problem on various distributions. In particular, the fox, proj and gdal libraries tend to be packaged in different versions, and along with changes in the SUMO source code. I currently use this script (with the package versions downloaded) to compile SUMO -- but this is for 0.30.0, and it breaks if any of the referenced source packages are moved (which happens quite often). My general recommendation would be to either use a completely isolated version of SUMO (i.e., compiling by hand as much as possible) or relying on a pre-packaged version (see above), as long as that version is recent enough to work with VEINS.
I'm trying to build gnuradio 3.7.9 on raspberry pi as the version provided by apt-get has some problems.
However the classic cmake/make/mke install procedure tries to build the documentation which requires latex to be installed. As don't want to install latex, I'm looking for an option to build gnuradio without the documentation.
Any help appreciated
Cmake will just disable documentation of it doesn't find doxygen. And if doxygen doesn't find LaTeX, it should just skip the formulas.
Anyway, use cmake with the -DENABLE_DOXYGEN=OFF flag.
More importantly, don't build GNU Radio on the pi itself. The raspberry pi is an embedded device, not a compilation platform, to be honest. RAM will quickly become a bottleneck, and together with the limited storage bandwidth that means that even if successful, the build will take days.
Instead, spend that time on fixing whatever is wrong with the packet. I do happen to know the maintainer of the Debian gnuradio packages, and he's a really nice guy. If you can write a good bug report, I'm sure he, or the GNU Radio mailing list, will figure something out.
I can't seem to find anything useful in the man pages etc for this, but it seems like it should be straightforward..?
Our servers are running CentOS 6.8 but also have the Atomic repository for some package versions. The most recent version of one of the packages that Atomic provides seems to be broken, so we've had to do a yum downgrade of that package.
Problem now is that we're running Plesk, which performs automatic Yum updates on a schedule, and the next time this happens, the broken package will just drag back in again!
All I want to do is tell Yum to ignore this specific package version so that it updates the next time there's a newer version, but skips the current.
I found that I can add exclude= lines to yum.conf but I can't seem to find how to define a specific version number in this exclude. It looks like I can only exclude entire package names?
I'm more familiar with Gentoo where we can tell Portage to mask specific versions when problems like this occur. Is this not an option in CentOS?
Much appreciated.
I have been using Enthought Canopy Distribution (Academic License) for the last few weeks. I have also used the Package Manager to install packages.
But now today when I tried to install Scikit learn it showed the following error message "Takes no argument 1 given". Infact this problem is there even if I try to install other packages. I also tried to upgrade a few packages, but those too showed the same error.
Have I changed some setting by mistake or is it an issue with the software?
I encountered the same problem in both the Canopy GUI and on the command line (epkg) on OS X 10.8 with the 32-bit version. This is part of the reply I got from the Enthought support team:
This looks like a familiar bug which should have been fixed.
Could you please update to 1.0.1.1191, and if the problem still occurs, then submit this as a bug report from the Canopy Help menu so we can gather more system information?
Only problem is, I am running 1.0.1.1190, and Help/Software Updates... claims there is no newer version available. I informed support of this, and I will report back as soon as I have more information on or a solution for this problem.
Update
Planning do document the exact error message, I just went back to the command line and invoked epkg, which suddenly did work:
$ enpkg
Enstaller is out of date. Update? ([y]/n) y
enstaller-4.6.1-2.egg
[fetching] 264 KB
[.................................................................]
enstaller-4.6.1-2.egg
[installing] 755 KB
[.................................................................]
Enstaller has been updated. Please re-run your previous command.
I can now successfully install and update packages via enpkg or the Canopy GUI.