Re: Working with Git

[Mojca Miklavec]

On 31 October 2016 at 16:35, Daniel J. Luke wrote:
> On Oct 31, 2016, at 11:29 AM, Ryan Schmidt wrote:
>>
>> One of the suggestions in this thread was to use the "hub" wrapper around 
>> git. Based on the fact that their homepage only mentions how to install hub 
>> with Homebrew, and that they have twice refused [1] to acknowledge on their 
>> web page that hub can also be installed with MacPorts, I am uncomfortable 
>> referring users to their web page, and I suggest that we do not mention 
>> "hub" in our page.
>
> while that's super-silly of the 'hub' author, I don't think we need to 
> retaliate by not using or recommending the software if it's useful.

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 with the software and file
a bug report, they might get an equally annoying answer saying
"Install Homebrew, I don't support MP". I had a problem with one
particular project in the past that a typical answer to any bug report
I filed was "stop using MacPorts, it's obviously broken" when in 90%
of the cases it was their bug that just showed up when using certain
newer dependencies or a particular set of configure flags they never
tested.

I would understand not accepting a complex patch for the sake of
supporting some legacy system, but not such a strong attitude against
adding one line to the documentation.

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.

Disclaimer: I have no clue how useful the software is, I've never
tested it myself.

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

Re: GitHub migration complete

[Ryan Schmidt]

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-user-".

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.



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

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

[David Strubbe]

I just wanted to try out the new git setup to make sure things were working
for me, and this was a simple little thing to do.

On Mon, Oct 31, 2016 at 7:10 PM, Brandon Allbery 
wrote:

>
> On Mon, Oct 31, 2016 at 10:05 PM, Lawrence Velázquez 
> wrote:
>
>> new 8ed388e berkeleygw: Remove svn $Id$ line.
>
>
> btw, given that it's not being automated because of the unnecessary builds
> it would trigger, I would say don't bother making commits that *only*
> remove the Id line. It's not harmful; it's just irrelevant with git. Just
> remember to remove the line as part of the next update you make.
>
> --
> brandon s allbery kf8nh   sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Brandon Allbery]

On Mon, Oct 31, 2016 at 10:05 PM, Lawrence Velázquez 
wrote:

> new 8ed388e berkeleygw: Remove svn $Id$ line.


btw, given that it's not being automated because of the unnecessary builds
it would trigger, I would say don't bother making commits that *only*
remove the Id line. It's not harmful; it's just irrelevant with git. Just
remember to remove the line as part of the next update you make.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[David Strubbe]

Thanks, yes I just realized I hadn't set that up.

David

On Mon, Oct 31, 2016 at 7:05 PM, Lawrence Velázquez 
wrote:

> 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/
> 8ed388e541ce01d92d698791fefd72a4bd2448c9
>
> The following commit(s) were added to refs/heads/master by this push: new 
> 8ed388e  berkeleygw: Remove svn $Id$ line.8ed388e is described below
> commit 8ed388e541ce01d92d698791fefd72a4bd2448c9Author: David Strubbe 
> 
> AuthorDate: Mon Oct 31 18:48:04 2016 -0700
> berkeleygw: Remove svn $Id$ line.---
>  science/berkeleygw/Portfile | 1 -
>  1 file changed, 1 deletion(-)
> diff --git a/science/berkeleygw/Portfile b/science/berkeleygw/Portfileindex 
> 0a82359..9f495ea 100644--- a/science/berkeleygw/Portfile+++ 
> b/science/berkeleygw/Portfile@@ -1,5 +1,4 @@ # -*- coding: utf-8; mode: tcl; 
> tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- 
> vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4-# $Id$
>  PortSystem  1.0
>  PortGroup   mpi 1.0
>
> ___
> macports-changes mailing list
> macports-chan...@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-changes
>
>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Lawrence Velázquez]

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/8ed388e541ce01d92d698791fefd72a4bd2448c9
>  
> 
> The following commit(s) were added to refs/heads/master by this push:
>  new 8ed388e  berkeleygw: Remove svn $Id$ line.
> 8ed388e is described below
> 
> commit 8ed388e541ce01d92d698791fefd72a4bd2448c9
> Author: David Strubbe 
> AuthorDate: Mon Oct 31 18:48:04 2016 -0700
> 
> berkeleygw: Remove svn $Id$ line.
> ---
>  science/berkeleygw/Portfile | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/science/berkeleygw/Portfile b/science/berkeleygw/Portfile
> index 0a82359..9f495ea 100644
> --- a/science/berkeleygw/Portfile
> +++ b/science/berkeleygw/Portfile
> @@ -1,5 +1,4 @@
>  # -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; 
> c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
> -# $Id$
>  
>  PortSystem  1.0
>  PortGroup   mpi 1.0
> 
> ___
> macports-changes mailing list
> macports-chan...@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-changes

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

Re: Removing "$Id$" lines

[Rainer Müller]

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 20,000 builds per
> builder is much more than we've ever attempted before and I think it
> would not be happy about it. At the very least, I would want to wait
> until I've switched the buildbot from SQLite to PostgreSQL.

Can we maybe decide on special commands in commit messages that cause
the buildbot to completely ignore the commit? Such things should not
limit us to what we can commit or not.

Perhaps a footer line (similar to Signed-off-by) at the end, such as:

buildbot: ignore


For reference, other services seem to use "[ci skip]" as a keyword that
can appear anywhere in the commit message.

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

Re: Removing "$Id$" lines

[Dan Ports]

On Mon, Oct 31, 2016 at 07:03:24PM -0500, 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 per builder is 
> much more than we've ever attempted before and I think it would not be happy 
> about it. At the very least, I would want to wait until I've switched the 
> buildbot from SQLite to PostgreSQL.
> 
> Please, for now, just make this change together with other necessary changes. 

That's what I was wondering about. I'll wait.

Dan

-- 
Dan R. K. PortsUW CSEhttps://drkp.net/
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: GitHub desired workflow...

[Brandon Allbery]

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


On Mon, Oct 31, 2016 at 7:08 PM, Eric A. Borisch 
wrote:

