Re: port xmh: upgrade failure due to trace mode?

es before building a package. Trace mode hides runtime dependencies from the build. Consequently, for a build without trace mode, xbitmaps is actually there and being used in all cases. This is a corner case that trace mode reveals, but is pretty harmless in practice. -- Cle

Re: port xmh: upgrade failure due to trace mode?

On 2015-11-24 14:23, Davide Liessi wrote: > Yesterday night I upgraded some ports on a Yosemite machine using > trace mode and got a configure failure for port xmh. > Then I tried again upgrading it without trace mode and it succeeded. > During the failed try, trace mode reported t

Re: port xmh: upgrade failure due to trace mode?

2015-11-24 14:23 GMT+01:00 Davide Liessi : > Warning: The following existing file was hidden from the build system > by trace mode: > /opt/local/bin/gsed I forgot to add that I got the same warning from trace mode also for many other x* ports, but their build

port xmh: upgrade failure due to trace mode?

Hi all. Yesterday night I upgraded some ports on a Yosemite machine using trace mode and got a configure failure for port xmh. Then I tried again upgrading it without trace mode and it succeeded. During the failed try, trace mode reported the following: Warning: The following existing file was

Re: Trace mode

Hi Ryan, - On 16 Nov, 2015, at 21:26, Ryan Schmidt ryandes...@macports.org wrote: > 75% sounds like a lot. 75% of what? Are we saying that port builds take 75% > longer? Yes, that's what I'm saying. Last time I measured this was a very unscientific use of time(1) and only for a single port,

Re: Trace mode

On Nov 16, 2015, at 3:26 PM, Ryan Schmidt wrote: >> IMO trace mode should get faster using client-side >> caching mechanisms, possibly shared between different processes, before we >> enable >> it by default. > > What kind of caching? https://lists.macosforge.o

Re: Trace mode

On Nov 16, 2015, at 14:01, Clemens Lang wrote: > On 16 Nov, 2015, at 20:52, Ryan Schmidt wrote: > >> Enabling trace mode by default would solve a lot of problems. Where are we >> with >> that? What outstanding issues remain? Is there a (hidden?) macports.conf >>

Re: Trace mode

Hi, - On 16 Nov, 2015, at 20:52, Ryan Schmidt ryandes...@macports.org wrote: > Enabling trace mode by default would solve a lot of problems. Where are we > with > that? What outstanding issues remain? Is there a (hidden?) macports.conf > option > I can use to always enable t

Trace mode

Enabling trace mode by default would solve a lot of problems. Where are we with that? What outstanding issues remain? Is there a (hidden?) macports.conf option I can use to always enable trace mode or do I have to remember to use the "-t" flag with every po

Problems with trace mode & xcodebuild on 10.7: requesting agreement to licence

