Re: Proposal for a MacPorts'ish commit message template

On 2016-11-04 18:46, Lawrence Velázquez wrote: > Actually, I might have been thinking about another editor. My vim > highlights the subject in *green* up until 50 chars, and then black for > the overflow. But one can probably change that black to red if they want > :P .vimrc: hi def link

Re: PR usage by people with commit access

On 2016-11-04 18:10, Ivan Larionov wrote: > I'm not saying that you have to wait for review or something like > this, but opening a PR from your branch and then merging it has some > pros: > > * Better visibility of changes. Instead of cloning full repository > and digging through history I can

Re: Working with Git

On 2016-11-04 03:41, Lawrence Velázquez wrote: >> On Nov 3, 2016, at 9:48 PM, Ryan Schmidt wrote: >> >> I did already run "git branch -D l2dy-curl-ca-bundle-update" when "git >> branch -d l2dy-curl-ca-bundle-update" failed because of an error. > > Do you remember what

Re: [MacPorts] CommittersGuide/PersonalSVNRepository modified

On 2016-11-04 05:01, Lawrence Velázquez wrote: >> On Nov 2, 2016, at 9:40 PM, MacPorts wrote: >> >> Page "CommittersGuide/PersonalSVNRepository" was changed by raimue >> Diff URL: >> >>

Re: Properly merging pull requests

On 2016-11-03 18:57, Lawrence Velázquez wrote: >> On Nov 3, 2016, at 1:46 PM, Rainer Müller <rai...@macports.org> wrote: >> >> I think the proper way to do it on GitHub would be as follows: >> When the pull request author checked the box for "Allow modificati

Re: Pull Requests for Work in Progress (WIP)

On 2016-11-03 17:49, Sterling Smith wrote: > The main question of procedure is: Should the main macports repo be > used for proposing review of work in progress via pull requests? If > not, what is the proposed method? I propose you put your changes on a branch, add the compare URL to a ticket

Re: Properly merging pull requests

On 2016-11-03 16:59, Mojca Miklavec wrote: > Hi, > > We have recently experienced problems with pull requests showing up as > rejected on the web interface rather than merged (while the changes > were in fact accepted, possibly with some modifications). > > I admit my sins. In one case I did a

Re: [MacPorts] #1: foo @1.2: fails to build from source

On 2016-11-03 15:01, MacPorts wrote: > #1: foo @1.2: fails to build from source > -+-- > Reporter: anonymous | Owner: somebody > Type: defect | Status: new > Priority: blocker | Milestone: > Component: component1 |

Re: Using a different bugtracker [Was: Re: Poll: should Trac send email notifications when adding or replacing an attachment?]

On 2016-11-03 12:38, René J.V. Bertin wrote: > Conversion of existing tickets would be nifty, but I don't think it's > something I'd miss myself. What do you want to discuss then? A bug tracker is for tracking, we will not throw everything away that was reported. Overall, can we just stop this

Re: GitHub usernames as maintainers

On 2016-11-02 23:58, Clemens Lang wrote: > On Wed, Nov 02, 2016 at 06:45:21PM -0400, Brandon Allbery wrote: >> For me, it looks too much like an email address when combined with >> other things (e.g. "maintainers openmaintainer @foo"). > > I think that's a formatting problem. We could just as

Re: Github user repos?

On 2016-11-02 23:39, Ryan Schmidt wrote: > Contrary to Rainer's statement above, my plan was to leave unclaimed > old user repo in the macports org indefinitely. Deleting them implies > they contain no useful information; having not examined them, I'm not > in a position to make that

Re: Proposal for a MacPorts'ish commit message template

On 2016-11-02 23:46, Ryan Schmidt wrote: >> Which editor are you using? It differs by editor. > > Well, you mentioned vim. Very occasionally I use that. I don't > remember seeing any particular syntax highlighting in it when editing > a commit message. You would need these settings in your

New mailing list host: lists.macports.org

