ungoogled-chromium - Google Chromium, sans integration with Google

[db]

Hi

I filed a request for this port. I post to the list because I think 
ungoogled-chromium is noteworthy, regardless if someone tries to make a port 
for it.

https://github.com/Eloston/ungoogled-chromium

https://trac.macports.org/ticket/62505

GSoC 2019

[db]

On 2 Apr 2019, at 17:11, macports-dev-requ...@lists.macports.org wrote:
> GSoC 2019

Could it be possible to relocate all this topics somewhere else?

New website design

[db]

On 6 Feb 2019, at 13:00, macports-dev-requ...@lists.macports.org wrote:
> Message: 2
> Date: Tue, 5 Feb 2019 21:31:22 +0100
> From: Mojca Miklavec 
> To: MacPorts Development 
> Subject: New website design
> Message-ID:
>   
> Content-Type: text/plain; charset="UTF-8"

> Our website design is in fact desperately outdated, it probably hasn't
> changed since day one. (I believe the project started in 2002?)

> We need a complete redesign; not just changing the colour palette, but
> completely restructuring contents, decreasing the amount of
> information, adding some pictures etc.

No to a complete redesign and changing colours.
Yes to some restructuring of contents and responsive design.
No to decreasing the amount of information (portgroups info?).
No to needless pictures.
Yes to an intro/overview page to get new users up and running, a là HB.

Re: macports rot

[db]

On 16 Dec 2018, at 13:00, macports-dev-requ...@lists.macports.org wrote:
> Message: 1
> Date: Sat, 15 Dec 2018 13:48:21 +0100
> From: Nils Breunese 
> 
> I’m also not involved in most upstream projects for the ports I maintain, but 
> especially when the upstream project has a website project you can send a 
> pull request to, they’ll often accept that.

A pull request changing README.md on many projects at GitHub should be enough. 
But I prefer to contact the developer.

Re: How to submit changes with a GitHub Pull Request (was Re: CI system for PR builds)

[db]

On 12 Apr 2018, at 19:52, Craig Treleaven  wrote:
> Is there a playground somewhere to try out such features?  For those of us 
> that are somewhat git- and github-challenged.

Not that I'm aware of. Just fork some repo or create a new one and make it your 
playground.

Re: CI system for PR builds

[db]

On 12 Apr 2018, at 18:52, Ryan Schmidt  wrote:
> 1. MacPorts does not have a method of declaring that a port does not build on 
> a version of macOS. Such a feature is being discussed:
> https://trac.macports.org/ticket/15712
> In the absence of this feature, we write pre-fetch blocks that manually check 
> the OS version and print an error.

Opened 10 years ago. Fat chance, I guess.

> 3. There is no plan to have any automated process add such blocks.

Precisely that I wanted to know. I'd like the powers that be to consider this — 
delivering portfiles that won't build (in certain platforms) doesn't make much 
sense.

Re: CI system for PR builds

[db]

On 8 Apr 2018, at 02:04, Rainer Müller  wrote:
> So here is the full plan in detail:

Side note: Wouldn't it be feasible to adjust portfiles based on CI's feedback? 
Let's say, you have something build on 10.6-10.13, but for whatever reason it 
fails on 10.9, so that could be reflected in the portfile in order to avoid 
having users build from source in vain, when the result is already known. Then, 
when there's a fix for 10.9, that change is reverted.

Re: How to submit changes with a GitHub Pull Request (was Re: CI system for PR builds)

[db]