Hi, With Xcode 4.6.3 and the latest release of MacPorts base I get the following error when I try to use the trace mode: You have not agreed to the Xcode license agreements, please run 'xcodebuild -license' (for user-level acceptance) or 'sudo xcodebuild -license' (for sy

Re: Please test trace mode on El Capitan

- On 27 Oct, 2015, at 22:51, Clemens Lang c...@macports.org wrote: > I didn't see this in my test runs, but maybe I just overlooked it. I guess we > should just add that path to the trace whitelist, because it's basically > /usr/bin or /bin anyway. Should be fixed in r141852. -- Clemens La

Re: Please test trace mode on El Capitan

> Warning: The following existing files were hidden from the build system by > trace > mode: > /opt/local/bin/gawk > /opt/local/bin/grep > /opt/local/bin/gsed > /opt/local/bin/perl > Warning: The following file inside the MacPorts prefix not installed by a port > wa

Re: Please test trace mode on El Capitan

esn't know anything about? > > -- > Clemens Lang I use ‘sudo port -t install xyz’ - Ok, now that I look at the output again perhaps I’m confused. It is the “not installed by a port” that has the “sip”. ---> Configuring gmp Warning: The following existing files were hidden fr

Re: Please test trace mode on El Capitan

- On 27 Oct, 2015, at 17:36, Kurt Hindenburg khindenb...@macports.org wrote: > Sorry perhaps I wasn’t clear > > The current output is : > /opt/local/var/macports/sip-workaround/502/usr/bin/perl5.18 > I think should be : /usr/bin/perl5.18 Yes, sounds like it. *Where* do you see the output,

Re: Please test trace mode on El Capitan

> On Oct 27, 2015, at 12:24 PM, Clemens Lang wrote: > > Hey, > > - On 27 Oct, 2015, at 16:23, Kurt Hindenburg khindenb...@macports.org > wrote: > >> The new trace seems to work fine. My only suggestion would be if you can >> remove >> “sip” part from the output. >> >> /opt/local/var/ma

Re: Please test trace mode on El Capitan

Hey, - On 27 Oct, 2015, at 16:23, Kurt Hindenburg khindenb...@macports.org wrote: > The new trace seems to work fine. My only suggestion would be if you can > remove > “sip” part from the output. > > /opt/local/var/macports/sip-workaround/502/usr/bin/perl5.18 -> > /usr/bin/perl5.18 Whe

Re: Please test trace mode on El Capitan

> On Oct 24, 2015, at 11:45 AM, Clemens Lang wrote: > > Hi developers, > > if you are running MacPorts trunk on El Capitan, please make sure you're at > the > latest version and test trace mode. Originally, El Capitan's system integrity > protection

Please test trace mode on El Capitan

Hi developers, if you are running MacPorts trunk on El Capitan, please make sure you're at the latest version and test trace mode. Originally, El Capitan's system integrity protection broke trace mode because all DYLD_* variables are stripped when executing a binary under SIP. I mo

Re: How to enable trace mode automatically (to hide other ports while building)?

e types of ports that we typically offer in multiple versions. A user might conceivably want to run lua code that requires a particular lua version -- even after we've updated the ports in MacPorts to use newer versions of lua. > I remember talking about switching the trace mode on by

Re: How to enable trace mode automatically (to hide other ports while building)?

trictly against that change, but it needs some thought. (I'm also seriously considering downgrading the lua port back to version 5.2.) I kind of keep hoping that the number of programs that are incompatible with lua 5.3 (and/or 5.2) will keep decreasing and hopefully drop to zero at some point

Re: How to enable trace mode automatically (to hide other ports while building)?

On Sep 17, 2015, at 10:51 AM, Mojca Miklavec wrote: > On Thu, Sep 17, 2015 at 4:47 PM, Rainer Müller wrote: >> On 2015-09-17 14:49, Mojca Miklavec wrote: >>> I would like to hide a couple of ports while building one specific >>> port. I know that I can do this with "port -t build foo", but I would

Re: How to enable trace mode automatically (to hide other ports while building)?

> On Sep 17, 2015, at 11:51 AM, Mojca Miklavec wrote: > I'm not saying that this isn't doable, but it would be so much more > helpful if I could simply make the other ports "invisible" during the > build. Yes, it would be good for everyone if we could run in trace

Re: How to enable trace mode automatically (to hide other ports while building)?

On Thu, Sep 17, 2015 at 4:47 PM, Rainer Müller wrote: > On 2015-09-17 14:49, Mojca Miklavec wrote: >> I would like to hide a couple of ports while building one specific >> port. I know that I can do this with "port -t build foo", but I would >> like to do this automatically within the Portfile, oth

Re: How to enable trace mode automatically (to hide other ports while building)?

On 2015-09-17 14:49, Mojca Miklavec wrote: > I would like to hide a couple of ports while building one specific > port. I know that I can do this with "port -t build foo", but I would > like to do this automatically within the Portfile, otherwise the port > would have to conflict with a whole bunch

How to enable trace mode automatically (to hide other ports while building)?

Hi, I would like to hide a couple of ports while building one specific port. I know that I can do this with "port -t build foo", but I would like to do this automatically within the Portfile, otherwise the port would have to conflict with a whole bunch of other ports without any good reason (other

Re: Speed up trace mode

Hi Shashwat, - On 9 Mar, 2015, at 00:36, Shashwat Pandey devshashwatpan...@gmail.com wrote: > 'Speed up trace mode' suggests implementation of a cache data structure to > improve performance of trace mode. > > I have been trying to understand the code rela

Speed up trace mode

Hi The ideas page this time around has many ideas related to trace mode. 'Speed up trace mode' suggests implementation of a cache data structure to improve performance of trace mode. I have been trying to understand the code related to trace mode. The darwintrace shared library gets

Re: trace mode to determine dependencies?

Hi, - On 5 Mar, 2015, at 21:04, René J.V. Bertin rjvber...@gmail.com wrote: > All this talk about trace mode has made me wonder if one couldn't use the > foundation on which it's built to determine the dependencies one should > declare > for a port. Creating a new port

trace mode to determine dependencies?

Hi, All this talk about trace mode has made me wonder if one couldn't use the foundation on which it's built to determine the dependencies one should declare for a port. Creating a new portfile that's always the big question for me, starting with a rather complete install li

Re: Trace mode (was Re: port upgrade outdated order)

Hi, - On 4 Mar, 2015, at 15:47, Arno Hautala a...@alum.wpi.edu wrote: > I remember discussions about enabling trace mode by default and > concerns that it included a performance hit. I also seem to remember > discussion about this penalty being reduced recently. Is there any >

Trace mode (was Re: port upgrade outdated order)

On Wed, Mar 4, 2015 at 6:52 AM, Chris Jones wrote: > > trace mode, which blocks access to files a port should not be using (because > they have not declared a dependency) is a great tool at providing this > reproducibility. I do not see any use case for an individual port being

Re: Weird behaviour of trace mode on p5-file-path

> understand is the difference between the normal and the trace mode. > > Does anyone have any ideas? Can you change DARWINTRACE_DEBUG to 1 in your base's src/darwintracelib1.0/darwintrace.h, run make clean, make, sudo make install in this directory, try again and attach the out

Weird behaviour of trace mode on p5-file-path

Hello, I'm experiencing a weird behaviour. If I run sudo port -v test p5.20-file-path it succeeds, but if I try sudo port -v -t test p5.20-file-path it fails (most probably due to line 24 in t/Path.t). What I don't understand is the difference between the normal and the trace m

Re: buildbot trace mode

Hi, On 8 Sep, 2014, at 22:48, Daniel J. Luke dl...@geeklair.net wrote: > On Sep 8, 2014, at 4:15 PM, Jeremy Lavergne > wrote: >> Were considering enabling trace mode by default on the buildbots? Are we? Not that I know of. > I don't know of any specifics, but the longer-

Re: buildbot trace mode

On Sep 8, 2014, at 4:15 PM, Jeremy Lavergne wrote: > > Were considering enabling trace mode by default on the buildbots? I don't know of any specifics, but the longer-term plan is to just always have trace mode on, right? -- Dan

buildbot trace mode

Were considering enabling trace mode by default on the buildbots? ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Problem with trace mode in custom installation

2014-08-20 1:20 GMT+02:00 Clemens Lang : > In your case, I think this was a simple off-by-one, should be fixed in > https://trac.macports.org/changeset/124145. I've just tried /opt/macports-x86_64 and /opt/macports-test12345678901234567890 and they both work as expected. Thanks! Best wishes. Dav

Re: Problem with trace mode in custom installation

Hi, > There's a buffer somewhere that holds the sandbox definition string, > which contains $prefix a couple of times. I figure that's the one that's > actually overflowing, but I'd have to check. In your case, I think this was a simple off-by-one, should be fixed in https://trac.macports.org/ch

Re: Problem with trace mode in custom installation

Hey, > I think that you are right: I've just tried with /opt/macports-testtt > (same length as ...-x86_64) and it fails with the same error. I feared that might be the problem :( There's a buffer somewhere that holds the sandbox definition string, which contains $prefix a couple of times. I figu

Re: Problem with trace mode in custom installation

2014-08-17 21:55 GMT+02:00 Clemens Lang : > I think this might happen because some of the trace mode code is really > old and uses fixed-size buffers. So the problem might actually be the length > of > $prefix. I think that you are right: I've just tried with /opt/macports-testt

Re: Problem with trace mode in custom installation

ree. I think this might happen because some of the trace mode code is really old and uses fixed-size buffers. So the problem might actually be the length of $prefix. We should definitely fix that. -- Clemens Lang ___ macports-dev mailing list

Re: Problem with trace mode in custom installation

On Sun, Aug 17, 2014 at 10:39 AM, Davide Liessi wrote: > > /opt/macports-x86_64/libexec/macports/lib/darwintrace1.0/darwintrace.dylibDARWINTRACE_LOG=/tmp/macports_trace_859-336 > This looks to me like a space is dropped somewhere, possibly only in the case where a non-default prefix is in use. I

Re: Problem with trace mode in custom installation

2014-08-17 16:39 GMT+02:00 Davide Liessi : [...] > (I omit apparently regular output; full Terminal transcript is attached) [...] > I attach also the main.log file. I forgot the attachments... Davide main.log.bz2 Description: BZip2 compressed data Terminal-macports-x86_64.log.bz2 Description:

Problem with trace mode in custom installation

version in /opt/macports-x86_64 and I found out that this folder name breaks trace mode. Here's what I did: (I omit apparently regular output; full Terminal transcript is attached) =BEGIN ~ $ /opt/local/bin/svn info /opt/macports-src/trunk/ Percorso: /opt/macports-src/trunk Working Copy Root

Re: Missing (build) dependencies as found through trace mode.

> https://github.com/cooljeanius/LocalPorts/blob/master/devel/gnutls2/Portfile#L182 So it's just missing the (default) --disable or --without switches, OK. >> Even better, cmake's list: (optional) [huge list] > where are you getting this from? Oh, you know, building stuff

Re: Missing (build) dependencies as found through trace mode.

the > Command Line Tools. Even though MacPorts' versions of these tools are used > when > they are installed (without trace mode), we should rather stick to the system > versions -- especially as long as we use system compilers and the rest of the > system toolchain. Same for cc

Re: Missing (build) dependencies as found through trace mode.

On Tue, Jul 1, 2014 at 8:36 AM, Clemens Lang wrote: > > The other tools links, lynx, elinks fall into another category I have > really > > no idea how to handle: while they seem to certainly be optional, > shouldn't we > > make apache2 happy by providing them? Or is that useless bloating? > > I'd

Re: Missing (build) dependencies as found through trace mode.

Hi, > I wonder what to do with "missing" build time dependencies as found by > running trace mode, which are optional though. As you already guessed that really depends on which files are referenced. > Quick example to let you actually grasp what I'm talking about

Re: Missing (build) dependencies as found through trace mode.

e or something mentioning that the variant >> only exists to placate trace mode's pedantry (and anyone's own >> personal OCD). Although some people might object to such a variant >> even with such a note, so you might want to be careful with these >> ones. >

Re: Missing (build) dependencies as found through trace mode.

rcurial port:qt4-mac port:openssh port:subversion file:include/cairo/cairo.h:cairo port:fontconfig port:freetype port:gdk-pixbuf2 file:include/glib-2.0/glib-object.h:glib port:gtk2 file:include/pango-1.0/pango/pango.h:pango port:gettext port:python26 In such cases, I'd rather have "autom

Re: Missing (build) dependencies as found through trace mode.

The way I would handle each of those categories would be: - "mandatory": simple enough, just use a `port:`-style depspec - "recommended": use a `bin:`-style depspec, so the system versions can still satisfy it. Note that the autogen port does not fit in with the rest of the autotools suite, desp

Re: Missing (build) dependencies as found through trace mode.

This said, I have a rather huge list of ports to upgrade, so I'll keep track of all of them and make a list of categorized "missing" dependencies. Currently I have the categories: "mandatory": build failures "recommended": better to have them around, stuff like autogen, automake, autoconf etc. "op

Missing (build) dependencies as found through trace mode.

Hi all, I wonder what to do with "missing" build time dependencies as found by running trace mode, which are optional though. Quick example to let you actually grasp what I'm talking about: apache2 configure + build phase: Warning: An activity was attempted outside sandbox:

Please test trace mode with your ports

Hi, I just committed a major overhaul of trace mode[1] in r113026[2] that fixes the last few problems I have seen so far. All ports that I have installed on my system (currently 526) build fine using these fixes, so I think it should be pretty complete now. If you have MacPorts trunk installed

Re: MacPorts and sandboxing [was Re: Current state of trace mode?]

On Sep 11, 2012, at 7:13 PM, Jordan K. Hubbard wrote: > Still, even with security being applied in hindsight, I think there's enough > fundamental goodness in the architecture of macports (we were idiots, but we > weren't TOTAL idiots in other words ;-) ) and flexibility in the sandbox > mech

