I think the OCC part should probably stay a variant because OCC is
relatively heavy, and won't be necessary for a lot of netgen users, but
making nglib as part of the normal install seems reasonable to me. -Ian-
On 5/04/2016 10:04 am, "MacPorts" wrote:
> #50687: netgen @5.3.1 Add nglib and occ v
Hi,
On Mon, Apr 04, 2016 at 08:17:55PM +0200, René J.V. Bertin wrote:
> > > There's only one way to enforce the reproducible build principle
> > > all the way, and that's to remove the whole possibility of
> > > building from source so that users can only install official,
> > > binary packages.
Hi,
On Mon, Apr 04, 2016 at 07:04:46PM +0200, René J.V. Bertin wrote:
> How would one check that (without putting my whole install at risk)?
http://serverfault.com/questions/8048/how-can-i-verify-that-a-sqlite-db3-file-is-valid-consistent
See also
https://trac.macports.org/browser/trunk/base/src
I'd like to second that. I think many issues of variant dependencies are
helped by passing down both manually specified and default variants.
David
On Mon, Apr 4, 2016 at 10:44 AM, Takeshi Enomoto
wrote:
> Dear Ryan and Mojca,
>
> OK. So I see that this is not the problem of the port.
> I don’t
On Monday April 04 2016 18:47:03 Clemens Lang wrote:
Hi,
>Paths and flags should be part of configuration files installed by a
>port, e.g. CMake config files or pkg-config files.
They aren't always ... esp. not if those very files were hidden away by the
port. The paths can also be to executabl
On Monday April 04 2016 18:52:08 Clemens Lang wrote:
>However, now I'm interested why the backup worked flawlessly, but
>MacPorts failed to open the registry. Maybe there was something wrong
>with one of the indexes in the database (which wouldn't be used when
>doing a full dump or backup, but are
> On Apr 4, 2016, at 9:45 AM, Bradley Giesbrecht wrote:
>
>> On Apr 4, 2016, at 9:42 AM, René J. V. Bertin wrote:
>>
>> Bradley Giesbrecht wrote:
>>
>>> Did you keep a copy of the registry? If so, try opening it with the sqlite
>>> client.
>>
>> Thanks for the suggestion. Curiously that went
On Mon, Apr 04, 2016 at 06:42:24PM +0200, René J. V. Bertin wrote:
> Thanks for the suggestion. Curiously that went just fine, but it also
> seems to contradict the previous claim that any interaction with an
> sqlite3 db modifies it.
No, any writing interaction modifies it (that should be obvious
Hi,
On Mon, Apr 04, 2016 at 10:42:16AM +0200, René J.V. Bertin wrote:
> Typically paths defined through variables indeed, or configure
> settings,
Paths and flags should be part of configuration files installed by a
port, e.g. CMake config files or pkg-config files.
> plus the occasional pre- or
> On Apr 4, 2016, at 9:42 AM, René J. V. Bertin wrote:
>
> Bradley Giesbrecht wrote:
>
>> Did you keep a copy of the registry? If so, try opening it with the sqlite
>> client.
>
> Thanks for the suggestion. Curiously that went just fine, but it also seems
> to
> contradict the previous claim
Bradley Giesbrecht wrote:
> Did you keep a copy of the registry? If so, try opening it with the sqlite
> client.
Thanks for the suggestion. Curiously that went just fine, but it also seems to
contradict the previous claim that any interaction with an sqlite3 db modifies
it. I did a .dump which
On Monday April 04 2016 17:59:11 Rainer Müller wrote:
> As Clemens said, PortGroups need to be available to parse a port. They
> cannot be installed with a port. You would have to keep one version in
> the ports tree and then another one that is installed by a port. That
Yes, that's what I am now
> On Apr 3, 2016, at 2:31 AM, René J.V. Bertin wrote:
>
> Hi,
>
> I just went through a bit of a hairy exercise. With a bit too much
> distraction and hurry going on I did a `port upgrade --force` of a port I'd
> just rebuilt from source so I forgot both the -s and the (crucial) -n
> options.
On 2016-04-04 17:13, René J.V. Bertin wrote:
> On Monday April 04 2016 16:22:27 Rainer Müller wrote:
> This should *not* be the case if the current lookup rules for
> _resources continue to be applied, but a higher priority central
> location (var/macports/sources/PortGroups) is added where copies
On Monday April 04 2016 16:22:27 Rainer Müller wrote:
>A user already installed port A with the official port group foo-1.0.
>Then they add a new source, overriding the port group foo-1.0, which
>redefines some paths. This will not cause A to be outdated and no
>rebuild of A will be triggered. Now
Dear Ryan and Mojca,
OK. So I see that this is not the problem of the port.
I don’t have a solution at this time,
but I hope that the manually specified variants
and default_variants should be treated equally
in the future.
Regards,
Takeshi
-
Takeshi Enomoto
take...@macports.org
__
On 2016-04-04 10:42, René J.V. Bertin wrote:
> On Monday April 04 2016 07:34:32 Clemens Lang wrote:
>> That would potentially cause ports to build different depending on
>> which packages you have installed in your environment, which is
>> not reproducible.
>
> Yes, but that is already the case wh
On Monday April 04 2016 07:34:32 Clemens Lang wrote:
>What kind of information are we talking about here? Compiler flags?
>Paths?
Typically paths defined through variables indeed, or configure settings, plus
the occasional pre- or post- block. And dependency info, of course (e.g.
declaring a de
18 matches
Mail list logo