Hello, as part of the move off of macOS forge, we will migrate the mailing lists to the new mail server. We will migrate all subscriptions and user preferences and postings to the old mailing list addresses will be forwarded. However, the new hostname lists.macports.org implies that addresses and

Re: Trac down again

On 2016-11-02 19:16, Adam Mercer wrote: > On Tue, Nov 1, 2016 at 10:17 AM, Rainer Müller <rai...@macports.org> wrote: > >> We still have some options for tuning, but as it only occurs >> sporadically, we always have to wait to see if this solved it. > > Seems lik

New project members: jonesc

Please join us in welcoming the following new MacPorts project member: - Chris Jones (jonesc) We look forward to continued excellent contributions! - Joshua, Ryan, and Rainer Do you want to join the MacPorts team? If you would like to be considered for team membership and commit access,

Re: [macports-ports] branch master updated: libcxx: Bump to 3.9.0 (#52666)

On 2016-11-02 00:54, Jeremy Huddleston Sequoia wrote: > Jeremy Huddleston Sequoia (jeremyhu) pushed a commit to branch master > in repository macports-ports. > > https://github.com/macports/macports-ports/commit/864eb7639d6774a7853767be6b15384c790bfe70 > [...] > commit

Re: Github user repos?

On 2016-11-01 21:10, David Evans wrote: > I see that some github user repos have been created while others (like mine > ;-) ) have not. Is this an ongoing process > that's going to take a while or is there some action that the user needs to > take and get his repo created? Yours is already

Re: How to handle MacPorts' handles in the future (including the email address connected to it)??

On 2016-11-01 20:27, Marko Käning wrote: > I’d actually be happier if I had my - up to now - MacPorts handle > (mk) also for the future… :) > > But ok, I guess I’ll have to apply at ad...@macports.org for a new > handle then, being m...@macports.org, right? > > The only problem with all this is,

Re: Removing "$Id$" lines

On 2016-11-01 19:43, Lawrence Velázquez wrote: > In any case, the proposed set of commits is utterly unnecessary and is > not worth any of this fuss. I do not want to keep commenting on every single submission that it needs to remove the $Id$ line. This should be done as one commit and we would

Re: GitHub usernames as maintainers [Was: Re: [macports-ports] branch master updated: berkeleygw: Remove svn $Id$ line.]

On 2016-11-01 19:57, Clemens Lang wrote: > On Tue, Nov 01, 2016 at 07:42:23PM +0100, Mojca Miklavec wrote: >> At some point (rather sooner than later) we'll have to start adding >> GitHub usernames to Portfiles (we might have to extend the base to >> properly support that). > > I agree,

Re: rev-upgrade question

On 2016-11-01 19:50, Clemens Lang wrote: > On Tue, Nov 01, 2016 at 07:09:48PM +0100, Marko Käning wrote: >> how can I convince rev-upgrade to actually rebuild broken ports if >> 'revupgrade_mode' is set to ‘report' in macports.conf? > > You can specifically rebuild them manually using port -nf

Re: [macports-ports] branch master updated: berkeleygw: Remove svn $Id$ line.

On 2016-11-01 19:23, Sean Farley wrote: > Lawrence Velázquez writes: > >> You should set your repository's user.email to your MacPorts email address. > > Is this really necessary? I've seen mention of a mailmap but that hardly > seems like a big enough reason to force us to

Re: Trac down again