MacPorts and sandboxing [was Re: Current state of trace mode?]

[ Re-subjecting to better reflect the new and current topic of conversation ] > See, I thought that should be the case, but last time I went looking > (around the time Lion was released I believe) I couldn't find sufficient > docs to try anything. The man page for sandbox-exec is fine as far as it

Re: Current state of trace mode?

the lifetime of the process. If we have to, I guess we >> could use helper processes instead of changing the access of port(1), >> but that's a fair bit of extra work. > > Well, that's the sticky part. Once a child is in a specific sandbox, it > can't break out

Re: Current state of trace mode?

a child is in a specific sandbox, it can't break out / modify its own rules since that would obviously defeat the purpose of sandboxing. If you were willing (perhaps only when using trace mode) to invoke each phase of port as a separate fork/exec then, of course, it would be easy and also let

Re: Current state of trace mode?

On 2012-9-4 03:11 , Jordan K. Hubbard wrote: > > On Sep 2, 2012, at 7:37 AM, Joshua Root > wrote: > >> I completely agree, it would be better for the OS to provide the >> mechanisms. Please make it happen. ;-) > > I'll see what I can do. :-) > > Just to make sure we'r

Re: Current state of trace mode?

On Sep 2, 2012, at 7:37 AM, Joshua Root wrote: > I completely agree, it would be better for the OS to provide the > mechanisms. Please make it happen. ;-) I'll see what I can do. :-) Just to make sure we're up-to-date and in sync on the mission goals: MacPorts would like to be able to know,

