similar error .../data/auth/mongodb-aws.rst (before removing this file)##
i encountered this problem once before but cannot remember how to fix it...
starting with an up and running project on wsl2 (ubuntu20.04) after adding a simple dependency golang.org/x/net/proxy and running go mod tidy => go mod vendor started to show this error each time:
-tried to change ownership of the mentioned package
-tried to change w/r permissions of mentioned package
-tried to remove whole go module (go.mod + go.sum + vendor...) and re-initialize it
-tried to create a whole new Golang environment with a different version of go.mongodb.org/mongo-driver (v1.9.0) \
its worth mentioning that even after resetting my version control to commits which are
already up and running on other devices, same error occurs locally(works fine inside docker) so its most likely an os-level problem (i have no proxy or vpn activated on my machine and dns is as usual) \
GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/feedmeun1c0de/.cache/go-build"
GOENV="/home/feedmeun1c0de/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/feedmeun1c0de/code_storage/gozone/CPO_Tor/Ozzy/vendor/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/feedmeun1c0de/code_storage/gozone/CPO_Tor/Ozzy/vendor"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/feedmeun1c0de/sdk/go1.19"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/feedmeun1c0de/sdk/go1.19/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.19"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/feedmeun1c0de/code_storage/gozone/CPO_Tor/Ozzy/go.mod"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-
map=/tmp/go-build3018163972=/tmp/go-build -gno-record-gcc-switches"
anyone has any clue how to fix this?
Related
I tried to build the Android SDK Addon System Image of halogenOS 13 (AOSP 13, nothing was changed in the AOSP source code yet).
The steps to build are as usual:
source build/envsetup.sh
lunch aosp_sdk_phone_x86_64-eng
m sdk_addon
At 100%, the build fails with following error:
[100% 12483/12483] Packaging SDK Addon System-Image: out/host/linux-x86/sdk_addon/custom-eng.simao--
FAILED: out/host/linux-x86/sdk_addon/custom-eng.simao--img.zip
/bin/bash -c "(cp -R out/target/product/emulator_x86_64/data out/host/linux-x86/obj/SDK_ADDON/custom_intermediates/custom-eng.simao--img/images/x86_64/data ) && (out/host/linux-x86/bin/soong_zip -o out/host/linux-x86/sdk_addon/custom-eng.simao--img.zip -C out/host/linux-x86/obj/SDK_ADDON/custom_intermediates/custom-eng.simao--img/images/ -D out/host/linux-x86/obj/SDK_ADDON/custom_intermediates/custom-eng.simao--img/images/x86_64 )"
cp: bad 'out/target/product/emulator_x86_64/data': No such file or directory
13:17:13 ninja failed with: exit status 1
If I just mkdir out/target/product/emulator_x86_64/data, of course, that just solves the build error but the SDK addon does not actually boot in the emulator due to encryption issues with the userdata partition so I think this is related. This makes me guess that in the data directory there should be some files in there but for some reason the are not created.
EDIT:
What's really odd here is that the file device/generic/goldfish/vendor.mk explicitly adds some data files to PRODUCT_COPY_FILES, notably:
PRODUCT_COPY_FILES += \
device/generic/goldfish/data/etc/dtb.img:dtb.img \
device/generic/goldfish/emulator-info.txt:data/misc/emulator/version.txt \
device/generic/goldfish/data/etc/apns-conf.xml:data/misc/apns/apns-conf.xml \
device/generic/goldfish/radio/RadioConfig/radioconfig.xml:data/misc/emulator/config/radioconfig.xml \
device/generic/goldfish/data/etc/iccprofile_for_sim0.xml:data/misc/modem_simulator/iccprofile_for_sim0.xml \
If I manually build them using, for example, m out/target/product/emulator_x86_64/data/misc/emulator/version.txt, the file is created at the correct location, as expected. Which leads me to wonder when entries PRODUCT_COPY_FILES are considered targets to be built and when they aren't.
EDIT2:
I got the emulator to boot but the data directory is still not being created. (Creating manually or building one target in the data dir is a workaorund).
While enabling libvirt in yocto, I am seeing below data file clash issue while building yocto image,
Below are the packages I am trying to append install to my yocto image
IMAGE_INSTALL_append = " \
packagegroup-core-boot \
qemu \
libvirt \
libvirt-libvirtd \
libvirt-virsh \
kernel-module-kvm \
kernel-module-kvm-intel \
"
But I see below issue, when I build image enabling above packages,
`Collected errors:
check_data_file_clashes: Package iptables wants to install file /-/-/-/rootfs/etc/ethertypes
But that file is already provided by package * ebtables`
FYI: I see that libvirt has both iptables and ebtables dependency.
can someone help on understanding this and how to resolve?
I tried to remove ebtables with PACKAGECONFIG_remove = "ebtables" and image is built but I when starting libvirtd service it is always in dead mode and I see some issue related to socket.
Actually, this is a problem that has no solution except:
Remove one of the packages (ebtables or iptables)
Remove the file ethertypes from one of the recipes
libvirt depends on iptables on compile time only, so I did not know why iptables is present in the image ?
Anyways, it has a config on ebtables and from your comment when you removed it from PACKAGECONFIG it failed to work. So:
I suggest check if iptables is required by other package at run time, if not remove it.
If both are required in your case, then go for the second solution which is removing the file from one of the recipes, using a bbappend file for one of them:
The block that you may need to add is:
do_install_append() {
rm ${D}/etc/ethertypes
}
either to:
meta-custom/recipes-filter/ebtables/ebtables_%.bbappend
or to:
meta-custom/recipes-extended/iptables/iptables_%.bbappend
NOTE
If you go for the second solution, you need to make sure that the file is not present in the FILES variable of the recipe that you will remove the file from, FILES_ebtables or FILES_iptables.
I am attempting to install DevStack on a CentOS system. I have performed the necessary setup for running stack.sh, but when I run it I am getting the following failure:
Installing collected packages: PyYAML, zipp, importlib-metadata, stevedore, colorama, pyperclip, cmd2, pyparsing, cliff, future, stestr, os-testr
Attempting uninstall: PyYAML
Found existing installation: PyYAML 5.3
ERROR: Cannot uninstall 'PyYAML'. It is a distutils installed project and thus we cannot accurately determine which files belong to it which would lead to only a partial uninstall.
+inc/python:pip_install:1 exit_trap
+./stack.sh:exit_trap:489 local r=1
++./stack.sh:exit_trap:490 jobs -p
+./stack.sh:exit_trap:490 jobs=
+./stack.sh:exit_trap:493 [[ -n '' ]]
+./stack.sh:exit_trap:499 '[' -f '' ']'
+./stack.sh:exit_trap:504 kill_spinner
+./stack.sh:kill_spinner:399 '[' '!' -z '' ']'
+./stack.sh:exit_trap:506 [[ 1 -ne 0 ]]
+./stack.sh:exit_trap:507 echo 'Error on exit'
Error on exit
+./stack.sh:exit_trap:509 type -p generate-subunit
+./stack.sh:exit_trap:512 [[ -z /opt/stack/logs ]]
+./stack.sh:exit_trap:515 /usr/bin/python3.6 /opt/stack/devstack/tools/worlddump.py -d /opt/stack/logs
ebtables v1.8.4 (nf_tables): table `broute' is incompatible, use 'nft' tool.
+./stack.sh:exit_trap:524 exit 1
Researching this on the Internet, I have learned that this failure apparently occurs when python's pip3 commamd attempts to uninstall something that was installed using distutils (including, apparently, PyYAML). I also see that somewhere in stack.sh PyYAML gets installed, then later an attempt is made to uninstall it which fails!
I have also looked at the setup.py script that comes with Devstack, but that script apparently does not use distutils. It is used elsewhere during the PyYAML install, but cannot find where it is.
Worse, there are workarounds (including using the --ignore-installed option for PIP), but I am not seeing where to place that option in stack.sh or any of the other files I have seen.
As things stand, stack.sh looks to be unusable. It is incapable of installing Devstack because of this problem.
Has anyone found a way to install Devstack and get around this problem? Is there an alternative to stack.sh? To devstack?
I have found a solution to my problem:
Do not use Devstack. Use Packstack.
I have even posted a bug report on this problem for Devstack. It doesn't appear that it is going to be fixed in the near future. Consequently, those seeking to create a development installation should use Packstack. I was able to install and run Openstack with Packstack using the instructions provided in:
https://www.linuxtechi.com/install-openstack-centos-8-with-packstack/
At first I run the command to see my layers:
$bitbake-layers show-layers
layer path priority
meta .../poky-krogoth-15.0.0/meta 5
meta-poky .../poky-krogoth-15.0.0/meta-poky 5
meta-yocto-bsp .../poky-krogoth-15.0.0/meta-yocto-bsp 5
meta-oe .../meta-openembedded/meta-oe 6
and build my image:
bitbake core-image-sato
everything is OK,I found the meta-oe layer is useless. So I delete it:
bitbake-layers remove-layer .../meta-openembedded/meta-oe
and build it again:
$bitbake core-image-sato
it show error:
ERROR: core-image-sato-1.0-r0 do_rootfs: Unable to install packages.
Command
'/buildarea/ddu/poky-krogoth-15.0.0/build-beaglebone/tmp/sysroots/x86_64-linux/usr/bin/smart
--log-level=warning --data-dir=/buildarea/ddu/poky-krogoth-15.0.0/build-beaglebone/tmp/work/beaglebone-poky-linux-gnueabi/core-image-sato/1.0-r0/rootfs/var/lib/smart
install -y packagegroup-core-ssh-dropbear#all
packagegroup-core-x11-sato-games#beaglebone
packagegroup-core-x11-base#all smartpm#cortexa8hf_neon
psplash#cortexa8hf_neon packagegroup-core-boot#beaglebone
packagegroup-base-extended#beaglebone rpm#cortexa8hf_neon
packagegroup-core-x11-sato#beaglebone
locale-base-en-us#cortexa8hf_neon locale-base-en-gb#cortexa8hf_neon'
returned 1:
Loading cache...
Updating cache...
################################## [100%]
Computing transaction...error: Can't install
packagegroup-core-x11-utils-1.0-r40#all: no package provides
xserver-nodm-init
ERROR: core-image-sato-1.0-r0 do_rootfs: Function failed: do_rootfs
ERROR: Logfile of failure stored in:
/buildarea/ddu/poky-krogoth-15.0.0/build-beaglebone/tmp/work/beaglebone-poky-linux-gnueabi/core-image-sato/1.0-r0/temp/log.do_rootfs.52174
ERROR: Task 9
(/buildarea/ddu/poky-krogoth-15.0.0/meta/recipes-sato/images/core-image-sato.bb,
do_rootfs) failed with exit code '1'
Why it said that no package provides xserver-nodm-init?
$find ../meta -name xserver-nodm-init*
../meta/recipes-graphics/x11-common/xserver-nodm-init.bb
../meta/recipes-graphics/x11-common/xserver-nodm-init
Because of the way meta-oe currently replaces some of the X11 startup components, you pretty much need to delete TMPDIR if you've build X11 with meta-oe in your bblayers.conf and then decide you want to remove meta-oe (as you have done). However, if you now just delete TMPDIR but not your sstate-cache and then try again then it'll restore everything back to where you were from sstate pretty quickly without needing to recompile everything, and the issue should be resolved.
What meta-oe is doing isn't desirable, there is a bug open to fix it:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=5546
It's assigned to me and I'm sad to say I haven't had time to resolve it so far; it doesn't appear to be a priority for anyone else either.
First of all. Why do you think meta-oe is useless?
And why do you want to delete it? It does no harm?
The general rule is. If it does not break, Do not fix it.
Like you said. Put everything back and it will work.
I'm trying to build a very simple PostgreSQL client in C over Cygwin.
Here's what I've done so far:
I've downloaded the PostgreSQL source code version 9.1.2 (to match the same version that is running on my server)
I've configured and compiled the source code from Cygwin. The compilation seemed to go smoothly.
From what I can tell, the header files are in:
/cygdrive/c/workspace/src/postgresql-9.1.2/src/interfaces/libpq, and
/cygdrive/c/workspace/src/postgresql-9.1.2/src/include
The libraries are in:
/cygdrive/c/workspace/src/postgresql-9.1.2/src/interfaces/libpq
From here, I compiled and linked the client program using the makefile below:
testlibpq: testlibpq.c
gcc -o testlibpq -I /cygdrive/c/workspace/src/postgresql-9.1.2/src/interfaces/libpq -I /cygdrive/c/workspace/src/postgresql-9.1.2/src/include -L /cygdrive/c/workspace/src/postgresql-9.1.2/src/interfaces/libpq testlibpq.c -Bstatic -lpq
The compilation and the linking succeeded without errors or warnings.
However, when I try to run the program, I get the following error:
$ ./testlibpq
/cygdrive/c/Users/dleclair/Dropbox/denis/src/testlibpq/testlibpq.exe: error while loading shared libraries: cygpq.dll: cannot open shared object file: No such file or directory
I haven't figured out how to fix this. Any pointers would be greatly appreciated.
Oh, one more thing, I found the folder that cygpq.dll was sitting in and set my LD_LIBRARY_PATH to point to it but it still gave me the same result.
dleclair#dleclair-win7l ~/Dropbox/denis/src/testlibpq
$ ls /cygdrive/c/workspace/src/postgresql-9.1.2/src/interfaces/libpq
bcc32.mak encnames.o fe-connect.o fe-misc.o fe-protocol3.o ip.o libpq-events.c md5.c pgstrcasecmp.c pqsignal.c thread.o
blibpqdll.def exports.txt fe-exec.c fe-print.c fe-secure.c libpq.a libpq-events.h md5.o pgstrcasecmp.o pqsignal.h wchar.c
chklocale.c fe-auth.c fe-exec.o fe-print.o fe-secure.o libpq.rc.in libpq-events.o nls.mk po pqsignal.o wchar.o
chklocale.o fe-auth.h fe-lobj.c fe-protocol2.c inet_net_ntop.c libpqddll.def libpq-fe.h noblock.c pqexpbuffer.c pthread-win32.c win32.c
cygpq.dll fe-auth.o fe-lobj.o fe-protocol2.o inet_net_ntop.o libpq-dist.rc libpq-int.h noblock.o pqexpbuffer.h README win32.h
encnames.c fe-connect.c fe-misc.c fe-protocol3.c ip.c libpqdll.def Makefile pg_service.conf.sample pqexpbuffer.o thread.c win32.mak
dleclair#dleclair-win7l ~/Dropbox/denis/src/testlibpq
$ echo $LD_LIBRARY_PATH
/cygdrive/c/workspace/src/postgresql-9.1.2/src/interfaces/libpq
dleclair#dleclair-win7l ~/Dropbox/denis/src/testlibpq
Normally on unix/linux systems after building the source a make install is done which copies the headers to standard locations like /usr/local/include and /usr/local/lib. You may have to do that on cygwin to to get the DLL in the search path.
Or you can just locate the DLL yourself and put it on the search path or in the same folder as your executable.