Would a reasonable feature request be to use the glsa ID in a URI instead of a stand alone thing? I was unaware such an alert existed so did not recognize what GLSA meant.
On Sunday, April 23, 2017 at 2:06:45 PM UTC-7, Charles Allen wrote: > > Spot on! > Actually the thing that's getting pulled in requires subversion. I think > for both building and running, but I can check deeper if its just > compiling. Is it possible to have a DEPEND but not RDEPEND on subversion? > > Thanks for the prompt response. > > On Sunday, April 23, 2017 at 2:02:16 PM UTC-7, David Michael wrote: >> >> On Sun, Apr 23, 2017 at 1:38 PM, Charles Allen <[email protected]> >> wrote: >> > I looked at the following websites: >> > >> > https://coreos.com/os/docs/latest/sdk-modifying-coreos.html >> > >> https://coreos.com/os/docs/latest/sdk-tips-and-tricks.html#add-new-upstream-package >> >> > >> > But when I get to where I have the new ebuild under >> > ~/trunk/src/third_party/coreos-overlay I can't ./build_packages or else >> I >> > get the following cryptic error: >> > >> > This system is affected by the following GLSAs: >> > 201610-05 >> > The above GLSAs apply to /build/amd64-usr >> > ERROR build_packages: script called: build_packages (args unknown, no >> debug available) >> > ERROR build_packages: Backtrace: (most recent call is last) >> > ERROR build_packages: file build_packages, line 68, called: >> die_err_trap 'return $returncode' '1' >> > ERROR build_packages: >> > ERROR build_packages: Command failed: >> > ERROR build_packages: Command 'return $returncode' exited with >> nonzero >> > code: 1 >> > >> > How can I figure out what caused this failure? >> >> It is telling you that you have the security vulnerability at >> https://security.gentoo.org/glsa/201610-05 , so I assume your changes >> are incorrectly pulling subversion into the image. It is not normally >> installed, so the old version shouldn't matter. The new ebuild >> probably has a USE=svn flag that should be disabled. >> >> Thanks. >> >> David >> >
