Joshua, Ryan, Sorry about that. When running portindex, this error confused me as well. The problem was that I meant to run this as part of post-destroot, but didn’t implement it that way.
> On Feb 2, 2018, at 3:55 PM, Ryan Schmidt <ryandes...@macports.org > <mailto:ryandes...@macports.org>> wrote: > > > On Jan 29, 2018, at 20:23, Joshua Root wrote: > >> Joshua Root (jmroot) pushed a commit to branch master >> in repository macports-ports. >> >> >> https://github.com/macports/macports-ports/commit/2e764efee3293478fc1dd9788d64391ce2274b56 >> >> <https://github.com/macports/macports-ports/commit/2e764efee3293478fc1dd9788d64391ce2274b56> >> >> The following commit(s) were added to refs/heads/master by this push: >> >> new 2e764ef py-octave_kernel: don't try to install a file on every parse >> >> 2e764ef is described below >> >> >> commit 2e764efee3293478fc1dd9788d64391ce2274b56 >> >> Author: Joshua Root >> AuthorDate: Tue Jan 30 13:22:04 2018 +1100 >> >> py-octave_kernel: don't try to install a file on every parse >> >> Also don't bypass destroot, and don't make the subports conflict. >> Fortunately this should have failed due to permissions, so no rev bump >> or cleanup code should be necessary. > > It did cause a kernel.json file to appear unexpectedly in the ports tree on > the private rsync server. Because it was installed with 640 permissions, it > caused a permissions error when the public rsync server tried to get it, > which the administrator of the public server reported to me today: > >> rsync: send_files failed to open >> "release/ports/python/py-octave_kernel/${prefix}/share/py-octave_kernel/kernel.json" >> (in macports): Permission denied (13) > > Manually removing that "${prefix}" directory from the server has cleared up > the problem and syncs to the public server are happening normally again. > > Marius -- Marius Schamschula Marius -- Marius Schamschula