Re: How to handle MacPorts' handles in the future (including the email address connected to it)??
> On Nov 9, 2016, at 7:17 PM, Rainer Müller wrote: > > On 2016-11-10 01:30, Ryan Schmidt wrote: >> I don't think MacPorts wants the burden of running and securing an >> smtp server. That's not our mission. You'll have to find an smtp >> server that allow you to change the from address. > > Uhm, in fact, we already do that for the forwards and the mailing lists. There would be additional things needed above what we already have. For example, a way for users to securely authenticate with the server, such as passwords or certificates. > As I said in my previous mail, I would like to offer that at some point, > but it is not going to happen in the near future.
Re: How to handle MacPorts' handles in the future (including the email address connected to it)??
On 2016-11-10 01:30, Ryan Schmidt wrote: > I don't think MacPorts wants the burden of running and securing an > smtp server. That's not our mission. You'll have to find an smtp > server that allow you to change the from address. Uhm, in fact, we already do that for the forwards and the mailing lists. As I said in my previous mail, I would like to offer that at some point, but it is not going to happen in the near future. Rainer
Re: How to handle MacPorts' handles in the future (including the email address connected to it)??
On 10 Nov 2016, at 01:30 , Ryan Schmidt wrote: > I don't think MacPorts wants the burden of running and securing an smtp > server. That's not our mission. You'll have to find an smtp server that allow > you to change the from address. I understand. Yeah, makes perfect sense. Sorry for the noise.
Re: How to handle MacPorts' handles in the future (including the email address connected to it)??
> On Nov 9, 2016, at 6:28 PM, Marko Käning wrote: > > Hi Ryan, > > On 05 Nov 2016, at 19:05 , Ryan Schmidt wrote: > >>> I’d like to be able to send emails as well, not just receive them. What >>> am I missing here - in case the requested is also possible since 10 years? >> >> Use your normal smtp server, from your ISP or wherever. Set a different From >> address in your email client. In Apple Mail, for example, I get a drop-down >> menu in my compose window, so I can choose which address I want to send from >> for each message. > > the reason why I bring this up here is that my ISPs do not allow me to use a > From-address which isn’t hosted by them.* > > This is why my outgoing email using my MacPorts handle is currently being > sent for me by MacPorts fellow and friend Brad (pixilla) since years. This is > working fine, but I’d like to have a more general approach as I can’t imagine > that I am the only one faced with this kind of problem for the MacPorts > handle email address. > > Greets, > Marko > > > > *) This is done to put a stop to spammers, I believe. > I don't think MacPorts wants the burden of running and securing an smtp server. That's not our mission. You'll have to find an smtp server that allow you to change the from address.
Re: How to handle MacPorts' handles in the future (including the email address connected to it)??
Hi Ryan, On 05 Nov 2016, at 19:05 , Ryan Schmidt wrote: >> I’d like to be able to send emails as well, not just receive them. What >> am I missing here - in case the requested is also possible since 10 years? > > Use your normal smtp server, from your ISP or wherever. Set a different From > address in your email client. In Apple Mail, for example, I get a drop-down > menu in my compose window, so I can choose which address I want to send from > for each message. the reason why I bring this up here is that my ISPs do not allow me to use a From-address which isn’t hosted by them.* This is why my outgoing email using my MacPorts handle is currently being sent for me by MacPorts fellow and friend Brad (pixilla) since years. This is working fine, but I’d like to have a more general approach as I can’t imagine that I am the only one faced with this kind of problem for the MacPorts handle email address. Greets, Marko *) This is done to put a stop to spammers, I believe.
Re: Pull Requests for Work in Progress (WIP)
Hi Mojca, On 04 Nov 2016, at 19:21 , Mojca Miklavec wrote: > On 4 November 2016 at 18:55, Marko Käning wrote: >> >> Besides there is even a clearly visible RED "Work-In-Progress" label >> available in the PR interface, which Mojca had spotted eventually. > > I didn't spot it. I though it was useful and made it after this > discussion was started. at the time of writing I wasn’t aware of that. As a result of the discussion I guess one should remove this label from GitHub again. Greets, Marko
Re: GitHub migration complete
On 07 Nov 2016, at 16:43 , Lawrence Velázquez wrote: > No, we should absolutely forbid "$Id$" lines. New ports should not have > them. +1 This goes back to CVS. Who needs that? That’s what “git log -1 FILENAME” is for! :)
Re: PR usage by people with commit access
On 07 Nov 2016, at 17:55 , Lawrence Velázquez wrote: > I think the objection to #7 is that it was intentionally posted in an > incomplete state with the expectation that development would continue in > the pull request. I am not sure that that is the best approach for us. TBH I had hoped that it wasn’t that incomplete at the time of posting... > When I said that committers should feel free to open PRs, I meant PRs > for contributions that are essentially complete and might just need > a bit of tweaking. Well, if you look at the tweaks which have been done since submitting it I’d rather say it needed only a bit of tweaking itself. No? So? :-) One rarely knows the answer before uttering a question… Please comment on the PR if you have any objections, otherwise I’ll go ahead with committing a squashed version of it once I got the pending tests of its various variants successfully done, if that’s okay.
Re: Issues with upgrading with private repositories
Hi,
On Wed, Nov 09, 2016 at 10:17:36AM +, Artur Szostak wrote:
> During my testing when developing Portfiles I have a few different
> private repositories configured under
> /opt/local/etc/macports/sources.conf. I have gotten into a situation
> where after a "sudo port sync" I am seeing a version number that is
> not expected for my package when listing it with "sudo port list
> mypackage".
That version number comes from the portindex. Check the PortIndex files
for your local repositories. Also, check the order of those sources in
sources.conf to make sure the newer version you'd expect is first.
> When I look at all the cached Portfiles found under
> /opt/local/var/macports/sources/, I cannot find any existing Portfile
> with the version number seen in the "sudo port list mypackage"
> listing.
That suggests that your PortIndex might somehow be outdated. Usually the
'portindex' command uses file modification times to figure out which
ports to re-index, so touching the Portfile in question and running
portindex might fix this.
> Is there a way to clean any such caches if they exist? ("sudo port
> clean --all installed" did not help)
You can also just delete PortIndex and PortIndex.quick entirely, but it
might take a while to re-generate if you have a lot of ports.
--
Clemens
Re: GitHub migration complete
On Wednesday November 09 2016 12:09:24 Michael wrote: > Git is practical. With git, and it took me a while to learn this, when you > clone a repository, commit to your repository, and then push upstream to the > clone source, your clone source has both their commits and your commits, and > can cherry-pick which of yours they want to include. ? Only if "you" commit to a personal branch. If you clone, commit and push without any other actions there's nothing left to cherry-pick of your commits. I presume it's still possible to filter on who made the commit but I don't think that's what you meant. Git is undoubtedly very powerful and its basic use is relatively simple and straightforward, but the learning curve seems to get pretty steep quickly when you start looking at more advanced usage. I also have the impression that the developers are more interested in doing things the rigorously right way than in keeping it practical. While that's fine in itself it may not be the most appropriate for the kind of users who'll be using it here (myself not excluded). A bit like using a big bad-ass database application for keeping track of your record collection :) I guess time will tell... R.
Re: GitHub migration complete
On 2016-11-09, at 6:18 AM, René J.V. Bertin wrote: > On Wednesday November 09 2016 13:01:42 Christopher Jones wrote: > >> In my view, no it is not practical. Pull requests are to pull one branch, >> all diffs, from one to another. This is why I maintain the sooner people get >> use to the idea of making a separate branch for each piece of work, and pull >> request, the faster they will make progress with working with git. This is >> actually the power of git, not a hindrance. But it takes time for newcomers >> to git to realise this ;) > > So, the power of git is that it's not practical? A bit like how medicine is > supposed not to taste good? :) Pull Requests are NOT GIT. Pull requests are GITHUB Git is practical. With git, and it took me a while to learn this, when you clone a repository, commit to your repository, and then push upstream to the clone source, your clone source has both their commits and your commits, and can cherry-pick which of yours they want to include. Now, cherry picking may be difficult. I don't know. I have never used the built-in cherry pick -- I've used a GUI that lets me select line by line / hunk by hunk of the stuff committed, and git's native cherry-pick is whole commit at a time. But the idea of "Put each item on their own branch" is still a good idea. Git likes lots of small branches that get merged back in. Branches are cheap. I understand that this is the opposite of svn, that regards lots of branches as somewhat expensive. --- Entertaining minecraft videos http://YouTube.com/keybounce
Re: GitHub migration complete
On 2016-11-09 15:18, René J.V. Bertin wrote:
> [...] If a change can be
> expressed as "please have a look at my version of this/ese file(s)
> and consider incorporating them", why would you have to jump through
> all kinds of hoops that only increase the chance for error?
Remember we still have Trac. There is no requirement to use pull
requests on GitHub for submission of changes, it is just an additional
way. You can just file a ticket with the new file. This won't support
any inline comments for reviews, though.
> On Wednesday November 09 2016 14:24:36 Rainer Müller wrote:
>
>> You can delete commits completely from a branch by editing the
>> history with 'git rebase -i'.
>
> Even when the commit has been pushed (or in this case, was made
> directly on the remote)? Git makes that hard intentionally. I'm still
> surprised that I've been able to rewind the remote fork and delete a
> branch off it that had an open pull request, without recreating the
> whole fork from scratch.
Yes, even when it was done remotely. You can modify branches in any way
you want locally, there are no restrictions to stop you. Although you
will need to force-push the branch then to update it on the remote side.
Which should be fine in this case, as it is your personal repository and
does not have other users.
>> git log --graph --oneline --decorate @{upstream}..HEAD
>
> @{upstream}? Is that an existing keyword or something that you
> substitute automatically?
@{upstream} in git revision syntax refers to the last common commit
which is on both the current branch and its tracking branch.
https://git-scm.com/docs/gitrevisions
Rainer
Re: GitHub migration complete
On Wednesday November 09 2016 13:01:42 Christopher Jones wrote:
>In my view, no it is not practical. Pull requests are to pull one branch, all
>diffs, from one to another. This is why I maintain the sooner people get use
>to the idea of making a separate branch for each piece of work, and pull
>request, the faster they will make progress with working with git. This is
>actually the power of git, not a hindrance. But it takes time for newcomers to
>git to realise this ;)
So, the power of git is that it's not practical? A bit like how medicine is
supposed not to taste good? :)
I won't claim that being able to create pull request as currently the case
doesn't have its use cases, but when you google around a bit I'm clearly not
the only one who finds it, yes, a hindrance if the goal is to request inclusion
of just a single file.
If a change can be expressed as "please have a look at my version of this/ese
file(s) and consider incorporating them", why would you have to jump through
all kinds of hoops that only increase the chance for error?
I wonder how many people will end up using and sharing their own complete ports
tree over time, after all that's only a small step once you have taken the
required steps to be able to make pull requests.
As a *side remark*, there are at least 2 simple review boards that work with
simple patches and don't require dealing with commits and branches: Review
Board (www.reviewboard.org) and Phabricator
(https://secure.phabricator.com/book/phabricator/article/installation_guide/).
On Wednesday November 09 2016 14:24:36 Rainer Müller wrote:
>You can delete commits completely from a branch by editing the history
>with 'git rebase -i'.
Even when the commit has been pushed (or in this case, was made directly on the
remote)?
Git makes that hard intentionally. I'm still surprised that I've been able to
rewind the remote fork and delete a branch off it that had an open pull
request, without recreating the whole fork from scratch.
>to submit as a pull request. Always start these branches off the remote
>that refers to macports, see 'git remote -v' which one this is.
By default that'll be origin.
>If you need to re-create changes you have already committed somewhere on
>other branches, use 'git cherry-pick' to get these onto the pr-branch.
This I think I'll continue to do the old-fashioned way, manually, just like I
usually "rebase" by stashing my local patches (git stash or to a patchfile),
pulling and reapplying my patches (which I only commit when they're about to be
upstreamed). A bit more work but less error prone or at least when something
does go wrong it's not because you misunderstood some intricate detail, and
it's easier to back out of non-committed changes.
> git log --graph --oneline --decorate @{upstream}..HEAD
@{upstream}? Is that an existing keyword or something that you substitute
automatically?
R.
Re: GitHub migration complete
On 2016-11-09 13:51, René J.V. Bertin wrote:
> 1- Initially I followed github's suggestions as usual and added a
> README.md (in a first commit), thinking I'd be able to avoid that
> file easily enough. Instead it appears that pull requests can not be
> made for a specific commit or file/directory; README.md was an
> unintended part of my request. When I removed the file the pull
> request showed the addition and removal and I'm quite sure the same
> would have been true for a reverse commit. I managed to back out and
> recreate the branch, but it's highly annoying you only find out such
> things after doing a commit. Is there a way around this, or are pull
> requests always a reflection of the difference between the original
> master/head and the fork's head? IOW, is it going to be necessary to
> use 1 branch per pull request? That'd make it very impractical to use
> a single ports tree as both a local source for installed ports and a
> source for pull requests ...
Yes, you have to use a separate branch for each pull request. The pull
request will present the changes that where made from the start of the
branch to the current HEAD of the branch.
You can delete commits completely from a branch by editing the history
with 'git rebase -i'.
> 2- Suppose it *is* possible to have all local changes and custom
> ports in a single personal branch and then create pull requests when
> time and port are ripe. IIRC there's a magic incantation to rebase a
> topic branch on the remote origin/master (i.e. merge in remote
> changes on top of the changes in your topic branch without losing its
> history). Of course I haven't been able to retain that formula. It
> would be useful to describe the procedure on the working-with wiki.
You can keep other branches with other changes in the same repository.
You just have to be careful when you create a new branch that you intend
to submit as a pull request. Always start these branches off the remote
that refers to macports, see 'git remote -v' which one this is.
For example, when "origin" is macports/macports-ports, create a branch
based on the current upstream master:
git checkout -b pr-branch origin/master
If you need to re-create changes you have already committed somewhere on
other branches, use 'git cherry-pick' to get these onto the pr-branch.
To see which commits will be submitted in a pull request, use:
git log --graph --oneline --decorate origin/master..pr-branch
In general, if you created the branch as described above, the following
command will be identical when you are on the pr-branch. I use an alias
for this to quickly check which changes are "new" the current branch:
git log --graph --oneline --decorate @{upstream}..HEAD
Rainer
Request for review and/or commit of #52706
Hello, I am requesting a review and/or commit of this ticket. It hasn't received any attention in about 2 weeks. https://trac.macports.org/ticket/52706 Thanks, David
Re: GitHub migration complete
> On 9 Nov 2016, at 12:51 pm, René J.V. Bertin wrote: > > Hi, > > I've just managed (I think) to fork macports-ports via github.com, add it as > an additional remote to my working copy of the original, created a topic > branch in my fork and made a pull request from there. > > Questions raised during that process: > > 1- Initially I followed github's suggestions as usual and added a README.md > (in a first commit), thinking I'd be able to avoid that file easily enough. > Instead it appears that pull requests can not be made for a specific commit > or file/directory; README.md was an unintended part of my request. When I > removed the file the pull request showed the addition and removal and I'm > quite sure the same would have been true for a reverse commit. I managed to > back out and recreate the branch, but it's highly annoying you only find out > such things after doing a commit. > Is there a way around this, or are pull requests always a reflection of the > difference between the original master/head and the fork's head? IOW, is it > going to be necessary to use 1 branch per pull request? That'd make it very > impractical to use a single ports tree as both a local source for installed > ports and a source for pull requests … In my view, no it is not practical. Pull requests are to pull one branch, all diffs, from one to another. This is why I maintain the sooner people get use to the idea of making a separate branch for each piece of work, and pull request, the faster they will make progress with working with git. This is actually the power of git, not a hindrance. But it takes time for newcomers to git to realise this ;) > > 2- Suppose it *is* possible to have all local changes and custom ports in a > single personal branch and then create pull requests when time and port are > ripe. IIRC there's a magic incantation to rebase a topic branch on the remote > origin/master (i.e. merge in remote changes on top of the changes in your > topic branch without losing its history). Of course I haven't been able to > retain that formula. It would be useful to describe the procedure on the > working-with wiki. > > Thanks, > R. smime.p7s Description: S/MIME cryptographic signature
Re: GitHub migration complete
Hi, I've just managed (I think) to fork macports-ports via github.com, add it as an additional remote to my working copy of the original, created a topic branch in my fork and made a pull request from there. Questions raised during that process: 1- Initially I followed github's suggestions as usual and added a README.md (in a first commit), thinking I'd be able to avoid that file easily enough. Instead it appears that pull requests can not be made for a specific commit or file/directory; README.md was an unintended part of my request. When I removed the file the pull request showed the addition and removal and I'm quite sure the same would have been true for a reverse commit. I managed to back out and recreate the branch, but it's highly annoying you only find out such things after doing a commit. Is there a way around this, or are pull requests always a reflection of the difference between the original master/head and the fork's head? IOW, is it going to be necessary to use 1 branch per pull request? That'd make it very impractical to use a single ports tree as both a local source for installed ports and a source for pull requests ... 2- Suppose it *is* possible to have all local changes and custom ports in a single personal branch and then create pull requests when time and port are ripe. IIRC there's a magic incantation to rebase a topic branch on the remote origin/master (i.e. merge in remote changes on top of the changes in your topic branch without losing its history). Of course I haven't been able to retain that formula. It would be useful to describe the procedure on the working-with wiki. Thanks, R.
Issues with upgrading with private repositories
Dear MacPorts developers,
During my testing when developing Portfiles I have a few different private
repositories configured under /opt/local/etc/macports/sources.conf. I have
gotten into a situation where after a "sudo port sync" I am seeing a version
number that is not expected for my package when listing it with "sudo port list
mypackage".
When I look at all the cached Portfiles found under
/opt/local/var/macports/sources/, I cannot find any existing Portfile with the
version number seen in the "sudo port list mypackage" listing.
Is there any other place that MacPorts caches the version information than
/opt/local/var/macports/sources/ ?
Is there a way to clean any such caches if they exist? ("sudo port clean --all
installed" did not help)
Any other possible reason why I am seeing this miss match?
Kind regards.
Artur
