Re: [GSoC] migration

[Umesh Singla]

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/macports/macports-base/blob/
> e3a0dc2ebde62a9c5feac6a1edee1708a95bb02a/src/cregistry/sql.c#L122-L131
>
> 2) The metadata table in registry.db has a row with key='version', where
> value holds the schema version. The code to update from one schema
> version to the next is here:
>
> https://github.com/macports/macports-base/blob/
> e3a0dc2ebde62a9c5feac6a1edee1708a95bb02a/src/cregistry/sql.c#L231-L240


Thanks Rainer for this. This is really useful. I had doubts on how often
cregistry/sql.c file gets updated or whether this is the one. The name
sql.c seems to be so OS core file. So, I can just add the new tables here?

Also, new tables means adding them in update_db() too, just like it is the
case with existing port or portgroup tables?

Forgive me for asking almost everything.


--
Umesh Singla

Re: [GSoC] migration

[Umesh Singla]

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 to refactor the interface in the future it
> will be easier to combine pieces then split into parts.


Acknowledged.

> 4. Another thing that ran my mind while pondering that there are 2
> options for sqlite database as well: make the tables in the very beginning
> (while initial installation) or while running the snapshot for the first
> time. I suggest to go with the first one because it's simple.
> > The major target is to finish the snapshot action before Jun 24.
>
> Does “port selfupdate” constitute an “initial installation”?
>

The way I went through macports1.0 -> selfupdate.tcl file, I don't see any
such thing.

Does port currently perform schema checks?
>

If there's sql.c -> update_db() function, then it should be called
somewhere. I only see it at one place inside registry attach function which
is not really relevant here.


> If port can detect if the schema needs updating then perhaps we can hook
> in and “do the right thing".
>

But all this is for the first time, right? I'll ponder over it more.

Point to me if I missed something vital.


> I suggest IRC #macports on Wednesdays at 2:00 PM UTC. If this time does
> not work for anyone who would like to be included suggest an alternative or
> additional day and time.
>

So, today!


--
Umesh Singla

Re: Are macports builds prevented from accessing /dev/random ?

[Michael]

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 my best bet is one of these is doing it. As writing to /dev/random is 
>> allowed, to update the entropy pool, I don’t think this in itself is an 
>> issue.
>> So is it OK to add /dev/random to the allowed locations for the sandbox ?
> 
> Yes, that would be fine.
> 
> I had a look at the xnu source by the way, and writing to /dev/random on 
> Darwin is indeed equivalent to writing to /dev/null; the kernel doesn't use 
> the written data in any way.
> 
> - Josh

Odd. The manual states: "To add entropy to the random generation system, open 
/dev/random for writing and write data that you believe to be somehow random."

In the past, on linux systems, I would have a shutdown script that pulled 512 
bytes out of /dev/random, and saved it in a file; on restart, it would be put 
back into /dev/random. But that was when it was actually possible to modify 
/etc/rc and run stuff at startup.

So in Xnu, how do you ensure random data in the entropy pool? How do you seed 
the random numbers so that there's some ... randomness?

(rc.local is way too late to adjust system startup. And launchd/init wants to 
have some sort of hard-coded startup functions that you can't alter).

---
Entertaining minecraft videos
http://YouTube.com/keybounce

Re: Are macports builds prevented from accessing /dev/random ?

[Joshua Root]

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 /dev/random is allowed, 
to update the entropy pool, I don’t think this in itself is an issue.

So is it OK to add /dev/random to the allowed locations for the sandbox ?


Yes, that would be fine.

I had a look at the xnu source by the way, and writing to /dev/random on 
Darwin is indeed equivalent to writing to /dev/null; the kernel doesn't 
use the written data in any way.


- Josh

Re: Are macports builds prevented from accessing /dev/random ?

[Christopher Jones]

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 includes filling some 
histograms and tuples with random numbers.

Is it possible to flag at a port level that access to some areas is OK for 
certain ports ? To be honest I would be surprised if there was, as it would 
potentially allow ports to start turning off the protections the sandbox 
provides willy nilly, but I thought I would ask ?

Failing that, yes, could we add /dev/random to the list of allowed areas ? Odd 
yes, but in this case does make some sense…

cheers Chris


> 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 prevent the 
>>> build process from accessing this. Is this possible ? If so, more to the 
>>> point, is there a way I can get this to work… ?
>> I suspect the sandbox doesn't include access to /dev/random (Macports 
>> started using sandbox-exec with version 2.2.0)
>> As a temporary workaround (or to test this theory) you can add 
>> "sandbox_enable no" to your macports.conf
> 
> Our sandbox only restricts writes. Seems like the program is opening 
> /dev/random with O_RDWR? Writing to it is technically allowed (though I don't 
> know that it does anything on darwin), so we should probably add it to the 
> sandbox exceptions, but I'm not sure why it would be needed.
> 
> - Josh



