Re: [152743] trunk/dports/_resources/port1.0/group

[Rainer Müller]

On 2016-09-16 17:33, Ryan Schmidt wrote:
> 
>> On Sep 16, 2016, at 9:06 AM, Rainer Müller  wrote:
>>
>> I would keep this as Mac OS X 10.5 Leopard, the name does not change
>> retroactively.
> 
> I suppose that's an open question. Previously, I've tried to use the OS 
> marketing name as it was when that OS version was released. Now, I'm thinking 
> we should always use the current marketing name. Do we have any guidance from 
> Apple on what they want people to do?
> 
>> The version number is usually also helpful to get the
>> "10.X" to "darwin Y" mapping right.
> 
> Yes but I didn't want to go into a long explanation in that comment.

Then let's just replace it here with "(e.g. 16 for macOS 10.12 Sierra)"
to avoid the confusion.

>>> options minimum_xcodeversions
>>> @@ -57,7 +57,7 @@
>>> return -code error "unable to find Xcode"
>>> }
>>> if {[vercmp ${xcodeversion} ${minimum_xcodeversion}] < 0} {
>>> -ui_error "On Mac OS X ${macosx_version}, ${name} 
>>> ${version} requires Xcode ${minimum_xcodeversion} or later but you have 
>>> Xcode ${xcodeversion}."
>>> +ui_error "On macOS ${macosx_version}, ${name} 
>>> @${version} requires Xcode ${minimum_xcodeversion} or later but you have 
>>> Xcode ${xcodeversion}."
>>
>> Why drop the foo @1.0 syntax that we use at so many other places to
>> specify a port version?
> 
> I didn't drop it; I started using it, finally, in this portgroup.

Sorry, somehow I misread that in reverse... I blame Friday :-)

Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [152743] trunk/dports/_resources/port1.0/group

[Daniel J. Luke]

On Sep 16, 2016, at 11:33 AM, Ryan Schmidt  wrote:
>> I would keep this as Mac OS X 10.5 Leopard, the name does not change
>> retroactively.
> 
> I suppose that's an open question. Previously, I've tried to use the OS 
> marketing name as it was when that OS version was released. Now, I'm thinking 
> we should always use the current marketing name. Do we have any guidance from 
> Apple on what they want people to do?

I don't think the change was retroactive