> I hoped someone would point me to a command like this. Thanks!
>
>   - Eric
>
> On Monday, October 31, 2016, Joshua Root  wrote:
>>
>> I'm using 'git pull --rebase --autostash' which does the stash-before and
>> pop-after automatically.
>>
>> - Josh
>>
>
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
>


-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Removing "$Id$" lines

[Ryan Schmidt]

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 per builder is much 
more than we've ever attempted before and I think it would not be happy about 
it. At the very least, I would want to wait until I've switched the buildbot 
from SQLite to PostgreSQL.

Please, for now, just make this change together with other necessary changes. 


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

Re: GitHub desired workflow...

[Eric A. Borisch]

I hoped someone would point me to a command like this. Thanks!

  - Eric

On Monday, October 31, 2016, Joshua Root  wrote:
>
> I'm using 'git pull --rebase --autostash' which does the stash-before and
> pop-after automatically.
>
> - Josh
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: GitHub desired workflow...

[Joshua Root]

On 2016-11-1 09:21 , Lawrence Velázquez wrote:

The only downside of running "portindex" manually
is that you have to pass the location of the ports tree as an argument.


Or cd there first. If you're working on a ports tree you'll often be in 
the right place already.


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

Re: Removing "$Id$" lines

[Lawrence Velázquez]

> 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/listinfo/macports-dev

Re: GitHub desired workflow...

[Lawrence Velázquez]

> 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 add/remove a
>> port? Why does 'port sync' call at all what the state is?
> 
> Updating the repository is the whole point of "port sync".

That's not to say "port sync" couldn't be smarter about it, obviously.
The Git functionality was implemented in a very straightforward way,
back when just a few people used git-svn or Mac OS Forge's Git mirrors.

But yeah, it's a layer-cake sort of thing. "port selfupdate" updates
base and does a sync. "port sync" updates the ports tree and reindexes.
"portindex"…indexes. The only downside of running "portindex" manually
is that you have to pass the location of the ports tree as an argument.

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

Re: Removing "$Id$" lines

[Dan Ports]

Any reason not to just bulk-remove them all at once?

Dan

On Mon, Oct 31, 2016 at 05:30:07PM -0400, Lawrence Velázquez wrote:
> 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/eee819a1785e92bd2824517c0aff6ee855837c12
> >  
> > 
> > The following commit(s) were added to refs/heads/master by this push:
> >  new eee819a  libpcap: update to version 1.8.1.
> > eee819a is described below
> > 
> > commit eee819a1785e92bd2824517c0aff6ee855837c12
> > Author: Marius Schamschula 
> > AuthorDate: Mon Oct 31 16:16:22 2016 -0500
> > 
> > libpcap: update to version 1.8.1.
> > ---
> >  net/libpcap/Portfile | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/net/libpcap/Portfile b/net/libpcap/Portfile
> > index 6b8eb0d..201f2bd 100644
> > --- a/net/libpcap/Portfile
> > +++ b/net/libpcap/Portfile
> > @@ -1,10 +1,10 @@
> >  # -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; 
> > c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
> > -# $Id$
> > +# $Id: Portfile 152274 2016-09-02 11:03:02Z m...@macports.org $
> >  
> >  PortSystem  1.0
> >  
> >  namelibpcap
> > -version 1.8.0
> > +version 1.8.1
> >  categories  net
> >  maintainers mps openmaintainer
> >  license BSD
> > @@ -17,8 +17,8 @@ homepagehttp://www.tcpdump.org/
> >  platforms   darwin
> >  master_sites${homepage}release/
> >  
> > -checksums   rmd160  4cfef07ac9f008b329c00bf0ebbe547f6738f2eb \
> > -sha256  
> > f47b51533f9f060afb304010ea5cbf51d032707333bca70c36351d255754659c
> > +checksums   rmd160  295766ab2646c05c330aa04cabc30c5737200279 \
> > +sha256  
> > 673dbc69fdc3f5a86fb5759ab19899039a8e5e6c631749e48dcd9c6f0c83541e
> >  
> >  configure.args  --disable-bluetooth \
> >  --disable-canusb \
> 

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


-- 
Dan R. K. PortsUW CSEhttps://drkp.net/
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [macports-ports] branch master updated: jasper: needs a revbump

[Marko Käning]

So, now I ran *again* into a problem with my local install after self updating 
it just now:
---
$ port -v rev-upgrade
--->  Scanning binaries for linking errors
Warning: Error parsing file /opt/local/bin/cdda2wav: Error opening or reading 
file
Warning: Error parsing file /opt/local/bin/cdrecord: Error opening or reading 
file
Warning: Error parsing file /opt/local/bin/readcd: Error opening or reading file
Warning: Error parsing file /opt/local/sbin/rscsi: Error opening or reading file
Warning: Error parsing file /opt/local/libexec/dbus-daemon-launch-helper: Error 
opening or reading file
Incompatible library version: /opt/local/bin/imgcmp requires version 12.0.0 or 
later, but /opt/local/lib/libjpeg.9.dylib provides version 11.0.0
Incompatible library version: /opt/local/bin/imginfo requires version 12.0.0 or 
later, but /opt/local/lib/libjpeg.9.dylib provides version 11.0.0
Incompatible library version: /opt/local/bin/jasper requires version 12.0.0 or 
later, but /opt/local/lib/libjpeg.9.dylib provides version 11.0.0
Incompatible library version: /opt/local/bin/tmrdemo requires version 12.0.0 or 
later, but /opt/local/lib/libjpeg.9.dylib provides version 11.0.0
Incompatible library version: /opt/local/lib/libjasper.1.dylib requires version 
12.0.0 or later, but /opt/local/lib/libjpeg.9.dylib provides version 11.0.0
--->  Found 5 broken file(s), matching files to ports
--->  Found 1 broken port(s):
 jasper @1.900.16 
 /opt/local/bin/imgcmp
 /opt/local/bin/imginfo
 /opt/local/bin/jasper
 /opt/local/bin/tmrdemo
 /opt/local/lib/libjasper.1.dylib
---

So, obviously, my own setup is borked. Turns out I have an older jpeg in my 
ports tree
---
$ port dir jpeg
/Users/marko/WC/GIT/macstrop/graphics/jpeg
---
which is the cause of trouble here.

I am sorry for rev-bumping! Not the first time that this happens to me. I have 
to become more careful!!!
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: GitHub desired workflow...

