Instaling lang pack on debian circular dependency - localization

I have problems installing language packs on debian
I followed this https://stackoverflow.com/a/26940856/3202194
(I followed that because apt returns E: Unable to locate package language-pack-sk)
so I downloaded latest packages for sk and sk-base a tried to install them using dpkg
but i get this when i try to install sk
Unpacking language-pack-sk (1:16.04+20160415) over (1:16.04+20160415) ...
dpkg: dependency problems prevent configuration of language-pack-sk:
language-pack-sk depends on language-pack-sk-base (>= 1:16.04+20160415);
and this when sk-base
Unpacking language-pack-sk-base (1:16.04+20160415) ...
dpkg: dependency problems prevent configuration of language-pack-sk-base:
language-pack-sk-base depends on language-pack-sk (>= 1:16.04+20160415);
How do I install lang pack when there is circular dependency ?? (btw I need to instal more then sk, but I suppose it will be same)

Ok, if you only do "apt-get install" then after confirmation prompt it will install both at once
(all downloaded and not fully packages at once)
solving circular dependencies

Related

Erlang installation giving erlang-mode is broken error

I am trying to install Elixir from the elixir website on Ubuntu 14.04. I get the following error when I execute $ sudo apt-get install esl-erlang. Can anyone help me out here ?
$ sudo apt-get install esl-erlang
Reading package lists... Done
Building dependency tree
Reading state information... Done
esl-erlang is already the newest version.
The following packages were automatically installed and are no longer required:
libgconf2-4 python-requests-whl python-setuptools-whl python-six-whl
python-urllib3-whl python-wheel
Use 'apt-get autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 406 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Setting up erlang-mode (1:21.0.5-1) ...
ERROR: erlang-mode is broken - called emacs-package-install as a new-style add-on, but has no compat file.
Install emacsen-common for emacs23
emacsen-common: Handling install of emacsen flavor emacs23
Wrote /etc/emacs23/site-start.d/00debian-vars.elc
Wrote /usr/share/emacs23/site-lisp/debian-startup.elc
Install emacsen-common for emacs24
emacsen-common: Handling install of emacsen flavor emacs24
Wrote /etc/emacs24/site-start.d/00debian-vars.elc
Wrote /usr/share/emacs24/site-lisp/debian-startup.elc
Install erlang-mode for emacs
Install erlang-mode for emacs23
install/erlang: Handling install for emacsen flavor emacs23
Wrote /usr/share/emacs23/site-lisp/erlang/erlang-edoc.elc
Wrote /usr/share/emacs23/site-lisp/erlang/erlang-eunit.elc
Wrote /usr/share/emacs23/site-lisp/erlang/erlang-flymake.elc
Wrote /usr/share/emacs23/site-lisp/erlang/erlang-skels-old.elc
Wrote /usr/share/emacs23/site-lisp/erlang/erlang-skels.elc
Wrote /usr/share/emacs23/site-lisp/erlang/erlang-start.elc
Wrote /usr/share/emacs23/site-lisp/erlang/erlang.elc
Wrote /usr/share/emacs23/site-lisp/erlang/erlang_appwiz.elc
In toplevel form:
erldoc.el:64:1:Error: Cannot open load file: cl-lib
Wrote /usr/share/emacs23/site-lisp/erlang/path.elc
ERROR: install script from erlang-mode package failed
dpkg: error processing package erlang-mode (--configure):
subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
erlang-mode
E: Sub-process /usr/bin/dpkg returned an error code (1)
Thanks
I don't know what is causing your errors, but you could try ASDF with the Elixir plugin. This allows you to install multiple versions of Elixir and its dependencies, and uses your user environment with shims instead of installing to system directories. This avoids many of the dependency and permission problems that comes with performing a single system-level installation.
It looks like you have both emacs23 and emacs24 installed. The failure is happening when trying to build for emacs23. Unless you really want emacs23 for some reason, remove it and then it should install fine:
sudo apt-get remove emacs23
It is possible you might have to delete some of the other emacs23-* packages by hand.
This problem only affects the erlang-mode package, which adds support for editing Erlang code in Emacs. If you're not using Emacs (or not developing Erlang in it), you can just uninstall that package:
sudo apt remove erlang-mode
As noted in Penguin Brian's answer, this happens when installing erlang-mode on a system using Emacs 23, as erlang-mode only supports Emacs 24 or newer. (Looks like this is a bug in the package: it shouldn't try to compile itself for unsupported Emacs versions.) If you do want to use erlang-mode in Emacs, I'd suggest running Emacs 24 and installing the Erlang mode from MELPA.

Unmet dependencies when installing libboost-all-dev on i386/debian Docker image

