I removed by mistake /usr/lib64/libpython2.7.so, and as a consequence, yum does not work.
So I'm trying to reinstall python2.7.18 (which is the version that I currently have) from source, but in compilation I get that some modules are missing
Python build finished, but the necessary bits to build these modules were not found:
_bsddb _curses _curses_panel
_ssl _tkinter bsddb185
bz2 dl imageop
readline sunaudiodev
To find the necessary bits, look in setup.py in detect_modules() for the module's name.
But:
yum doesn't work, pip2 also doesn't work, setuptools for python setup.py install is not found...
And all solutions I'm finding involve some of those, so I'm getting into some circular problem here.
I looked for the *.rpm for python 2.7.18 for CentOS 7, in the hope I could just install it with rpm and solve the issue, but I couldn't find it.
Any idea?
Found a solution, starting from here.
After manually rm-ing all the /usr/**/*python2.7* files (probably just the libpython2.7.so* and the python2.7 executables would be enough), from
http://mirror.centos.org/centos/7/os/x86_64/Packages/, I downloaded
bzip2-devel-1.0.6-13.el7.x86_64.rpm
compat-db-4.7.25-28.el7.x86_64.rpm
dlm-devel-4.0.7-1.el7.x86_64.rpm
dlm-lib-4.0.7-1.el7.x86_64.rpm
gdbm-1.10-8.el7.x86_64.rpm
gdbm-devel-1.10-8.el7.x86_64.rpm
keyutils-libs-devel-1.5.8-3.el7.x86_64.rpm
krb5-devel-1.15.1-46.el7.x86_64.rpm
libcom_err-devel-1.42.9-17.el7.x86_64.rpm
libdb-devel-5.3.21-25.el7.x86_64.rpm
libdb-tcl-5.3.21-25.el7.x86_64.rpm
libdb-tcl-devel-5.3.21-25.el7.x86_64.rpm
libselinux-devel-2.5-15.el7.x86_64.rpm
libsepol-devel-2.5-10.el7.x86_64.rpm
libverto-devel-0.2.5-4.el7.x86_64.rpm
ncurses-devel-5.9-14.20130511.el7_4.x86_64.rpm
openssl-devel-1.0.2k-19.el7.x86_64.rpm
pkgconfig-0.27.1-4.el7.x86_64.rpm
python-2.7.5-88.el7.x86_64.rpm
python-devel-2.7.5-88.el7.x86_64.rpm
python-libs-2.7.5-88.el7.x86_64.rpm
python-pycurl-7.19.0-19.el7.x86_64.rpm
sqlite-3.7.17-8.el7_7.1.x86_64.rpm
sqlite-devel-3.7.17-8.el7_7.1.x86_64.rpm
sqlite-tcl-3.7.17-8.el7_7.1.x86_64.rpm
python-setuptools-0.9.8-7.el7.noarch.rpm
python-six-1.9.0-2.el7.noarch.rpm
python-tools-2.7.5-88.el7.x86_64.rpm
python-urlgrabber-3.10-10.el7.noarch.rpm
readline-6.2-11.el7.x86_64.rpm
readline-devel-6.2-11.el7.x86_64.rpm
popt-devel-1.13-16.el7.x86_64.rpm
rpm-4.11.3-43.el7.x86_64.rpm
rpm-apidocs-4.11.3-43.el7.noarch.rpm
rpm-build-4.11.3-43.el7.x86_64.rpm
rpm-build-libs-4.11.3-43.el7.x86_64.rpm
rpm-devel-4.11.3-43.el7.x86_64.rpm
rpmdevtools-8.3-5.el7.noarch.rpm
rpm-libs-4.11.3-43.el7.x86_64.rpm
rpm-python-4.11.3-43.el7.x86_64.rpm
sqlite-3.7.17-8.el7_7.1.x86_64.rpm
sqlite-devel-3.7.17-8.el7_7.1.x86_64.rpm
tcl-devel-8.5.13-8.el7.x86_64.rpm
tix-8.4.3-12.el7.x86_64.rpm
tix-devel-8.4.3-12.el7.x86_64.rpm
tk-devel-8.5.13-6.el7.x86_64.rpm
tkinter-2.7.5-88.el7.x86_64.rpm
yum-3.4.3-167.el7.centos.noarch.rpm
yum-metadata-parser-1.1.4-10.el7.x86_64.rpm
zlib-devel-1.2.7-18.el7.x86_64.rpm
and installed them with sudo rpm -Uvh --replacepkgs --force *.rpm.
Yum works fine now.
When I attempt to run yum updates on my CentOS 7 VM, the process aborts with the following information:
--> Finished Dependency Resolution
--> Running transaction check
---> Package kernel.x86_64 0:3.10.0-693.el7 will be erased
---> Package msodbcsql17.x86_64 0:17.2.0.1-1 will be updated
--> Processing Dependency: msodbcsql17 < 17.3.0.0 for package: mssql-tools-17.2.0.2-1.x86_64
--> Finished Dependency Resolution
Error: Package: mssql-tools-17.2.0.2-1.x86_64 (#packages-microsoft-com-prod)
Requires: msodbcsql17 < 17.3.0.0
Removing: msodbcsql17-17.2.0.1-1.x86_64 (#packages-microsoft-com-prod)
msodbcsql17 = 17.2.0.1-1
Updated By: msodbcsql17-17.3.1.1-1.x86_64 (packages-microsoft-com-prod)
msodbcsql17 = 17.3.1.1-1
Available: msodbcsql17-17.0.1.1-1.x86_64 (packages-microsoft-com-prod)
msodbcsql17 = 17.0.1.1-1
Available: msodbcsql17-17.1.0.1-1.x86_64 (packages-microsoft-com-prod)
msodbcsql17 = 17.1.0.1-1
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
How can I solve this properly without just skipping over the errors? Thanks in advance.
The repo is properly sync'd now. A normal install or update is possible again.
Likely just a short term issue with the MS repos not in sync.
Periodically run:
yum clean all
and try the update again.
I fixed it by using a previous version
sudo ACCEPT_EULA=Y yum install msodbcsql17-17.2.0.1-1.x86_64 mssql-tools -y
I have created a c++ app on Debian Jessie 8.10 amd64 which also need the following libraries:
sudo apt-get install libssl-dev
sudo apt-get install libcurl4-openssl-dev
I also need to cross compile the source code for armhf. So according to this quite helpful link https://wiki.embeddedarm.com/wiki/Jessie_armhf_Cross_Compile I gave the following commands:
sudo apt-get install curl build-essential
su root
echo "deb http://emdebian.org/tools/debian jessie main" >
/etc/apt/sources.list.d/emdebian.list
curl http://emdebian.org/tools/debian/emdebian-toolchain-archive.key | apt-key add -
dpkg --add-architecture armhf
apt-get update
apt-get install crossbuild-essential-armhf
Everything got installed correctly and then I also gave :
sudo apt-get install libssl-dev:armhf
sudo apt-get install libcurl4-openssl-dev:armhf
The first command executed successfully. On the other hand the second one failed giving the following output:
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
libcurl4-doc:armhf libcurl3-dbg:armhf libidn11-dev:armhf libkrb5-dev:armhf libldap2-dev:armhf
librtmp-dev:armhf libssh2-1-dev:armhf pkg-config:armhf
The following NEW packages will be installed:
libcurl4-openssl-dev:armhf
0 upgraded, 1 newly installed, 0 to remove and 2 not upgraded.
23 not fully installed or removed.
Need to get 0 B/316 kB of archives.
After this operation, 863 kB of additional disk space will be used.
(Reading database ... 94032 files and directories currently installed.)
Preparing to unpack .../libcurl4-openssl-dev_7.38.0-4+deb8u8_armhf.deb ...
Unpacking libcurl4-openssl-dev:armhf (7.38.0-4+deb8u8) ...
dpkg: error processing archive /var/cache/apt/archives/libcurl4-openssl-dev_7.38.0-4+deb8u8_armhf.deb (--unpack):
trying to overwrite shared '/usr/include/curl/curlbuild.h', which is different from other instances of package libcurl4-openssl-dev:armhf
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Processing triggers for man-db (2.7.0.2-5) ...
Errors were encountered while processing:
/var/cache/apt/archives/libcurl4-openssl-dev_7.38.0-4+deb8u8_armhf.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
Since I'm quite new in cross compilation procedures does anyone have any idea what I'm doing wrong?
You are doing nothing wrong. It is a file conflict in related with multiarch packages. It is a bug in the package
Here is a explanation of this kind of bugs, from https://wiki.debian.org/MultiArch/Hints
The package in question is marked Multi-Arch: same, but has
conflicting versions of at least one file for different architectures.
The hint tells the filename (or the number of filenames) and the
architectures (or number of architectures) in question. The easiest
way to fix is to remove the Multi-Arch: same declaration, but often
enough it can be fixed by moving the offending files to
per-architecture locations (typically
/usr/lib/$(DEB_HOST_MULTIARCH)/). For *-dev packages, the Multi-Arch:
same capability often is not critical and removing is a good initial
measure.
I just run into the same kind of problem, which still is an issue with some packages. In my case libcurl-openssl-dev was replacing the /usr/bin/curl-config binary.
To me it required swapping from x64/i386 libraries when i needed cross-compiling but i am well aware it might not be possible for everyone.
While installing utop via opam on my ArchLinux laptop, I got the following message:
$ opam install utop
The following actions will be performed:
- install camomile.0.8.5 [required by utop]
- install zed.1.3 [required by utop]
- install lambda-term.1.6 [required by utop]
- install utop.1.14
4 to install | 0 to reinstall | 0 to upgrade | 0 to downgrade | 0 to remove
Do you want to continue ? [Y/n]
=-=-= Installing camomile.0.8.5 =-=-=
Applying cmxs.patch.
[ERROR] Due to some errors while processing camomile.0.8.5, the following actions will NOT proceed:
- install utop.1.14
- install lambda-term.1.6
- install zed.1.3
===== ERROR while installing camomile.0.8.5 =====
Could not get the source for camomile.0.8.5:
# opam-version 1.1.1
# os linux
Patch file "/home/sinan/.opam/system/build/camomile.0.8.5/cmxs.patch" not found.
'opam install utop' failed.
Trying to install camomile by itself also gives the same error. This seems to be related to commit 672e44e which carried over to the opam repository as cmxs.patch. I am not sure where things break so that opam tries to build without the patch file.
I tried downloading, and putting cmxs.patch in the reported location, but, of course, that directory gets clobbered the next time I try to install via opam.
How should I proceed?
I would have preferred to have been able to fix the underlying problem, but, in the end, downloading the contents of the cmxs.patch file, adding it to the already downloaded ~/.opam/archives/camomile.0.8.5+opam.tar.gz archive, and then issuing
$ opam install camomile
worked.
After that, opam install utop went without a hitch as well.
For your reference, I have:
$ opam --version
1.1.1
$ cat .opam/repo/default/repo
upstream: "https://github.com/ocaml/opam-repository/tree/master/"
browse: "https://opam.ocaml.org/pkg/"
I am experiencing very annoying problems with the application apktool problem.
I do not understand what i am doing wrong, or what the problem is.
I tried this on debian , and on linux mint. I used different versions of apktool,
resulting in the same error:
I: Checking whether sources has changed...
I: Checking whether resources has changed...
I: Building resources...
Exception in thread "main" brut.androlib.AndrolibException: brut.common.BrutException: could not exec command: [aapt, p, -F, /tmp/APKTOOL3630495287059303807.tmp, -I, /home/awesomename/apktool/framework/1.apk, -S, /home/awesomename/out/./res, -M, /home/awesomename/out/./AndroidManifest.xml]
at brut.androlib.res.AndrolibResources.aaptPackage(Unknown Source)
at brut.androlib.Androlib.buildResourcesFull(Unknown Source)
at brut.androlib.Androlib.buildResources(Unknown Source)
at brut.androlib.Androlib.build(Unknown Source)
at brut.androlib.Androlib.build(Unknown Source)
at brut.apktool.Main.cmdBuild(Unknown Source)
at brut.apktool.Main.main(Unknown Source)
Caused by: brut.common.BrutException: could not exec command: [aapt, p, -F, /tmp/APKTOOL3630495287059303807.tmp, -I, /home/windows/apktool/framework/1.apk, -S, /home/windows/out/./res, -M, /home/windows/out/./AndroidManifest.xml]
at brut.util.OS.exec(Unknown Source)
... 7 more
Caused by: java.io.IOException: Cannot run program "aapt": error=2, No such file or directory
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1041)
at java.lang.Runtime.exec(Runtime.java:617)
at java.lang.Runtime.exec(Runtime.java:485)
... 8 more
Caused by: java.io.IOException: error=2, No such file or directory
at java.lang.UNIXProcess.forkAndExec(Native Method)
at java.lang.UNIXProcess.<init>(UNIXProcess.java:135)
at java.lang.ProcessImpl.start(ProcessImpl.java:130)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1022)
... 10 more
It seems it can not use aapt , but i read about apktool.
And it seems that aapt is build inside apktool , why is it not working ?
It seems there's some problem in building the resources while recompiling the apk.
what you can do is, when you decompile your apk use this command
apktool d -f -r apkfilename.apk
here -f is to replace previous decompiled apk's code and -r is to ignore the decompiling of resources.
this would prevent the resources from being decompiled and will simply copy the same resources when you recompile the apk.
In case you've been using v1 and now upgraded to v2, try manually deleting the framework file.
On windows 8 it's normally at C:\Users\YourName\apktool\framework\1.apk.
The file should be regenerated once you try to build something.
My problem was solved by deleting the \framework\1.apk, making a backup on the files I modified, ereasing the dir and decompiling the *.apk again, etc... (on linux, the path is home/[user]/apktool/...). After the update, apktool always loaded the old resource table. N
For me, I solved this problem by first clearing apktool's framework directory by typing in the terminal.
$ apktool empty-framework-dir
Afterwards I uninstalled apktool and related files by typing
$ sudo apt purge apktool
Then i went to https://bitbucket.org/iBotPeaches/apktool/downloads/ to get the latest jar file for apktool(apktool_2.5.0.jar as at the time of writing this).
On first run
$ java -jar apktool_2.5.0.jar b <MyAPP.apk> #Without ><
it works.
since I work with apktool most of the times I needed a situation where I can run apktool from anywhere so I gave the jar file execute permissions by typing
$ sudo chmod +x apktool_2.5.0.jar
Afterwards I moved it /usr/bin/ by typing
$ sudo apktool_2.5.0.jar /usr/bin/
Definitely seems like the aapt PATH problem I had awhile back. Have you added aapt to PATH? If you still have problems, I have made a good apk kit in bash to avoid all these dependency problems. It supports apktool, signapk, zipalign,adb, fastboot, and heimdall. Check it out. All you need is a current java install.
http://forum.xda-developers.com/android/development/toolkit-apk-munky-rench-t3026757/post58747626#post58747626
There isn’t really enough information to give you a definite answer.
How ever you mentioned using different versions but the aapt issue was solved in version 2.4. Dependencies have been reduced to java version 1.8 or greater and the framework.
I use Debian and have the following:
Apktool 2.4
java version 11
Android framework
That’s all it took to get rid of the aapt path error.
The last error I came across was unrelated to aapt but was on the framework so I ran this command
apktool empty-framework-dir
And it solved it.
try to put the dir which include aapt file to your PATH. for example, export PATH=$PATH:./ ./apktool b
try to install ia32-libs and update latest version of apktool. (if possible restart)
apktool requires "ia32-libs" which is not available after Ubuntu 12.04. install ia32-libs
sudo apt-get install lib32z1 lib32ncurses5 lib32bz2-1.0 lib32stdc++6
Download latest version of apktools.jar - https://bitbucket.org/iBotPeaches/apktool/downloads
apktool complete installation guide - http://ibotpeaches.github.io/Apktool/install/
I just encounter same problem when run apktool d foo.apk(decompiled success) and then apktool b foo(recompile failed with similar error).
The apktool tool above was installed via sudo apt-get install apktool on Kali Linux.
So, the solution was visits apktool's official site, e.g. https://connortumbleson.com/2017/01/23/apktool-v2-2-2-released/ (it's latest version at this time of writing), download it, md5sum it, e.g. md5sum apktool_2.2.2.jar to verify, then rename that apktool_2.2.2.jar to apktool.jar.
Then do java -jar ./apktool.jar b foo to recompile, it success without error (the generated apk located at ./foo/dist/foo.apk).
The main issue is apktool version you need 2.4.0
You must manually install it from ibotpeaches git hub
here some good info
https://www.youtube.com/watch?v=kB6s10Uwpcs
and a automated script for kali
https://github.com/catenatedgoose?tab=repositories
In my mind the problem is how you install apktool...
I had the same problem and I did this and it worked very well:
For installation you first have to remove any installed apktool by the command:
sudo apt purge apktool
Then you'll have to install apktool but in a different way.
To continue save the link bellow as apktool in a directory.
[https://raw.githubusercontent.com/iBotPeaches/Apktool/master/scripts/linux/apktool]
Then open this link below and download the latest apktool.jar file: https://bitbucket.org/iBotPeaches/apktool/downloads/
Then rename the file as apktool.jar
After that give both files the permission by the command:
Sudo chmod -x apktool.jar
And for the saved script:
Sudo chmod -x apktool
At the end copy both files in the directory:
/usr/local/bin
By the command:
Sudo cp apktool.jar /usr/local/bin
And the script file:
Sudo cp apktool /usr/local/bin
After that try running apktoolin the terminal.
The solution is to include your apktool directory into your system PATH.