Several debian packages fail to build with the following error.
"dh_sphinxdoc: error: 1.0/jquery-3.5.1.js is not in the index; is it up-to-date?"
It's not clear why this error is being generated, or what actions would resolve it. Some advice?
I tried to read the sphinx source code in order to find what steps would trigger an update of some kind of index. I tried searching for issues with debhelper and sphinx. I expected an error message which explains what the problem is and why it is a problem.
Related
The repo in question is /etc/zypp/repos.d/mysql-community-debuginfo.repo and all the other repos associated with the mysql package I downloaded for mysql80-community-release-sles12-6.noarch.rpm
The specific error is this
Unexpected exception.
/etc/zypp/repos.d/mysql-community-debuginfo.repo: Section [mysql80-community-debuginfo]: Line 9 contains garbage (no '=' or ',|/\' in key)
Please file a bug report about this.
See http://en.opensuse.org/Zypper/Troubleshooting for instructions.
The opensuse documentation listed doesn't really help at all
I've read the documentation for installing MySQL for SLES but I always get this error when I try to run any zypper commands.
Any help is appreciated.
This is my first post, so I might get the format wrong.. Anyway, after searching for a solution online (which I could not find), I resorted to asking here.
Upon launching my msfconsole a few days ago, I started getting all of these warnings/errors which were not showing before.
$ sudo msfconsole
[!] The following modules could not be loaded!..\
[!] /usr/share/metasploit-framework/modules/auxiliary/scanner/msmail/host_id.go
[!] /usr/share/metasploit-framework/modules/auxiliary/scanner/msmail/exchange_enum.go
[!] /usr/share/metasploit-framework/modules/auxiliary/scanner/msmail/onprem_enum.go
[!] Please see /root/.msf4/logs/framework.log for details.
metasploit v6.0.31-dev
I could not find any solution to this .go module loading issue. I might have screwed something over some time ago, but my last VM snapshot is just too far away.
Thank you all for your help!
just install go in your kali:
sudo apt install gccgo-go
I also got the same problem.
But, since the error message clearly ask me to check error log file, actually there is clear solution too.
[!] Please see /root/.msf4/logs/framework.log for details.
[09/05/2021 22:29:56] [e(0)] core: /usr/share/metasploit-framework/modules/auxiliary/scanner/msmail/onprem_enum.go failed to load - LoadError Failed to execute external Go module. Please ensure you have Go installed on your environment.
And after the Go installation, the problem is solved.
Therefore, the solutions is that you just need to install Go on your machine.
I need to get the meta data, especially the iptc meta data from the uploaded files on the server.
I have found two packages I can import, but both of them require the "libiptcdata" libary. It should not be a problem, but after I installed the libary with brew, as it is written on both of the packages page, and typed go get "https://github.com/Melraidin/iptc" (for example, one of the two packages I wanted to use), I got the following error:
../../github.com/Melraidin/iptc/main.go:10:10: fatal error: libiptcdata/iptc-data.h: No such file or directory
#include <libiptcdata/iptc-data.h>
^~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
The error is real, the file is really is not there, but how then it could work at anyone else? I found these 2 packages suggestion of using on a few page.
Thank you for your help
First, I have removed the brew installed "libiptcdata" libary, than installed the following libaries:
"libiptcdata0"
"libiptcdata0-dev"
"python-iptcdata"
with these three, the "go get" is managed to run, and could continue working on the original problem...
I'm cross-compiling ecasound, which goes well up to the point that all binaries get compiled, but fails during (at the end of?) the installation phase.
The thing is, I don't see any error message or anything, so I'm left guessing here:
ecasound: installs files in /home/buildroot/buildroot-2018.02-rc2/output/target//home/buildroot/buildroot-2018.02-rc2/output
make[1]: *** [/home/buildroot/buildroot-2018.02-rc2/output/build/ecasound-2.9.1/.stamp_target_installed] Error 1
make: *** [_all] Error 2
Full output: https://pastebin.com/ca6FJebB (hope this contains enough details)
Presumably the ecasound 'make install' returns (silently?) with an error. We don't have an ecasound package in upstream Buildroot, so it is hard to know what you are doing, but the install location (../output/target/home/buildroot/..) certainly looks wrong.
It did work after first doing a complete build, followed by ecasound seperately, indicating it was missing dependencies. Turned out the missing piece here was: BR2_PACKAGE_PYTHON_CURSES.
In case anyone wants to build ecasound for buildroot, a working package is available in my github account.. Not sure if it's clean code/by the book, but it works..
The problem is your install path somehow duplicated itself
/home/buildroot/.../target//home/buildroot/...
I have seen this several times too, and havent really found a way to fix it except to make clean & make again
I am now trying to install mingw for a couple of hours, however I keep on getting the following error message:
"install: gcc-c++-4.8.1-4-mingw32-bin.tar.lzma
installing gcc-c++-4.8.1-4-mingw32-bin.tar.lzma
mingw-get-gui: * ERROR * unexpected end of archive reading header record"
and cannot find any solution to my problem. I tried to reinstall 7zip, because I thought it may caused from that. I am trying to install gcc on a 32-bit Windows 7. I would be really happy for any suggestions.
Bye!
Even though this is an old question, I will post an answer, in case other users come across this again.
I encountered the same problem:
at first I did not notice that something went wrong with the installation/upgrade itself, because the graphical update manager showed a line like "everything went successful" ...
if I had bothered to look into the log details, I would have seen the error messesage mingw-get-gui: * ERROR * unexpected end of archive reading header record and immediately known, that something went wrong (its really misleading, to show a dialog saying that a task was completed successfully when there were errors!).
But pertaining to your problem (or at least this was, what caused mine):
Cause
most likely something went wrong, when the mentioned archive file was downloaded. Unfortunately, mingw-get seems to ignore download errors and continues as if nothing went wrong... thus the error message archive header record is invalid, because it is not really an archive file, but a text file containing the HTML error message.
To complicate things further, mingw-get caches these files and when you try to re-install the packages it uses these invalid, cached files.
Solution
One way of fixing this, would be to delete the cached files and then re-install the package.
The cached files should be at
<mingw directory>\var\cache\mingw-get\packages
e.g.
C:\MinGW\var\cache\mingw-get\packages
Side Note: if you "lost" the error message like me, and don't know, for which packages there was an error, you can search the cache directory for files which contain the HTML error message, e.g. a search term like <html> should work; also these files are quite small, but there may also be other valid packages with small file size to this is no unambiguous criterion
If you continue to get error messages * ERROR * unexpected end of archive reading header record with the mingw-get tool you could also try to download the file manually and place it in the folder for the cached packages.
For re-installing the packages you could use the graphical interface of mingw-get (e.g. remove and then install the package) or, for example the command line version
mingw-get --reinstall install <package name>
for mingw packages the <package name> is usually just the prefix of the file name (before the first version number), e.g. for
libiconv-1.14-3-mingw32-dev.tar.lzma
the package name would be libiconv. For msys packages the package name usually has the prefix msys-, e.g. something like msys-libopts
(you should be able to see if it's a mingw or a msys package by looking at the part of the file name that comes after the first version number, e.g. for libiconv-1.14-3-mingw32-dev.tar.lzma: ...3-mingw32-de...)