Re: port:qt5 and (proposed) port:qt5-kde cohabitation

> On Oct 23, 2016, at 5:25 AM, René J.V. Bertin wrote: > >> On Sunday October 23 2016 02:21:02 Marko Käning wrote: >> >> I guess we can wait committing those once the new GitHub workflow is >> in place, because it would make reviewing all the changes much >> easier in a GitHub’ish pull request.

Re: port:qt5 and (proposed) port:qt5-kde cohabitation

> On Oct 23, 2016, at 6:04 PM, Fred Wright wrote: > >> On Sun, 23 Oct 2016, Clemens Lang wrote: >> >>> On Sun, Oct 23, 2016 at 11:25:52AM +0200, René J.V. Bertin wrote: >>> >>> I noticed it for Trac (which isn't a complete improvement *). I'm not >>> aware that git allows pulling only changes t

Re: Moving to GitHub: Status Update, Action Required

> On Oct 24, 2016, at 12:50 PM, Mojca Miklavec wrote: > >> On 21 October 2016 at 20:12, Clemens Lang wrote: >> >> Action Required: GitHub Accounts >> >> Our new Trac installation will use GitHub for login. If you do not have >> a GitHub account yet, please create

Re: Moving to GitHub: Status Update, Action Required

> On Oct 24, 2016, at 2:00 PM, Vincent Habchi wrote: > > I’ve bought Coda 2 when I use to do a bit of HTML development. Can > I use it to check out - tinker with the new MacPorts GIT repository? You can use any Git client you like, as long as you're aware that we'll effectively be trashing the c

Re: Moving to GitHub: Status Update, Action Required

> On Oct 24, 2016, at 1:58 PM, Clemens Lang wrote: > > I don't think we should mandate a complex "run these magic git commands" > workflow. Making things complicated will just make them go wrong. Agreed. >> On Mon, Oct 24, 2016 at 07:47:18PM +0200, Mojca Miklavec wrote: >> >> (My preference wo

Re: Git tools for managing patchsets

> On Oct 24, 2016, at 2:13 PM, Michael wrote: > > I'm looking into what "Git for Windows" does, because this is exactly > what they do -- maintain a large set of patches that are release > specific and not integrated upstream. And, it's my understanding that > MacPorts is basically a pair of (por

Re: Git tools for managing patchsets

> On Oct 24, 2016, at 5:57 PM, Marko Käning wrote: > > The only question mark I have there is: > > Will we ask the committers to squash their changesets or prefer > to clutter the main repo with potentially many tiny iterations > for the changed ports?? > > Personally I don’t

Re: Git tools for managing patchsets

> On Oct 24, 2016, at 7:03 PM, Michael wrote: > >> On 2016-10-24, at 2:57 PM, Marko Käning wrote: >> >> Well, but I think what you, Michael, are describing, is only needed >> if you work with many patches which aren’t really committed to any >> repository. > > Actually, it's something else. It

Re: "Failed to open portfile from registry" while reinstalling because of configure.optflags

> On Oct 25, 2016, at 1:17 PM, René J.V. Bertin wrote: > > I've looked into putting the offending statement (`$workername eval set > user_options($opt) $val`) in a loop, something like > > $workername eval set user_options($opt) "" > foreach v $val { >$workername eval set user_options($

Re: port:qt5 and (proposed) port:qt5-kde cohabitation

> On Oct 25, 2016, at 4:43 PM, René J.V. Bertin wrote: > > Where does one file tickets for trac? In Trac. vq ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Trac down again

It’s back. I have seen this error a couple of times since the Trac migration. vq > On Oct 26, 2016, at 3:18 PM, Marius Schamschula wrote: > > Hmm. > > Service Unavailable > > The server is temporarily unable to service your request due to maintenance > downtime or capacity problems. Please

Fwd: [154314] trunk/dports/security/paperkey/Portfile

Please do not commit version updates to my openmaintainer ports. I don't consider such changes "minor". vq > Begin forwarded message: > > From: not...@macports.org > Subject: [154314] trunk/dports/security/paperkey/Portfile > Date: October 27, 2016 at 1:46:10 PM EDT > To: macports-chan...@list

Re: git fetch fails because of gnutls_handshake

> On Oct 29, 2016, at 9:54 AM, René J.V. Bertin wrote: > > On Saturday October 29 2016 15:32:19 Clemens Lang wrote: > > hi, > >> That's https://trac.macports.org/ticket/51516. > > Ah, thanks. > >>> What could this be due to? >> >> Your system libcurl is too old to talk modern SSL, or you hav

Re: git fetch fails because of gnutls_handshake

> On Oct 29, 2016, at 11:17 AM, René J.V. Bertin wrote: > > Does trac no longer auto-subscribe new participants? Our Trac has never automatically subscribed anyone except ticket reporters. Owners and Cc need to be set explicitly. I don't know if other projects do things differently. vq ___

Re: GitHub migration complete

> On Oct 30, 2016, at 9:54 PM, Clemens Lang wrote: > > Our Subversion repository has been split into several repositories on > GitHub. Please note that Ryan ran the svn2git conversion several times this weekend, so any clones made previously will have nothing in common with the final repositorie

Re: GitHub migration complete

> On Oct 30, 2016, at 9:54 PM, Clemens Lang wrote: > > MacPorts developers should now have commit access to the GitHub > repositories. A quick reminder about commit messages: Old habits die hard, but from now on do NOT refer to Trac tickets as "#12345" in your commit messages; GitHub's website

Re: GitHub migration complete

> On Oct 31, 2016, at 7:12 AM, René J.V. Bertin wrote: > >> On Monday October 31 2016 11:52:28 Rainer Müller wrote: >> >> rsync -vt >> rsync://rsync.macports.org/macports/release/ports/PortIndex_darwin_16_i386/PortIndex* >> $ports > > Thanks for the suggestion, I might do that. > > (Are you

Re: GitHub migration complete

> On Oct 31, 2016, at 12:16 PM, Thibaut Paumard wrote: > >> Le 31/10/2016 à 17:01, René J.V. Bertin a écrit : >>> On Monday October 31 2016 10:00:05 Ryan Schmidt wrote: >>> >>> This issue only affects the very small percentage of the MacPorts user >>> population (including developers and mainta

Re: Working with Git

> On Oct 31, 2016, at 11:29 AM, Ryan Schmidt wrote: > >> On Oct 5, 2016, at 9:53 PM, Ryan Schmidt wrote: >> >> How will this work on GitHub? >> >> The user will submit a pull request. How do I test it locally? What if the >> pull request is incomplete? I know I can tell the user what's wrong,

Re: Working with Git

> On Oct 31, 2016, at 1:04 PM, Lawrence Velázquez wrote: > > Now you can check out the new branch and try out the submitter's > changes. You can also modify the branch as you see fit. > > $ git checkout l2dy-curl-ca-bundle-update Actually, if the rebas

Re: GitHub migration complete

> On Oct 31, 2016, at 1:16 PM, Thibaut Paumard wrote: > > Le 31/10/2016 à 17:23, Lawrence Velázquez a écrit : >>> On Oct 31, 2016, at 12:16 PM, Thibaut Paumard wrote: >>> >>>> Le 31/10/2016 à 17:01, René J.V. Bertin a écrit : >>>>>

Re: GitHub migration complete

> On Oct 31, 2016, at 5:23 AM, Marko Käning wrote: > > a post-commit-hook checking whether the GitHub pull request ID #123 > actually exists for the main repository seems like a valuable feature, > especially in the transition phase. Shall I file a ticket on trac for it? Sure, if you like. Feel

Removing "$Id$" lines

Hi, We no longer have use for "$Id" lines, so committers should remove them at their convenience. vq > On Oct 31, 2016, at 5:20 PM, Schamschula > wrote: > > Schamschula pushed a commit to branch master > in repository macports-ports. > > https://github.com/macports/macports-ports/commit/eee

Re: GitHub desired workflow...

> On Oct 31, 2016, at 5:01 PM, Eric A. Borisch wrote: > > Just so I'm clear on this, is the desired approach for each committer > to: > > == setup == > 1) clone macports/macports-ports to the local filesystem After cloning, you should be sure that you are using your MacPorts email address for c

Re: GitHub desired workflow...

> On Oct 31, 2016, at 5:46 PM, Lawrence Velázquez wrote: > > Ultimately, anything you do before pushing is up to you, as long as > you don't push any merge commits. We've disabled force-pushing on all > master branches, so you don't have to worry too much doing th

Re: GitHub desired workflow...

> On Oct 31, 2016, at 5:50 PM, Sean Farley wrote: > > I'm not sure I agree with attempting to modify the git repo at all. For > example, what if I'm in the middle of bisecting and need to add/remove a > port? Why does 'port sync' call at all what the state is? Updating the repository is the whol

Re: GitHub desired workflow...

> On Oct 31, 2016, at 5:55 PM, Lawrence Velázquez wrote: > >> On Oct 31, 2016, at 5:50 PM, Sean Farley wrote: >> >> I'm not sure I agree with attempting to modify the git repo at all. For >> example, what if I'm in the middle of bisecting and need to a

Re: Removing "$Id$" lines

> On Oct 31, 2016, at 6:17 PM, Dan Ports wrote: > > Any reason not to just bulk-remove them all at once? No reason other than time and effort. vq ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/list

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

You should set your repository's user.email to your MacPorts email address. vq > On Oct 31, 2016, at 9:50 PM, dstrubbe > wrote: > > dstrubbe pushed a commit to branch master > in repository macports-ports. > > https://github.com/macports/macports-ports/commit/8ed388e541ce01d92d698791fefd72a4b

Re: Working with Git

> On Nov 1, 2016, at 4:57 AM, Rainer Müller wrote: > >> On 2016-11-01 05:54, Mojca Miklavec wrote: >> >> I'm with Ryan in this case. We don't prevent anyone from using this >> software if they choose to, I just don't see the point of advertising >> software whose maintainer decided to go against

Re: Removing "$Id$" lines

> On Nov 1, 2016, at 7:00 AM, Mojca Miklavec wrote: > > On 1 November 2016 at 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

Re: Removing "$Id$" lines

> On Nov 1, 2016, at 2:22 PM, Mojca Miklavec wrote: > >> On 1 November 2016 at 18:07, Lawrence Velázquez wrote: >> >>> On Nov 1, 2016, at 7:00 AM, Mojca Miklavec wrote: >>> >>> Why not: >>> - wait until all the slaves have something n

Re: Removing "$Id$" lines

> On Nov 1, 2016, at 4:59 AM, Marko Käning wrote: > >> On 01 Nov 2016, at 02:02 , Rainer Müller wrote: >> >> buildbot: ignore > > +1 > > I’d also suggest to use this also to specify which buildbots should be used > for a commit: > > buildbot: Mavericks Sierra > > I think that can be very h

Re: Removing "$Id$" lines

> On Nov 1, 2016, at 3:45 PM, Rainer Müller wrote: > > 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 su

Re: Removing "$Id$" lines

> On Nov 1, 2016, at 3:55 PM, Daniel J. Luke wrote: > >> On Nov 1, 2016, at 3:36 PM, Lawrence Velázquez wrote: >> >> While I agree in principle that our committing should not be >> hampered by the buildbot and would welcome another solution, I'm not >&

Claiming your user repository

Hello, As a reminder: > On Oct 31, 2016, at 11:00 PM, Ryan Schmidt wrote: > > If you had a personal directory in the users directory of the > Subversion repository, that has now been converted to a separate git > repository in https://github.com/macports with a name starting with > "macports-us

Re: Proposal for a MacPorts'ish commit message template

> On Nov 1, 2016, at 6:51 PM, Marko Käning wrote: > > I know that many of you weren't in favour of a commit message template, > but I propose one anyway, which I derived from KDE’s neat one, as I find > it on the console quite handy to know when 50 or 72 characters are > reached in a line: To be

Re: port info --{build,configure}.dir ?

> On Nov 2, 2016, at 5:06 AM, René J.V. Bertin wrote: > > Would a request to provide the build and/or configure directory > variables as meta-info data be accepted? Probably not. vq ___ macports-dev mailing list macports-dev@lists.macosforge.org https

Re: New build failure emails are difficult to act on

Can you open a ticket for this and assign it to me? You can just copypaste your original email as the description or something. vq > On Nov 2, 2016, at 3:56 AM, Jeremy Huddleston Sequoia > wrote: > > >> On Nov 2, 2016, at 00:20, Mojca Miklavec wrote: >> >> On 2 November 2016 at 06:17, Jerem

Re: New project members: jonesc

> On Nov 2, 2016, at 2:20 PM, Rainer Müller wrote: > > Please join us in welcoming the following new MacPorts project member: > > - Chris Jones (jonesc) > > We look forward to continued excellent contributions! Yay! vq ___ macports-dev mailing list

Re: Working with Git

> On Nov 2, 2016, at 11:24 PM, Ryan Schmidt wrote: > > Yes, there are "command line instructions" on the web site, but they > are different from the commands you gave below, which are again > different from other commands suggested in previous threads, so it is > difficult to know which set of in

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

> On Nov 3, 2016, at 8:01 AM, René J.V. Bertin wrote: > > On Thursday November 03 2016 12:42:40 Rainer Müller wrote: > >> Overall, can we just stop this discussion, please? We settled to stay >> with Trac and it is not going to change. > > Really, all your decisions are always set in stone from

Re: How to submit an updated portfile on new system?

> On Nov 3, 2016, at 12:12 PM, Watson Ladd wrote: > > Dear all, > A new version of Pari has come out, and I will update the portfile > soon. However, I haven't found new git compatible workflow > documentation anywhere. Should I still do the old-fashioned make a > patch and submit in a ticket, or

Re: Properly merging pull requests

> On Nov 3, 2016, at 12:19 PM, Sterling Smith wrote: > > The user will not learn if you change it under his/her feet. I think > that you should make line by comments of changes that need to be made > in the files tab of the pull request and ask the pull request > submitter to make those changes.

Re: Properly merging pull requests

> On Nov 3, 2016, at 11:59 AM, Mojca Miklavec wrote: > > 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

Re: Properly merging pull requests

> On Nov 3, 2016, at 1:46 PM, Rainer Müller 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 modifications by > maintainers" [1], you can force-push your changes to the pull request > branch, replacing the original

Re: Properly merging pull requests

> On Nov 3, 2016, at 2:16 PM, Rainer Müller wrote: > > On 2016-11-03 18:57, Lawrence Velázquez wrote: >>> On Nov 3, 2016, at 1:46 PM, Rainer Müller wrote: >>> >>> I think the proper way to do it on GitHub would be as follows: >>> When the p

Re: Properly merging pull requests

> On Nov 3, 2016, at 2:46 PM, Lawrence Velázquez wrote: > > >> On Nov 3, 2016, at 2:16 PM, Rainer Müller wrote: >> >> On 2016-11-03 18:57, Lawrence Velázquez wrote: >>>> On Nov 3, 2016, at 1:46 PM, Rainer Müller wrote: >>>> >>>>

Re: Working with Git

> 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 the error was? The next time it happens could you let me know? I could certainly h

Re: Working with Git

> On Nov 3, 2016, at 10:29 PM, Rainer Müller wrote: > > While Larry's version ensures you will always do a rebase, the version > from GitHub could fall back to a merge. Right. My intention is to always avoid merges. > Assuming the 'git pull' results in a fast-forward, both command > sequences s

Re: [MacPorts] CommittersGuide/PersonalSVNRepository modified

> On Nov 2, 2016, at 9:40 PM, MacPorts wrote: > > Page "CommittersGuide/PersonalSVNRepository" was changed by raimue > Diff URL: > > Revision 9 > Comment: No longer applies after move to GitHub > Changes

Re: [MacPorts] CommittersGuide/PersonalSVNRepository modified

> On Nov 4, 2016, at 9:59 AM, Rainer Müller wrote: > >> On 2016-11-04 05:01, Lawrence Velázquez wrote: >> >> Is there a reason you didn't just delete the page? > > Deleting a wiki page also erases all of its history and it is > irreversible. Ah right, t

Re: Proposal for a MacPorts'ish commit message template

> On Nov 4, 2016, at 1:30 PM, Marko Käning wrote: > > Oh, I’d be using vim as well, good to know that it does support git. > I didn’t know that vim would be able to treat commit message line > formatting for the first and the 3r+ lines differently with 50 and 72 > chars respectively. It doesn't

Re: Proposal for a MacPorts'ish commit message template

> On Nov 4, 2016, at 1:43 PM, Marko Käning wrote: > >> On 04 Nov 2016, at 18:34 , Lawrence Velázquez wrote: >> >> It doesn't really do anything differently w.r.t. wrapping, but it >> highlights subject-line overflow in an alarming red color. > > that’

Re: PR usage by people with commit access

> On Nov 4, 2016, at 1:48 PM, Clemens Lang wrote: > >> * Using the same change methods as outside contributors may help to >> develop better PR flow. I am not particularly interested in accommodating contributors' workflow expectations for their own sake. Their workflows may work for them but no

Re: How best to change a hard-coded config search path, before compilation

> On Nov 4, 2016, at 8:53 PM, A. Karl Kornel wrote: > > The first thing I was thinking of doing is using "reinplace" directly > on the file in question, in the pre-build phase. The section method > I came up with was to use a patch file to change the line, replacing > "/etc" with "PREFIX_GOES_HER

Re: Github user repos?

> On Nov 5, 2016, at 12:46 PM, Marko Käning wrote: > > please delete my user repo https://github.com/macports/macports-user-mk > > I don’t need it and didn’t use is since ages. Done, thanks. vq ___ macports-dev mailing list macports-dev@lists.macosfo

Re: zsh +mp_completion (auto-completion for port(1))

On Nov 27, 2013, at 2:48 AM, Jean-Philippe Ouellet wrote: > Changeset 101584 removed the mp_completion variant of zsh, supposedly > because it "has zero versioning relationship to anything else that is > installed". > > What does that mean? It still works, it was useful, and it wasn't > replaced

Re: [114094] trunk/dports/python

On Dec 4, 2013, at 1:30 AM, Ryan Schmidt wrote: > On Nov 29, 2013, at 05:40, Peter Danecek wrote: > >> No testing is not done during build or installation. So these dependencies >> are strictly not necessary. However, when you would like to test the package >> (after installation) you would n

Re: [114303] trunk/dports

On Dec 4, 2013, at 2:18 PM, michae...@macports.org wrote: > Revision: 114303 > https://trac.macports.org/changeset/114303 > Author: michae...@macports.org > Date: 2013-12-04 11:18:35 -0800 (Wed, 04 Dec 2013) > Log Message: > --- > various dports: allow use of either py*-pyqt

Re: What should be done about tickets that seem to be forgotten?

On Dec 10, 2013, at 5:17 AM, Akim Demaille wrote: > For instance https://trac.macports.org/ticket/34225 The best thing to do is to email macports-dev, as you did. The ticket might just have been overlooked, or maybe no one's found the time to get to that particular ticket. Feel free to email

Looks like Trac is down again. (eom)

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

Re: [114733] users/landonf/openjdk7/dports/java/openjdk6/Portfile

On Dec 27, 2013, at 8:56 AM, Landon Fuller wrote: > On Dec 22, 2013, at 3:11 , Ryan Schmidt wrote: > >> This will unnecessarily make users of Xcode < 5 install the llvm-gcc42 port, >> when they have a perfectly good version of llvm-gcc42 provided by Xcode. >> Rather than this, you should use

Re: Launchpad-links to non-existing executables stay behind after deinstalling mythtv-core.27

On Dec 30, 2013, at 9:57 AM, Craig Treleaven wrote: > Yes, that would be expected behaviour. MacPorts has no way of knowing that > the link was created so it ends up pointing to a now-deleted file after an > uninstall. Where do the links come from? Are they created by MythTV at runtime? If M

Re: [115275] users/landonf/openjdk7/dports/java/openjdk7/Portfile

This prevents use of our llvm-gcc42 port ("macports-llvm-gcc-4.2"). Is this intentional? vq On Dec 30, 2013, at 10:20 AM, land...@macports.org wrote: > Revision > 115275 > Author > land...@macports.org > Date > 2013-12-30 07:20:02 -0800 (Mon, 30 Dec 2013) > Log Message > > Explicitly whitelis

Re: Launchpad-links to non-existing executables stay behind after deinstalling mythtv-core.27

On Dec 30, 2013, at 7:11 PM, Craig Treleaven wrote: > Myth installs double-clickable Applescript helpers that you can drag to the > Dock--which auto-magically creates a link. What I've experienced is that when > Myth is uninstalled, the link on the Dock remains. Perhaps LaunchPad is > doing t

Re: Launchpad-links to non-existing executables stay behind after deinstalling mythtv-core.27

On Dec 31, 2013, at 6:33 AM, mk-macpo...@techno.ms wrote: > Perhaps I wasn’t patient enough and should have rebooted to make MacOSX’s > launchpad realise the vanishing of the two files? ;) Heh. I can't speak for you, obviously, but when I deactivated GitX just now on Mavericks, the icon disappe

Re: [115352] trunk/dports/devel/gettext/Portfile

Looks like the patch went MIA. vq On Dec 31, 2013, at 3:33 PM, jerem...@macports.org wrote: > Revision > 115352 > Author > jerem...@macports.org > Date > 2013-12-31 12:33:36 -0800 (Tue, 31 Dec 2013) > Log Message > > gettext: autoreconf to pick up correct C++ runtime > Modified Paths > > trunk

Re: [115561] trunk/dports/audio/mpd/Portfile

On Jan 5, 2014, at 3:13 AM, Ryan Schmidt wrote: > Default variants must include “+” or “-“ as desired, e.g.: > > default_variants +mad > > if you want to enable the variant by default or: > > default_variants -mad > > if you want to disable it by default. https://trac.macports.org/changeset/

Re: [115574] trunk/dports/graphics/makeicns/Portfile

> On Jan 5, 2014, at 5:29 PM, Ryan Schmidt wrote: > > Right, it’ll become simplified, but not totally eliminated. :/ > > Adding -stdlib=… would be wrong for non-clang? > > It would be nice if base could put the right argument into the flags > automatically. I don’t think we can realistically e

Re: [MacPorts] Mirrors modified

On Jan 18, 2014, at 7:41 AM, MacPorts wrote: > Page "Mirrors" was changed by jakwi...@gmail.com > Diff URL: > Revision 54 > Comment: adds one Profiles mirror from China USTC > Changes: > ---8<--8<--8<--8<--8<-

Re: Compilers and MPI Port Groups

On Jan 19, 2014, at 6:41 PM, Sean Farley wrote: > Any objections before I push? Not sure they're "objections" so much as "nitpicks". > set compilers.list {cc cxx cpp objc fc f77 f90} There's a "configure.objcxx" option now. > # dragonegg versions will always match the corresponding clang vers

Re: Deactivating the installed version before trying to install the update

On Jan 20, 2014, at 8:44 AM, Adam Mercer wrote: > On Sun, Jan 19, 2014 at 11:37 PM, Ryan Schmidt > wrote: > >> Better yet, see if changing -I to -isystem fixes this; see #40656. If so, >> commit a local version of this fix to your port until MacPorts 2.3 is >> released. > > No, that doesn't

Re: [116291] trunk/dports/_resources/port1.0/group/debug-1.0.tcl

(a) There's already a configure.mtune option. You should use that ("configure.mtune native") instead of appending to all the flags options. (b) Don't you have to disable binary archives if you set "-mtune=native"? vq Sent from my iPhone > On Jan 23, 2014, at 3:07 PM, s...@macports.org wrote: >

Re: [115735] trunk/dports/devel/class-dump/Portfile

On Jan 10, 2014, at 2:41 PM, Jeremy Huddleston Sequoia wrote: > On Jan 10, 2014, at 08:50, Joshua Root wrote: > >>> Revision: 115735 >>> https://trac.macports.org/changeset/115735 >>> Author: larryv at macports.org >>> Date: 2014-01-09 21:25:03 -0800 (Thu, 09 Jan 2014) >>> Log Me

Re: [116449] trunk/base/src/port1.0

On Jan 25, 2014, at 11:57 AM, c...@macports.org wrote: > Revision > 116449 > Author > c...@macports.org > Date > 2014-01-25 08:57:17 -0800 (Sat, 25 Jan 2014) > Log Message > > port1.0: Tcl cleanup, from a patch by Gustaf Neumann > - removed numeric comparisons where not necessary > - braced exp

Re: deployment target and sdk version (was Re: [115735] trunk/dports/devel/class-dump/Portfile)

On Jan 25, 2014, at 6:28 AM, Joshua Root wrote: > I still think that quoting with braces in expressions when double quotes > would do is harder to read, BTW. The more I see it, the more I agree. https://trac.macports.org/changeset/116453 vq ___ macpo

Re: [116839] trunk/dports/devel/re2/Portfile

Doesn't this require an epoch bump also? vq Sent from my iPhone > On Feb 8, 2014, at 8:37 AM, h...@macports.org wrote: > > Revision > 116839 > Author > h...@macports.org > Date > 2014-02-08 05:37:06 -0800 (Sat, 08 Feb 2014) > Log Message > > re2: downgrade to 20130622 for Lion and Mountain Lion

Re: [116839] trunk/dports/devel/re2/Portfile

On Feb 8, 2014, at 4:42 PM, Sean Farley wrote: > I don't think so because it was uninstallable on machines believe > Mavericks due to libc++ issues. Ah, you're right then; I didn't actually look at the ticket until just now. Sorry for the noise. vq _

Re: Call for Testers: MacPorts Statistics

On Feb 8, 2014, at 4:55 PM, Eric Gallager wrote: > Really? That sounds dangerous, but if you say it works fine, I guess I can > give it a try... That's more or less what selfupdate already does. If you also want to switch to using a checkout of the ports tree, you'll have to edit your sources

Re: commit rights ...

On Feb 21, 2014, at 11:53 AM, Peter Danecek wrote: > But maybe having more committers might reduce backlog, just a thought … Membership requests are evaluated by the project managers only (Josh, Rainer, and Ryan). vq ___ macports-dev mailing list mac

Re: flags for base's configure script: should there be more or fewer? (was "Fwd: [MacPorts] #42756: macports doesn't compile with bundled tcl")

On Mar 7, 2014, at 5:06 PM, Eric Gallager wrote: > libtasn1 is not actually something that gnutls maintains themselves, they > only vendor it in as a convenience. Bringing it back to MacPorts, the copy of > Tcl that is vendored in is more like libtasn1 in gnutls, in that MacPorts > only vendor

Re: [117621] trunk/base

+1 vq On Mar 8, 2014, at 9:55 AM, Gustaf Neumann wrote: > Also, big, big thanks from my side! -gustaf neumann > > Am 08.03.14 08:53, schrieb Ryan Schmidt: >> On Mar 5, 2014, at 16:19, c...@macports.org wrote: >> >>> ... >>> macports: use a local copy of Tcl 8.5, mostly fix out-of-source build

Re: Root port update

On Mar 16, 2014, at 12:53 PM, Chris Jones wrote: > Could i ask a commitor to take a look at > > https://trac.macports.org/ticket/42867 > > It updates root to a new version, that fixes compilation with the latest > Xcode 5.1 on OSX 10.9, so it would be useful to get it out quickly. https://tra

Re: MacPorts Developer Meeting?

On Apr 4, 2014, at 3:22 PM, Mojca Miklavec wrote: > If you are interested in coming, maybe you can also add the continent > of your choice to the reply ;) Can't say for sure what I'll be up to in 2015, but I'd be interested. I'm currently in New York. vq (Sorry to dredge this up after so many

Re: Maintainers census

On Jul 22, 2014, at 2:11 PM, Arno Hautala wrote: > "BCC" because you know someone is going to start a "Reply All; Please > take me off this mailing list" fire. Plus, you're conducting a census, > not a discussion. +1 vq ___ macports-dev mailing list m

Re: [122496] branches/gsoc14-pip2port

On Jul 23, 2014, at 6:12 AM, gau...@macports.org wrote: > Revision > 122496 > Author > gau...@macports.org > Date > 2014-07-23 03:12:35 -0700 (Wed, 23 Jul 2014) > Log Message > > Used openssl for checksum generation > --- branches/gsoc14-pip2port/pypi2port.py 2014-07-23 10:11:24 UTC (rev > 1

Re: Please commit ticket #44474

On Aug 5, 2014, at 10:30 AM, Davide Liessi wrote: > Dear MacPorts developers, > can you please commit https://trac.macports.org/ticket/44474? Done, thanks! http://trac.macports.org/changeset/123117 vq ___ macports-dev mailing list macports-dev@lists

Re: [123423] trunk/dports/perl/p5-email-mime-contenttype/Portfile

On Aug 9, 2014, at 11:47 AM, Frank Schima wrote: > Just curious about why you are removing the indenting spacing in these perl > ports? I would say it is more common to indent in blocks. I’m open to a > discussion about what is preferred. I know when I edit p5 and other ports, I > add 4 spaces

Re: [123423] trunk/dports/perl/p5-email-mime-contenttype/Portfile

On Aug 9, 2014, at 4:41 PM, David Evans wrote: > On 8/9/14 12:46 PM, Frank Schima wrote: > >> I think the code looks better indented. But I will stay with the consensus >> on this (of course). >> > > +1 for Frank's position here. I've been adding the 4 spaces when > updating perl ports as wel

Re: [123558] trunk/dports/lang/rust/Portfile

On Aug 10, 2014, at 11:38 PM, Joshua Root wrote: > Chances are this will come back to bite you at some point, e.g. when > clang adds a new warning. There's really no reason to inflict build > failures due to warnings-turned-errors on our users. That's true; I guess I was overly focused on trimmi

Re: Usage of the term MacPorts (was: Topological sorting of perl modules)

On Aug 13, 2014, at 8:56 AM, Arno Hautala wrote: > I think the more important question is what the "venery" term is for > portfiles. > > "A MacPorts of Portfiles" doesn't sound that great. > A TCL of Portfiles? a Subversion of Portfiles vq ___ macpo

Re: Usage of the term MacPorts (was: Topological sorting of perl modules)

On Aug 13, 2014, at 6:45 AM, Joshua Root wrote: > If we were talking about portmgr then I would agree. But I don't think > MacPorts is a collective noun, it's a proper noun denoting a single > project. That the name has a plural form probably confuses the issue > further. I don't know, I think o

Re: Usage of the term MacPorts (was: Topological sorting of perl modules)

On Aug 13, 2014, at 6:45 AM, Joshua Root wrote: > If we were talking about portmgr then I would agree. But I don't think > MacPorts is a collective noun, it's a proper noun denoting a single > project. That the name has a plural form probably confuses the issue > further. I don't know, I think o

Re: [123768] trunk/base/src/macports1.0/macports.tcl

On Aug 14, 2014, at 2:40 AM, Joshua Root wrote: > Do we really need to call 'sh -c' here? I assumed that directory changes persist after the call to "system" — hence the pushd/popd in the previous version. We could probably get by with "cd $portdir && … && cd \$OLDPWD", though. We could also

Re: [123768] trunk/base/src/macports1.0/macports.tcl

On Aug 14, 2014, at 4:04 AM, Joshua Root wrote: > On 2014-8-14 17:58 , Lawrence Velázquez wrote: >> On Aug 14, 2014, at 2:40 AM, Joshua Root wrote: >> >>> Do we really need to call 'sh -c' here? >> >> I assumed that directory changes persist af

Re: [123768] trunk/base/src/macports1.0/macports.tcl

On Aug 14, 2014, at 12:50 PM, Eric Cronin wrote: > My original patch to add this that's in trac somewhere (#27485 it looks like) > did this, but others thought stash/stash pop was bad so I removed it and just > got in the habit of committing everything locally instead I don't really have a pro

Re: [124054] trunk/base/src/macports1.0/reclaim.tcl

On Aug 17, 2014, at 3:55 PM, ksamm...@macports.org wrote: > Revision > 124054 > Author > ksamm...@macports.org > Date > 2014-08-17 12:55:50 -0700 (Sun, 17 Aug 2014) > Log Message > > Added a block to stop it from deleting your home directory +1 vq _

Re: Failing livecheck for kdenlive

On Aug 21, 2014, at 5:50 PM, Marko Käning wrote: > any idea why kdenlive’s livecheck fails claiming that 0.9.2 is *newer* than > 0.9.8? > > --- > DEBUG: Executing org.macports.main (kdenlive) > DEBUG: livecheck phase started at Thu Aug 21 23:48:00 CEST 2014 > DEBUG: Executing org.macports.livec

Re: Failing livecheck for kdenlive

On Aug 21, 2014, at 7:25 PM, Marko Käning wrote: > On 22 Aug 2014, at 01:18 , Joshua Root wrote: >>> On Aug 21, 2014, at 5:50 PM, Marko Käning wrote: DEBUG: The regex is "kdenlive-(\d+(\.\d+)+)" >> More that if your livecheck isn't finding the current version, you need >> to fix your livec

<    1   2   3   4   5   6   7   8   9   >