[Sean Farley]

Lawrence Velázquez  writes:

>> 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 whole point of "port sync". If you just
> want to refresh your portindex, you should be running "portindex
> /path/to/ports/tree".

Alrighty then. I'll change my alias.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: GitHub desired workflow...

[Joshua Root]

On 2016-11-1 08:46 , Lawrence Velázquez wrote:

On Oct 31, 2016, at 5:01 PM, Eric A. Borisch  wrote:

5) 'push' changes (to macports-ports)

Oh, and and to capture upstream changes, somewhere after 1 and before
5 (4? 3?),

a) git fetch
b) git rebase origin/master
It looks like git pull --rebase does both of those, so that's not too
bad.


That's the idea, although you'll have to do this with a clean working
tree. That means committing or stashing your WIPs.


I'm using 'git pull --rebase --autostash' which does the stash-before 
and pop-after automatically.


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

Re: Working with Git

[Sean Farley]

Ryan Schmidt  writes:

> I don't want to understand git's theory or to be given lots of options 
> amongst which to choose; I just want to be told how to get my work done.

I had a thoroughly good chuckle reading this. It is the number one sin
of the design of git, IMHO.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: GitHub desired workflow...

[Lawrence Velázquez]

> 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 whole point of "port sync". If you just
want to refresh your portindex, you should be running "portindex
/path/to/ports/tree".

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

Re: GitHub desired workflow...

[Sean Farley]

"Eric A. Borisch"  writes:

> Thanks for all the hard work with this transition! I'm sure once we're all
> "over the hump" we'll look back and wonder why we waited so long.
>
> 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
> == every change ==
> 2) make changes
> 3) 'add' changes
> 4) 'commit' changes
> 5) 'push' changes (to macports-ports)
>
> Oh, and and to capture upstream changes, somewhere after 1 and before 5 (4?
> 3?),
>
> a) git fetch
> b) git rebase origin/master
> It looks like git pull --rebase does both of those, so that's not too bad.

I've noticed that when I do this and I run 'port sync', macports
apparently tries to rebase? 9 times out of 10 I wind up in a detached
head state.

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?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: GitHub desired workflow...

[Lawrence Velázquez]

> 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 that
> accidentally.

That is to say, you don't have to worry about accidentally
force-pushing. You still have to avoid pushing merge commits.

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

Re: GitHub desired workflow...

[Lawrence Velázquez]

> 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 commits. It's not the end of the world if you forget, but
the shorter our .mailmap files are, the better.

> == every change ==
> 2) make changes
> 3) 'add' changes
> 4) 'commit' changes

More or less. 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 that accidentally.

> 5) 'push' changes (to macports-ports)
> 
> Oh, and and to capture upstream changes, somewhere after 1 and before
> 5 (4? 3?),
> 
> a) git fetch
> b) git rebase origin/master
> It looks like git pull --rebase does both of those, so that's not too
> bad.

That's the idea, although you'll have to do this with a clean working
tree. That means committing or stashing your WIPs.

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

Re: Removing "$Id$" lines

[Marius Schamschula]

Larry,

OK. Will do.

On Oct 31, 2016, at 4:30 PM, Lawrence Velázquez  wrote:

> 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/eee819a1785e92bd2824517c0aff6ee855837c12
>> 
>> The following commit(s) were added to refs/heads/master by this push:
>>  new eee819a  libpcap: update to version 1.8.1.
>> eee819a is described below
>> 
>> commit eee819a1785e92bd2824517c0aff6ee855837c12
>> Author: Marius Schamschula 
>> AuthorDate: Mon Oct 31 16:16:22 2016 -0500
>> 
>> libpcap: update to version 1.8.1.
>> ---
>>  net/libpcap/Portfile | 8 
>>  1 file changed, 4 insertions(+), 4 deletions(-)
>> 
>> diff --git a/net/libpcap/Portfile b/net/libpcap/Portfile
>> index 6b8eb0d..201f2bd 100644
>> --- a/net/libpcap/Portfile
>> +++ b/net/libpcap/Portfile
>> @@ -1,10 +1,10 @@
>>  # -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; 
>> c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
>> -# $Id$
>> +# $Id: Portfile 152274 2016-09-02 11:03:02Z m...@macports.org $
>>  
>>  PortSystem  1.0
>>  
>>  namelibpcap
>> -version 1.8.0
>> +version 1.8.1
>>  categories  net
>>  maintainers mps openmaintainer
>>  license BSD
>> @@ -17,8 +17,8 @@ homepagehttp://www.tcpdump.org/
>>  platforms   darwin
>>  master_sites${homepage}release/
>>  
>> -checksums   rmd160  4cfef07ac9f008b329c00bf0ebbe547f6738f2eb \
>> -sha256  
>> f47b51533f9f060afb304010ea5cbf51d032707333bca70c36351d255754659c
>> +checksums   rmd160  295766ab2646c05c330aa04cabc30c5737200279 \
>> +sha256  
>> 673dbc69fdc3f5a86fb5759ab19899039a8e5e6c631749e48dcd9c6f0c83541e
>>  
>>  configure.args  --disable-bluetooth \
>>  --disable-canusb \
> 
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev

Marius
--
Marius Schamschula




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

Removing "$Id$" lines

[Lawrence Velázquez]

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/eee819a1785e92bd2824517c0aff6ee855837c12
>  
> 
> The following commit(s) were added to refs/heads/master by this push:
>  new eee819a  libpcap: update to version 1.8.1.
> eee819a is described below
> 
> commit eee819a1785e92bd2824517c0aff6ee855837c12
> Author: Marius Schamschula 
> AuthorDate: Mon Oct 31 16:16:22 2016 -0500
> 
> libpcap: update to version 1.8.1.
> ---
>  net/libpcap/Portfile | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/net/libpcap/Portfile b/net/libpcap/Portfile
> index 6b8eb0d..201f2bd 100644
> --- a/net/libpcap/Portfile
> +++ b/net/libpcap/Portfile
> @@ -1,10 +1,10 @@
>  # -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; 
> c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
> -# $Id$
> +# $Id: Portfile 152274 2016-09-02 11:03:02Z m...@macports.org $
>  
>  PortSystem  1.0
>  
>  namelibpcap
> -version 1.8.0
> +version 1.8.1
>  categories  net
>  maintainers mps openmaintainer
>  license BSD
> @@ -17,8 +17,8 @@ homepagehttp://www.tcpdump.org/
>  platforms   darwin
>  master_sites${homepage}release/
>  
> -checksums   rmd160  4cfef07ac9f008b329c00bf0ebbe547f6738f2eb \
> -sha256  
> f47b51533f9f060afb304010ea5cbf51d032707333bca70c36351d255754659c
> +checksums   rmd160  295766ab2646c05c330aa04cabc30c5737200279 \
> +sha256  
> 673dbc69fdc3f5a86fb5759ab19899039a8e5e6c631749e48dcd9c6f0c83541e
>  
>  configure.args  --disable-bluetooth \
>  --disable-canusb \

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