(for example, Apple Store lists Mac OS X 10.6 Snow Leopard - 
http://www.apple.com/shop/product/MC573Z/A/mac-os-x-106-snow-leopard )

back in the pre-history of 'System 7' -> 'Mac OS 7.6', previous versions didn't 
officially change their name.

-- 
Daniel J. Luke



___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [152743] trunk/dports/_resources/port1.0/group

[Joshua Root]

On 2016-9-17 01:33 , Ryan Schmidt wrote:



On Sep 16, 2016, at 9:06 AM, Rainer Müller  wrote:

On 2016-09-16 01:09, ryandes...@macports.org wrote:

Revision: 152743
 https://trac.macports.org/changeset/152743
Author:   ryandes...@macports.org
Date: 2016-09-15 16:09:26 -0700 (Thu, 15 Sep 2016)
Log Message:
---
Portgroups: replace "Mac OS X" and "OS X" with "macOS"



Modified: trunk/dports/_resources/port1.0/group/xcodeversion-1.0.tcl
===
--- trunk/dports/_resources/port1.0/group/xcodeversion-1.0.tcl  2016-09-15 
23:06:35 UTC (rev 152742)
+++ trunk/dports/_resources/port1.0/group/xcodeversion-1.0.tcl  2016-09-15 
23:09:26 UTC (rev 152743)
@@ -38,7 +38,7 @@
#   minimum_xcodeversions   {darwin_major minimum_xcodeversion}
#
# where darwin_major is the major version of the underlying Darwin OS (e.g. 9
-# for Mac OS X 10.5 Leopard) and minimum_xcodeversion is the minimum version
+# for macOS Leopard) and minimum_xcodeversion is the minimum version
# of Xcode the port requires (e.g. 3.1).


I would keep this as Mac OS X 10.5 Leopard, the name does not change
retroactively.


I suppose that's an open question. Previously, I've tried to use the OS 
marketing name as it was when that OS version was released. Now, I'm thinking 
we should always use the current marketing name.


I agree with Rainer, "macOS Leopard" is just confusing. The current 
marketing name does not apply to previous releases.



Do we have any guidance from Apple on what they want people to do?


They still list previous OS releases back to Lion in the App Store as 
"OS X", if that helps you.


- Josh
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [152743] trunk/dports/_resources/port1.0/group

[Ryan Schmidt]

> On Sep 16, 2016, at 9:06 AM, Rainer Müller  wrote:
> 
> On 2016-09-16 01:09, ryandes...@macports.org wrote:
>> Revision: 152743
>>  https://trac.macports.org/changeset/152743
>> Author:   ryandes...@macports.org
>> Date: 2016-09-15 16:09:26 -0700 (Thu, 15 Sep 2016)
>> Log Message:
>> ---
>> Portgroups: replace "Mac OS X" and "OS X" with "macOS"
> 
>> Modified: trunk/dports/_resources/port1.0/group/xcodeversion-1.0.tcl
>> ===
>> --- trunk/dports/_resources/port1.0/group/xcodeversion-1.0.tcl   
>> 2016-09-15 23:06:35 UTC (rev 152742)
>> +++ trunk/dports/_resources/port1.0/group/xcodeversion-1.0.tcl   
>> 2016-09-15 23:09:26 UTC (rev 152743)
>> @@ -38,7 +38,7 @@
>> #   minimum_xcodeversions   {darwin_major minimum_xcodeversion}
>> #
>> # where darwin_major is the major version of the underlying Darwin OS (e.g. 9
>> -# for Mac OS X 10.5 Leopard) and minimum_xcodeversion is the minimum version
>> +# for macOS Leopard) and minimum_xcodeversion is the minimum version
>> # of Xcode the port requires (e.g. 3.1).
> 
> I would keep this as Mac OS X 10.5 Leopard, the name does not change
> retroactively.

I suppose that's an open question. Previously, I've tried to use the OS 
marketing name as it was when that OS version was released. Now, I'm thinking 
we should always use the current marketing name. Do we have any guidance from 
Apple on what they want people to do?

> The version number is usually also helpful to get the
> "10.X" to "darwin Y" mapping right.

Yes but I didn't want to go into a long explanation in that comment.

>> options minimum_xcodeversions
>> @@ -57,7 +57,7 @@
>> return -code error "unable to find Xcode"
>> }
>> if {[vercmp ${xcodeversion} ${minimum_xcodeversion}] < 0} {
>> -ui_error "On Mac OS X ${macosx_version}, ${name} 
>> ${version} requires Xcode ${minimum_xcodeversion} or later but you have 
>> Xcode ${xcodeversion}."
>> +ui_error "On macOS ${macosx_version}, ${name} 
>> @${version} requires Xcode ${minimum_xcodeversion} or later but you have 
>> Xcode ${xcodeversion}."
> 
> Why drop the foo @1.0 syntax that we use at so many other places to
> specify a port version?

I didn't drop it; I started using it, finally, in this portgroup.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [MacPorts] #51689: preserve_runtime_libraries convenience PortGroup

[René J . V . Bertin]

On Friday September 16 2016 16:06:54 Rainer Müller wrote:

>Moving the discussion to macports-dev as this is about the
>implementation, nothing users should care about.

You're not entirely right: users can and should care about ease of updating. I 
posted to macports-users on purpose, to get the largest possible awareness.

>That would be solved with dependency resolution using a SAT solver and
>version information in dependency specifications. We already started to
>work on that in last GSoC.

I'm not entirely sure if versioned dependencies are a solution to this 
particular problem. They shouldn't even become necessary when old runtime 
libraries can be left around; any port using them that gets updated will use 
the latest version. I don't see how you could end up in a situation where a 
non-rebuilt/reinstalled port that worked with a previous version will stop to 
work if you upgrade that dependency while keeping the required old runtime 
libraries around. A bump in the required dependency version will by definition 
be a result of an upgrade of the dependent.

>Putting the files into the destroot for the new archive is the wrong
>solution to this problem.

But the only workable workaround at the moment, as far as I can tell.
Even if it'll remain acceptable only in custom ports trees I'd still appreciate 
suggestions to improve it.

>Libraries that would not be replaced, but still have linking information
>need to be preserved on disk and in the registry indicating which port
>they belonged to. After all other ports linking to the files are
>upgraded, they can be safely removed.

Are you thinking of an automatic feature here? You're right that this should be 
feasible but that'd be so elegant even I didn't dare dreaming of it :)

