| View previous topic :: View next topic |
| Author |
Message |
Katackae
n00b
Joined: 02 Jul 2018
Posts: 3
|
 Posted: Mon Jul 02, 2018 3:51 am Post subject: Meson Ebuild Failing w/ Python GAI Errno -3 [SOLVED] |
 |
|
When attempting to emerge the ebuild the following output is produced
| Code: | (cr) ((bddf217e...)) julian@julian-System-Product-Name /mnt/host/source/src/third_party/portage-stable/dev-python/pip $ sudo emerge -1av gputop
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild N ~] dev-libs/gputop-0.0::chromiumos 0 KiB
Total: 1 package (1 new), Size of downloads: 0 KiB
Would you like to merge these packages? [Yes/No] yes
>>> Emerging (1 of 1) dev-libs/gputop-0.0::chromiumos
* GPUTop offers partial support for Linux kernels 4.13 and 4.14. Please upgrade to 4.15+ for complete functionality
* Running stacked hooks for pre_pkg_setup
* sysroot_build_bin_dir ... [ ok ]
* Running stacked hooks for post_pkg_setup
* python_eclass_hack ... [ ok ]
* Running stacked hooks for pre_src_unpack
* python_multilib_setup ... [ ok ]
>>> Unpacking source...
* Fetching HEAD from https://github.com/rib/gputop.git ...
_git-r3_smart_fetch --no-tags https://github.com/rib/gputop.git -f HEAD:dev-libs/gputop/0/__main__
git fetch --progress --no-tags https://github.com/rib/gputop.git -f HEAD:dev-libs/gputop/0/__main__
* Checking out https://github.com/rib/gputop.git to /var/tmp/portage/dev-libs/gputop-0.0/work/gputop-0.0 ...
git checkout -f dev-libs/gputop/0/__main__ .
GIT update -->
repository: https://github.com/rib/gputop.git
at the commit: 455a2486db44732b2ea0f18775ae864b4c3392c7
>>> Source unpacked in /var/tmp/portage/dev-libs/gputop-0.0/work
* Running stacked hooks for post_src_unpack
* asan_init ... [ ok ]
>>> Preparing source in /var/tmp/portage/dev-libs/gputop-0.0/work/gputop-0.0 ...
>>> Source prepared.
>>> Configuring source in /var/tmp/portage/dev-libs/gputop-0.0/work/gputop-0.0 ...
meson --libdir lib64 --localstatedir /var/lib --prefix /usr --sysconfdir /etc /var/tmp/portage/dev-libs/gputop-0.0/work/gputop-0.0 /var/tmp/portage/dev-libs/gputop-0.0/work/gputop-0.0-build
The Meson build system
Version: 0.44.1
Source dir: /var/tmp/portage/dev-libs/gputop-0.0/work/gputop-0.0
Build dir: /var/tmp/portage/dev-libs/gputop-0.0/work/gputop-0.0-build
Build type: native build
Project name: GPUTop
Native C compiler: x86_64-pc-linux-gnu-clang (clang 7.0)
Appending CFLAGS from environment: '-O2 -pipe'
Appending LDFLAGS from environment: '-Wl,-O2 -Wl,--as-needed -Wl,-O2 -Wl,--as-needed'
Native C++ compiler: x86_64-pc-linux-gnu-clang++ (clang 7.0)
Appending CXXFLAGS from environment: '-O2 -pipe'
Appending LDFLAGS from environment: '-Wl,-O2 -Wl,--as-needed -Wl,-O2 -Wl,--as-needed'
Build machine cpu family: x86_64
Build machine cpu: x86_64
Downloading protobuf-c from https://github.com/protobuf-c/protobuf-c/releases/download/v1.3.0/protobuf-c-1.3.0.tar.gz
Traceback (most recent call last):
File "/usr/lib64/python3.4/urllib/request.py", line 1183, in do_open
h.request(req.get_method(), req.selector, req.data, headers)
File "/usr/lib64/python3.4/http/client.py", line 1137, in request
self._send_request(method, url, body, headers)
File "/usr/lib64/python3.4/http/client.py", line 1182, in _send_request
self.endheaders(body)
File "/usr/lib64/python3.4/http/client.py", line 1133, in endheaders
self._send_output(message_body)
File "/usr/lib64/python3.4/http/client.py", line 963, in _send_output
self.send(msg)
File "/usr/lib64/python3.4/http/client.py", line 898, in send
self.connect()
File "/usr/lib64/python3.4/http/client.py", line 1279, in connect
super().connect()
File "/usr/lib64/python3.4/http/client.py", line 871, in connect
self.timeout, self.source_address)
File "/usr/lib64/python3.4/socket.py", line 498, in create_connection
for res in getaddrinfo(host, port, 0, SOCK_STREAM):
File "/usr/lib64/python3.4/socket.py", line 537, in getaddrinfo
for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
socket.gaierror: [Errno -3] Temporary failure in name resolution
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib64/python3.4/site-packages/mesonbuild/mesonmain.py", line 366, in run
app.generate()
File "/usr/lib64/python3.4/site-packages/mesonbuild/mesonmain.py", line 151, in generate
self._generate(env)
File "/usr/lib64/python3.4/site-packages/mesonbuild/mesonmain.py", line 200, in _generate
intr.run()
File "/usr/lib64/python3.4/site-packages/mesonbuild/interpreter.py", line 2897, in run
super().run()
File "/usr/lib64/python3.4/site-packages/mesonbuild/interpreterbase.py", line 171, in run
self.evaluate_codeblock(self.ast, start=1)
File "/usr/lib64/python3.4/site-packages/mesonbuild/interpreterbase.py", line 193, in evaluate_codeblock
raise e
File "/usr/lib64/python3.4/site-packages/mesonbuild/interpreterbase.py", line 187, in evaluate_codeblock
self.evaluate_statement(cur)
File "/usr/lib64/python3.4/site-packages/mesonbuild/interpreterbase.py", line 200, in evaluate_statement
return self.assignment(cur)
File "/usr/lib64/python3.4/site-packages/mesonbuild/interpreterbase.py", line 659, in assignment
value = self.evaluate_statement(node.value)
File "/usr/lib64/python3.4/site-packages/mesonbuild/interpreterbase.py", line 202, in evaluate_statement
return self.method_call(cur)
File "/usr/lib64/python3.4/site-packages/mesonbuild/interpreterbase.py", line 451, in method_call
obj = self.evaluate_statement(invokable)
File "/usr/lib64/python3.4/site-packages/mesonbuild/interpreterbase.py", line 198, in evaluate_statement
return self.function_call(cur)
File "/usr/lib64/python3.4/site-packages/mesonbuild/interpreterbase.py", line 441, in function_call
return self.funcs[func_name](node, self.flatten(posargs), kwargs)
File "/usr/lib64/python3.4/site-packages/mesonbuild/interpreterbase.py", line 77, in wrapped
return f(s, node_or_state, args, kwargs)
File "/usr/lib64/python3.4/site-packages/mesonbuild/interpreterbase.py", line 55, in wrapped
return f(self, node, args, kwargs)
File "/usr/lib64/python3.4/site-packages/mesonbuild/interpreter.py", line 1718, in func_subproject
return self.do_subproject(dirname, kwargs)
File "/usr/lib64/python3.4/site-packages/mesonbuild/interpreter.py", line 1740, in do_subproject
resolved = r.resolve(dirname)
File "/usr/lib64/python3.4/site-packages/mesonbuild/wrap/wrap.py", line 145, in resolve
self.download(p, packagename)
File "/usr/lib64/python3.4/site-packages/mesonbuild/wrap/wrap.py", line 321, in download
dhash, tmpfile = self.get_data(srcurl)
File "/usr/lib64/python3.4/site-packages/mesonbuild/wrap/wrap.py", line 271, in get_data
resp = urllib.request.urlopen(url)
File "/usr/lib64/python3.4/urllib/request.py", line 161, in urlopen
return opener.open(url, data, timeout)
File "/usr/lib64/python3.4/urllib/request.py", line 464, in open
response = self._open(req, data)
File "/usr/lib64/python3.4/urllib/request.py", line 482, in _open
'_open', req)
File "/usr/lib64/python3.4/urllib/request.py", line 442, in _call_chain
result = func(*args)
File "/usr/lib64/python3.4/urllib/request.py", line 1226, in https_open
context=self._context, check_hostname=self._check_hostname)
File "/usr/lib64/python3.4/urllib/request.py", line 1185, in do_open
raise URLError(err)
urllib.error.URLError: <urlopen error [Errno -3] Temporary failure in name resolution>
* ERROR: dev-libs/gputop-0.0::chromiumos failed (configure phase):
* (no error message)
*
* Call stack:
* ebuild.sh, line 133: Called src_configure
* environment, line 3856: Called die
* The specific snippet of code:
* tc-env_build "$@" || die
*
* If you need support, post the output of `emerge --info '=dev-libs/gputop-0.0::chromiumos'`,
* the complete build log and the output of `emerge -pqv '=dev-libs/gputop-0.0::chromiumos'`.
* The complete build log is located at '/var/log/portage/dev-libs:gputop-0.0:20180702-034649.log'.
* For convenience, a symlink to the build log is located at '/var/tmp/portage/dev-libs/gputop-0.0/temp/build.log'.
* The ebuild environment file is located at '/var/tmp/portage/dev-libs/gputop-0.0/temp/environment'.
* Working directory: '/var/tmp/portage/dev-libs/gputop-0.0/work/gputop-0.0'
* S: '/var/tmp/portage/dev-libs/gputop-0.0/work/gputop-0.0'
>>> Failed to emerge dev-libs/gputop-0.0, Log file:
>>> '/var/log/portage/dev-libs:gputop-0.0:20180702-034649.log'
* Messages for package dev-libs/gputop-0.0:
* GPUTop offers partial support for Linux kernels 4.13 and 4.14. Please upgrade to 4.15+ for complete functionality
* ERROR: dev-libs/gputop-0.0::chromiumos failed (configure phase):
* (no error message)
*
* Call stack:
* ebuild.sh, line 133: Called src_configure
* environment, line 3856: Called die
* The specific snippet of code:
* tc-env_build "$@" || die
*
* If you need support, post the output of `emerge --info '=dev-libs/gputop-0.0::chromiumos'`,
* the complete build log and the output of `emerge -pqv '=dev-libs/gputop-0.0::chromiumos'`.
* The complete build log is located at '/var/log/portage/dev-libs:gputop-0.0:20180702-034649.log'.
* For convenience, a symlink to the build log is located at '/var/tmp/portage/dev-libs/gputop-0.0/temp/build.log'.
* The ebuild environment file is located at '/var/tmp/portage/dev-libs/gputop-0.0/temp/environment'.
* Working directory: '/var/tmp/portage/dev-libs/gputop-0.0/work/gputop-0.0'
* S: '/var/tmp/portage/dev-libs/gputop-0.0/work/gputop-0.0' |
I've looked into my hosts file and the nsswitch along with several forums, however I have been unable to find anything which stands out as incorrect or find a fix to my issues. Apologies for the lack of experience! If there is anything I can add to this post to help clarify the issue, please let me know!
I've attached my ebuild below
| Code: | EAPI=5
PYTHON_COMPAT=( python3_{4,5} )
inherit eutils git-r3 meson multiprocessing ninja-utils python-any-r1
DESCRIPTION="An open-source GPU profiling tool"
HOMEPAGE="https://github.com/rib/gputop"
SRC_URI=""
EGIT_REPO_URI="https://github.com/rib/gputop.git"
LICENSE="MIT"
SLOT="0"
KEYWORDS="~amd64 ~x86"
IUSE=""
RDEPEND="dev-libs/openssl" #libssl-devgo
DEPEND="${RDEPEND}
${PYTHON_DEPS}" #meson? ninja?
#Isolates kernel major and minor versions with string clipping
full_kv=$(uname -r)
kv=${full_kv%.*}
major_kv=${kv%.*}
minor_kv=${kv#*.}
if [[ $major_kv -le 3 || ( $major_kv -eq 4 && $minor_kv -lt 13 ) ]]; then 1>&2 ewarn "GPUTop does not support your Linux kernel version. Please upgrade to 4.15+";
elif [[ $major_kv -eq 4 && $minor_kv -lt 15 ]]; then 1>&2 ewarn "GPUTop offers partial support for Linux kernels 4.13 and 4.14. Please upgrade to 4.15+ for complete functionality";
fi
#Investigate meson_use for GTK GUI support
#Clones the git repo
src_unpack() {
#git-r3_src_unpack #Clones EGIT_REPO_URI
git-r3_src_fetch
git-r3_checkout
}
#Runs the meson . build configuration
src_configure() {
debug-print-function ${FUNCNAME} "$@"
# Common args
local mesonargs=(
--libdir "$(get_libdir)"
--localstatedir "${EPREFIX}/var/lib"
--prefix "${EPREFIX}/usr"
--sysconfdir "${EPREFIX}/etc"
)
if tc-is-cross-compiler || [[ ${ABI} != ${DEFAULT_ABI-${ABI}} ]]; then
_meson_create_cross_file || die "unable to write meson cross file"
mesonargs+=( --cross-file "${T}/meson.${CHOST}.${ABI}" )
fi
# https://bugs.gentoo.org/625396
python_export_utf8_locale
# Append additional arguments from ebuild
mesonargs+=("${emesonargs[@]}")
BUILD_DIR="${BUILD_DIR:-${WORKDIR}/${P}-build}"
set -- meson "${mesonargs[@]}" "$@" \
"${EMESON_SOURCE:-${S}}" "${BUILD_DIR}"
echo "$@"
tc-env_build "$@" || die
} |
Last edited by Katackae on Tue Jul 03, 2018 3:45 am; edited 1 time in total |
|
| Back to top |
|
 |
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21631
|
| Posted: Tue Jul 03, 2018 1:53 am Post subject: Re: Meson Dependent Ebuild Failing with Python GAI Errno -3 |
|
|
Welcome to the forums.
Your problem is not related to Meson.
| Katackae wrote: | | Code: |
>>> Configuring source in /var/tmp/portage/dev-libs/gputop-0.0/work/gputop-0.0 ...
meson --libdir lib64 --localstatedir /var/lib --prefix /usr --sysconfdir /etc /var/tmp/portage/dev-libs/gputop-0.0/work/gputop-0.0 /var/tmp/portage/dev-libs/gputop-0.0/work/gputop-0.0-build
The Meson build system
Version: 0.44.1
Build machine cpu: x86_64
Downloading protobuf-c from https://github.com/protobuf-c/protobuf-c/releases/download/v1.3.0/protobuf-c-1.3.0.tar.gz
* ERROR: dev-libs/gputop-0.0::chromiumos failed (configure phase):
|
I've looked into my hosts file and the nsswitch along with several forums, however I have been unable to find anything which stands out as incorrect or find a fix to my issues. |
Nothing is incorrect in your configuration. This is a defect in the upstream build system. It attempts to download content from the Internet during the build. This is a bad idea, and is actively disallowed by Portage. When the network sandbox is enabled, the package under compilation is not permitted access to the Internet during the configure phase (or certain other phases).
The solution is that you need to prevent the package from trying to download anything. It may skip the download if you install dev-libs/protobuf-c before starting the compilation. If so, then the longer term fix is to add dev-libs/protobuf-c to DEPEND so that Portage insists on installing it first.
Ideally, you should get upstream to disable this sub-build. | Katackae wrote: | | Code: | #Isolates kernel major and minor versions with string clipping
full_kv=$(uname -r)
kv=${full_kv%.*}
major_kv=${kv%.*}
minor_kv=${kv#*.} |
|
This is incorrect. You should not shell out to inspect system state at global scope in an ebuild. Instead, do the lookup and warning during the early package preparation, such as in pkg_pretend. | Katackae wrote: | | Code: | src_unpack() {
#git-r3_src_unpack #Clones EGIT_REPO_URI
git-r3_src_fetch
git-r3_checkout
} |
|
Why not call git-r3_src_unpack and let it do the work, or leave src_unpack undefined and let it default to calling git-r3_src_unpack? |
|
| Back to top |
|
|
Katackae
n00b
Joined: 02 Jul 2018
Posts: 3
|
| Posted: Tue Jul 03, 2018 2:28 am Post subject: |
|
|
Thanks!
I see. Apologies for the misunderstanding!
Following along similar lines, I'm not entirely sure I get the purpose of the meson eclass. While it clearly allows for --wrap-mode nodownload meson configuration support and ninja compilation/install, wrap dependencies are a pretty big part of what makes meson so powerful. Is this limited functionality the result of a disconnect between Portage and Meson's differing philosophies or am I possibly missing some obvious solution which bridges the gap?
I can certainly fork the repo and tar the upstream dependencies so as not to disturb the current Meson subproject configuration. Would downloading these dependencies separately, restructuring the Meson build files and establishing references in my ebuild's depend variable offer any benefit from a Portage perspective?
In regards to redefining src_unpack(), I noticed with the git-r3 eclass that there seemed to exist some needless repetition. As seen below, the default call of git-r3_src_unpack calls _git-r3_env_setup followed by git-r3_src_fetch. git-r3_src_fetch already calls _git-r3_env_setup and as such I was rather confused as to why git-r3_src_unpack found it necessary to invoke this function twice.
| Code: | git-r3_src_fetch() {
debug-print-function ${FUNCNAME} "$@"
if [[ ! ${EGIT3_STORE_DIR} && ${EGIT_STORE_DIR} ]]; then
ewarn "You have set EGIT_STORE_DIR but not EGIT3_STORE_DIR. Please consider"
ewarn "setting EGIT3_STORE_DIR for git-r3.eclass. It is recommended to use"
ewarn "a different directory than EGIT_STORE_DIR to ease removing old clones"
ewarn "when git-2 eclass becomes deprecated."
fi
_git-r3_env_setup
git-r3_fetch
}
git-r3_src_unpack() {
debug-print-function ${FUNCNAME} "$@"
_git-r3_env_setup
git-r3_src_fetch
git-r3_checkout
} |
I'll be sure to make the changes you suggested! Thank you very much for all of your advice |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21631
|
| Posted: Tue Jul 03, 2018 2:57 am Post subject: |
|
|
| Katackae wrote: | | I see. Apologies for the misunderstanding! |
What misunderstanding? It's normal for people with problems to misdiagnose them. That's why we're here to set them straight.  | Katackae wrote: | | Following along similar lines, I'm not entirely sure I get the purpose of the meson eclass. |
Generally, an eclass is for storing generic logic that would otherwise be replicated in every ebuild that needs to interact with some subsystem. As for questions about why the meson eclass works as it does, I cannot help you. I have never maintained an ebuild that used that eclass. Hopefully, someone more familiar with it will join in and explain the design. | Katackae wrote: | | While it clearly allows for --wrap-mode nodownload meson configuration support and ninja compilation/install, wrap dependencies are a pretty big part of what makes meson so powerful. Is this limited functionality the result of a disconnect between Portage and Meson's differing philosophies or am I possibly missing some obvious solution which bridges the gap? |
I do not know. I can say that the Portage philosophy says, in part, that bundling is bad and should be avoided whenever practical. The wrapped dependencies appear to be a form of bundling. Worse, they are a particularly unnecessary form of bundling. Bundling can be accepted if the main package relies on a bundled fork and is incompatible with the system package. If the wrapped dependency is just a straight download of the supporting project, then the system copy should have been used instead. | Katackae wrote: | | I can certainly fork the repo and tar the upstream dependencies so as not to disturb the current Meson subproject configuration. Would downloading these dependencies separately, restructuring the Meson build files and establishing references in my ebuild's depend variable offer any benefit from a Portage perspective? |
If I am right, and I am purely speculating, the short-term solution is emerge --oneshot dev-libs/protobuf-c before installing your ebuild. If that makes it work, add dev-libs/protobuf-c to DEPEND. You would not need to fork upstream, nor modify their configuration at all, nor repackage any of the dependencies.
| Katackae wrote: | | In regards to redefining src_unpack(), I noticed with the git-r3 eclass that there seemed to exist some needless repetition. As seen below, the default call of git-r3_src_unpack calls _git-r3_env_setup followed by git-r3_src_fetch. git-r3_src_fetch already calls _git-r3_env_setup and as such I was rather confused as to why git-r3_src_unpack found it necessary to invoke this function twice. |
Me too. I see no good reason for it to do that. Perhaps you could contact the maintainer who wrote that code and ask for an explanation. |
|
| Back to top |
|
|
Katackae
n00b
Joined: 02 Jul 2018
Posts: 3
|
| Posted: Tue Jul 03, 2018 3:34 am Post subject: |
|
|
That makes sense. Fingers crossed, I'd love to hear more about the Meson eclass' design intentions.
With a few modifications to the meson.build, adding protobuf-c as a dependency appears to have worked!
I'll be sure to follow up with the git-r3 maintainer.
Thank you very much Hu! Being quite unfamiliar with the gentoo forums' posting convention, should I edit this thread's title marking it as closed? |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21631
|
| Posted: Tue Jul 03, 2018 3:44 am Post subject: |
|
|
| Yes, though we tend to say "SOLVED" rather than "CLOSED", since some people may interpret "CLOSED" to mean abandoned without solution. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