On 2016-11-01 13:54, Marko Käning wrote: > Trac is down again. It seems like it is periodically dying and reviving > itself. :( I kicked it again. Periodically, too many requests clog up the web server threads. The server would still have free resources and the load average is also not

Re: Working with Git

On 2016-11-01 05:54, Mojca Miklavec wrote: > I can imagine a newbie trying to navigate to the page and thinking > that installation of Homebrew is necessary for making that software > work, just to screw up the rest of MacPorts. An additional problem > might be that whenever users have a problem

Re: Removing "$Id$" lines

On 2016-11-01 01:03, Ryan Schmidt wrote: > On Oct 31, 2016, at 17:17, Dan Ports wrote: >> >> Any reason not to just bulk-remove them all at once? > > That would probably tie up the buildbot for weeks or months. We could > cancel those builds, but even the act of scheduling

Re: GitHub migration complete

On 2016-10-31 11:41, René J.V. Bertin wrote: > Pity though, the first-run portindex of a fresh git clone just took about 5 > quarters of an hour on one of my machines (a good 5s/port). Just as with Subversion. To speed it up, you could seed it with the latest generated version from rsync:

Re: CC maintainer on GitHub

On 2016-10-31 10:47, Zero King wrote: > I just submitted a PR on GitHub and the wiki didn't say how to CC the > maintainer. Should I use mention like @ryandesign? Yes, we need to use mentions. GitHub does not provide anything better. In the general case, you would first need to map the MacPorts

Re: Compiling dnsmasq with dnssec support?

On 2016-10-30 16:40, Johannes Kastl wrote: > Hi Joshua, > > On 30.10.16 12:19 Joshua Root wrote: >> On 2016-10-30 19:15 , Johannes Kastl wrote: >>> Question 1: Is it possible to use different >>> patchfiles-statements, depending on the variant? > >> Yes. > > As the documentation (at least the

Trac's Cc Me button is too small

On 2016-10-30 04:21, Fred Wright wrote: > Though if the new "Cc me" button were any smaller, it would be considered > a web bug. :-) I agree it is too small. The CSS rules for this button are minimal in addition to what Trac has for all other buttons. CSS and full plugin sources are available

Re: Moving to GitHub: Status Update, Action Required

On 2016-10-28 16:02, Craig Treleaven wrote: >> On Oct 21, 2016, at 2:12 PM, Clemens Lang wrote: >> ... >> Migration Timeline >> == >> The switch to Git will happen on the weekend of October 29th/30th. ... > > Is this still on track? Yes, expect Subversion to

Re: port:gpgme / Fwd: Review Request 129265: Port from KF5Gpgme to GpgME

On 2016-10-27 09:58, René J.V. Bertin wrote: > I'm not getting into trac (github being DDoS'ed again??), so I'm forwarding > this info via the ML hoping Ryan will catch it. Once again, our Trac is not hosted by GitHub. This is still the same cause Clemens reported on yesterday. Please bear with

Re: Moving to GitHub: Status Update, Action Required

On 2016-10-25 10:36, Ryan Schmidt wrote: > > > On Oct 24, 2016, at 17:57, Clemens Lang wrote: > >>> On Tue, Oct 25, 2016 at 12:17:57AM +0200, Marko Käning wrote: >>> A description of how exactly one would rebase (potentially squash and >>> history-rewrite) a submitted PR

Re: Trac & Subversion available again

On 2016-10-24 20:24, Daniel J. Luke wrote: > On Oct 24, 2016, at 1:26 PM, Clemens Lang wrote: >> On Mon, Oct 24, 2016 at 12:54:23PM -0400, Daniel J. Luke wrote: >>> This looks like it's true for me as well (cannot edit tickets beyond >>> making comments). >> >> Try clearing

Re: New Trac Uses Session Cookies

On 2016-10-22 18:16, Zero King wrote: > Please provide an option to keep the cookies after browser exits. Thanks for noticing. I raised the expiry date of cookies to 30 days. Rainer ___ macports-dev mailing list macports-dev@lists.macosforge.org

Re: SVN committing not possible ATM?

On 2016-10-22 14:44, Marko Käning wrote: > I just now couldn’t commit to the SVN server: > > --- > $ svn ci -m "gwenhywfar4-devel: update to 4.16.0beta" > SendingPortfile > Transmitting file data .svn: E175002: Commit failed (details follow): > svn: E175002: Unexpected server error 500

Re: foo-snapshot / foo-diff convenience functions

