On 1 November 2016 at 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, e
I've been having a bit of difficulty dealing with the new buildbot emails. I
would really like links to the individual failing jobs. Instead, we're given
links to each job and a list of failed ports, but there is no indication as to
which port corresponds to which job. One must look thorough
> On Nov 1, 2016, at 17:47, Rainer Müller wrote:
>
> 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/864eb7639d6774a7853767be6b
On 11/1/16 4:06 PM, Ryan Schmidt wrote:
> Off list, Larry likened removing $Id$ lines to adding modelines, which we
> also haven't globally done to all Portfiles yet. But it's not really the same
> thing. Adding modelines needs to be done on a case by case basis. For
> example, if a Portfile cur
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 864eb7639d6774a7853767be6b
> 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
Hi,
On Tue, Nov 01, 2016 at 11:51:52PM +0100, 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,
Developers are free to use your template if they want to. We don't want
to mandate using i
Off list, Larry likened removing $Id$ lines to adding modelines, which we also
haven't globally done to all Portfiles yet. But it's not really the same thing.
Adding modelines needs to be done on a case by case basis. For example, if a
Portfile currently uses tabs, then just adding the modeline
On 01 Nov 2016, at 23:56 , Sterling Smith wrote:
> Remind me, would using this template still give the commented git status
> (which is the default)?
Yes, make a change and test it like this:
$ git commit -a -t ~/.git-commit-template
The status gets appended at the bottom.
Marko
___
To answer myself, according to
https://git-scm.com/book/tr/v2/Customizing-Git-Git-Configuration
the answer is yes, there is still the commented git status.
-Sterling
On Nov 1, 2016, at 3:56PM, Sterling Smith wrote:
> Remind me, would using this template still give the commented git status
> (
Remind me, would using this template still give the commented git status (which
is the default)?
-Sterling
On Nov 1, 2016, at 3:51PM, Marko Käning wrote:
> Hi MacPorts’ GitHubians,
>
> I know that many of you weren't in favour of a commit message template,
> but I propose one anyway, which I
Hi MacPorts’ GitHubians,
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:
--- ~/.git-commit-template ---
# Pleas
A newer git (2.6.0 [1]) is required for the rebase.autostash configuration
switch to work. As of Xcode 7.2, git is at 2.5.4.
With these two options set to true, (rebase.autostash and pull.rebase),
'git pull' feels like 'svn update' (at least to me) -- which is very nice
for transition documentatio
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
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 ther
The question I already posted in the “GitHub migration complete” thread was
whether I can simply remove my git repo altogether?
On 01 Nov 2016, at 09:52 , Marko Käning wrote:
> On 01 Nov 2016, at 04:00 , Ryan Schmidt wrote:
>> We suggest that you move your user repository to your own GitHub a
Hi Rainer,
On 01 Nov 2016, at 21:05 , Rainer Müller wrote:
> What do you mean by address rewriting? If you are referring to problems
> with SPF,
I guess I do.
> the new mail server is now doing SRS [1].
OK...
> Right now we do not host any mailboxes with IMAP, we only forward mails
> to exi
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?
BTW, I note that at least one of those already created belongs to a m
Rainer Müller writes:
> 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 f
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,
> 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
>> crazy about the idea of polluting our (per
> 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 submission that it
> needs to remove
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 crazy about the
> idea of polluting our (permanent!) commit history with transient
> administrivia like this.
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 ne
> 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
On 01 Nov 2016, at 19:57 , Rainer Müller wrote:
> 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
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, especially
Hi folks,
Mojca was addressing the email and MacPorts handle issue in thread
“[macports-ports] branch master updated: berkeleygw: Remove svn $Id$
line.”
which brings me to the point, that this in in fact a bit of an long standing
annoyance for me.
On 01 Nov 2016, at 19:42 , Mojca Mikl
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 up
On Tue, Nov 01, 2016 at 07:42:23PM +0100, Mojca Miklavec wrote:
> If someone submits a pull request for a maintained port, the
> maintainer should probably be notified explicitly with @username. The
> problem is that currently only Trac maintainers have access to that
> mapping.
It's not a set of
On Tuesday November 01 2016 13:33:26 Brandon Allbery wrote:
Hi,
In hindsight it indeed seems unlikely that the registry would contain this kind
of information.
>I think that's a hack: save and nuke the port in question (manually), then
>let rev-upgrade catch the broken dependents for you.
Exac
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 upgrade $port.
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 change user.email.
>
> 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 non-trivial to do (make
>>> sure the queue is not empty)
>>> -
On 1 November 2016 at 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 change user.emai
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 change user.email.
I'm pushing back on this, by the way, because I'd li
On 1 November 2016 at 18:07, Lawrence Velázquez wrote:
>> 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 probab
Hi folks,
how can I convince rev-upgrade to actually rebuild broken ports if
'revupgrade_mode' is set to ‘report' in macports.conf?
Greets,
Marko
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/list
While using the git port is a good idea for many reasons, the
Xcode-provided git should have autostash since Xcode 5.1 or so.
- Josh
On 2016-11-2 03:40 , Eric A. Borisch wrote:
As should the fact that, for this to work, you need to be using a
new-enough git (like from ports) and not the system
On Nov 1, 2016, at 12:38, Bradley Giesbrecht wrote:
>
> Would it work as well to have the buildbots ignore commits with unchanged
> epoch_version_revision.
No: imagine that a port fails to build because pkgconfig wasn't there. To fix
that, you'll add a build dependency on pkgconfig; you won't c
Hi,
On Tue, Nov 01, 2016 at 10:38:42AM -0700, Bradley Giesbrecht wrote:
> Would it work as well to have the buildbots ignore commits with
> unchanged epoch_version_revision.
That's https://trac.macports.org/ticket/52765. It would still take the
time to process the change and figure out that a por
> On Oct 31, 2016, at 6:02 PM, Rainer Müller wrote:
>
> 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 tho
On Tue, Nov 1, 2016 at 1:11 PM, Clemens Lang wrote:
> I don't understand how bzip2 and port rev-upgrade relate.
I think that's a hack: save and nuke the port in question (manually), then
let rev-upgrade catch the broken dependents for you.
--
brandon s allbery kf8nh
Hi,
On Tue, Nov 01, 2016 at 03:10:30PM +0100, René J.V. Bertin wrote:
> A variant of my earlier question: is there a magic formula to query
> the registry which files (and/or ports) depend on a given binary file?
> IOW, an elegant alternative to something like
No, there's no such thing in the reg
> 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
On Tue, Nov 1, 2016 at 12:40 PM, Eric A. Borisch
wrote:
> As should the fact that, for this to work, you need to be using a
> new-enough git (like from ports) and not the system-provided one.
I would recommend that anyway, considering that the system one may be
missing things like a moderately
As should the fact that, for this to work, you need to be using a
new-enough git (like from ports) and not the system-provided one.
On Tue, Nov 1, 2016 at 4:01 AM, Marko Käning wrote:
> On 01 Nov 2016, at 01:10 , Brandon Allbery wrote:
>
> > You can even configure so that becomes the default fo
> 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
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
particula
Hi,
A variant of my earlier question: is there a magic formula to query the
registry which files (and/or ports) depend on a given binary file? IOW, an
elegant alternative to something like
%> sudo bzip2 -v foo
%> sudo port -v rev-upgrade
%> sudo bunzip2 foo.bz2
Thanks,
R.
_
Trac is down again. It seems like it is periodically dying and reviving itself.
:(
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
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
> those builds, but even the act of scheduling 20,000 builds pe
On 01 Nov 2016, at 01:10 , Brandon Allbery wrote:
> You can even configure so that becomes the default for "git pull" for that
> repo.
>
> git config --local --bool pull.rebase true
> git config --local --bool rebase.autoStash true
This should go into the wiki page!
__
On 01 Nov 2016, at 09:57 , Rainer Müller wrote:
>
> I do not see valid reasons not to use hub.
+1
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
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 helpful in some cases.
Opened a ticket for this: https://trac.macports.org/tick
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 wi
On 01 Nov 2016, at 04:00 , Ryan Schmidt wrote:
> We suggest that you move your user repository to your own GitHub account
> where you can continue to use it as you see fit. Instructions for how to move
> it are forthcoming. You should not use the Fork button to do so.
Can I simply remove it?
__
Hi Mojca and Ryan,
On 01 Nov 2016, at 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 MP.
I am with you here! Port hub is
58 matches
Mail list logo