Re: GitHub desired workflow...

[Jeremy Lavergne]

You can `pull -r` immediately before pushing. Conveniently, you can
configure pull to autorebase. Either way, the simplest modification to
your last step is this:

git pull -r && git push


On 10/31/2016 05:01 PM, Eric A. Borisch wrote:
> Thanks for all the hard work with this transition! I'm sure once we're
> all "over the hump" we'll look back and wonder why we waited so long.
> 
> 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
> == every change ==
> 2) make changes
> 3) 'add' changes
> 4) 'commit' changes
> 5) 'push' changes (to macports-ports)
> 
> Oh, and and to capture upstream changes, somewhere after 1 and before 5
> (4? 3?),
> 
> a) git fetch
> b) git rebase origin/master
> It looks like git pull --rebase does both of those, so that's not too bad.
> 
> If I'm wrong, or if I've missed something, please let me know; there's
> been more discussion than I've had time to follow of late surrounding
> this transition...
> 

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

GitHub desired workflow...

[Eric A. Borisch]

Thanks for all the hard work with this transition! I'm sure once we're all
"over the hump" we'll look back and wonder why we waited so long.

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
== every change ==
2) make changes
3) 'add' changes
4) 'commit' changes
5) 'push' changes (to macports-ports)

Oh, and and to capture upstream changes, somewhere after 1 and before 5 (4?
3?),

a) git fetch
b) git rebase origin/master
It looks like git pull --rebase does both of those, so that's not too bad.

If I'm wrong, or if I've missed something, please let me know; there's been
more discussion than I've had time to follow of late surrounding this
transition...

  - Eric

"Linux is like if the creator of git wrote an operating system." -
SwiftOnSecurity
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [macports-ports] branch master updated: jasper: needs a revbump

[Clemens Lang]

On Mon, Oct 31, 2016 at 08:08:26PM +0100, Marko Käning wrote:
> Doesn’t the second build of jasper justify the revbump, or should we
> simply ignore this and let rev-upgrade take care of it??

The revbump is justified. Your commit message should have mentioned why
it was necessary, though.

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

Re: GitHub migration complete

[Marko Käning]

On 31 Oct 2016, at 21:14 , Lawrence Velázquez  wrote:

>> 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 free to assign me as owner; I'll try to look into it 
> this week.

Thanks, done in https://trac.macports.org/ticket/52763#ticket .
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: GitHub migration complete

[Lawrence Velázquez]

> 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 free to assign me as owner; I'll try to look into it 
this week.

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

Re: [macports-ports] branch master updated: jasper: needs a revbump

[Joshua Root]

On 2016-11-1 06:34 , Marko Käning wrote:

On 31 Oct 2016, at 20:25 , Joshua Root  wrote:

Depends on the nature of the breakage, which is not shown above. The only 
dependency is jpeg, which has not changed in some time. My jasper installation 
is certainly not broken.


Hmmm…

OK, next time I need to get more detailed logs. Just don’t know how to get that 
done in the demoed workflow. :(


It would probably help to set:
revupgrade_mode report

Then if it finds anything, you can rerun with -v for details.


Maybe something else is being linked to, in which case simply rev bumping does 
not fix the problem. Or maybe something happened to your copy of jpeg that 
changed the soname, in which case that is the problem.


I don’t think I can do anything now there anymore.

Perhaps I better ask the list if I run into stg similar again and then we can 
decide together whether to revbump or not?


Tell me. That's what maintainers are for. :)

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

Re: [macports-ports] branch master updated: jasper: needs a revbump

[Marko Käning]

On 31 Oct 2016, at 20:25 , Joshua Root  wrote:
> Depends on the nature of the breakage, which is not shown above. The only 
> dependency is jpeg, which has not changed in some time. My jasper 
> installation is certainly not broken.

Hmmm…

OK, next time I need to get more detailed logs. Just don’t know how to get that 
done in the demoed workflow. :(


> Maybe something else is being linked to, in which case simply rev bumping 
> does not fix the problem. Or maybe something happened to your copy of jpeg 
> that changed the soname, in which case that is the problem.

I don’t think I can do anything now there anymore.

Perhaps I better ask the list if I run into stg similar again and then we can 
decide together whether to revbump or not?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: GitHub migration complete

[Lawrence Velázquez]

> 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 :
> 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 maintainers) that clones the git 
> repository. Most users will use the rsync server, on which we do generate 
> portindexes for each macOS version.
 
 Of course, but note how I used the word collective, which was supposed to 
 include the idea that portindex has to be run each time by every user. :)
 
>>> 
>>> I would actually believe the number of affected users should be between
>>> very small and zero.
>> 
>> Pretty much.
>> 
>> In any case, between the capabilities of Git itself and the facilities 
>> GitHub provides, I do not believe it is possible to do what you suggest.
> 
> You mean what René is suggesting?

Yes.

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

Re: [macports-ports] branch master updated: jasper: needs a revbump

[Joshua Root]

On 2016-11-1 06:08 , Marko Käning wrote:

Hi Joshua,

On 31 Oct 2016, at 18:04 , Joshua Root  wrote:

Why?


because I ran into this:
---
--->  Scanning binaries for linking errors
--->  Found 5 broken file(s), matching files to ports
--->  Found 1 broken port(s), determining rebuild order
--->  Rebuilding in order
 jasper @1.900.16