On 10/20/2016 10:25 PM, René J.V. Bertin wrote: > On Thursday October 20 2016 15:38:42 Lawrence Velázquez wrote: > >> Better that than increasing the complexity of base and portfiles. > > Yeah, unless someone proposes to implement something in a portgroup. Then all > of a sudden it becomes base

Re: Trac down?

On 2016-10-20 20:28, Vincent Habchi wrote: >> On 20 Oct 2016, at 14:04, Ryan Schmidt wrote: >> Trac, svn, www-origin and guide-origin are inaccessible outside of the Apple >> network. I'm trying to figure out why. > > I’ve been very busy lately and didn’t have much time

Re: 2nd MacPorts Meeting & Online Meeting

On 2016-10-16 22:36, David Evans wrote: > * now that I think about it, using irc might be the best way to go since a > transcript of the meeting > can be obtained from the irc logs. After the meeting this can be processed > into a "minutes" document and > published to document the meeting

Re: 2nd MacPorts Meeting & Online Meeting

On 2016-10-16 23:58, Clemens Lang wrote: > On Mon, Oct 10, 2016 at 07:53:13AM +0200, Mojca Miklavec wrote: >> Me and Aljaž would be willing to host the MacPorts meeting in 2017 >> again. > > Thanks, and sorry for not putting a plan together to do it in Munich in > the fall. Seems I need to

Re: MP Cert Revoked?