>version) changes. This does not happen that often and as long as the
>major part of ports comes from our ports tree, the current solution of

It happens often enough with far-reaching enough consequences, in my perception!

>and cannot introduce the rev-bump at the same time. However, the
>automatic scanning in rev-upgrade will detect the problem and either
>upgrade the broken port with a new binary archive or eventually rebuild
>the port locally, ensuring the user has a working installation of all ports.

And hopefully for him/her, one that doesn't have any ports that require manual 
rebuilding, have pending changes, or any other whatever-it-is that means it 
shouldn't be upgraded completely automatically.

>needs to be done in base. As you said, that will require changes to the
>registry format. As we currently handle upgrade as a completely
>transparent deactivate old/activate new cycle, that would also require
>significant changes to the internal phases.

I know next to nothing about db internals, so I have no idea if one can store 
new data fields in a database and still keep it forwards compatible (i.e. old 
db file readable by the new code). I'd hope this is or can be more or less 
transparent, but if not, couldn't that new data be stored in an additional file?
And wouldn't that reduce the overhead of operating on a single huge db file, at 
least in theory?

R
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Could not open Portfile

[Joshua Root]

On 2016-9-17 00:04 , Rainer Müller wrote:

On 2016-09-16 14:20, Craig Treleaven wrote:

I’ve hit this scenario a couple of times.  Am I doing something wrong with svn 
patch?


What is your umask set to? From the permissions it looks like this is
with umask 0077.

I encountered the same problem before. svn patch does not preserve the
permissions of the existing files. Actually this behavior is not even
specific to svn patch, other commands such as svn revert behave the same
way. svn creates a new temporary file with umask applied, deletes the
existing file and moves the new file in place.

Personally, I use ACLs on my ports directory to automatically grant read
permissions to everyone on new files. This also resolves this problem
with svn patch for me.

chmod -R +a "group:everyone allow
read,execute,list,search,file_inherit,directory_inherit" ~/ports

It would be nice to have a better solution for this problem, but the
actual bug is in Subversion.


I reported this upstream a while ago with respect to svn commit and it 
was fixed. If you report these other affected commands and reference the 
fix for commit they should be able to fix them pretty easily too.




- Josh
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Could not open Portfile

[Craig Treleaven]

> On Sep 16, 2016, at 10:04 AM, Rainer Müller  wrote:
> 
> On 2016-09-16 14:20, Craig Treleaven wrote:
>> I’ve hit this scenario a couple of times.  Am I doing something wrong with 
>> svn patch?
> 
> What is your umask set to? From the permissions it looks like this is
> with umask 0077.
> 
> I encountered the same problem before. svn patch does not preserve the
> permissions of the existing files. Actually this behavior is not even
> specific to svn patch, other commands such as svn revert behave the same
> way. svn creates a new temporary file with umask applied, deletes the
> existing file and moves the new file in place.
> 
> Personally, I use ACLs on my ports directory to automatically grant read
> permissions to everyone on new files. This also resolves this problem
> with svn patch for me.
> 
> chmod -R +a "group:everyone allow
> read,execute,list,search,file_inherit,directory_inherit" ~/ports
> 
> It would be nice to have a better solution for this problem, but the
> actual bug is in Subversion.
> 
Thanks Rainer!  I thought maybe I was just missing a step, somewhere.  I found 
a ‘sudo chmod 0666’ on the affected Portfiles allowed me to go ahead.  

Craig
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Goodbye Mac OS Forge, hello GitHub

[Craig Treleaven]

> On Aug 20, 2016, at 2:07 AM, Lawrence Velázquez  wrote:
> 
>> On Aug 19, 2016, at 8:18 PM, Ryan Schmidt  wrote:
>> 
>> And our new buildbot automated build system announced earlier this month is
>> being hosted by me on my hardware, outside of Apple, and will just need
>> minor changes to monitor GitHub instead of Subversion.
> 
> FYI I've made some progress on this tonight and hope to make initial commits 
> tomorrow or Sunday.