Doesn’t the second build of jasper justify the revbump, or should we simply 
ignore this and let rev-upgrade take care of it??


Depends on the nature of the breakage, which is not shown above. The 
only dependency is jpeg, which has not changed in some time. My jasper 
installation is certainly not broken.


Maybe something else is being linked to, in which case simply rev 
bumping does not fix the problem. Or maybe something happened to your 
copy of jpeg that changed the soname, in which case that is the problem.


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

Re: [macports-ports] branch master updated: jasper: needs a revbump

[Marko Käning]

Hi Joshua,

On 31 Oct 2016, at 18:04 , Joshua Root  wrote:
> Why?

because I ran into this:
---
$ port dir jasper
/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/graphics/jasper
$ sudo port upgrade outdated
--->  Computing dependencies for jasper
--->  Fetching archive for jasper
--->  Attempting to fetch jasper-1.900.16_0.darwin_13.x86_64.tbz2 from 
http://nue.de.packages.macports.org/jasper
--->  Attempting to fetch jasper-1.900.16_0.darwin_13.x86_64.tbz2.rmd160 from 
http://nue.de.packages.macports.org/jasper
--->  Installing jasper @1.900.16_0
--->  Cleaning jasper
--->  Computing dependencies for jasper
--->  Deactivating jasper @1.900.5_0
--->  Cleaning jasper
--->  Activating jasper @1.900.16_0
--->  Cleaning jasper
--->  Uninstalling jasper @1.900.5_0
--->  Cleaning jasper
--->  Computing dependencies for py27-pycparser
--->  Fetching archive for py27-pycparser
--->  Attempting to fetch py27-pycparser-2.17_0.darwin_13.noarch.tbz2 from 
http://nue.de.packages.macports.org/py27-pycparser
--->  Attempting to fetch py27-pycparser-2.17_0.darwin_13.noarch.tbz2.rmd160 
from http://nue.de.packages.macports.org/py27-pycparser
--->  Installing py27-pycparser @2.17_0
--->  Cleaning py27-pycparser
--->  Computing dependencies for py27-pycparser
--->  Deactivating py27-pycparser @2.16_1
--->  Cleaning py27-pycparser
--->  Activating py27-pycparser @2.17_0
--->  Cleaning py27-pycparser
--->  Uninstalling py27-pycparser @2.16_1
--->  Cleaning py27-pycparser
--->  Computing dependencies for py27-setuptools
--->  Fetching archive for py27-setuptools
--->  Attempting to fetch py27-setuptools-28.7.0_0.darwin_13.noarch.tbz2 from 
http://nue.de.packages.macports.org/py27-setuptools
--->  Attempting to fetch py27-setuptools-28.7.0_0.darwin_13.noarch.tbz2.rmd160 
from http://nue.de.packages.macports.org/py27-setuptools
--->  Installing py27-setuptools @28.7.0_0
--->  Cleaning py27-setuptools
--->  Computing dependencies for py27-setuptools
--->  Deactivating py27-setuptools @28.5.0_0
--->  Cleaning py27-setuptools
--->  Activating py27-setuptools @28.7.0_0
--->  Cleaning py27-setuptools
--->  Uninstalling py27-setuptools @28.5.0_0
--->  Cleaning py27-setuptools
--->  Computing dependencies for py34-setuptools
--->  Fetching archive for py34-setuptools
--->  Attempting to fetch py34-setuptools-28.7.0_0.darwin_13.noarch.tbz2 from 
http://nue.de.packages.macports.org/py34-setuptools
--->  Attempting to fetch py34-setuptools-28.7.0_0.darwin_13.noarch.tbz2.rmd160 
from http://nue.de.packages.macports.org/py34-setuptools
--->  Installing py34-setuptools @28.7.0_0
--->  Cleaning py34-setuptools
--->  Computing dependencies for py34-setuptools
--->  Deactivating py34-setuptools @28.5.0_0
--->  Cleaning py34-setuptools
--->  Activating py34-setuptools @28.7.0_0
--->  Cleaning py34-setuptools
--->  Uninstalling py34-setuptools @28.5.0_0
--->  Cleaning py34-setuptools
--->  Computing dependencies for py35-setuptools
--->  Fetching archive for py35-setuptools
--->  Attempting to fetch py35-setuptools-28.7.0_0.darwin_13.noarch.tbz2 from 
http://nue.de.packages.macports.org/py35-setuptools
--->  Attempting to fetch py35-setuptools-28.7.0_0.darwin_13.noarch.tbz2.rmd160 
from http://nue.de.packages.macports.org/py35-setuptools
--->  Installing py35-setuptools @28.7.0_0
--->  Cleaning py35-setuptools
--->  Computing dependencies for py35-setuptools
--->  Deactivating py35-setuptools @28.5.0_0
--->  Cleaning py35-setuptools
--->  Activating py35-setuptools @28.7.0_0
--->  Cleaning py35-setuptools
--->  Uninstalling py35-setuptools @28.5.0_0
--->  Cleaning py35-setuptools
--->  Updating database of binaries
--->  Scanning binaries for linking errors
--->  Found 5 broken file(s), matching files to ports
--->  Found 1 broken port(s), determining rebuild order
--->  Rebuilding in order
 jasper @1.900.16 
--->  Computing dependencies for jasper
--->  Cleaning jasper
--->  Scanning binaries for linking errors
--->  Found 5 broken file(s), matching files to ports
--->  Found 1 broken port(s), determining rebuild order
--->  Rebuilding in order
 jasper @1.900.16 
--->  Computing dependencies for jasper
--->  Fetching distfiles for jasper
--->  Attempting to fetch jasper-1.900.16.tar.gz from 
http://nue.de.distfiles.macports.org/jasper
--->  Attempting to fetch jasper-1.900.16.tar.gz from 
https://distfiles.macports.org/jasper
--->  Attempting to fetch jasper-1.900.16.tar.gz from 
http://lil.fr.distfiles.macports.org/jasper
--->  Attempting to fetch jasper-1.900.16.tar.gz from 
http://mse.uk.distfiles.macports.org/sites/distfiles.macports.org/jasper
--->  Attempting to fetch jasper-1.900.16.tar.gz from 
http://osl.no.distfiles.macports.org/jasper
--->  Attempting to fetch jasper-1.900.16.tar.gz from 
http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/jasper
--->  Attempting to fetch jasper-1.900.16.tar.gz from 
http://ykf.ca.distfiles.macports.org/MacPorts/mpdistfiles/jasper
--->  Attempting t