On 2016-10-13 17:11, Clemens Lang wrote: > Hi, > > - On 13 Oct, 2016, at 17:00, Michael Dickens michae...@macports.org wrote: > >> Your connection is not private >> Attackers might be trying to steal your information from >> trac.macports.org (for example, passwords, messages, or credit

Re: Can't edit commit message

On 2016-10-12 16:33, take...@macports.org wrote: > I can’t edit the commit message as described > in https://trac.macports.org/wiki/CommitRules. > > $ svn propedit --revprop svn:log -r 153822 > svn: E175008: While handling the 'svn:log' property on > '/repository/macports/!svn/bln/153822': > svn:

Re: path normalisation in "base"

On 2016-10-11 16:38, René J.V. Bertin wrote: > This does work though: > > {{{ > proc macports::normalize { filename } { > # normalise the user-specified prefix. The test file under $prefix need > not exist for that: > set nprefix [file dirname [file normalize "${macports::prefix}/foo"]]

Re: path normalisation in "base"

On 2016-10-11 10:43, René J.V. Bertin wrote: > To come back to action_provides: if the registry saves a port's > "intended" paths (the ones stored in the software image tarball), why > do a lookup of the actual/resolved path? That would make it > impossible to check which port installs a symlink

Re: Documentation overhaul

On 2016-10-10 01:23, Ryan Schmidt wrote: > Thanks for your interest, Marcel, but do you feel you would be able > to lead such an effort, since you seem to be new to MacPorts? I've > been with MacPorts for around 10 years and have thought of rewriting > the documentation for several years so I feel

Re: reasons for `port provides` not working?

On 2016-10-10 18:05, René J.V. Bertin wrote: > Is there a good reason why action_provides (in port) does a `file normalize`? > Wouldn't it be just as OK if the actual registry lookup (after doing all > checks) used the original $filename? file normalize is used to support relative paths and

Re: reasons for `port provides` not working?

On 2016-10-10 16:49, René J.V. Bertin wrote: > On Monday October 10 2016 15:30:57 Clemens Lang wrote: >> IIRC the problem was that your installation mangled paths somehow, either by >> making /opt/local a symlink or some other uncommon configuration. > > Yes (/opt/local is a symlink), but from

Re: Documentation overhaul

Hello Marcel, On 2016-10-09 15:53, Marcel Bischoff wrote: > As Ryan has identified that the online documentation needs work, I'm > hereby volunteering to give it a go. Since there appear to be quite > specific views on how everthing here needs to be, I'm asking in advance: > > - Is that in

Re: Issues with oudated ports / GitHub

On 2016-10-07 19:07, Marcel Bischoff wrote: > On 16/10/07, Ryan Schmidt wrote: >> The problem is: somebody needs to do the correct work to update each of >> those ports to the latest version. In many cases, tickets are already >> filed, and you can look them up to see what the current status is;

Re: Issues with oudated ports / GitHub

On 2016-10-07 20:58, Christopher Jones wrote: > >> On 7 Oct 2016, at 7:40 pm, Lawrence Velázquez >> wrote: >> >>> On Oct 7, 2016, at 2:09 PM, Chris Jones >>> wrote: >>> >>> Currently, once they find out about svn, and trac >> >> We will still

Re: Working with Git

On 2016-10-07 19:00, Brandon Allbery wrote: > On Fri, Oct 7, 2016 at 12:43 PM, Chris Jones > wrote: > > Indeed, I was a little dubious of the suggestions that involve > -force. I suspect there are better ways of working that

Re: Issues with oudated ports / GitHub

On 2016-10-07 18:25, Ken Cunningham wrote: > The current "port update" ticket queue I find to be a rather > unpredictable mixture of requests of port updates, requests for new > ports, announcements that somebody has noticed a version update has > come available, and finished port updates awaiting

Re: Issues with oudated ports / GitHub

Hello Marcel, On 2016-10-06 19:12, Marcel Bischoff wrote: > I was advised that I should ask my questions and raise my issues here. > > I'm currently considering dropping the use of MacPorts altogether as > this projects' track record regarding critical updates of major software > tools is rather

Re: Working with Git

On 2016-10-06 09:33, Sterling Smith wrote: > On Oct 5, 2016, at 7:53PM, Ryan Schmidt wrote: > >> Suppose a user submits an update to a port. >> >> With Subversion, the user would submit a patch in a Trac ticket. To test it, >> I would download the patch and apply it to

Re: Working with Git

On 2016-10-06 10:22, Ryan Schmidt wrote: > On Oct 6, 2016, at 02:33, Sterling Smith > wrote: >> When is the macports repo on GitHub supposed to appear? > > I have no ETA for you yet. "When it's ready." Part of being ready > includes having documentation about how we'll

Re: Working with Git

On 2016-10-06 14:28, Ryan Schmidt wrote: > If there are easy ways to rewrite the history of a pull request, by all > means, let's suggest the user do that, and provide instructions for how to do > so. I have no idea how to do it. You can rewrite the source branch of a pull request in any way

Re: order of operations in port upgrade

On 2016-10-06 00:14, Brandon Allbery wrote: > On Wed, Oct 5, 2016 at 5:41 PM, Rainer Müller <rai...@macports.org > <mailto:rai...@macports.org>> wrote: > > On 2016-10-05 11:09, René J.V. Bertin wrote: > > Quick question: a normal (non-forced) upgrade cu

Re: order of operations in port upgrade

On 2016-10-05 11:09, René J.V. Bertin wrote: > Quick question: a normal (non-forced) upgrade currently does > > 1) install (create new tarball image) > 2) deactivate old > 3) activate new > 4) clean ${workpath} (unless -k) Cannot reproduce. The clean target will already be run after step 1) and

Patch naming policy (was: Re: [153574] trunk/dports/sysutils/skey)

On 2016-10-05 01:45, Ryan Schmidt wrote: >> Patches should follow the patch-*.diff naming scheme, so this >> should be named patch-skeyprune-man8.diff or similar. >> >> https://guide.macports.org/#development.patches.source > > Popular opinion seems to be that we should relax that restriction. >

Re: [153574] trunk/dports/sysutils/skey

On 2016-10-04 22:03, lar...@macports.org wrote: > Revision: 153574 > https://trac.macports.org/changeset/153574 > Author: lar...@macports.org > Date: 2016-10-04 13:03:08 -0700 (Tue, 04 Oct 2016) > Log Message: > --- > skey: Rename patch > > Modified Paths: > --