Where does the migration stand now?

Craig
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [152743] trunk/dports/_resources/port1.0/group

[Rainer Müller]

On 2016-09-16 01:09, ryandes...@macports.org wrote:
> Revision: 152743
>   https://trac.macports.org/changeset/152743
> Author:   ryandes...@macports.org
> Date: 2016-09-15 16:09:26 -0700 (Thu, 15 Sep 2016)
> Log Message:
> ---
> Portgroups: replace "Mac OS X" and "OS X" with "macOS"

> Modified: trunk/dports/_resources/port1.0/group/xcodeversion-1.0.tcl
> ===
> --- trunk/dports/_resources/port1.0/group/xcodeversion-1.0.tcl
> 2016-09-15 23:06:35 UTC (rev 152742)
> +++ trunk/dports/_resources/port1.0/group/xcodeversion-1.0.tcl
> 2016-09-15 23:09:26 UTC (rev 152743)
> @@ -38,7 +38,7 @@
>  #   minimum_xcodeversions   {darwin_major minimum_xcodeversion}
>  #
>  # where darwin_major is the major version of the underlying Darwin OS (e.g. 9
> -# for Mac OS X 10.5 Leopard) and minimum_xcodeversion is the minimum version
> +# for macOS Leopard) and minimum_xcodeversion is the minimum version
>  # of Xcode the port requires (e.g. 3.1).

I would keep this as Mac OS X 10.5 Leopard, the name does not change
retroactively. The version number is usually also helpful to get the
"10.X" to "darwin Y" mapping right.