Re: GitHub migration complete

[Thibaut Paumard]

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 :
 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 maintainers) that clones the git 
 repository. Most users will use the rsync server, on which we do generate 
 portindexes for each macOS version.
>>>
>>> Of course, but note how I used the word collective, which was supposed to 
>>> include the idea that portindex has to be run each time by every user. :)
>>>
>>
>> I would actually believe the number of affected users should be between
>> very small and zero.
> 
> Pretty much.
> 
> In any case, between the capabilities of Git itself and the facilities GitHub 
> provides, I do not believe it is possible to do what you suggest.

You mean what René is suggesting?

What *I* am suggesting (and that is not in the text you quoted) has very
little to do with git. Running portindex somewhere after pulling from
git is easily done with a post-merge hook, but that's barely relevant.

Regards, Thibaut.


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

Re: Working with Git

[Lawrence Velázquez]

> 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 rebase is successful, you'll automatically end up in
this branch and won't have to check it out yourself.

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

[macports-ports] branch master updated: jasper: needs a revbump

[Joshua Root]

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

Re: Working with Git

[Lawrence Velázquez]

> 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, and 
>> they can push another commit to the same branch they made to initiate the 
>> pull request, and those new commits will automatically appear in the pull 
>> request, and I can then merge it if I like it. But what if the user does not 
>> respond and fix the changes? What if the user makes additional commits but 
>> they're still not sufficient? How do I take the user's pull request, make 
>> additional changes, and commit them to our master?
> 
> There were several different and sometimes conflicting answers to this 
> question in this thread. Now that we have converted to git, and I have 
> received a pull request for one of my ports, I need to know how to test it 
> locally and then commit it to master. I don't want to understand git's theory 
> or to be given lots of options amongst which to choose; I just want to be 
> told how to get my work done.

Here are some rough instructions. These will have to be refined; let me
know if you have any problems. I'm writing this in a bit of
a sleep-deprived fog.

To the right of the big green "Rebase and merge" button on the PR page,
you should see a link to view "command line instructions". Those
instructions are almost what you want, but you'll have to tweak them to
avoid merge commits.

To obtain the submitter's changes:

$ git fetch https://github.com/l2dy/macports-ports.git 
curl-ca-bundle-update
$ git checkout -b l2dy-curl-ca-bundle-update FETCH_HEAD
$ git rebase master l2dy-curl-ca-bundle-update

The first command imports changes from the submitter's
"curl-ca-bundle-update" branch. The second command creates a new local
branch to match. The third command transplants the submitter's changes
onto the top of your master branch. (Rebasing will fail if the
submitter's changes don't apply cleanly to the current ports tree. You
can just ask them to fix this themselves and push a new branch.)

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

When you're ready to push the submitter's contributions to master:

$ git checkout master
$ git merge --ff-only l2dy-curl-ca-bundle-update
$ git push origin master

The first two commands incorporate the submitter's changes into your
master branch. The last one pushes to GitHub.

> Could someone please update the WorkingWithGit page with the correct 
> instructions?

Yes, I will polish up that page this week, as well as the migration FAQ.

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

Re: GitHub migration complete

[Lawrence Velázquez]

> 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 maintainers) that clones the git 
>>> repository. Most users will use the rsync server, on which we do generate 
>>> portindexes for each macOS version.
>> 
>> Of course, but note how I used the word collective, which was supposed to 
>> include the idea that portindex has to be run each time by every user. :)
>> 
> 
> I would actually believe the number of affected users should be between
> very small and zero.

Pretty much.

In any case, between the capabilities of Git itself and the facilities GitHub 
provides, I do not believe it is possible to do what you suggest.

vq
Sent from my iPhone
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: GitHub migration complete

[Thibaut Paumard]

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 maintainers) that clones the git 
>> repository. Most users will use the rsync server, on which we do generate 
>> portindexes for each macOS version.
> 
> Of course, but note how I used the word collective, which was supposed to 
> include the idea that portindex has to be run each time by every user. :)
> 

Hi,

I would actually believe the number of affected users should be between
very small and zero.

I personally never run portindex on the full port tree: I have a very
small development tree in which I keep symlinks only to the ports that I
am currently developing, and I run portindex on this tiny subset. For
the rest, I trust rsync. I'm wondering whether I got the hint from some
macports cookbook, but I think not.

Such a workflow should work for most maintainers, and should scale
fairly well also for very active developers.

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

Re: GitHub migration complete

[René J . V . Bertin]

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 maintainers) that clones the git 
> repository. Most users will use the rsync server, on which we do generate 
> portindexes for each macOS version.

Of course, but note how I used the word collective, which was supposed to 
include the idea that portindex has to be run each time by every user. :)

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

Re: Working with Git

[Daniel J. Luke]

On Oct 31, 2016, at 11:29 AM, Ryan Schmidt  wrote:
> I just want to be told how to get my work done.

+1 for having a 'CheatSheet' of some sort

We did this at $WORK when moving from one system to another, and it's always 
been helpful.

> One of the suggestions in this thread was to use the "hub" wrapper around 
> git. Based on the fact that their homepage only mentions how to install hub 
> with Homebrew, and that they have twice refused [1] to acknowledge on their 
> web page that hub can also be installed with MacPorts, I am uncomfortable 
> referring users to their web page, and I suggest that we do not mention "hub" 
> in our page.

while that's super-silly of the 'hub' author, I don't think we need to 
retaliate by not using or recommending the software if it's useful.

-- 
Daniel J. Luke



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

Re: Working with Git

[Ryan Schmidt]

> 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, and they 
> can push another commit to the same branch they made to initiate the pull 
> request, and those new commits will automatically appear in the pull request, 
> and I can then merge it if I like it. But what if the user does not respond 
> and fix the changes? What if the user makes additional commits but they're 
> still not sufficient? How do I take the user's pull request, make additional 
> changes, and commit them to our master?