I want to dockerize a build environment for Linux i386 targets. I need to install library dependencies such as boost. But I came across this error:
Dockerfile
FROM i386/debian:sid
RUN apt-get update
RUN apt-get -y install libboost1.67-all-dev
But even this simple script failed:
The following packages have unmet dependencies:
libboost1.67-all-dev : Depends: libboost-mpi1.67-dev but it is not going to be installed
Depends: libboost-mpi-python1.67-dev but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
I changed to libboost1.67-dev and it worked. I'm not sure what's the difference. If someone knows please explain that to me.
In a similar situation, I found two solutions:
opt.1) sudo apt install <unmet dependencies and sub-dependencies>
this is not straightforward but it should work
opt.2) give up all-dev and install only required packages which may be like
sudo apt install build-essential:i386 libboost-system-dev:i386 libboost-thread-dev:i386 libboost-program-options-dev:i386 libboost-test-dev:i386

cabal failed to install mtl missing dependency of transformers

I was trying to use cabal to install mtl while it told me I missed transformers ==0.4.* && ==0.5.2.0.
$ cabal install mtl
Resolving dependencies...
Configuring mtl-2.2.1...
cabal.exe: At least the following dependencies are missing:
transformers ==0.4.* && ==0.5.2.0
cabal.exe: Error: some packages failed to install:
mtl-2.2.1 failed during the configure step. The exception was:
ExitFailure 1
I stuck here for almost one week. I've installed transformers in version 0.4.3.0 and 0.5.2.0. My cabal is in version 1.10.2.0 and my ghc is 7.6.3. I'm new to ghc so I can't figure out what is the problem. I can't understand what the transformers ==0.4.* means. Any suggestions? Thanks a lot!
The line
transformers ==0.4.* && ==0.5.2.0
is a dependency constraint on the version of the transformers library. Here it states that it requires that the transformers version is at the same time 0.4.* and 0.5.2.0.
Although there can be different versions installed, during compilation only one version can be used—therefore, this constraint can never be satisfied.
For some reasons, cabal seems to get confused with the two revisions of the mtl package.
The second revision adds support for transformers-5. See also issue 30 of mtl, where it is noted that the metadata of hackage is the second revision, but the source tarball that is finally downloaded is the original revision.
Until a new version of mtl is released, you have to explicitly install transformers-0.4.3.0 (and only that version) and then install mtl.
cabal install transformers-0.4.3.0
If the dependencies are satisfied when installing mtl, transformers-0.4.3.0 will pass the dependency check.
It seems that cabal automatically adds the latest version as a dependency (e.g. == transformers-0.5.2.0) when that version is installed. Therefore, only 0.4.* versions should be installed.
If you have already installed the latest transformers version, you can uninstall it:
ghc-pkg unregister --force transformers-0.5.2.0
rm -r .cabal/packages/hackage.haskell.org/transformers/0.5.2.0
(Do this for every 5.x version that is installed, see cabal info transformers for a list of installed version.)

lua-sec-prosody Unable to locate package

using ubuntu 14.04LTS
trying to install jitsimeet >https://github.com/jitsi/jitsi-meet/blob/master/INSTALL.md
but fails to install lua-sec-prosody package
$sudo apt-get install lua-sec-prosody
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package lua-sec-prosody
sources.list contain this line at end.
deb http://packages.prosody.im/debian trusty main
I had the same problem.
Changed the line in the sources.list to a previous version and it worked.
deb http://packages.prosody.im/debian precise main
From what I gather, lua-sec-prosody is an (old) fork of lua-sec that merges in some required changes. If it's not available for your platform, it means you should just use lua-sec :)
http://prosody.im/doc/depends/luasec/prosody

dse-libcassandra-3.1.4-1.noarch conflicts with filesystem-3.2-13.fc19.x86_64

I'm unable to install dse-full or opscenter due to the following transaction errors
Total
Running transaction check
Running transaction test
Transaction check error:
file /usr/bin from install of dse-libcassandra-3.1.4-1.noarch conflicts with file from package filesystem-3.2-13.fc19.x86_64
file /usr/sbin from install of dse-libcassandra-3.1.4-1.noarch conflicts with file from package filesystem-3.2-13.fc19.x86_64
Error Summary
-------------
Is there some yum foo to get around this? Why would the package include a /user/bin and /usr/sbin?
**UPDATE Resolved**
I was able to work around this by doing the following:
Downloaded the latest rpm from the datastax repository using my login credentials:
wget http://xxx:xxx#rpm.datastax.com/enterprise/noarch/dse-libcassandra-3.1.4-1.noarch.rpm
Then ran:
rpm -Uvh --force dse-libcassandra-3.1.4-1.noarch.rpm
I had to do the same thing to get opscenter installed. I believe the rpm's were packaged incorrectly and hope it is resolved in a future release.
**NOTE**
If you use this solution you should also download the filesystem rpm and run:
rpm -Uvh --force filesystem-3.2-13.fc19.x86_64.rpm
This way /usr/bin and /usr/sbin is owned by the filesystem package again. Otherwise you might run into problems later trying to upgrade fedora.
Yes this is an issue in the rpm spec that has been resolved for upcoming releases. Both packages erroneously try to take control over /usr/bin and /usr/sbin.

Resources