>  options minimum_xcodeversions
> @@ -57,7 +57,7 @@
>  return -code error "unable to find Xcode"
>  }
>  if {[vercmp ${xcodeversion} ${minimum_xcodeversion}] < 0} {
> -ui_error "On Mac OS X ${macosx_version}, ${name} 
> ${version} requires Xcode ${minimum_xcodeversion} or later but you have Xcode 
> ${xcodeversion}."
> +ui_error "On macOS ${macosx_version}, ${name} 
> @${version} requires Xcode ${minimum_xcodeversion} or later but you have 
> Xcode ${xcodeversion}."

Why drop the foo @1.0 syntax that we use at so many other places to
specify a port version?

Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Could not open Portfile

[Rainer Müller]

On 2016-09-16 14:20, Craig Treleaven wrote:
> I’ve hit this scenario a couple of times.  Am I doing something wrong with 
> svn patch?

What is your umask set to? From the permissions it looks like this is
with umask 0077.

I encountered the same problem before. svn patch does not preserve the
permissions of the existing files. Actually this behavior is not even
specific to svn patch, other commands such as svn revert behave the same
way. svn creates a new temporary file with umask applied, deletes the
existing file and moves the new file in place.

Personally, I use ACLs on my ports directory to automatically grant read
permissions to everyone on new files. This also resolves this problem
with svn patch for me.

chmod -R +a "group:everyone allow
read,execute,list,search,file_inherit,directory_inherit" ~/ports

It would be nice to have a better solution for this problem, but the
actual bug is in Subversion.

Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [MacPorts] #51689: preserve_runtime_libraries convenience PortGroup

[Rainer Müller]

https://trac.macports.org/ticket/51689

Moving the discussion to macports-dev as this is about the
implementation, nothing users should care about.

On 2016-09-16 10:06, René J.V. Bertin wrote:
> My proposal aims to introduce (and provide a proof of concept) of an
> optional other solution, which could be used by select ports and give
> users with specific needs an easier way to adjust the update
> behaviour and cycle to their requirements. Easier than backing out of
> an upgrade cycle that turns out to have unwelcome consequences, copy
> the retrieved outdated culprit ports to a personal ports tree and
> start over again.
> 
> It'd be more elegant if implemented in "base", with more control over
> which libraries get preserved from an existing install, but I think
> it's obvious a non-default variant should be used to activate the
> feature.
> 
> It'd be even more elegant if the implementation actually reactivated
> select files from an older software image, meaning they'd remain
> members of that installed version only and be removed from the system
> when the user uninstalls that or those older versions. I'd love to
> try my hand at that but it's clearly going to involve substantial
> changes to "base", possibly even a change to the registry database,
> and I'm not comfortable with that. Maybe the additional metadata
> could be stored in an additional *sql file?
> 
> If that additional metadata includes a list of which ports depend on
> what "outdated" libraries it should even become trivial to present a
> list of recommended updates, i.e. the ports that ought to be rebuilt
> in order to use the latest dependencies available. That's the same
> list of ports that would break when uninstalling a particular version
> of a particular dependency.

That would be solved with dependency resolution using a SAT solver and
version information in dependency specifications. We already started to
work on that in last GSoC.

> I know that users can already decide not to upgrade select ports (and
> back out of an unwelcome upgrade by reactivating old versions), but
> then you quickly end up with an increasing list of outdated ports
> (making it hard to see and figure out which can and should be
> upgraded) and at some point you almost stop upgrading (and
> selfupdating) at all.

Overall, handling these kinds of upgrades could be improved. You are
correct that the proposed way would be what other package managers do,
for example Gentoo's portage:

https://wiki.gentoo.org/wiki/Preserve-libs

Putting the files into the destroot for the new archive is the wrong
solution to this problem.

Libraries that would not be replaced, but still have linking information
need to be preserved on disk and in the registry indicating which port
they belonged to. After all other ports linking to the files are
upgraded, they can be safely removed.

This problem will only appear when the SONAME (or dylib compatibility
version) changes. This does not happen that often and as long as the
major part of ports comes from our ports tree, the current solution of
rev-bumping works. The problem exists mainly for custom ports trees with
ports linking with the main ports tree. We have no control over these
and cannot introduce the rev-bump at the same time. However, the
automatic scanning in rev-upgrade will detect the problem and either
upgrade the broken port with a new binary archive or eventually rebuild
the port locally, ensuring the user has a working installation of all ports.

There is really no way to add such a functionality in a port group, it
needs to be done in base. As you said, that will require changes to the
registry format. As we currently handle upgrade as a completely
transparent deactivate old/activate new cycle, that would also require
significant changes to the internal phases.

Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: lldb ...

[Rainer Müller]

On 2016-09-16 10:18, Jeremy Huddleston Sequoia wrote:
> Yeah, this contradicts what I'm seeing as expected.  Given that
> you've signed /opt/local/bin/ggdb with an entitlement, it should be
> CS_RESTRICT which should imply CS_HARD.  The lack of a code signature
> would trigger !CS_VALID which would prevent the process from loading
> the unsigned libraries.

There is actually no entitlement data in the code-signature itself.
The access is granted by embedding a Info.plist into the binary:

$ otool -P /opt/local/bin/ggdb
/opt/local/bin/ggdb:
(__TEXT,__info_plist) section

http://www.apple.com/DTDs/PropertyList-1.0.dtd";>


  CFBundleIdentifier
  org.gnu.gdb
  CFBundleName
  gdb
  CFBundleVersion
  1.0
  SecTaskAccess
  
allowed
debug
  



Probably that is why these rules are not enforced?

Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Could not open Portfile

[Craig Treleaven]

Hi:

Fresh install of MacPorts on a new VM with an svn checkout of trunk, I get this 
error:

$ sudo port install mariadb-server
Password:
Error: Unable to execute port: Could not open file: 
/Users/macmyth/mp/trunk/dports/databases/mariadb/Portfile

I had applied a patch to mariadb, ala:

$ svn patch 
/Volumes/Clooney/Test_installers/patch_port_mariadb-server_startupitem_and_pkg_2016Sep14.diff
 
U Portfile
A files/org.macports.mariadb-server.plist
A files/postinstall
A files/preinstall

The permissions before running the patch were:

$ pwd
/Users/macmyth/mp/trunk/dports/databases/mariadb
$ ls -l
total 24
-rw-r--r--  1 macmyth  staff  10021 16 Sep 07:32 Portfile
drwxr-xr-x  7 macmyth  staff238 16 Sep 07:32 files

After the patch:

$ ls -l
total 24
-rw---   1 macmyth  staff  11885 16 Sep 08:02 Portfile
drwxr-xr-x  10 macmyth  staff340 16 Sep 08:02 files

I did update sources.conf to include:

file:///Users/macmyth/mp/trunk/dports [default]
rsync://rsync.macports.org/release/tarballs/ports.tar

I’ve hit this scenario a couple of times.  Am I doing something wrong with svn 
patch?

Craig

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [152630] contrib/buildbot-test

[Mojca Miklavec]

On 14 September 2016 at 21:15, Ryan Schmidt wrote:
>> On Sep 14, 2016, at 2:01 PM, Rainer Müller wrote:
>> On 2016-09-14 16:10, Ryan Schmidt wrote:
>>>
>>> I had to remove these lines when deploying because I don't have a "docs" 
>>> worker set up yet.
>>>
>>> Configuration Errors:
>>>  builder 'docs-www' uses unknown slaves 'docs'
>>>  builder 'docs-guide' uses unknown slaves 'docs'
>>
>> I agree this will be more than just documentation. Maybe give it a very
>> generic name such as "jobs"?
>
> I like that. Or we could call it "steve".

I like the idea :) :) :)