There were several different and sometimes conflicting answers to this question 
in this thread. Now that we have converted to git, and I have received a pull 
request for one of my ports, I need to know how to test it locally and then 
commit it to master. I don't want to understand git's theory or to be given 
lots of options amongst which to choose; I just want to be told how to get my 
work done. Could someone please update the WorkingWithGit page with the correct 
instructions?

One of the suggestions in this thread was to use the "hub" wrapper around git. 
Based on the fact that their homepage only mentions how to install hub with 
Homebrew, and that they have twice refused [1] to acknowledge on their web page 
that hub can also be installed with MacPorts, I am uncomfortable referring 
users to their web page, and I suggest that we do not mention "hub" in our page.


[1] https://github.com/github/hub/pulls?utf8=✓&q=is%3Apr%20macports

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

Re: GitHub migration complete

[Ryan Schmidt]

> On Oct 31, 2016, at 4:18 AM, René J. V. Bertin  wrote:
> 
> Clemens Lang wrote:
> 
>> If your question is not yet answered, ask on the mailing lists so it can
>> be added.
> 
> I may have overlooked this, but does github have any provisions that would 
> allow 
> the PortIndex files to be generated on the server and served with the actual 
> repo 
> contents? That would probably give a very significant reduction in the 
> resources 
> spent collectively to regenerate those files...

This issue only affects the very small percentage of the MacPorts user 
population (including developers and maintainers) that clones the git 
repository. Most users will use the rsync server, on which we do generate 
portindexes for each macOS version.

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

Re: GitHub migration complete

[Lawrence Velázquez]

> 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 running 10.12 on a 32bit host? Is that even possible?)

The portindices are based on platform, not architecture. There are
indices for Intel and (for Tiger and Leopard) PowerPC.

-

% rsync 'rsync://rsync.macports.org/macports/release/ports/PortIndex*'

Willkommen auf dem RSYNC-server auf ftp.fau.de.
Nicht all unsere Mirror sind per rsync verfuegbar.

Welcome to the RSYNC daemon on ftp.fau.de.
Not all of our mirrors are available through rsync.


-rw-r--r-- 11,985,357 2016/10/31 08:31:49 PortIndex
-rw-r--r--509,450 2016/10/31 08:31:49 PortIndex.quick
drwxr-xr-x  4,096 2016/10/31 09:01:42 PortIndex_darwin_10_i386
drwxr-xr-x  4,096 2016/10/31 09:01:45 PortIndex_darwin_11_i386
drwxr-xr-x  4,096 2016/10/31 09:01:48 PortIndex_darwin_12_i386
drwxr-xr-x  4,096 2016/10/31 09:01:50 PortIndex_darwin_13_i386
drwxr-xr-x  4,096 2016/10/31 09:01:53 PortIndex_darwin_14_i386
drwxr-xr-x  4,096 2016/10/31 09:01:55 PortIndex_darwin_15_i386
drwxr-xr-x  4,096 2016/10/31 09:01:57 PortIndex_darwin_16_i386
drwxr-xr-x  4,096 2016/10/31 09:01:35 PortIndex_darwin_8_i386
drwxr-xr-x  4,096 2016/10/31 09:01:32 PortIndex_darwin_8_powerpc
drwxr-xr-x  4,096 2016/10/31 09:01:40 PortIndex_darwin_9_i386
drwxr-xr-x  4,096 2016/10/31 09:01:37 PortIndex_darwin_9_powerpc

-

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

Re: GitHub migration complete

[René J . V . Bertin]

On Monday October 31 2016 11:52:28 Rainer Müller wrote:

>Just as with Subversion.

Yeah, I wouldn't expect that the SVC type had any influence on this.

>  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 running 10.12 on a 32bit host? Is that even possible?)

>Just make sure you use the correct OS version in the rsync path. There
>is also no guarantee that this really matches the git ports tree, which
>might already contain newer Portfile changes.

That should just mean more ports will be indexed, no?

A related question: what happens if you run portindex on a fresh clone on one 
host, and then rsync the whole tree to another host with a different OS 
version? I just did that transfer; using rsync with compression (-z) it took 
much less time (48s ...) than even simply checking out the tree from git on the 
other host. Just running portindex on the transferred tree without -f didn't do 
anything so apparently it doesn't check for OS version or platform mismatches?

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

Re: GitHub migration complete

[Rainer Müller]

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:

  rsync -vt 
rsync://rsync.macports.org/macports/release/ports/PortIndex_darwin_16_i386/PortIndex*
 $ports

Just make sure you use the correct OS version in the rsync path. There
is also no guarantee that this really matches the git ports tree, which
might already contain newer Portfile changes.

Rainer

PS: On purpose not sending this to macports-users, as it should not be
used in the general case.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: GitHub migration complete

[René J . V . Bertin]

On Monday October 31 2016 10:49:55 Clemens Lang wrote:

Hi,

>Just as with Subversion, the answer is no. Remember that the PortIndex
>is specific to the macOS version you are running, so a server-generated

Ah, of course. I didn't actually know this but indeed port versions could be 
specific to OS version or platform even if no other specific information is 
stored.
Sorry for the noise.

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

>Additionally, git does not preserve timestamps from the repository on
>checkout, so you might actually end up re-generating the index locally
>anyway.

I think that wouldn't (or shouldn't) happen as the timestamp would be newer. 
And of course the auto-regeneration could be deactivated if the server always 
serves an up-to-date index.

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

Re: CC maintainer on GitHub

[Rainer Müller]

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 handle to
a GitHub username.

> If mentioning is correct I suggest that we use mention-bot [0] to
> automatically mention developers in PRs.
> 
> [0] https://github.com/facebook/mention-bot

A bot like this sounds like a good idea, but we would need custom rules
to specifically mention the maintainers.

Mentioning those who touched the file in the past will mostly hit those
that regularly committed patches from Trac, but not the maintainer.

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

Re: Moving to GitHub: Status Update, Action Required

[Clemens Lang]

Hi,

On Mon, Oct 31, 2016 at 10:25:33AM +0100, Davide Liessi wrote:
> I have just noticed in one of my GitHub repositories that in Settings
> -> Options there is a "Merge button" section that lets you
> enable/disable the behaviours of the merge button described in the
> above link.
> Maybe you could leave only "Allow rebase merging" enabled and disable
> the rest.