On 11 Apr 2018, at 19:24, Perry E. Metzger  wrote:
> The main steps are:
> […]
> [By the way, if someone wants to turn this email into a document, I
> was pretty careful writing what's above so that would be easy.]

Thanks for the write-up. Although I probably rather prefer the PR way, it's 
getting around git+GitHub vs. attaching a portfile in Trac. Would you mind 
adding it to the guide's section 'Using Git and GitHub' you recently created?

Re: CI system for PR builds

[db]

On 11 Apr 2018, at 15:44, Mojca Miklavec <mo...@macports.org> wrote:
> On 11 April 2018 at 14:11, db wrote:
>> On 10 Apr 2018, at 20:07, Mojca Miklavec wrote:
>>> 
>>>> That streamlined process is what keeps new and updated portfiles in my 
>>>> local repo…
>>> I have no clue what you wanted to say with this.
>> It means that ports I submitted like stem and ipfs are not further reviewed, 
>> so new portfiles I write I just keep in my local repo and don't bother 
>> submitting.
> Are you willing to open pull requests for your submissions?

Sure. I just need to learn how and if I'm allowed to. Maybe submitters in trac 
could be notified en masse to also do so.

Re: CI system for PR builds

[db]

On 10 Apr 2018, at 20:07, Mojca Miklavec <mo...@macports.org> wrote:
> On 7 April 2018 at 15:45, db wrote:
>> On 7 Apr 2018, at 14:37, Ryan Schmidt wrote:
>> Is buildbot running on your basement???
> Yes (not mine).
> […]
>> Testing and reproducibility, doesn't seem to me as user to be a prime 
>> concern in MP.
> We still have a long way to go before we can achieve 100% binary
> reproducibility.
> […]
> What we need right now is mostly *code* (hardware would also help) as
> well as time & effort to help us reduce the number of all those Trac
> tickets, rather than pointing fingers to what MacPorts volunteers are
> not doing.

I won't address every single point and just say that it might be interpreted as 
finger-pointing, but I'm actually curious about what's the state of the 
project, how it got where it is, where is it going, should I build always from 
source, should I use another package manager or complement it with another one, 
etc. And all these I seem to learn only in the mailing list, which might be 
annoying, I admit.

>> That streamlined process is what keeps new and updated portfiles in my local 
>> repo…
> I have no clue what you wanted to say with this.

It means that ports I submitted like stem and ipfs are not further reviewed, so 
new portfiles I write I just keep in my local repo and don't bother submitting.

Re: CI system for PR builds

[db]

On 8 Apr 2018, at 13:50, Ryan Schmidt <ryandes...@macports.org> wrote:
> On Apr 8, 2018, at 06:49, db wrote:
> On 8 Apr 2018, at 13:34, Ryan Schmidt wrote:
>>> No, as I think we've explained several times already, now, Travis CI builds 
>>> the proposed change automatically, immediately after it's submitted. The 
>>> purpose is to verify that it builds, and the results of that build can 
>>> inform our review.
>> That streamlined process is what keeps new and updated portfiles in my local 
>> repo…
> So is your suggestion to delete the MacPorts Travis CI integration? Don't 
> test-build PRs?

Buildbot is a CI framework. Use that for testing. And automate deployment where 
possible.

Re: CI system for PR builds

[db]

On 8 Apr 2018, at 13:34, Ryan Schmidt  wrote:
> No, as I think we've explained several times already, now, Travis CI builds 
> the proposed change automatically, immediately after it's submitted. The 
> purpose is to verify that it builds, and the results of that build can inform 
> our review.

That streamlined process is what keeps new and updated portfiles in my local 
repo…

Re: CI system for PR builds

[db]

On 8 Apr 2018, at 13:18, Ryan Schmidt <ryandes...@macports.org> wrote:
> On Apr 8, 2018, at 06:12, db wrote:
>> That seems to waste at least buildtime and storage.
> What do you mean?
>> Many updates and revbumps could be almost automatically deployed (after a 
>> quick review).
> Isn't that we do now?

It seems to me that a PR builds in TravisCI, then is reviewed and eventually 
built by buildbot for distribution. If you would review a PR first, say for a 
minor version update, version and checksums changed, you could approve the 
change of couple of lines and trigger the build by buildbot and, if successful, 
upload the binary without further intervention. Is this now the case?

Re: CI system for PR builds

[db]

On 8 Apr 2018, at 12:42, Zero King <l...@macports.org> wrote:
> On Sun, Apr 08, 2018 at 12:20:34PM +0200, db wrote:
>> If you review the code before, that should never be the case and it would 
>> build just once if it succeeds, right? Or am I missing something how PRs are 
>> handled?
> CI builds are automatically started when a PR is submitted or updated,
> and we usually review the code after the build completes. Unless CI
> builds are fast enough, manually triggering builds after code review
> would be a waste of manpower (we have to wait till the build completes).
> The CI system is useful because it can provide more information when we
> review the PRs. It would be less useful if we have to manually start the
> builds.

That seems to waste at least buildtime and storage. Many updates and revbumps 
could be almost automatically deployed (after a quick review).

Re: CI system for PR builds

[db]

On 7 Apr 2018, at 19:44, Clemens Lang  wrote:
> Remember that Portfiles can execute arbitrary code and root access is
> available from Portfiles. We do not want to run arbitrary code in a PR
> on the same build machines we use to build packages that we will
> distribute to our users. A malicous attacker could modify the machines
> in a way that packages built after that will be miscompiled.

If you review the code before, that should never be the case and it would build 
just once if it succeeds, right? Or am I missing something how PRs are handled?

Re: CI system for PR builds

[db]

On 7 Apr 2018, at 07:47, Mojca Miklavec  wrote:
> No, because that would make the infrastructure that distributes binaries to 
> all our users susceptible to malicious PRs.

How is reviewing a PR, then letting it build and, if it succeeds, uploading the 
binary, if not, reporting the results — different from the current setup, which 
it seems to me duplicates the process, instead of reusing the infrastructure?
If a PR fails for all or some systems, then the changes would never make it 
into the tree, respectively, sparing trac.
I'd like to understand what is current and what would be the ideal CI for MP 
and what's needed to get there.

Re: CI system for PR builds

[db]

On 3 Apr 2018, at 18:04, Mojca Miklavec  wrote:
> Travis has lots of limitations, but it offers both (a) and (b) for free.

Couldn't (b) be the current infrastructure? If I understood correctly previous 
posts, Travis builds PRs for 10.11-10.13, but then Buildbot builds the binaries 
that are being distributed?

Re: CI system for PR builds

[db]

On 3 Apr 2018, at 13:09, Rainer Müller  wrote:
> But what exactly do you think would be the benefit from such a complicated 
> setup (GitHub -> GitLab -> External Runner)?

Testing? But hey, I only know MP's infrastructure from what I read in the list, 
TravisCI does wonders and everything's jolly good.

Re: CI system for PR builds

[db]

On 3 Apr 2018, at 02:20, Rainer Müller  wrote:
> Then please explain what this would offer us at all?

I'll try. GitLab let's you have external runners 
(https://docs.gitlab.com/ee/ci/runners/README.html), while TravisCI offers a 
certain amount of pipeline minutes and only supports the currently supported 
macOS versions (AFAIK from what others posted not long ago on the subject). 
Now, since version 10.6 you can use an external repo hosted on GitHub 
(https://about.gitlab.com/2018/03/22/gitlab-10-6-released/#gitlab-cicd-for-external-repos).
 And once a build succeeds, I guess it's also deliverable, whereas I'm not sure 
it's now the case.

Re: CI system for PR builds

[db]

On 2 Apr 2018, at 23:09, Clemens Lang <c...@macports.org> wrote:
> On Mon, Apr 02, 2018 at 08:43:52PM +0200, db wrote:
>> GitLab 10.6 released with CI/CD for GitHub
> Interesting, but I couldn't find any indication that this would support 
> builds on macOS. Do you have more info?

I think you and Mojca were referring to the shared runners, then 
https://gitlab.com/gitlab-com/infrastructure/issues/3183. But you don't need 
them.

Re: CI system for PR builds

[db]

On 2 Apr 2018, at 23:09, Clemens Lang <c...@macports.org> wrote:
> On Mon, Apr 02, 2018 at 08:43:52PM +0200, db wrote:
>> GitLab 10.6 released with CI/CD for GitHub
> Interesting, but I couldn't find any indication that this would support 
> builds on macOS. Do you have more info?

Nope, but I don't see why it wouldn't, 
https://docs.gitlab.com/ee/ci/examples/#languages-frameworks-oss.

Re: CI system for PR builds

[db]

On 2 Apr 2018, at 22:53, Mojca Miklavec  wrote:
> I fail to find any info about available runners for hosted CI infrastructure.

Is this what you're looking for? https://about.gitlab.com/features/github/ 
search for 'self-hosted'.

Re: CI system for PR builds

[db]

GitLab 10.6 released with CI/CD for GitHub

https://about.gitlab.com/2018/03/22/gitlab-10-6-released/#open-source-projects

Re: How to prevent fetching from macports mirrors

[db]

On 21 Mar 2018, at 23:04, Ryan Schmidt  wrote:
> List only the hostnames, not full URLs.

My bad. This works:

host_blacklist  distfiles.macports.org aarnet.au.distfiles.macports.org 
ywg.ca.distfiles.macports.org ykf.ca.distfiles.macports.org 
pek.cn.distfiles.macports.org lil.fr.distfiles.macports.org 
nue.de.distfiles.macports.org her.gr.distfiles.macports.org 
jog.id.distfiles.macports.org fco.it.distfiles.macports.org 
kmq.jp.distfiles.macports.org nou.nc.distfiles.macports.org 
osl.no.distfiles.macports.org jnb.za.distfiles.macports.org 
cjj.kr.distfiles.macports.org mse.uk.distfiles.macports.org 
sea.us.distfiles.macports.org

I suppose I could leave out aarnet's or kmq.jp's (longer rtt) as fallback if 
master sites don't have the source or are unreachable for some reason.

Re: How to prevent fetching from macports mirrors

[db]

On 21 Mar 2018, at 00:54, Ryan Schmidt <ryandes...@macports.org> wrote:
> On Mar 20, 2018, at 09:21, db wrote:
>> How do you blacklist MP mirrors? Like so: host_blacklist  
>> *.packages.macports.org ?
> I don't think it supports wildcards. List each complete hostname you want to 
> blacklist.


This doesn't seem to work either.

host_blacklist  https://distfiles.macports.org/ 
http://aarnet.au.distfiles.macports.org/pub/macports/distfiles/ 
http://ywg.ca.distfiles.macports.org/mirror/macports/distfiles/ 
http://ykf.ca.distfiles.macports.org/MacPorts/mpdistfiles/ 
https://pek.cn.distfiles.macports.org/macports/distfiles/ 
http://lil.fr.distfiles.macports.org/ http://nue.de.distfiles.macports.org/ 
http://her.gr.distfiles.macports.org/ 
http://jog.id.distfiles.macports.org/macports/distfiles/ 
http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/ 
http://kmq.jp.distfiles.macports.org/ 
http://nou.nc.distfiles.macports.org/pub/macports/distfiles.macports.org/ 
http://osl.no.distfiles.macports.org/ 
http://jnb.za.distfiles.macports.org/distfiles/ 
http://cjj.kr.distfiles.macports.org/ 
http://mse.uk.distfiles.macports.org/sites/distfiles.macports.org/ 
http://sea.us.distfiles.macports.org/macports/distfiles/

Re: How we announce MacPorts changes

[db]

On 21 Mar 2018, at 12:49, Rainer Müller  wrote:
> Apparently you care a lot about these details. As you are already actively 
> following the mailing lists and commit logs, feel free to prepare a weekly 
> newsletter of the important changes to the ports tree.

I'd rather follow irregular updates (see linuxbrew updates issue on GH) and 
check first updated technical documentation, than follow two mailing lists.

Re: How we announce MacPorts changes (was: Re: Enhance livecheck to check not only version but also checksums)

[db]

On 21 Mar 2018, at 00:31, Ryan Schmidt <ryandes...@macports.org> wrote:
> On Mar 20, 2018, at 09:20, db wrote:
>> macports-announce seems scant to me.
> Intentionally. We only post there when we have something to announce, which 
> is seldom.

I still think things like python default and protobuff changes, or enhancements 
like port bump could be announced there, or at least somewhere, besides the 
changelog, that most skim through at best.

Re: How to prevent fetching from macports mirrors

[db]

On 20 Mar 2018, at 14:40, Joshua Root  wrote:
> host_blacklist, preferred_hosts
> 

How do you blacklist MP mirrors? Like so: host_blacklist  
*.packages.macports.org ?

Re: Enhance livecheck to check not only version but also checksums

[db]

On 20 Mar 2018, at 14:54, Rainer Müller  wrote:
> https://lists.macports.org/pipermail/macports-announce/
> https://github.com/macports/macports-base/blob/master/ChangeLog

macports-announce seems scant to me. I suggest using a GitHub issue, like 
Linuxbrew does, https://github.com/Linuxbrew/brew/issues/1, or adding 
changes/enhancements to macports-announce.

Re: How to prevent fetching from macports mirrors

[db]

On 20 Mar 2018, at 03:34, Ryan Schmidt <ryandes...@macports.org> wrote:
> On Mar 19, 2018, at 16:29, db wrote:
>> Is there any way to set in macports.conf to only fetch from master site 
>> and/or, if needed, try a mirror?
> What do you mean? MacPorts already tries to fetch from the master_sites 
> specified in the portfile, and the mirrors, in an order defined by which ones 
> are thought to be closest to you. Are you saying you want to influence the 
> order in which they're tried?

Yes. Are there any options? The guide says, macports_distfiles mirror is always 
implicitly appended to master_sites, but from the my logs it seems *prepended*, 
as mirrors are hit first.

Re: Enhance livecheck to check not only version but also checksums

[db]

On 20 Mar 2018, at 00:59, Ryan Schmidt  wrote:
> Once that's done, it makes it easier to implement a better "bump" command -- 
> one that can use any published checksums and compute the rest, and warn if no 
> checksums were published.
> https://trac.macports.org/ticket/53851

Sorry, this one is off-topic, but would such enhancements make it in 
macports-announce?

Re: How to prevent fetching from macports mirrors

[db]

On 19 Mar 2018, at 17:42, Rainer Müller  wrote:
> With git master:
> $ sudo port fetch --no-mirrors
> With 2.4.x:
> $ sudo port fetch global_mirror_site=

Is there any way to set in macports.conf to only fetch from master site and/or, 
if needed, try a mirror?

Re: MacPorts from behind proxy servers & fetching the file directly

[db]

On 16 Mar 2018, at 16:03, "Daniel J. Luke"  wrote:
> portfiles could in theory attempt to connect to any port, so a comprehensive 
> list like you're asking for is probably not possible to create.

But there could be one in practice, as there is infrastructure building all 
ports. Ever upgraded outdated overnight to find in the morning that it couldn't 
fetch a file?

Re: MacPorts from behind proxy servers & fetching the file directly

[db]

On 16 Mar 2018, at 12:31, Mojca Miklavec  wrote:
> While discussing GSOC with Umesh, he repeated what we already
> discussed during the meeting. Students in campuses (including the one
> where he is studying and from which roughly 40 students participate in
> GSOC each year) might be behind proxies and might not even be able to
> run MacPorts due to blocked rsync.

Is there any list of ports used for installing base and **any other** port? 
I've had some problems behind firewalls. Checked guide and wiki to no avail.

Re: Changing default cxx_stdlib to libc++

[db]

On 15 Mar 2018, at 05:19, Ryan Schmidt <ryandes...@macports.org> wrote:
> On Mar 14, 2018, at 07:23, db wrote:
>> On 14 Mar 2018, at 01:14, Rainer Müller wrote:
>>> Are you going to sponsor a dedicated Mac server for GitLab CI?
>>> Travis CI is available at no cost and we have no funds to pay for anything.
>> If MacPorts is short on resources, these could be listed on the website. 
>> Folks can certainly ask around.
> We did have an offer on the list some months ago from someone with spare Mac 
> hardware in a data center that they would let us use. We did not respond to 
> the offer. I'm not sure how comfortable I am accepting unsolicited 
> infrastructure offers from unfamiliar parties.

Not responding to an offer doesn't encourage people to ask around for or 
provide resources. Definitively not me. You might also need to describe how a 
gift horse has to look like, i.e., specify requirements.

Re: CI system for PR builds (was: Re: Changing default cxx_stdlib to libc++)

[db]

On 15 Mar 2018, at 05:13, Ryan Schmidt <ryandes...@macports.org> wrote:
> Because PRs come from untrusted sources, we have to assume their contents are 
> tainted. So after any PR is finished building, the VM is tainted and we have 
> to throw it away and make a new one from our template for the next PR build.

> On Mar 14, 2018, at 07:25, db wrote:
>> Otherwise, you could make the machines sync to the packages public server 
>> for the distributable, and to a private server for the non-distributable 
>> binaries.
> I can't find an interpretation of that sentence that helps to solve the 
> prepopulation problem.

I didn't know how you handled the templating. Couldn't you just prepopulate the 
cloned VM, take a snapshot, build the PR, restore the snapshot, eventually, 
delete the snapshot, update outdated, then retake it?

Re: Changing default cxx_stdlib to libc++

[db]

On 14 Mar 2018, at 01:14, Rainer Müller  wrote:
> Are you going to sponsor a dedicated Mac server for GitLab CI?
> Travis CI is available at no cost and we have no funds to pay for anything.

If MacPorts is short on resources, these could be listed on the website. Folks 
can certainly ask around.

Re: Changing default cxx_stdlib to libc++

[db]

On 14 Mar 2018, at 00:22, Mojca Miklavec  wrote:
> Because someone would need to write the code for an alternative CI

Wouldn't self-hosted GitLab CI be good enough?
I get the impression that testing across the board is not a priority.

Re: Changing default cxx_stdlib to libc++

[db]

On 13 Mar 2018, at 17:10, Mojca Miklavec  wrote:
> The main problem is that Travis is *not* out main build system, we use
> a different system for that. Travis has lots of limitations:

Got it. Then why use it in the first place instead of an alternative CI?

Re: Changing default cxx_stdlib to libc++

[db]

On 13 Mar 2018, at 15:22, Ryan Schmidt <ryandes...@macports.org> wrote:
> On Mar 13, 2018, at 08:47, db wrote:
>> On 12 Mar 2018, at 21:35, Ryan Schmidt wrote:
>>> On Mar 12, 2018, at 13:56, db wrote:
>>>> If not, shouldn't it, prior to accepting an updated port definition?
>>> The buildbot is only engaged after a commit is in the repository master 
>>> branch.
>>> We have a separate system, using Travis CI, for doing test builds of 
>>> updates that have been submitted as pull requests but have not yet been 
>>> merged into the repository master branch. But most maintainers that are 
>>> committers don't submit pull requests for their own software, they just 
>>> commit directly to master, so their changes would not go through Travis.
>> Then why contribute an update to a port circumventing the test build system? 
>> What's the sense in that?
> You're the first person, that I'm aware of, to suggest that we should 
> restrict commits to master and require all contributors, including those who 
> have already been vetted and given commit access, to make their contributions 
> through pull requests. I'm sure there are other projects that have made such 
> policies, but we haven't so far. Instead, we allow direct commits to master, 
> and we encourage others to review those commits on the macports-dev mailing 
> list or on GitHub.
> 
> We've only been on GitHub since late 2016. For the 10 years prior to that, we 
> used a Subversion repository, and prior to that it was CVS. The only way to 
> update those repositories was for a someone with commit access to commit to 
> them. Many of us who were MacPorts committers during that time are used to 
> this way of working and might find the additional roadblocks to our 
> contributions that pull requests represent to be intrusive. In my case, I 
> feel like I might finally be becoming proficient at submitting pull requests 
> at least, but it has been a long and frustrating learning process for me, and 
> one which is far from over; I'm still making git mistakes daily.
> 
> We've only had our Travis CI integration set up since mid-2017. I am not 
> certain what its reliability is now. Often, when I've looked at a Travis 
> failure log, it has turned out to be a problem specific to Travis, and not a 
> reason to reject a PR. So I am not paying a great amount of attention to what 
> Travis is doing at this time. It's nice that we have it, it's nice that our 
> other developers like to use it to check their work before publishing it. But 
> developers are already expected to check their work and verify the port 
> installs on their own machines before committing or submitting a PR or patch; 
> if they do that, they shouldn't see much on Travis that they didn't already 
> know about.

Thanks for the background. I don't know how much inconvenience would that mean 
for developers, I do know as a user though. I suppose that problems would be 
properly caught in the pipeline and almost never make it to the user. Skipping 
it because of being inconvenienced, that doesn't make any sense whatsoever to 
me.

Re: Changing default cxx_stdlib to libc++

[db]

On 12 Mar 2018, at 21:35, Ryan Schmidt <ryandes...@macports.org> wrote:
> On Mar 12, 2018, at 13:56, db wrote:
>> If not, shouldn't it, prior to accepting an updated port definition?
> The buildbot is only engaged after a commit is in the repository master 
> branch.
> We have a separate system, using Travis CI, for doing test builds of updates 
> that have been submitted as pull requests but have not yet been merged into 
> the repository master branch. But most maintainers that are committers don't 
> submit pull requests for their own software, they just commit directly to 
> master, so their changes would not go through Travis.

Then why contribute an update to a port circumventing the test build system? 
What's the sense in that?

Re: Changing default cxx_stdlib to libc++

[db]

On 12 Mar 2018, at 21:56, Ryan Schmidt  wrote:
> I'm not aware of any plan to notify users of the cxx_stdlib change, other 
> than the same way that users are notified of any other port update being 
> available: by the user running "sudo port selfupdate" and then examining the 
> output of "port outdated".

I was considering only subscribing to macports-announce. Would this change make 
it in there?

>> Besides rebuilding from source from time to time, I only do port sync.
> You'll of course have to run "sudo port selfupdate" (or run the installer 
> downloaded from our web site), not just "sudo port sync", to receive the new 
> version of MacPorts.

I compile both base and ports from source, so there's that.

Re: Python default version

[db]

On 12 Mar 2018, at 15:46, Ryan Schmidt  wrote:
> Should we change the default python version to 3.6 now, or soon?

Soon. Btw, https://brew.sh/2018/01/19/homebrew-1.5.0/ (first bullet).

Re: Changing default cxx_stdlib to libc++

[db]

On 11 Mar 2018, at 02:47, "Kenneth F. Cunningham" 
<ken.cunningham.web...@gmail.com> wrote:
> On 2018-03-10, at 12:23 PM, db wrote:
>> Except for building from source for minor versions and revbumps, especially 
>> large binaries, and for ports that have open defects. Oh well…
> Well, everything for 10.6.8 users on MacPorts is about to get supremely 
> better. Hard to be too upset about that!

I don't doubt that! What I don't understand is, why would port be allowed to 
build a port from source on a certain system that already failed on the 
buildbot, and what's worse, be left with a port in a non-working state, while 
downloading binaries would work, because it couldn't donwload something that's 
failed to build.

Re: Changing default cxx_stdlib to libc++

[db]

On 10 Mar 2018, at 18:06, "Kenneth F. Cunningham" 
<ken.cunningham.web...@gmail.com> wrote:
> I think I"m likely not going to change anything on my LibcxxOnOlderSystems 
> 10.6.8 system for a while, db. It will continue to work just as it does now, 
> and I don't mind building from source -- kinda got used to it.

Except for building from source for minor versions and revbumps, especially 
large binaries, and for ports that have open defects. Oh well…

Re: Changing default cxx_stdlib to libc++

[db]

On 10 Mar 2018, at 00:09, Joshua Root <j...@macports.org> wrote:
> On 2018-3-10 08:43 , db wrote:
>> 
>> If I build base and ports from source, will buildfromsource be changed 
>> unilaterally by MP or would it need user intervention? I also have certain 
>> versions of gcc and llvm locally to avoid rebuilding after minor versions 
>> and revbumps.
> We're not going to modify your macports.conf.

How will I know about the lib change and the availability of binaries? Besides 
rebuilding from source from time to time, I only do port sync.

Re: Changing default cxx_stdlib to libc++

[db]

On 9 Mar 2018, at 15:21, Joshua Root <j...@macports.org> wrote:
> On 2018-3-9 20:38 , db wrote:
>> On 9 Mar 2018, at 01:27, Ryan Schmidt <ryandes...@macports.org> wrote:
>>> When would we run this script to delete libstdc++ archives? Presumably, 
>>> after all legacy users have MacPorts 2.5 and have switched to libc++.
>> How about those that build MP from source?
> There are no additional problems arising from that

If I build base and ports from source, will buildfromsource be changed 
unilaterally by MP or would it need user intervention? I also have certain 
versions of gcc and llvm locally to avoid rebuilding after minor versions and 
revbumps.

Re: Changing default cxx_stdlib to libc++

[db]

On 9 Mar 2018, at 01:27, Ryan Schmidt  wrote:
> When would we run this script to delete libstdc++ archives? Presumably, after 
> all legacy users have MacPorts 2.5 and have switched to libc++.

How about those that build MP from source?

Re: request for port create command, to build a portfile from a URL

[db]

On 7 Mar 2018, at 01:53, Rainer Müller <rai...@macports.org> wrote:
> On 2018-03-06 23:00, db wrote:
>> [...] an *overview* of how to write a portfile is much needed.
> Isn't this what this chapter in the guide is supposed to provide?
> https://guide.macports.org/#development

Yes, supposed. When you're in it's difficult to say, but AFAIR I was probably 
trying to write a portfile for something hosted on GitHub without knowing about 
the relative portgroup and its documentation being buried somewhere under the 
prefix in the tcl file itself.

Re: request for port create command, to build a portfile from a URL

[db]

On 6 Mar 2018, at 16:19, Joshua Root  wrote:
> On 2018-3-7 01:58 , Ken Cunningham wrote:
>> 
>> port create URL
>> Might make things faster and easier for people to get started and up and 
>> running.
> There's a fairly basic tool called portfile-gen in contrib.

I took a bit to find it, so here's the link 
https://github.com/macports/macports-contrib/tree/master/portfile-gen.

I learned to write a portfile following some article in the wild, then I went 
through the whole guide, landed eventually in the mailing list.

While portfile-gen might help (homebrew has a similar feature), an *overview* 
of how to write a portfile is much needed.

Re: Ports with default modeline & lots of mixed tabs with spaces

[db]

On 1 Mar 2018, at 13:14, Ryan Schmidt  wrote:
> What do you mean?
> I don't think port lint currently gives whitespace recommendations. And if it 
> did, port lint still just provides suggestions that must be moderated by 
> human decisions.

I just tried it and it seems port lint doesn't catch tabs. Anyway, I thought 
not using tabs would be a basic rule that could easily be followed, but 
apparently it is not.

Re: Ports with default modeline & lots of mixed tabs with spaces

[db]

On 28 Feb 2018, at 14:58, Ryan Schmidt  wrote:
> I wouldn't completely change the whitespace of someone else's port, even 
> after a maintainer timeout. But I would correct whitespace mistakes in 
> someone else's port after a suitable timeout.

Shouldn't port lint be the rule here?

Re: Search for a MacPorts Mascot: looking for talented artists

[db]

On 22 Feb 2018, at 12:24, Mojca Miklavec  wrote:
> In the spirit of plays around "Port" there's another relevant wikipedia 
> article:
>https://en.wikipedia.org/wiki/Port_wine
> But it would not be too tasty to use that given our history with
> certain other projects :) :) :)

Hexley with a beer mug and a beret à la LibreSSL, 
https://en.wikipedia.org/wiki/LibreSSL#/media/File:LibreSSL_logo.png.

Re: Oh sh!t git

[db]

On 22 Feb 2018, at 16:05, Craig Treleaven  wrote:
> If, like me, you sometimes don’t get git:
> http://ohshitgit.com

Nomen est omen

http://justinhileman.info/article/git-pretty/git-pretty.png
http://ndpsoftware.com/git-cheatsheet.html

Re: Suggestions for hacking sessions & discussions for the MacPorts meeting in March

[db]

On 22 Feb 2018, at 11:32, Umesh Singla <umeshksin...@macports.org> wrote:
> On Thu, Feb 22, 2018 at 12:26 AM, db <iams...@gmail.com> wrote:
> On 21 Feb 2018, at 17:33, Mojca Miklavec <mo...@macports.org> wrote:
> > - New website!
> Homebrew/Linuxbrew's are good examples to get up and running quickly, and 
> still have updated technical documentation.
> or ReadTheDocs (rst files, easy to manage the directory structure, can use 
> templates)? Website is more-or-less documentation only in our case.

I meant, there's no overview. And some topics discussed in the list never make 
it to the guide.

Re: Search for a MacPorts Mascot: looking for talented artists

[db]

On 21 Feb 2018, at 17:32, Mojca Miklavec  wrote:
> Something in the spirit of ...
>http://en.wikifur.com/w/images/4/46/Hexley_fork_450.png

I like that MacPorts lacks a mascot identity. But if you really need, want one, 
then I probably choose Darwin's Hexley. Another that I'd consider, and since 
there're already 20K+ ports, is some sort of behemoth, e.g.

http://monster.wikia.com/wiki/Behemoth
https://alexgilble.deviantart.com/art/Behemoth-The-Land-Monster-413063725

Re: Suggestions for hacking sessions & discussions for the MacPorts meeting in March

[db]

On 21 Feb 2018, at 17:33, Mojca Miklavec  wrote:
> - New website!

Homebrew/Linuxbrew's are good examples to get up and running quickly, and still 
have updated technical documentation.

> - How to deal with huge number of open tickets on Trac
> - It would be fun to go through features of HB and:
>  - write clear explanations (PR statements) about why we do something
> things differently (sudo, not using /usr/local) + list of features we
> don't want to implement and why

I look forward to the meeting minutes.


Also, maybe the think tank could consider some mechanism that avoids installing 
ports from source for a certain arch while defects are open in trac.

Re: ansible replacement by py-ansible

[db]

On 23 Jan 2018, at 11:31, Russell Jones  wrote:
> Not quite what you're asking, but there is a GitHub portgroup.

Yes, I know. I actually tried vcs with pip as the portfile now is, but it 
didn't work, or at least, I couldn't make it work. But ansible is now 
pypi-based and imo unnecessarily prepended as if it were a module, but the docs 
are still in the distfile.

Re: ansible replacement by py-ansible

[db]

On 15 Dec 2017, at 15:41, Andrew Fernandes  wrote:
> Not in the pypi dist!

I just checked and manpages, examples, etc are there.

https://pypi.python.org/packages/4f/65/ae3ad8589c38f9e04ebc8a824c2880eb4f9e603a1f62b5f5a3f938e524b0/ansible-2.4.2.0.tar.gz#md5=88240a923505d604bd7a4fb91d7721e8

Re: reclaim and rleaves

[db]

On 15 Dec 2017, at 15:51, db <iams...@gmail.com> wrote:
> Shouldn't reclaim use rleaves instead of unrequested? As of now I have to 
> rerun reclaim in order to remove unnecessary ports.

Can anyone clarify why multiple runs of reclaim are necessary?

Re: port "gohome" --> "A keychain cannot be found."

[db]

On 3 Jan 2018, at 00:24, db <iams...@gmail.com> wrote:
> On 2 Jan 2018, at 22:51, Ken Cunningham <ken.cunningham.web...@gmail.com> 
> wrote:
>> Found a consistent trigger.
>> If safari is _not_ running:
>> "port gohome gtk3"  -> brings up “A keychain cannot be found”
> Did you try different versions of Safari? It works fine in v6.

I tried it in v11. If you keep cancelling that message until the website loads, 
it disappears. It comes back once when you quit Safari.

Re: port "gohome" --> "A keychain cannot be found."

[db]

On 2 Jan 2018, at 22:51, Ken Cunningham  wrote:
> Found a consistent trigger.
> If safari is _not_ running:
> "port gohome gtk3"  -> brings up “A keychain cannot be found”

Did you try different versions of Safari? It works fine in v6.

Re: ansible replacement by py-ansible

[db]

Is it possible to use pip with git? I couldn't find a portfile using, for 
example, git+https.

https://pip.readthedocs.io/en/latest/reference/pip_install/#vcs-support

Re: ansible replacement by py-ansible

[db]

On 15 Dec 2017, at 15:41, Andrew Fernandes  wrote:
> Not in the pypi dist!

That's great. I guess, I'll have to make my own or look somewhere else.

Re: ansible replacement by py-ansible

[db]

On 15 Dec 2017, at 05:25, Andrew Fernandes  wrote:
> patched and committed in f5a44cbcb1

Weren't there also man pages?

Re: ansible replacement by py-ansible

[db]

On 14 Dec 2017, at 16:53, Joshua Root  wrote:
> It needs the attached change.

Should I reopen #55229 and attach the diff?

ansible replacement by py-ansible

[db]

I tried upgrading ansible from 2.3.2.0.1_1 to 2.3.2.0.1_2 and it failed. The 
log showed a conflict with ansible (sic) so I cat'ed the portfile and noticed 
the ui_error in the pre-configure phase stating its replacement by py-ansible 
and some instructions. So I did install py-ansible and it failed with the 
following error.

--->  Extracting py-ansible
Error: Failed to patch py-ansible: 
/opt/local/var/macports/build/_opt_local_var_macports_sources_github.com_macports_macports-ports_python_py-ansible/py-ansible/work/ansible-2.4.2.0:
 no such file or directory

I remembered a similar error with subports and did a quick try installing 
py27-ansible and it succeeded, but it wasn't marked as requested.

I don't see a ticket in the tracker, so I'll file one shortly.

Why is py27-ansible not marked as requested?

How can you catch that ui_error error while upgrading in the portfile?

Re: Too many compilers needed for C++11

[db]

On 7 Dec 2017, at 07:29, Ryan Schmidt  wrote:
> They are, if you're running on an OS version where those dependencies are 
> added.

Here's what I see:

$ sw_vers
ProductName:Mac OS X
ProductVersion: 10.8.5
BuildVersion:   12F2560
$ port rdeps highlight
The following ports are dependencies of highlight @3.40_1:
  boost
zlib
  xz
libiconv
  gperf
gettext
  expat
  ncurses
bzip2
icu
python27
  pkgconfig
  db48
  libedit
  libffi
  openssl
  sqlite3
  python_select
  python2_select
  cctools
libunwind-headers
llvm-3.7
  libcxx
  perl5
perl5.24
  gdbm
readline
  llvm_select
  lua
$ port installed | grep clang
  clang-3.9 @3.9.1_3+analyzer (active)
  clang-4.0 @4.0.1_1+analyzer+libstdcxx (active)
  clang_select @2_0 (active)

I use master from last Sunday and build ports from source with libc++.

Re: Too many compilers needed for C++11

[db]

On 7 Dec 2017, at 12:59, Mojca Miklavec  wrote:
> Nowadays many ports claim
>Warning: All compilers are either blacklisted or unavailable; defaulting 
> to first fallback option
> but do install nevertheless at the end. I would say that this is a bug in 
> either the portfiles or portgroups that's worth fixing anyway, but I just 
> wanted to say that if you make this an error, suddenly a huge number of ports 
> that can easily be built will simply stop working.
> 
> One of annoying things is that I'm getting this warning when I run "port 
> livecheck maintainer:..." and I have absolutely no clue where it comes from.

When I temporarily switched to clang 3.9 in macports.conf with

default_compilers  macports-clang-3.9

that warning showed for every installation

$ sudo port install highlight
Warning: All compilers are either blacklisted or unavailable; defaulting to 
first fallback option
Warning: All compilers are either blacklisted or unavailable; defaulting to 
first fallback option
--->  Computing dependencies for highlight
...

and the following line was added on each `port info`, even to those ports that 
don't need it

Build Dependencies:   clang-3.9

Re: Too many compilers needed for C++11

[db]

On 6 Dec 2017, at 00:46, Ken Cunningham  wrote:
> clang/llvm 5.0 is the current cxx11 1.1 compiler, so that is what is being 
> called up.

Shouldn't such portgroup dependencies be listed by `port rdeps`? I don't see 
it, for example, in highlight.

Re: base master and editing commands

[db]

On 4 Dec 2017, at 13:20, Rainer Müller  wrote:
> You are trying to build MacPorts against readline installed by MacPorts.

Why can I build it against its own curl but not its own readline?

Eventually, I temporarily deactivated readline and it built fine.

Re: base master and editing commands

[db]

On 4 Dec 2017, at 01:00, Joshua Root  wrote:
> So you want --enable-readline as well.

I tried cleaning and rebuilding, and now I get the following error.

readline.c:128:23: error: use of undeclared identifier 
'username_completion_function'; did you mean 'rl_username_completion_function'?
generator_func = 
USERNAME_COMPLETION_FUNCTION;
 
^~~~
 
rl_username_completion_function
readline.c:49:39: note: expanded from macro 'USERNAME_COMPLETION_FUNCTION'
#   define USERNAME_COMPLETION_FUNCTION username_completion_function
^
/opt/local/include/readline/readline.h:465:14: note: 
'rl_username_completion_function' declared here
extern char *rl_username_completion_function PARAMS((const char *, int));
 ^
1 error generated.
make[2]: *** [readline.o] Error 1
make[1]: *** [all] Error 1
make: *** [all] Error 1

Re: base master and editing commands

[db]

On 4 Dec 2017, at 01:00, Joshua Root  wrote:
> So you want --enable-readline as well.

I just tried it and some of the commands still don't work: ^A, ^E, arrows — ^U, 
^W work though.

Re: base master and editing commands

[db]

On 4 Dec 2017, at 01:00, Joshua Root  wrote:
> So you want --enable-readline as well.

Thanks. In the guide 2.2.2. doesn't use this option, 2.2.3. does.

base master and editing commands

[db]

Basic editing commands don't work in shell mode.

 macports-base $ port
MacPorts 2.4.99
Entering shell mode... ("help" for help, "quit" to quit)
[Code/macports-base] > syncc^H^H^A^E^K

Fortunately ^U works.

I haven't found an issue in the tracker.

Re: Force build on wrong builder

[db]

On 12 Oct 2017, at 16:13, Ryan Schmidt <ryandes...@macports.org> wrote:
> On Oct 12, 2017, at 09:11, db wrote:
>> 
>> Does a commit to a dependency trigger a rebuild of its rdependents?
> Unfortunately no. We've been discussing that on the -infra list but I don't 
> think we found a solution we like yet.

What happens if a requested port needs a newer dependency? Does it build it 
locally and trigger the buildbot to schedule it? Ideally, it could do that, or 
even, depending on the buildbot's current jobs, it could at least rebuild the 
remaining dependencies of the requested port and make those available for 
download, since it would probably take more cycles to build locally and it 
won't be distributed anyway.

Re: State of the GnuPG ports

[db]

On 10 Oct 2017, at 07:18, Leonardo Brondani Schenkel  
wrote:
> On 2017-10-10 03:10, Helmut K. C. Tessarek wrote:
>> On 2017-10-09 08:11, Rainer Müller wrote:
>>> gnupg   -> 2.2
>>> gnupg-devel -> 2.3
>>> gnupg1  -> 1.4
>> +1
> +1

+1

Re: Releasing 2.4.2

[db]

On 6 Oct 2017, at 18:54, Ryan Schmidt  wrote:
> Thanks, that was exactly the fix I was just going to suggest. I'll deploy 
> that, then 2.4.2 should be available within the hour.

Sorry to hijack the thread. I just installed 2.4.2 from source and realised 
that rleaves didn't make it to it yet. Any ideas why?

Re: virtual machine for 10.5 intel ?

[db]

On 3 Oct 2017, at 05:01, Ken Cunningham  wrote:
> if anyone would care to enlighten me on the best approach to making a VM for 
> 10.5 intel, I would appreciate it. This is the only system I have that I 
> can’t presently see a way to virtualize.

At that time I wanted to do the same and found this post which I eventually 
didn't try.

https://blog.rectalogic.com/2008/08/virtualizing-mac-os-x-leopard-client.html?showComment=122712174

I have the original as PDF if you want it. The actual post misses most of the 
comments from that day.

Re: Restoring from Time Machine backup relocates home directories

[db]

On 17 Sep 2017, at 00:15, Ryan Schmidt  wrote:
> File ownership can be preserved on disk images, but that ownership is 
> preserved by uid and gid, not by user name and group name.

I suspected this but didn't know how it actually works on OS X.

>> MP could also checked if the UIDs/GIDs are already in use, before a port 
>> creates a user/group.
> MacPorts already does this, in that the MacPorts command to create a new user 
> will use the first uid numbered 500 or greater that does not already exist in 
> the directory service. Or did you mean something different by "already in 
> use"?

I meant not already in use in the file system, but that would introduce the 
delay upon uninstallation and eventually wouldn't avoid the pitfalls of file 
ownership preservation.

Couldn't MP use a higher numbered block of UID/GIDs instead of availability for 
user creation?

Re: Restoring from Time Machine backup relocates home directories

[db]

On 16 Sep 2017, at 16:03, Rainer Müller  wrote:
> As you just run it on your system, you know how long that will take.
> Clearly not an option to do this before/after every install/uninstall.

Only those that create users.

> And what would you gain from that? A free uid. They are not a scarce
> resource, so I do not think the effort would be justified.

A cleaner system. Users created by MP won't end up owning files from some other 
remaining user, as in the case mentioned.

Re: Restoring from Time Machine backup relocates home directories

[db]

On 15 Sep 2017, at 23:47, Ryan Schmidt  wrote:
> MacPorts and ports can add users, but MacPorts doesn't remove them. I'm not 
> sure how we could change that. Suppose you install a port that has a user 
> that needs to own some data, such as postresql96-server. You then uninstall 
> the port, which then hypothetically removes the user. Now the databases you 
> created with that port are owned by a userid that doesn't exist anymore. Now 
> you reinstall the port, which creates a postgres user but with a new userid. 
> This creates more work for the user: needing to reassociate files the port 
> needs with the new userid.

Shouldn't MP delete it if no files are owned by that user? In any case, it 
could notify during installation that a user was created and upon 
uninstallation that a user still owns files (and which) or not, and if not, it 
could give the option to delete it.

I searched for files owned by users created by two ports installed not long ago 
(quagga is still installed, dbus uninstalled) to find the following (just an 
example of a mess I now realised it's in place and I don't have a clue how it 
happened).

$ ls -l /Library/Screen\ Savers/Substrate.saver/Contents
total 16
-rw-r--r--@ 1 rootmessagebus   692 Apr 12  2010 CodeResources
-rw-r--r--@ 1 rootmessagebus  1491 Apr 12  2010 Info.plist
drwxr-xr-x@ 3 quagga  messagebus   102 Apr 12  2010 MacOS
drwxr-xr-x@ 3 quagga  messagebus   102 Apr 12  2010 Resources
drwxr-xr-x@ 3 quagga  messagebus   102 Apr 12  2010 _CodeSignature

AFAIR, I installed that screen saver by dragging and dropping, no installer.

MP could also checked if the UIDs/GIDs are already in use, before a port 
creates a user/group.

Re: Restoring from Time Machine backup relocates home directories

[db]

On 15 Sep 2017, at 18:06, Ryan Schmidt  wrote:
> Not always, because many ports use local variables when setting the home 
> directory, so you then have to find the place in the Portfile where that 
> local variable is set. And also, many ports split the add_users invocation 
> over multiple lines, such that the line that sets the home directory might 
> not be on the same line that includes the string "add_users".

I ran

dscl . list /Users | grep -v ^_.*

and noticed the user messagebus, so I filtered it from

port cat all

and realised that dbus set it, but MP didn't remove it when uninstalled.

MP should also take care of that.

Re: Restoring from Time Machine backup relocates home directories

[db]

On 15 Sep 2017, at 04:32, Ryan Schmidt  wrote:
> I recently reinstalled macOS and, during the setup process, restored from a 
> Time Machine backup. One would think that after restoration, the machine 
> would be in a state sufficiently similar to the one it was in at backup time, 
> but for our purposes, it is not, specifically with regard to user accounts.

May I assume that by macOS you mean 10.12?

Hasn't this problem already been reported in previous versions of OS X?

To prepare for the manual fix, would it be enough to run `port cat installed | 
grep add_user`?

Re: Switching cxx_stdlib for C++11 on legacy macOS

[db]

On 4 Sep 2017, at 20:16, Ken Cunningham  wrote:
> switch to libc++:
> Benefits:
> 1. most builds are identical to 10.9+, most portfiles need no changes.
> Drawbacks:
> 1. needs changes in macports infrastructure to support new buildbots and 
> pre-built binaries
> 2. poorly-written software or Portfiles do not spec the stdlib on the compile 
> line. Clang adds wrong default stdlib if we want libc++. Need to be manually 
> fixed, usually be adding the -stdlib to the compiler spec. (see botan).
> 3. bootstrapping issues - no getting around the LibCxxOnOlderSystems 
> instructions. Might be beyond some users.

Couldn't this be implemented with a transition phase in which broken ports are 
reported for users who depend on them? When I tested using libc++ it worked for 
the most part, except for 2 out of ~450 installed ports.

Re: Why does macports require a migration across major version bumps?

[db]

On 30 Aug 2017, at 20:29, Clemens Lang  wrote:
> Use 'sudo port -f selfupdate' instead, which should also recompile your
> version of MacPorts.

> In theory, reinstalling MacPorts and using 'sudo port -t upgrade
> outdated' after an OS update should thus have the same effect as the
> migration instructions.

Running these two commands would then leave you with a working system, except 
for those arch-dependent ports?

Re: get user's home

[db]

On 8 Aug 2017, at 02:12, Ryan Schmidt  wrote:
> path:-style dependencies are used when more than one port could satisfy the 
> dependency, in this case the development and stable versions of 
> bash-completion.


Thanks, that cleared it up.

Re ipfs, I left the startup item for the user to install (as I don't see a use 
of startup item for launch agents), corrected the go dependency and left the 
autocompletion as it was (never got feedback on copying to 
${prefix}/share/bash-completion/).

Re: get user's home

[db]

On 7 Aug 2017, at 23:03, Joshua Root  wrote:
> Dependency specifications are documented here: 
> 

I already read that too, but don't see why in case of docker-machine a path 
dependency makes more sense than a port one.

Re: get user's home

[db]

On 7 Aug 2017, at 20:03, Bradley Giesbrecht <pixi...@macports.org> wrote:
>> On Aug 5, 2017, at 3:55 AM, db <iams...@gmail.com> wrote:
>>> docker-machine's port, although I don't quite grasp what depends_run-append 
>>> exactly does there.
> Depends_run-appends adds to the depends_run variable.

That I knew so far, but docker-machine uses a path dependency in prefix for 
bash-completion.

depends_run-append path:etc/bash_completion:bash-completion

Does it mean that it checks if that shell script exists in order to run? What 
if it doesn't?

Re: get user's home

[db]

On 4 Aug 2017, at 22:58, Joshua Root  wrote:
> Suppose a port is built on the buildbot. The user is 'buildbot' and so the 
> value of $user_home will be something like '/Users/buildbot'.

During testing I didn't thoroughly checked that env var there. I suppose, it 
could be deleted or set to nil and left to the user to set it himself. As I 
said, I wrote the port for me, and uploaded it for others to test, as I 
couldn't figure out a (better) way to set it in the startup item and didn't 
find documentation on how macports would handle this case.

Re: get user's home

[db]

On 4 Aug 2017, at 16:05, Joshua Root  wrote:
> Should be in $user_home (if it could be determined, which is not guaranteed). 
> But why do you need it? The user installing the port is not necessarily the 
> one that will use it.

That worked, thanks. I used it for an env var's default value in ipfs' startup 
item (#54566). I don't know if we could pass a different value on install or 
load, for that matter. Everything's fine as in works_for_me. How come 
schraderbräu has it and macports not?

get user's home

[db]

How can I get the user's home, the flesh and blood bot's?

set home$::env(HOME)

righteously returns /opt/local/var/macports/home/

Re: reinplace first occurrence

[db]

On 3 Aug 2017, at 18:46, Ryan Schmidt  wrote:
> You could run a two-command sed manually (with system, not reinplace). Or 
> maybe you can use awk, or an ed script.

This works. Caveat emptor: || (empy RE) doesn't work and range seems to start 
on first line, not on its subsequent.

reinplace -E 1,/foo/s|foo|foo\\\n\\\tbar| file

> I can't remember anybody asking for this functionality (replace first 
> occurrence) before, so that's why there isn't an easy way to do it.

I needed to add disabled/true to a startup item provided by a port's source.

reinplace first occurrence

[db]

I checked portfile's man page and peaked at the source, but couldn't figure out 
yet, why these forms don't work.

https://stackoverflow.com/a/11458836/2167331

In the meantime, I worked around it, but I'd still like to know how to do it.

Re: recursively copy docs

[db]

On 29 Jul 2017, at 20:39, Ryan Schmidt  wrote:
> copy ${worksrcpath}/sphinx-doc ${destroot}${docdir}

That macro works, but file copy errored each time I tried it before.

recursively copy docs

[db]

I want to recursively copy a port's documentation which has nested dirs.

Is there any caveat for using

exec cp -R ${worksrcpath}/sphinx-doc ${destroot}${docdir}

instead of the more canonical form in the wiki?

https://trac.macports.org/wiki/PortfileRecipes#doc

Re: [GSoC] migration

[db]

On 27 Jul 2017, at 21:21, Bradley Giesbrecht  wrote:
> Migration will uninstall all installed ports and then install all the ports 
> from the snapshot

Yes, but I'm talking about using snapshot and restore at different times with 
ports being updated between them, likely resulting in different outcomes.

Re: [GSoC] migration

[db]

On 27 Jul 2017, at 00:35, Umesh Singla  wrote:
> Hi Josh
>> We don't have version dependencies so no, this sort of check is not possible 
>> a priori. Breakage will be caught by rev-upgrade after the fact in many 
>> cases (and if it is set to rebuild automatically, it may well revert you 
>> back to the newer version).

>> Also note that we can't actually revert to an older version of a port if it 
>> has been uninstalled.

Does it mean that snapshot just outputs a list of ports, deps and variants 
without their versions, so if I postpone the restore long enough, it'll 
reinstall current versions of all of them? I'm thinking here about the 
possibility of reinstalling a system or migrating between machines with same 
operating system and ending up with some broken ports.

Re: [GSoC] migration

[db]

On 22 Jul 2017, at 03:01, Umesh Singla  wrote:
> I don't know, in the above example, what do you mean when you say "..you 
> realize that from its deps..", like, realize how? I am just asking this if 
> there's some other way to get info on the latest modifications that I might 
> not be aware of.
> 'sync' or 'upgrade outdated' provide the information what all ports got 
> updated immediately on console but I'm not sure if it can be accessed later 
> since the user may not realize that another port has broken immediately, like 
> hstr here.

Since MP doesn't keep logs (!) I keep them myself and investigate when 
something doesn't work properly.

> Another thing that comes to my mind now is if, suppose, updated version of 
> ncurses was actually required for some another port and reverting it to the 
> older state could possibly result in breaking of that port.

No, because, as I said, it would revert to a previous tree state. The thing is 
doing it by reinstalling only the upgraded ports and not the whole tree. It 
shouldn't be difficult to implement.

Re: [GSoC] migration

[db]

On 21 Jul 2017, at 13:02, Umesh Singla  wrote:
> Unless we have a snapshot of the previous state, that is, before it got 
> hampered.
> But then again, we reinstall all the ports presently. At this time, it could 
> be hard for me to detect what went wrong while sync or upgrade.

If I understood you correctly it will presently reinstall all ports in a given 
snapshot.

I'm not saying that these commands should check for what went wrong during 
upgrade, but to reinstall only those whose upgrade caused another port to stop 
working as expected. The actual cause is for the user to find. For example, 
let's say you did upgrade outdated and hstr doesn't work anymore, but you 
realise that from its rdeps only ncurses was updated. Then you could use 
restore with the snapshot preceding the upgrade to just rollback the whole tree 
to that state by reinstalling in this case only ncurses and not hstr, readline, 
etc.

hstr
  pkgconfig
libiconv
  gperf
  ncurses
  readline