Anyway, can someone put an additional line into slaves.json.sample for
that worker?

It doesn't hurt to have a worker listed even if the actual machine
hasn't been set up yet. I got the same error as above (builder ...
uses unknown slaves 'docs'.)

Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: lldb ...

[Jeremy Huddleston Sequoia]

> On Sep 10, 2016, at 17:56, Jeremy Sequoia  wrote:
> 
> On Sep 10, 2016, at 16:51, Rainer Müller  wrote:
> 
>> I got gdb to work now on Sierra now. In fact I did not even have to sign
>> any of the libraries it links to.
>> 
>> 
>> $ otool -L /opt/local/bin/ggdb |awk 'NR>1 {print $1}' \
>>|grep '^/opt/local' | xargs -I{} codesign -d -v {}
>> /opt/local/lib/libintl.8.dylib: code object is not signed at all
>> /opt/local/lib/libncurses.6.dylib: code object is not signed at all
>> /opt/local/lib/libz.1.dylib: code object is not signed at all
>> /opt/local/lib/libiconv.2.dylib: code object is not signed at all
>> /opt/local/lib/libexpat.1.dylib: code object is not signed at all
>> 
>> $ /opt/local/bin/ggdb -q /opt/local/bin/curl
>> Reading symbols from /opt/local/bin/curl...(no debugging symbols
>> found)...done.
>> (gdb) r
>> Starting program: /opt/local/bin/curl
>> warning: unhandled dyld version (15)
>> curl: try 'curl --help' or 'curl --manual' for more information
>> [Inferior 1 (process 6964) exited with code 02]
>> (gdb) q
> 
> Hmm.  That isn't what I'd expect.  Gonna need to check why that is.  It looks 
> like CS_RESTRICT isn't implying CS_HARD like I thought it should.

Yeah, this contradicts what I'm seeing as expected.  Given that you've signed 
/opt/local/bin/ggdb with an entitlement, it should be CS_RESTRICT which should 
imply CS_HARD.  The lack of a code signature would trigger !CS_VALID which 
would prevent the process from loading the unsigned libraries.

Can you send me a tarball of your working

/opt/local/bin/ggdb
/opt/local/lib/libintl.8.dylib
/opt/local/lib/libncurses.6.dylib
/opt/local/lib/libz.1.dylib
/opt/local/lib/libiconv.2.dylib
/opt/local/lib/libexpat.1.dylib
+ all other recursive dependencies that those dylibs link against in /opt/local?

I want to take a closer look.

--Jeremy




smime.p7s
Description: S/MIME cryptographic signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: RFC: mp-buildbot failcache

[Mojca Miklavec]

> We should put the buildername/buildnumber/URL of the failing build into
> the failcache to be reported back on a match. The current output would
> not be helpful to find the reason why it failed. I added this
> information to the build environment [1].

Just curious. Given that you already implemented this, what is/was the
reason for not deploying it yet? (That piece of information would be
super helpful to me as well.)

I hope that failcache output will be properly parsed/recognized while
composing the email report.

(I didn't look into the code yet, I still need to catch up with other things.)
Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev