[MacPorts] #52327: Buildbot considers a port failed if conflicting ports are active
#52327: Buildbot considers a port failed if conflicting ports are active --------------------------+-------------------------------- Reporter: ryandesign@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: contrib | Version: 2.3.4 Keywords: | Port: --------------------------+-------------------------------- [https://build.macports.org/builders/ports-10.11_x86_64-builder/builds/5636 Build 5636] failed: {{{ port gnuradio +docs+grc+jack+portaudio+qtgui+sdl+swig+uhd+wavelet+wxgui fd2146872b399e4f5b215d6a9eb31e6523aa1f444c9855cede444c86829b1078 previously failed in build https://build.macports.org/builders/ports-10.11_x86_64-builder/builds/5623 Dependency 'gnuradio' with variants '+docs+grc+jack+portaudio+qtgui+sdl+swig+uhd+wavelet+wxgui' has previously failed and is required. }}} But in [https://build.macports.org/builders/ports-10.11_x86_64-builder/builds/5623 build 5623], the reason why gnuradio failed was: {{{ Error: Unable to execute port: Can't install gnuradio because conflicting ports are active: gnuradio-devel Build of dependency 'gnuradio' with variants '+docs+grc+jack+portaudio+qtgui+sdl+swig+uhd+wavelet+wxgui' failed, aborting. }}} Not sure why both gnuradio and gnuradio-devel were in the dependency tree, but the fact that gnuradio failed because gnuradio-devel was active shouldn't disqualify gnuradio from being built in the future. -- Ticket URL: <https://trac.macports.org/ticket/52327> MacPorts <https://www.macports.org/> Ports system for macOS
#52327: Buildbot fails incorrectly if calculated dependency tree becomes invalid during installation ---------------------------+-------------------------------- Reporter: ryandesign@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: contrib | Version: 2.3.4 Resolution: | Keywords: Port: | ---------------------------+-------------------------------- Comment (by cal@…): Build 5623 of `gnss-sdr-devel` should not have failed, because at the point where `gnuradio` was required by `gr-osmosdr`, `gnuradio-devel` was already installed and would have satisfied the dependency of `gr-osmosdr`. The problem is that at this point, we no longer know that `gr-osmosdr` would accept the already-installed `gnuradio-devel`, because we run dependency calculation first and then just stupidly iterate over the list. A solution for this problem might be complicated… basically, while iterating over the dependency tree and before installing a specific dependency, we'd have to check whether the port(s) that require(s) the current dependency still need it or the requirement has been satisfied using other means (e.g., a path:, lib:, or bin: dependency) meanwhile. This problem occurs more or less because we don't compute a closed form solution of the dependency tree before actually installing. To reset the incorrect state for now, you can just trigger a build of gnuradio directly, which will ignore the failcache but update it on success. -- Ticket URL: <https://trac.macports.org/ticket/52327#comment:1> MacPorts <https://www.macports.org/> Ports system for macOS
#52327: Buildbot fails incorrectly if calculated dependency tree becomes invalid during installation ---------------------------+-------------------------------- Reporter: ryandesign@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: contrib | Version: 2.3.4 Resolution: | Keywords: Port: | ---------------------------+-------------------------------- Comment (by ryandesign@…): Replying to [comment:1 cal@…]:
Build 5623 of `gnss-sdr-devel` should not have failed, because at the point where `gnuradio` was required by `gr-osmosdr`, `gnuradio-devel` was already installed and would have satisfied the dependency of `gr-osmosdr`. The problem is that at this point, we no longer know that `gr-osmosdr` would accept the already-installed `gnuradio-devel`, because we run dependency calculation first and then just stupidly iterate over the list.
A solution for this problem might be complicated… basically, while iterating over the dependency tree and before installing a specific dependency, we'd have to check whether the port(s) that require(s) the current dependency still need it or the requirement has been satisfied using other means (e.g., a path:, lib:, or bin: dependency) meanwhile. This problem occurs more or less because we don't compute a closed form solution of the dependency tree before actually installing.
I figured it was something tricky like this.
To reset the incorrect state for now, you can just trigger a build of gnuradio directly, which will ignore the failcache but update it on success.
Oh good, I didn't know that would work. I ran builds of gnuradio on all the builders, which succeeded on the recent OS versions at least. -- Ticket URL: <https://trac.macports.org/ticket/52327#comment:2> MacPorts <https://www.macports.org/> Ports system for macOS
participants (1)
-
MacPorts