Re: I'm a newbie mantainer and I'm confused about the buildbot

On 2016-09-30 00:09, Brandon Allbery wrote: > On Thu, Sep 29, 2016 at 4:28 PM, Daniel J. Luke > wrote: > > On Sep 29, 2016, at 3:51 PM, Lawrence Velázquez > wrote: > > Our blanket

Re: [MacPorts] WorkingWithGit modified

On 2016-09-23 20:38, Ryan Schmidt wrote: >> On Sep 23, 2016, at 13:33, Clemens Lang wrote: >> >> I didn't include this because it's not how I normally work. I >> usually only create branches for larger changes. I wouldn't be >> opposed to include it, but I'm probably not the

Re: No Xcode 8 CLT for El Capitan

On 2016-09-21 21:15, Adam Dershowitz wrote: > That comment does not make it at all clear what those of us who updated to > Xcode 8 (but not beta!) but are still on OS X 10.11 are supposed to do. > I have posted a ticket about building cmake that seems to be because it is > trying to use 10.12

Re: github desktop's request to install command line tools, and macports git command line tools ...

On 2016-09-18 19:39, Ken Cunningham wrote: > Github desktop seems a useful tool — but it wants to install command > line tools (specifically mentioning github utility and git-lfs) into > /usr/local/bin. > > right now, I’m set up with > > /opt/local/bin/git > > and I see there already is a port

python's LINKFORSHARED

Hello pythonXY maintainers, in python27, the LINKFORSHARED config variable is broken: $ python2.7 -c "import distutils.sysconfig; \ conf = distutils.sysconfig.get_config_var; \ print (conf('LINKFORSHARED'))" -u _PyMac_Error Python.framework/Versions/2.7/Python This value cannot be used for

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

On 2016-09-16 17:33, Ryan Schmidt wrote: > >> On Sep 16, 2016, at 9:06 AM, Rainer Müller <rai...@macports.org> wrote: >> >> I would keep this as Mac OS X 10.5 Leopard, the name does not change >> retroactively. > > I suppose that's an open questio

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

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

Re: Could not open Portfile

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

Re: [MacPorts] #51689: preserve_runtime_libraries convenience PortGroup

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

Re: lldb ...

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

Re: [152630] contrib/buildbot-test

On 2016-09-14 21:15, Ryan Schmidt wrote: > The master uses MacPorts in /opt/local for its own software (nginx, buildbot, > rsync, etc.). I can manually install anything else there that we need. It's > probably not best to automate selfupdating that MacPorts install, but it can > have its own

Re: [152630] contrib/buildbot-test

