Re: [MacPorts] #51448: New Portfile for pyFAI
clang was blacklisted because at the time the first version of a port file was generated (a while before the port was actually submitted), there was no open mp support for clang. It looks like everything builds smoothly now. Best, Nico. Le 2016-09-11 18:48, MacPorts a écrit : > #51448: New Portfile for pyFAI > ---+ > Reporter: coquelleni@… | Owner: macports-tickets@… > Type: submission | Status: new > Priority: Normal | Milestone: > Component: ports | Version: > Resolution: | Keywords: > Port: py-pyFAI | > ---+ > Changes (by raimue@…): > > * cc: raimue@… (added) > > Comment: > > Here is an updated Portfile with some changes: > > * Formatted in common style > * Use GitHub port group > * Update to 0.12.0 > * license is actually GPL-3+ > > Why was clang blacklisted in the original submission? The port builds fine > for me with the default Xcode 7.2.1 on OS X 10.10 Yosemite. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [152162] contrib
> On Sep 11, 2016, at 11:58 PM, Lawrence Velázquez wrote: > >> On Sep 12, 2016, at 12:30 AM, Ryan Schmidt wrote: >> >> The updated master.cfg is live. > > Sweet. Does it include the changes I made tonight? Yes! ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [152162] contrib
On 12 September 2016 at 06:30, Ryan Schmidt wrote: > > The updated master.cfg is live. Wonderful, thank you! Mojca ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [152162] contrib
> On Sep 12, 2016, at 12:30 AM, Ryan Schmidt wrote: > > The updated master.cfg is live. Sweet. Does it include the changes I made tonight? vq ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [152162] contrib
> On Aug 30, 2016, at 3:50 PM, lar...@macports.org wrote: > > Revision > 152162 > Author > lar...@macports.org > Date > 2016-08-30 13:50:45 -0700 (Tue, 30 Aug 2016) > Log Message > > mpbb: Deprecate "--port" option > > Relevant subcommands now accept port names in the positional parameters, > as "list-subports" already did. > > Keep the option functional until the updated Buildbot config goes live. The updated master.cfg is live. > Modified Paths > > • contrib/buildbot-test/master.cfg > • contrib/mp-buildbot/README.md > • contrib/mp-buildbot/mpbb > • contrib/mp-buildbot/mpbb-install-dependencies > • contrib/mp-buildbot/mpbb-install-port > • contrib/mp-buildbot/mpbb-list-subports ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [152490] contrib/buildbot-test
> On Sep 11, 2016, at 7:34 AM, rai...@macports.org wrote:
>
> Revision
> 152490
> Author
> rai...@macports.org
> Date
> 2016-09-11 05:34:55 -0700 (Sun, 11 Sep 2016)
> Log Message
>
> buildbot: move build platforms to slaves.json
> Modified Paths
>
> • contrib/buildbot-test/master.cfg
> • contrib/buildbot-test/slaves.json.sample
> Diff
>
> Modified: contrib/buildbot-test/master.cfg (152489 => 152490)
>
> --- contrib/buildbot-test/master.cfg 2016-09-11 11:07:27 UTC (rev 152489)
> +++ contrib/buildbot-test/master.cfg 2016-09-11 12:34:55 UTC (rev 152490)
>
> @@ -43,9 +43,6 @@
>
> path_base = "/usr/bin:/bin:/usr/sbin:/sbin"
>
> path_ports = os.path.join(toolsprefix, "bin") + ":" + path_base
>
>
>
> -# TODO: the following list should be configured in slaves.json
> -build_platforms = ["10.6_x86_64", "10.6_x86_64_legacy", "10.6_i386",
> "10.6_i386_legacy", "10.7_x86_64", "10.7_x86_64_legacy", "10.8_x86_64",
> "10.8_x86_64_legacy", "10.9_x86_64", "10.10_x86_64", "10.11_x86_64"]
> -
>
> # Allow spaces and tabs in property values
>
> import re
>
> c['validation'] = {
>
> @@ -64,7 +61,11 @@
>
>
>
> with open(_path('slaves.json')) as f:
>
> slavedata = json.load(f)
>
> -for slave, pwd in slavedata.items():
>
> +
> +# convert unicode to byte strings
> +build_platforms = [s.encode('utf-8') for s in slavedata['build_platforms']]
> +
> +for slave, pwd in slavedata['slaves'].items():
>
> c['slaves'].append(BuildSlave(slave, pwd))
>
>
>
>
>
> @@ -438,7 +439,7 @@
>
> # XXX: slavenames assignment should be automatic and more generic
>
> portsslaves = {}
>
> baseslaves = {}
>
> -slavenames = slavedata.keys()
>
> +slavenames = slavedata['slaves'].keys()
>
> for plat in build_platforms:
>
> baseslaves[plat] = filter(lambda x: x.endswith(plat+"-base"),
> slavenames)
>
> portsslaves[plat] = filter(lambda x: x.endswith(plat+"-ports"),
> slavenames)
>
> Modified: contrib/buildbot-test/slaves.json.sample (152489 => 152490)
>
> --- contrib/buildbot-test/slaves.json.sample 2016-09-11 11:07:27 UTC (rev
> 152489)
> +++ contrib/buildbot-test/slaves.json.sample 2016-09-11 12:34:55 UTC (rev
> 152490)
>
> @@ -1,19 +1,34 @@
>
> {
>
> -"base-10.6_x86_64": "",
> -"ports-10.6_i386": "",
> -"ports-10.6_i386_legacy": "",
> -"ports-10.6_x86_64": "",
> -"ports-10.6_x86_64_legacy": "",
> -"base-10.7_x86_64": "",
> -"ports-10.7_x86_64": "",
> -"ports-10.7_x86_64_legacy": "",
> -"base-10.8_x86_64": "",
> -"ports-10.8_x86_64": "",
> -"ports-10.8_x86_64_legacy": "",
> -"base-10.9_x86_64": "",
> -"ports-10.9_x86_64": "",
> -"base-10.10_x86_64": "",
> -"ports-10.10_x86_64": "",
> -"base-10.11_x86_64": "",
> -"ports-10.11_x86_64": ""
>
> +"build_platforms": [
> +"10.6_x86_64",
> +"10.6_x86_64_legacy",
> +"10.6_i386",
> +"10.6_i386_legacy",
> +"10.7_x86_64",
> +"10.7_x86_64_legacy",
> +"10.8_x86_64",
> +"10.8_x86_64_legacy",
> +"10.9_x86_64",
> +"10.10_x86_64",
> +"10.11_x86_64"
> +],
> +"slaves": {
> +"base-10.6_x86_64": "",
> +"ports-10.6_i386": "",
> +"ports-10.6_i386_legacy": "",
> +"ports-10.6_x86_64": "",
> +"ports-10.6_x86_64_legacy": "",
> +"base-10.7_x86_64": "",
> +"ports-10.7_x86_64": "",
> +"ports-10.7_x86_64_legacy": "",
> +"base-10.8_x86_64": "",
> +"ports-10.8_x86_64": "",
> +"ports-10.8_x86_64_legacy": "",
> +"base-10.9_x86_64": "",
> +"ports-10.9_x86_64": "",
> +"base-10.10_x86_64": "",
> +"ports-10.10_x86_64": "",
> +"base-10.11_x86_64": "",
> +"ports-10.11_x86_64": ""
> +}
This is repetitive. I had been thinking of doing this in a nested way instead.
Maybe:
{
"workers": {
"10.5_ppc": {
"base": ""
},
"10.5_ppc_legacy": {
"ports": ""
},
"10.6_x86_64": {
"base": "",
"ports": ""
},
"10.6_x86_64_legacy": {
"ports": ""
},
"10.6_i386": {
"ports": ""
},
"10.6_i386_legacy": {
"ports": ""
},
"10.7_x86_64": {
"base": "",
"ports": ""
},
"10.7_x86_64_legacy": {
"ports": ""
},
"10.8_x86_64": {
"base": "",
"ports": ""
},
"10.8_x86_64_legacy": {
"ports": ""
},
"10.9_x86_64": {
"base": "",
"ports": ""
},
"10.10_x86_64": {
"base": "",
"ports": ""
},
"10.11_x86_64": {
"base": "",
"ports": ""
},
"10.12_x86_64": {
"base": "",
"ports": ""
},
"master": {
"docs-guide
Re: lldb ...
Can you please file a radar and toss me the number. This might be somehow falling through the cracks with the new logging changes and didn't get noticed yet. Hopefully we can get it fixed in an update soon if there isn't a workaround. Sent from my iPhone... > On Sep 11, 2016, at 05:07, Rainer Müller wrote: > > On 2016-09-11 02:56, Jeremy Sequoia wrote: >>> By the way, as I did lots of trial and error, is there a way to get >>> debug output (from taskgated?) to see why task_for_pid() was denied? >> >> Is it not being logged? You should see it in the system log >> (Console.app, log collect, etc). > > That is where I looked. When it fails, all I see is: > > taskgatedMacOS error: -67062 > > I assumed there must be some switch to get more output, but maybe it is > only enabled Apple internal. > > Messages with the same error code also appear from taskgated when it > works, but also some other error codes. So this might even be unrelated > to the actual verification. When it works, I also get more output from > other components such as trustd and authd. > > Rainer ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [152490] contrib/buildbot-test
> On Sep 11, 2016, at 8:37 AM, Rainer Müller wrote: > > On 2016-09-11 14:34, rai...@macports.org wrote: >> Revision: 152490 >> https://trac.macports.org/changeset/152490 >> Author: rai...@macports.org >> Date: 2016-09-11 05:34:55 -0700 (Sun, 11 Sep 2016) >> Log Message: >> --- >> buildbot: move build platforms to slaves.json >> >> Modified Paths: >> -- >>contrib/buildbot-test/master.cfg >>contrib/buildbot-test/slaves.json.sample > > When you update to this revision, please also change your local > configuration in slaves.json accordingly. This avoids the need to edit > master.cfg to run a custom buildbot installation. Thank you! This will be very helpful. vq ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [152490] contrib/buildbot-test
On 2016-09-11 14:34, rai...@macports.org wrote: > Revision: 152490 > https://trac.macports.org/changeset/152490 > Author: rai...@macports.org > Date: 2016-09-11 05:34:55 -0700 (Sun, 11 Sep 2016) > Log Message: > --- > buildbot: move build platforms to slaves.json > > Modified Paths: > -- > contrib/buildbot-test/master.cfg > contrib/buildbot-test/slaves.json.sample When you update to this revision, please also change your local configuration in slaves.json accordingly. This avoids the need to edit master.cfg to run a custom buildbot installation. Rainer ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: lldb ...
On 2016-09-11 02:56, Jeremy Sequoia wrote: >> By the way, as I did lots of trial and error, is there a way to get >> debug output (from taskgated?) to see why task_for_pid() was denied? > > Is it not being logged? You should see it in the system log > (Console.app, log collect, etc). That is where I looked. When it fails, all I see is: taskgatedMacOS error: -67062 I assumed there must be some switch to get more output, but maybe it is only enabled Apple internal. Messages with the same error code also appear from taskgated when it works, but also some other error codes. So this might even be unrelated to the actual verification. When it works, I also get more output from other components such as trustd and authd. Rainer ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: lldb ...
On Sunday September 11 2016 00:24:17 Jeremy Huddleston Sequoia wrote: >Well, you can certainly upgrade the storage after purchase if you want (cf >https://eshop.macsales.com/shop/ssd/owc/macbook-pro-retina-display/2013-2014-2015) Sure ... and that's not even 10x more expensive than a 1TB HDD, and probably not even half the price I paid for my MBP. However, sadly OWC didn't have this out when I bought my Thunderbolt dock: https://eshop.macsales.com/shop/Thunderbolt/Dock/OWC/Thunderbolt2-Dock/ As they say, finally a dock done right (esp. if it heats less than my Belkin) R. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: lldb ...
On Sunday September 11 2016 00:24:17 Jeremy Huddleston Sequoia wrote: >The secure thing to do is not escalate until we need to, prompt, do our thing, >then throw away the privs when done. The problem with that is that we'd ask >for credentials 2-3 times during the install and only when we need them. The solution would be to do as sudo does: cache the password for a given period of time. >The less secure thing to do is just ask for credentials up front if anything >will need root access and then just promote/demote as needed. Which is already what happens during the stages that shouldnt be run as root. >Even though iOS shares much of the same codebase as macOS, it is not UNIX. >Apple has never certified iOS as UNIX. Well, my cats don't have an official certification that they're European race. Doesn't mean they aren't ;) You know, looks like a duck, talks like one, etc. The fact you can't sell it as Unix is a distinction that IMHO matters only to marketeers and lawyers... >FWIW, HDDs are much more flakey than SSDs. I've had to replace countless HDDs >in my life, but I've yet to see one of my SSDs reach the end of their lives. The thing with HDDs is that you can predict failure only when they start failing. There's of course a MTBF estimate, but for each individual pair of HDDs you could just as well see the new one fail almost immediately and the old one last years more as the opposite (given identical use). SDDs have the advantage of being much more resistant to mechanical wear and abuse, but then again it wasn't the HDD that failed in my Powerbook which accompanied me in 3 motorcycle accidents and thousands of kms. >Then you definitely weren't using a good SSD. =/ No, and I got a lemon at that too. >There's also an SDXC port there. You can get a micro SDXC card and one of the >many flush-insert adaptors Is that port really different from the SD card port I have in my 2011 MBP? I've never dared investing in a SDXC card but the more affordable ones of a reasonable size tend to be disappointingly sluggish in certain operations. Otherwise they'd probably make a good choice for putting a filesystem journal (or ZFS ZIL). R. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: lldb ...
> On Sep 10, 2016, at 09:44, René J.V. Bertin wrote: > > On Saturday September 10 2016 08:45:38 Jeremy Huddleston Sequoia wrote: > >> Yes, for most cases we would probably not need root access at activation >> time, but for those cases you just listed, we would. We could do a pass >> over the bom to determine if root access is needed or not. The UI for >> handling such a case is non-trivial. Do we prompt once for the entire run >> of the process or escalate permissions for each port we encounter and then >> drop them again? If 8 ports are being installed and 4 require root, that's >> not a good user experience to prompt for password 4 times. > > I think it'd be up to the port to indicate if it requires root privileges > during the destroot. This is (implicitly) what happens with ports that create > a new user or group; there's a phase that requires root (configure, I think). > How's that handled at the UI level? I'm guessing that the phase will simply > fail for the port(s) that don't have the appropriate privileges. My point is not about the failure case but the working case. Ideally, the user would be able to do 'port -v -s install '. The secure thing to do is not escalate until we need to, prompt, do our thing, then throw away the privs when done. The problem with that is that we'd ask for credentials 2-3 times during the install and only when we need them. The less secure thing to do is just ask for credentials up front if anything will need root access and then just promote/demote as needed. The latter is a better user experience, and perhaps this can be the default but configurable for those that want more security. >>> I understand that the certificate catching is coupled to the file's inode >>> (whatever that is under HFS+), and the new copy indeed had a new inode. And >>> yet another inode after signing it. >> >> If you can reproduce this, please let me know and file a radar with details >> and let me know the number, so I can followup internally on it. I haven't >> seen such cases. The only issue I'm aware of is with overwriting an >> existing file (eg: using cp instead of mv). > > To make this reproducible I'd probably be looking at the following sequence? > 1) copy a binary from some original and ad-hoc sign it > 2) delete it > 3) copy the original once more and sign it with another certificate > > Correct me if I'm wrong, but I think that's what a `port -n upgrade --force` > boils down to if signing is done in the post-activate, no? > Is there any reason to expect that the certificate used in 3) must be a new > one not yet used to sign other executables? > >> iOS was never branded as UNIX. It is UNIX-like, but it was never UNIX. > > AFAIK it is or used to be based on OS X, evidently without the userland but > with a comparable kernel. Was that just a shortcut way of thinking of things? iOS has the same core os macOS. Much of everything below the UI layer is shared between the two platforms, but there are subtle differences, similar to how tvOS and watchOS are forked from iOS. Even though iOS shares much of the same codebase as macOS, it is not UNIX. Apple has never certified iOS as UNIX. >> I've got an internal 1TB SSD and it is more than enough for most of my >> needs. I mainly use USB for thumbsticks and my camera. In such cases, the >> throughput is bottlenecked on the attached device, not the bus. >> >> That being said, my server machine is a 2012 MacMini, and I've got a >> DroboMini and a LaCie RAID attached to it via thunderbolt, and the >> throughput and latency are more than adequate for my demanding needs. > > Thunderbolt external disks and 1TB SSDs are simply out of my budget. > >> For folks like you and me, it might be a minor concern being limited to 1TB, >> but we can certainly use an external SSD or an SDXC to increase storage as >> needed in the future. > > I see it as more than a minor concern. Not because I expect I'll ever need > more than 1TB internal space, but I would certainly not feel comfortable when > I know I cannot replace something that can fail that easily and unpredictable > as an SSD (or HDD for that matter). I don't recall but it's quite likely too > that I replaced the HDD in my current MBP with a Hitachi as soon as I > received the machine. FWIW, HDDs are much more flakey than SSDs. I've had to replace countless HDDs in my life, but I've yet to see one of my SSDs reach the end of their lives. > My only experience to date with SSDs was as an external. Connected over FW800 > (the fastest bus I had at the time) showed 0 gain over a good HDD ... and the > whole thing died catastrophically after not even 4 months. Then you definitely weren't using a good SSD. =/ > FWIW, that Clevo notebook I mentioned has an internal 2.5" disk (came with an > SSHD) but even at its price point it has a fashionable slot to add an SSD. > That's the kind of approach I like: adding expansion options in