We already did this, but thanks for the pointer.

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

Re: GitHub migration complete

[Clemens Lang]

Hi,

On Mon, Oct 31, 2016 at 10:18:42AM +0100, René J.  V. Bertin wrote:
> I may have overlooked this, but does github have any provisions that
> would allow the PortIndex files to be generated on the server and
> served with the actual repo contents? That would probably give a very
> significant reduction in the resources spent collectively to
> regenerate those files...

Just as with Subversion, the answer is no. Remember that the PortIndex
is specific to the macOS version you are running, so a server-generated
PortIndex could only generate all of them into different files.

Additionally, git does not preserve timestamps from the repository on
checkout, so you might actually end up re-generating the index locally
anyway.

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

CC maintainer on GitHub

[Zero King]

I just submitted a PR on GitHub and the wiki didn't say how to CC the 
maintainer. Should I use mention like @ryandesign?


If mentioning is correct I suggest that we use mention-bot [0] to 
automatically mention developers in PRs.


[0] https://github.com/facebook/mention-bot

--
Best regards,
Zero King

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

Re: Moving to GitHub: Status Update, Action Required

[Davide Liessi]

2016-10-25 15:35 GMT+02:00 Ryan Schmidt :
>
>> On Oct 25, 2016, at 6:54 AM, Rainer Müller  wrote:
>>
>> 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 onto current master should be on our
> WorkingWithGit wiki page.

 the easiest approach is just clicking the button that does this on
 GitHub. Of course there's also a way to do it from the command line.
>>>
>>> We should document, with screenshots, the specific buttons that should be 
>>> clicked to achieve this, for the benefit of those developers like me who 
>>> are not that familiar with git and GitHub.
>>
>> Keeping such a documentation with screenshots updated to the current
>> GitHub release seems excessive. The GitHub documentation already has
>> screenshots. We should not try to recreate it, but rather place the
>> links to the relevant sections.
>>
>> https://help.github.com/articles/merging-a-pull-request/
>
> As long as we don't just link, but in cases where their documentation offers 
> multiple choices, tell the user which of those choices to use.

I have just noticed in one of my GitHub repositories that in Settings
-> Options there is a "Merge button" section that lets you
enable/disable the behaviours of the merge button described in the
above link.
Maybe you could leave only "Allow rebase merging" enabled and disable the rest.

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

Re: GitHub migration complete

[Marko Käning]

Hi Larry,

On 31 Oct 2016, at 05:38 , Lawrence Velázquez  wrote:
> Old habits die hard, but from now on do NOT refer to Trac tickets as
> "#12345" in your commit messages; GitHub's website interprets those as
> pull request numbers. Copy and paste the full Trac URL instead.

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?

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

Re: GitHub migration complete

[René J . V . Bertin]

Lawrence Velázquez wrote:

...
> $ git gc --aggressive

FWIW, while theoretically very space-efficient, git's .git directories tend to 
grow to considerable size for active repositories. I find it useful to run the 
attached script from time to time. It runs the garbage collector, but also 
(re)packs the remaining data.

R
#!/bin/sh
# NB: should support repos checked out with --separate-git-dir!
# those have .git as a file containing something like
# gitdir: /path/to/git-dir

if [ ! -d ./.git/ ] ;then
echo "Not a git repository (./.git/ is not a directory)"
exit 0
fi

# use a bit of a hack to determine if our stamp exists and is the newest entry 
in .git
# (using grep to filter out the . and .. entries; this is still faster than 
running the whole
# operation for nothing).
LASTFILE="`ls -1tra ./.git/ | grep -v '^\.[\.]*$' | tail -1`"
if [ "${LASTFILE}" = ".eradicated" ] ;then
echo "Nothing changed since last `basename $0` - skipping"
exit 0
fi

gfilter () {
echo git filter-branch -f  --index-filter "git rm --force --cached 
--ignore-unmatch \"$1\"" -- --all
git filter-branch -f  --index-filter "git rm --force --cached 
--ignore-unmatch \"$1\"" -- --all
}

for f in $@ ;do
gfilter "$f"
done

rm -Rf .git/refs/original && \
git reflog expire --expire=now --all && \
git gc --aggressive && \
git prune

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

Re: querying the registry for installed files

[René J . V . Bertin]

On Friday October 28 2016 21:34:32 Vincent Habchi wrote:

Hi,

>> sqlite> WITH i AS (SELECT id FROM files WHERE path LIKE exp GROUP BY id) 
>> SELECT name FROM ports, i WHERE ports.id = i.id;

This works great, and as expected *much* faster than any other method one could 
think of currently. Ideally one would find a means to input standard regexps 
for the pattern. And I'd probably also want to print some more information 
about the results to avoid printing just the port name as many times as you 
have versions/variants installed.  But that could also be achieved by running 
the output through uniq (or sort -u) and then into `port installed`).

%> /opt/local/bin/sqlite3 /opt/local/var/macports/registry/registry.db 
SQLite version 3.14.2 2016-09-12 18:50:49
Enter ".help" for usage hints.
sqlite> WITH i AS (SELECT id FROM files WHERE path LIKE '%reator%' GROUP BY id) 
SELECT name FROM ports, i WHERE ports.id = i.id;
db48
qt5-creator-devel
qt5-creator
py34-pyqt5
qt5-kde-devel-zz-docs
kf5-breeze-icons
kf5-kio
kf5-kdelibs4support
kf5-kdevelop-devel
qt5-kde-devel
qt5-kde-devel
kf5-kio
kf5-kdelibs4support
kf5-breeze-icons
kf5-kdevelop-devel
kf5-marble
kf5-kio-extras
kf5-kdevelop-devel
kf5-okteta
kf5-kdevelop-devel

>Oh, if you want the files, a simple
>
>SELECT path FROM ports WHERE path LIKE exp; 

This however does not work:

%> /opt/local/bin/sqlite3 /opt/local/var/macports/registry/registry.db
SQLite version 3.14.2 2016-09-12 18:50:49
Enter ".help" for usage hints.
sqlite> SELECT path FROM ports WHERE path LIKE '%reator%';
Error: no such column: path

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