On 2016-09-14 16:10, Ryan Schmidt wrote: >> +"deploy": { >> +"www": { >> +"host": "", >> +"user": "", >> +"sshkeyfile": "", >> +"sshknownhostsfile": "ssh_known_hosts", >> +"destpath": "" >> +}, >> +"guide": {

Re: RFC: mp-buildbot failcache

On 2016-09-12 14:41, Clemens Lang wrote: > here's a patch against mp-buildbot that would add a fail cache for use > on the buildbots. Unfortunately I don't have a test setup yet, so I'm > hesitating to commit this immediately. I'd welcome feedback, a code > review, or testing by somebody with a

Re: [152490] contrib/buildbot-test

On 2016-09-12 04:17, Ryan Schmidt wrote: > { > "workers": { > "10.5_ppc": { > "base": "" > }, > "10.5_ppc_legacy": { > "ports": "" > }, > "10.6_x86_64": { > "base": "", > "ports": "" > }, >

Re: [152507] contrib/mp-buildbot/mpbb-cleanup

On 2016-09-12 10:41, Clemens Lang wrote: > On Sun, Sep 11, 2016 at 11:47:58AM -0700, rai...@macports.org wrote: >> Revision: 152507 >> https://trac.macports.org/changeset/152507 >> Author: rai...@macports.org >> Date: 2016-09-11 11:47:58 -0700 (Sun, 11 Sep 2016) >> Log Message: >>

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 > >

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

Re: lldb ...

On 2016-09-10 17:52, Jeremy Huddleston Sequoia wrote: >> On OS X 10.10 Yosemite, signing only the ggdb binary was certainly >> enough. I cannot reproduce this on macOS 10.12 Sierra, so the >> requirements might have changed. > > 10.10 predates SIP and related hardening around ptrace(). That >

Re: lldb ...

On 2016-09-10 00:23, Jeremy Sequoia wrote: >>> YES! We should not be needing to do such things as root. That is >>> 100% true, and I am in full support of moving away from that and only >>> using root for activate. We should be able to use fakeroot >>> (https://wiki.debian.org/FakeRoot) for

Re: newbie python - cmake build problem I can't seem to fix...

On 2016-09-09 17:32, Ken Cunningham wrote: > I'm working on updating a port (hatari) that only builds with > python2.7 (or more accurately, doesn't build with python35 selected , > but does build with python27 selected). it uses cmake, and > FindPythonInterp to find python. >

Re: lldb ...

On 2016-09-09 13:38, René J.V. Bertin wrote: >> At least on OS X 10.10 Yosemite, I can use any path to a keychain with >> `codesign --keychain`. This keychain does not have to be listed in >> `security list-keychains`. > > Does `man codesign` still mention the search list requirement in the >

Re: lldb ...

On 2016-09-09 10:17, René J.V. Bertin wrote: > On Thursday September 08 2016 16:03:21 Jeremy Huddleston Sequoia wrote: > >> That's not really necessary. All that is relevant is that the macports user >> has read access to the file. > > The fact that codesign only accepts keychain file

Re: lldb ...

On 2016-09-09 11:26, Jeremy Huddleston Sequoia wrote: > Yes. The fact that we aren't doing that for the binary packages that > we ship is quite embarrassing. We should solve this problem more > generally such that we can ship properly signed binaries for every > port. Users installing the

Re: lldb ...

On 2016-09-09 03:38, Jeremy Sequoia wrote: > You are describing a system to automatically create and automatically > trust a code signing certificate that contains a private key in a file > on disk that is not encrypted with a passphrase and only depends on file > system ACLs to protect it. > >

Re: lldb ...

On 2016-09-08 22:03, Jeremy Huddleston Sequoia wrote: > >> On Sep 2, 2016, at 05:19, Rainer Müller <rai...@macports.org> wrote: >> >> In my opinion, the actual implementation of codesigning should be in base: >> >> 1) Create a self-signed certificate

Re: lldb ...

On 2016-09-08 22:09, Jeremy Huddleston Sequoia wrote: >> On Sep 5, 2016, at 03:49, Rainer Müller <rai...@macports.org> wrote: >> My intention here is to describe a way how the code-signing can be >> automated. We do not gain much by providing a solution that still >&g

Re: lldb ...

On 2016-09-05 12:56, René J.V. Bertin wrote: > On Monday September 05 2016 12:21:08 Rainer Müller wrote: > > Do the steps in that TN include the trust setting and the magic command in > lldb's code-signing document? I was talking about generating self-signed identities/

Re: lldb ...

On 2016-09-05 13:29, René J.V. Bertin wrote: > Reminds me: I'm not really comfortable with the idea that PortFiles > would be able to create and store certificates. I'd rather see a form > where they can check for the availability of the identity, and then > inform the user exactly what command to

Re: lldb ...

On 2016-09-05 00:57, René J.V. Bertin wrote: > In a first draft the command accepted a list of binaries to sign, and read > the identify from a configuration file. I suppose that corresponds to what > you mean with a declarative syntax? > I then went to a simpler, single-binary interface because

Re: lldb ...

On 2016-09-02 14:19, Rainer Müller wrote: > For step 4), how to give user 'macports' access to the System.keychain > without entering a password? As an alternative, how to import the > identity (both private/public key) into a different keychain with > unlocked access? I found

Re: lldb ...

On 2016-09-02 14:45, René J.V. Bertin wrote: > On Friday September 02 2016 14:19:02 Rainer Müller wrote: > >>> https://trac.macports.org/ticket/45251 >> >> That would equivalent to what gdb recommends for codesigning. > > Yes, minus the part related to task

Re: lldb ...

On 2016-08-31 23:25, Lawrence Velázquez wrote: >> On Aug 31, 2016, at 4:57 PM, René J.V. Bertin wrote: >> >> I noticed that Apple don't ship an lldb-mi executable (at least they don't >> for OS X 10.9). > > Xcode 7.3 includes it (`xcrun --run lldb-mi`) but Xcode 4.6.3 does

Re: checking a file's dependents/cies?

On 2016-08-30 12:33, René J.V. Bertin wrote: > Is there a direct way to check what (binary) files depend on a given file > belonging to a port, something a bit less blunt than moving the file aside > and running `port -v rev-upgrade`? > I presume a mysql query of the registry could return that

Re: Permission denied, "pkg" phase

On 2016-08-26 05:09, Craig Treleaven wrote: > I’ve tried adding: > > pkg.asroot yes > > to my portfile but that seems to be unrecognized. > > Is there a way around this? Not without patching base. I have no experience with creating pkgs, so I don't know if it makes sense to allow running this

Re: [MacPorts] #52081: Ports should require perl5.24 instead of 5.22

On 2016-08-24 21:40, Mihai Moldovan wrote: > On 24.08.2016 09:36 PM, Lawrence Velázquez wrote: >> But those Perl ports are always leaves (w.r.t. `cpuid`) because they are >> build dependencies. There's no need to revbump if you're just updating build >> dependencies. > > Aren't build

Re: request review #52066

On 2016-08-24 02:14, Björn Ketelaars wrote: > Would someone be so kind to review (and commit) > https://trac.macports.org/ticket/52066 ? Done. https://trac.macports.org/changeset/151932 Rainer ___ macports-dev mailing list

Re: how about a 'snowleopardfixes' library port?

On 2016-08-23 19:13, Ryan Schmidt wrote: > I would prefer you work with the developers of the affected software packages > to get the necessary compatibility functions into their sources. This will > help all Snow Leopard users, not just those using MacPorts. I agree that fixing bugs in

Re: [MacPorts] #52068: darkice needs pkgconfig dependency

On 2016-08-22 12:39, Niels Dettenbach wrote: > Hmmm, > i'm just wondering how the port worked up to 1.2 - there was no significant > changes within darkice sources done as far as i know from Rafael Diniz > (darkice maintainer) and i see no differences in the configure flag sheme too. If you had

Re: port install v port mpkg | mdmg

Hello, On 2016-08-10 17:23, Craig Treleaven wrote: > Is it possible for a port to take different actions depending on > whether the user has initiated ‘port install’ v. 'port mpkg’ (or > ‘port mdmg’)? Unfortunately, no, as all phases can be run individually. So up to the destroot phase, there is

Re: A separate PortIndex for libc++ on older systems

On 2016-08-10 20:09, Lawrence Velázquez wrote: > On Aug 10, 2016, at 4:37 AM, Ryan Schmidt > wrote: > >> We also still need to decide how to differentiate the URLs for >> libc++ packages from the URLs of the existing libstdc++ packages. >> One suggestion was to add

Re: Determine before installation whether a port can be installed

On 2016-07-28 09:06, Artur Szostak wrote: > This sounds like there is a need to allow encoding of version ranges. In > which case I would suggest to solve this problem generically, to allow > encoding version ranges in port dependencies also. Similar to what is > possible with RPMs or Debian

  1   2   3   4   5   6   7   8   9   10   >