smime.p7s
Description: S/MIME cryptographic signature

Re: Are macports builds prevented from accessing /dev/random ?

[Joshua Root]

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, more to the point, 
is there a way I can get this to work… ?


I suspect the sandbox doesn't include access to /dev/random (Macports started 
using sandbox-exec with version 2.2.0)

As a temporary workaround (or to test this theory) you can add "sandbox_enable 
no" to your macports.conf


Our sandbox only restricts writes. Seems like the program is opening 
/dev/random with O_RDWR? Writing to it is technically allowed (though I 
don't know that it does anything on darwin), so we should probably add 
it to the sandbox exceptions, but I'm not sure why it would be needed.


- Josh

Re: Are macports builds prevented from accessing /dev/random ?

[Daniel J. Luke]

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 can get this to work… ?

I suspect the sandbox doesn't include access to /dev/random (Macports started 
using sandbox-exec with version 2.2.0)

As a temporary workaround (or to test this theory) you can add "sandbox_enable 
no" to your macports.conf
-- 
Daniel J. Luke

Re: Are macports builds prevented from accessing /dev/random ?

[Sterling P. Smith]

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 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 of the build process seems to be failing due to it being 
unable to access /dev/random…

The build step is

:info:build cd 
/opt/local/var/macports/build/_Users_chris_Projects_MacPorts_ports_science_root6/root6/work/build/tutorials
 && 
DYLD_LIBRARY_PATH=/opt/local/var/macports/build/_Users_chris_Projects_MacPorts_ports_science_root6/root6/work/build/lib:
 ROOTIGNOREPREFIX=1 
/opt/local/var/macports/build/_Users_chris_Projects_MacPorts_ports_science_root6/root6/work/build/bin/root.exe
 -l -q -b -n -x hsimple.C -e return

You don’t need to understand the details, just that root.exe is the main 
excitable and hsimple.C is a c++ source file that root interprets (using the 
cling interpreter built on top of the clang compiler).

This gives the error, when run inside a macports build

: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 can get this to work… ?

cheers Chris

Re: [macports-ports] branch master updated: aiccu: bump revision and add notice that the service is discontinued

[Ryan Schmidt]

> 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 following commit(s) were added to refs/heads/master by this push:
> 
>  new 6c811e9  aiccu: bump revision and add notice that the service is 
> discontinued
> 
> 6c811e9 is described below
> 
> 
> commit 6c811e9f126a9453c3db2d1acb6179b058e102cd
> 
> Author: Dan Villiom Podlaski Christiansen 
> AuthorDate: Tue Jun 13 10:52:36 2017 +0200
> 
> 
> aiccu: bump revision and add notice that the service is discontinued


> +post-activate{
> +ui_msg 
> "**"
> +ui_msg "* Warning: The SixXS service is no longer available; as a 
> result,*"
> +ui_msg "* this port has little but historical value. 
> *"
> +ui_msg 
> "**"
> +}

You should use the "notes" command in the main part of the portfile, rather 
than using ui_msgs in a post-activate block. Also, don't surround the notes 
with ASCII art; just write the paragraph(s) of text.

Changes to the notes or the activate or deactivate phases aren't seen by users 
unless you increase the revision (because MacPorts uses the Portfile that was 
recorded in the registry at install time, not the Portfile in the ports tree).

Re: [macports-ports] 01/07: py-libvirt: new port

[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.com/macports/macports-ports/commit/f9fc74892da67d5116fd6c1df98251922b32fe3b
> 
> commit f9fc74892da67d5116fd6c1df98251922b32fe3b
> 
> Author: Dan Villiom Podlaski Christiansen 
> AuthorDate: Fri Feb 17 23:29:37 2017 +0100
> 
> 
> py-libvirt: new port


> +if {${name} ne ${subport}} {
> +depends_build   port:py${python.version}-setuptools \
> +port:pkgconfig
> +depends_lib port:libvirt
> +
> +livecheck.type  none
> +} else {
> +livecheck.name  ${python.rootname}
> +}
> +
> +if {${name} ne ${subport}} {
> +depends_build-append \
> +port:py${python.version}-setuptools
> +
> +livecheck.type  none
> +} else {
> +livecheck.type  pypi
> +}

Two "if {${name} ne ${subport}}" blocks?