Re: Current state of trace mode?

On 2012-9-2 14:36 , Jordan K. Hubbard wrote: > > I also got distracted by the notion of creating a MAC policy (kernel > module) instead since MAC has hooks for every single filesystem > operation and allows one to implement tracing below the syscall layer > such that it doesn't matter whether the

Re: Current state of trace mode?

On Aug 31, 2012, at 4:08 PM, Joshua Root wrote: > There was another thread discussing it at the end of last year, complete > with jkh threatening to write some code as I recall. But I guess nobody > found the time yet. I did indeed threaten this, now that you remind me, and it was sadly an empt

Re: Current state of trace mode?

On 2012-9-1 08:23 , Clemens Lang wrote: > Hey, > > does anybody know what the current state of trace mode in MacPorts is? Pretty sure it's at least partially broken. The tests don't pass. Haven't had the time to investigate properly. > The code seems old, but contrary

Current state of trace mode?

Hey, does anybody know what the current state of trace mode in MacPorts is? The code seems old, but contrary to my expectations the bit rod doesn't seem to have broken it completely (e.g., segfaulting or similar). >From my tests, it seems most things work, but checks against dependenc

Re: Improving trace mode

On Jan 4, 2009, at 4:24 AM, Joshua Root wrote: It sounds to me like trace mode just needs a better whitelist, and also a "greylist" which would warn on access but not prevent it. +1. I agree, this is the best direction for making tracemode "more reasonable" while st

Re: Improving trace mode

Rainer Müller wrote: > Jordan K. Hubbard wrote: >> From what I recall from the conversations between Paul Guyot, Landon >> Fuller, and others behind trace mode, this is sort of the point. A >> port is supposed to declare its dependencies, not write to areas >> o

Re: Improving trace mode

Jordan K. Hubbard wrote: > From what I recall from the conversations between Paul Guyot, Landon > Fuller, and others behind trace mode, this is sort of the point. A > port is supposed to declare its dependencies, not write to areas > outside of MacPorts' control, and

Re: Improving trace mode

recall from the conversations between Paul Guyot, Landon Fuller, and others behind trace mode, this is sort of the point. A port is supposed to declare its dependencies, not write to areas outside of MacPorts' control, and otherwise behave itself. If it's not behaving itself then

Improving trace mode

Hello, Trace mode (port -t) is a very good way to find out which files are accessed and need to be available during building a port. But currently this is not fully usable, as it has some problems with the way it currently works. When a file access outside of the sandbox (deps, Xcode, SDKs etc