I have tried installing magenta on 3 separate occasions using 'pip install magenta' as well as the 'bash install.sh' command as shown here https://github.com/magenta/magenta#installation. For starters, this installation goes on for hours and hours with the message 'press Ctrl+C if you want to abort' on install of every package. When I started the installation process, the disk space in drive (checked simply by right-click, 'properties') was 30GB. It fell to 4GB with the installation still going on. I want to know how much space does magenta package install take, and how do I prevent it from taking so much space? Is there a specific magenta version I should mention during the install?
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 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.
In maximum rpm under the section on the %pre install script, it mentions that it's rare to use the %pre script. In fact, it further states that (at that time anyway) none of the 400+ RedHat packages used the %pre script.
I would think the %pre script would be the ideal location to stop the existing service before installing files over top of the currently installed version.
Is my thinking wrong? How is it that RedHat got away with never using %pre during upgrade for this purpose in any of their service packages?
Yes %pre is much more commonly used than when "Maximum RPM" was written in 1997. That doesn't change the fact that %pre should be used "rarely".
The reason is that %pre prevents installation (and may cause an entire
transaction to fail if there are needed install time dependencies).
Stopping a service in %pre and restarting in %post opens a larger window
where the service is not running than simply restarting a service in %post
The already running service typically reads its configuration files
only on startup (and so rpm can replace files while daemon is running).
And running executables have a reference count on the file system and so
continue to run even if the file that was executed was removed/replaced
by a newer package.
Well, I went and did the research I should have done before asking this question. I downloaded several service packages from RedHat 7.1 and ran:
rpm -qp --scripts <package-name>.rpm
I found out 1) that it's no longer true that %pre is not used. Even among the few that I checked a couple of them used %pre, and 2) it appears that most services just allow rpm to overwrite their data files and binaries during upgrade, and then use the upgrade portion of the %postun (post uninstall) script to restart (or try-restart) the service.
I would have thought this rather unsafe, as while you're writing over data files (especially) during upgrade, the old running service might get confused. It seems to me ultimately it's safer to stop the service during upgrade on %pre and start it again on upgrade during %postun... but that's just me.
installing an application from a command line on a mac
Hope someone can help.
I need to reinstall Final Cup Studio 2 on my mac. Since I've change to the new operating system: Lion, I'm not able to reinstall the application from the installations disks because PowerPC applications are no longer supported with Lion. One suggested solution, seems to work with many people, is to instal the program from the command line with the following argument:
$ sudo installer -package /Volumes/Final\ Cut\ Studio/Installer/FinalCutStudio.mpkg -target /
After what appear to be a "successful installation", the program is no where to be found :(.
Another solution was to add the specific PATH to were the application/s are going to reside:
/Volumes/[MainDrive]/Applications/
The problem with this is that I don't know hoy to add the additional information to the command line.
I've created a subfolder named: FINALCUTSTUDIO2 under the Applications Folder and would like to give a command to install the applicationto that particular
Rosetta, the program that lets you run PowerPC binaries on Intel processors, was taken out of OS X starting with Lion. There's no way to make it run on Lion, unfortunately, even if you got it installed somehow.
I'm developing a jailbroken program for iPhone. When the disk space is not enough, the installation will still continue, thus part of files were copied, while the other files were not, this makes the disk dirty.
I've written disk space check code at preinst and prerm scripts which are control files of deb package. When disk space is not enough, the control scripts will exit with nonzero code. But the problem is, when we are upgrading a package, if the disk space is not enough, the dpkg will still remove the old files even the prerm script exit with nonzero status, thus upgrading becomes removal which is not my expect result.
I don't know much about Cydia specifically, but if it works exactly like dpkg, then this should be solveable. See the activity diagram for package upgrades at http://people.debian.org/~srivasta/MaintainerScripts.html#sec-3.4.3 .
That shows a few different paths that could be taken in the course of running prerms and preinsts which lead the system back to a clean, old-version-still-installed state. For example, if the new-preinst fails, then the new-postrm will be run with "abort-upgrade" as the parameter. If that succeeds, then the old-postinst is also run with "abort-upgrade". And if that succeeds, you're back to a clean, installed state.