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




Reply via email to