> On Feb 18, 2017, at 17:29, Dan Villiom Podlaski Christiansen
> wrote:
>
> Dan Villiom Podlaski Christiansen (danchr) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/f9fc74892da67d5116fd6c1df98251922b32fe3b
>
> commit
Thank you for pointing this out; fixed!
2017-06-13 9:31 GMT+02:00 Ryan Schmidt :
>
>> On Feb 18, 2017, at 17:29, Dan Villiom Podlaski Christiansen
>> wrote:
>>
>> Dan Villiom Podlaski Christiansen (danchr) pushed a commit to branch master
>> in repository macports-ports.
>>
>>
>> https://github.
> On Jun 13, 2017, at 03:52, Dan Villiom Podlaski Christiansen
> wrote:
>
> Dan Villiom Podlaski Christiansen (danchr) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/6c811e9f126a9453c3db2d1acb6179b058e102cd
>
> The fol
Hi,
I have a slightly odd issue… I am working on an update to the ROOT6 port, to
the newly released 6.10.00 release,
As part of the build process their build system runs the root C++ interpreter
on some example scripts, which generate various output files. This running of
the script has part o
Is this trace mode?
-Sterling
- Original Message -
From: "Christopher Jones"
To: "MacPorts Developers"
Sent: Tuesday, June 13, 2017 1:57:57 PM
Subject: Are macports builds prevented from accessing /dev/random ?
Hi,
I have a slightly odd issue… I am working on an update to the ROOT6 po
On Jun 13, 2017, at 4:57 PM, Christopher Jones wrote:
> :info:build open('/dev/random'): Operation not permitted
>
> Now, this works outside. So I suspect the build is in some way prevent the
> build process from accessing this. Is this possible ? If so, more to the
> point, is there a way I ca
On 2017-6-14 07:05 , Daniel J. Luke wrote:
On Jun 13, 2017, at 4:57 PM, Christopher Jones wrote:
:info:build open('/dev/random'): Operation not permitted
Now, this works outside. So I suspect the build is in some way prevent the
build process from accessing this. Is this possible ? If so, mor
Hi,
turning off the sandbox fixed the build, so this definitely is the issue….
I agree requiring access to /dev/random during the build is a bit weird, but
actually does make some sense in this case, the script being run is generating
an example output ROOT file for the tutorials, which include
> On 13 Jun 2017, at 10:42 pm, Joshua Root wrote:
>
> On 2017-6-14 07:05 , Daniel J. Luke wrote:
>> On Jun 13, 2017, at 4:57 PM, Christopher Jones
>> wrote:
>>> :info:build open('/dev/random'): Operation not permitted
>>>
>>> Now, this works outside. So I suspect the build is in some way prev
On 2017-6-14 08:18 , Christopher Jones wrote:
Had a look into this. The ROOT source never explicitly opens /dev/random in
read/write mode. Only read only.
However, it also uses a number of external library calls, like std::rand(), and
my best bet is one of these is doing it. As writing to /de
On 2017-06-13, at 4:20 PM, Joshua Root wrote:
> On 2017-6-14 08:18 , Christopher Jones wrote:
>> Had a look into this. The ROOT source never explicitly opens /dev/random in
>> read/write mode. Only read only.
>> However, it also uses a number of external library calls, like std::rand(),
>> and
Speaking of /dev/random, I did a little reading up on Yarrow today after
checking the man page.
Yarrow was effectively replaced by Fortuna, and Fortuna was published,
according to wikipedia, in 2003. Even the PDF paper describing it has a date of
2010. Linux got Fortuna in 2005.
This machine c
Hi
> I have not followed Rainer's strategy for having `port snapshot --create`
> and `port snapshot --restore` as discussed in the previous thread, instead
> have 3 separate actions...
>
> If I am following this correctly I think isolating the functionality into
> actions makes sense. If we want t
Hi
Please see inline.
> While the first one seems to be more realistic from user's perspective
> > but running it every time is also not a good idea since OS/hardware
> > changes are not frequent. I suggest running the detection for changes in
> > architecture before a set of some commands like i
Hi
For testing it should be enough to just modify the registry.db locally
> as you need it. Once you reach a stable schema, you will have to add
> modifications to the registry schema at two places.
>
> 1) The initial database schema for new installations is defined here:
>
> https://github.com/ma
15 matches
Mail list logo