Re: Unable to build Xcode projects using SwiftPM in MacPorts sandbox

[Zero King]

Hi Ryan,

On Sat, Mar 23, 2024 at 11:19:03PM -0500, Ryan Schmidt wrote:

On Mar 23, 2024, at 23:00, Zero King wrote:


I think it could be base's sandbox that prevented writes to the home directory, 
where SwiftPM stores its cache.


If disabling sandboxing in macports.conf makes it work, then your suspicion is 
probably correct.


Yes, it was the sandbox. I set `sandbox_enable no` and this error was 
gone.



MacPorts sets the HOME environment variable to point to a directory within 
workpath. It looks like it's ignoring that and trying to write to a 
subdirectory of the macports user's real home directory, 
/opt/local/var/macports/home. That would be a bug to file with Apple. It has 
been a long-standing problem that has affected MacPorts in other ways before.


SwiftPM seems to prefer the "idiomatic" cache directory, which is 
constructed from FileManager's .cachesDirectory that points to 
Library/Caches.


https://github.com/apple/swift-tools-support-core/blob/930e82e5ae2432c71fe05f440b5d778285270bdb/Sources/TSCBasic/FileSystem.swift#L462
https://github.com/apple/swift-package-manager/blob/9d48dc70aab03a1824ee63abdf105212e08b1dbd/Sources/Basics/FileSystem/FileSystem%2BExtensions.swift#L241-L265
https://developer.apple.com/documentation/foundation/filemanager/searchpathdirectory/cachesdirectory

I'm not sure whether to file this as a bug. At its root is the 
FileManager, but I doubt Apple would change its API.


SwiftPM has a cache-path option that could be used to override the cache 
path, but I'm not sure how to use it in an Xcode project yet.


--
Zero

Unable to build Xcode projects using SwiftPM in MacPorts sandbox

[Zero King]

Hi,

As I try to package the latest commit of poedit, I encountered the 
following error:


Failed to determine if database is empty or not: Error Domain=NSCocoaErrorDomain Code=513 "You don’t have 
permission to save the file “org.swift.swiftpm” in the folder “Caches”." 
UserInfo={NSFilePath=/opt/local/var/macports/home/Library/Caches/org.swift.swiftpm, NSUnderlyingError=0x6010daa0 
{Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"}}Failed to determine if database is empty 
or not: Error Domain=NSCocoaErrorDomain Code=513 "You don’t have permission to save the file “org.swift.swiftpm” 
in the folder “Caches”." UserInfo={NSFilePath=/opt/local/var/macports/home/Library/Caches/org.swift.swiftpm, 
NSUnderlyingError=0x61e180c0 {Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"}}

I think it could be base's sandbox that prevented writes to the home 
directory, where SwiftPM stores its cache.


Any ideas?

--
Zero

Re: maintaining packages in macports vs. in a language package manager

[Zero King]

Hi Perry,

On Fri, Nov 17, 2017 at 08:40:49AM +0100, Mojca Miklavec wrote:

(2) Insist in installing separate ocaml-* packages as individual ports
and mostly ignoring what "opam" does (apart from maybe providing a
port for it). Note that we do have tools like "cpan2port" and
"pip2port" that help the developer to nearly automatically create a
package from CPAN or PyPI. For Perl and Python this is super
important. I don't know whether we have some super useful software
written in ocaml that is already packaged or that we would want to get
packaged. If the answer is yes, we should keep using this approach. If
the answer is no, there's no need to do this. It's definitely more
complex to do, but it gives you more freedom at the end.


I'm trying to package comby for MacPorts, but there are some missing
dependencies that are too labor-intensive to create by hand, especially for me
because I'm not familiar with OCaml packaging.

It seems that we are going with option 2 for ocaml ports now and many new ports
have being added. Are you aware of any tool like pypi2port that could help
speed up the process of packaging new ocaml ports for MacPorts?

--
Zero

Re: Github pipeline builds fail during dependency fetching

[Zero King]

Hi,

On Tue, Jun 01, 2021 at 02:57:47AM +0100, Chris Jones wrote:

Hi all,

I have noticed in the github pipeline builds whilst they appear to be green, if 
you delve into the logs they are failing due to fetch errors installing 
dependencies. See e.g. the builds for

https://github.com/macports/macports-ports/pull/11189

Two of the three builds only took 9 or 10 mins, whilst the third took 292mins. 
If you look at the short builds they fail fetching dependencies

https://dev.azure.com/macports/macports-ports/_build/results?buildId=14669&view=logs&j=ca395085-040a-526b-2ce8-bdc85f692774&t=08703039-49d0-5b78-7691-5b9414c62c1d

2021-05-31T09:24:25.8033970Z Installing dependency (1 of 440) 'bzip2' with 
variants '' (requesting '') ... [FAIL] (archivefetch)
2021-05-31T09:24:25.8073620Z ##[endgroup]
2021-05-31T09:24:25.8074850Z ##[error]Failed to install dependencies for 
gnss-sdr
2021-05-31T09:24:25.8101400Z 
/Users/runner/work/_temp/db2e5a8e-16ad-4272-a4bd-3e2473590f36.sh: line 4:  1383 Terminated: 
15  tail -f "$workdir/logs/dependencies-progress.txt" 2> /dev/null

Anyone know what is wrong here ?


This is https://trac.macports.org/ticket/62530. I think we should revert
to the old behavior of failing the build.

Re: Publicizing MacPorts

[Zero King]

On Mon, Apr 19, 2021 at 01:24:51PM +0200, Mojca Miklavec wrote:

On Mon, 19 Apr 2021 at 12:45, Steven Smith wrote:


If a comparable announcement to this was made for MacPorts, I missed it:

https://arstechnica.com/gadgets/2021/02/mac-utility-homebrew-finally-gets-native-apple-silicon-and-m1-support/


We never made any announcement since it basically "worked from day 1"
(almost), and we never had any specific point in time when support for
M1 was significantly improved. (We probably needed an upgrade of
MacPorts base, but that happened very soon.)

We should probably be publicising that MacPorts works just fine with
M1 more aggressively from the very beginning.


Ironically, MacPorts is claimed to have "initial or beta support" for
Apple silicon on https://isapplesiliconready.com/ (top search result for
"is m1 ready" on Google), while Homebrew is "fully compatible".


If anyone is willing to volunteer to do PR for MacPorts ...

Mojca

Re: Time to remove Travis support?

[Zero King]

On Fri, Nov 27, 2020 at 10:27:09PM +0100, Clemens Lang wrote:

Hi,

On Fri, Nov 27, 2020 at 04:24:01PM +, Zero King wrote:
[...]

Sure. Let's do it before end of the year. I'll see what I can do about
the build log comment, but GitHub Actions IPs have to be whitelisted
on paste.macports.org first.


From what I've seen, the GitHub Actions-based builds seems to have
enough storage so we can just avoid the pastebot completely?


I want to stay in the browser and have a direct link to view the logs I
need. Having to download and extract the zip file to find that log file
is not so convenient.

OTOH, we could implement a service that automatically pulls logs from
GitHub Actions and generated predictable URLs for viewing. In this way,
the service could go down for maintenance without missing any logs, and
the PR bot could reference these URLs before they are ready.


See for example [1], which produced 357 MB logs (27 MB zipped), and
doesn't seem to have a problem with it.


[1]: https://github.com/macports/macports-ports/actions/runs/386150389

Re: Time to remove Travis support?

[Zero King]

On Mon, Nov 02, 2020 at 08:14:17PM +0100, Mojca Miklavec wrote:

Hi,

If I understand correctly, we'll soon be unable to run any builds on
Travis unless we pay for it (they are gradually moving existing
customers to the new billing plan, so it's just a matter of time):
   https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing


The travis-ci.org platform we are using will be disabled on or after
Dec. 31st, 2020[1]. Given this new billing plan, I'd rather just remove
Travis CI from our repos.

Beware that we have other repositories under our organization that are
using travis-ci.org, and they have to migrate away as well. For example,
https://github.com/macports/macports-webapp.


We cannot say that this wasn't expected, so maybe it's time to put the
last nail in that coffin? I don't know if we can expand the OS version
list in any of the other services (GitHub Actions or Azure), but it's
ok even if we don't.


Sure. Let's do it before end of the year. I'll see what I can do about
the build log comment, but GitHub Actions IPs have to be whitelisted on
paste.macports.org first.

I'll keep Azure around for macOS-10.14, but I think Microsoft will
eventually unify build environments on Azure and GH Actions, and we will
keep just GH Actions for convenience.

Generation of CI tarballs from macports-base would have to be migrated
to other CI systems. If we can install .pkgs from the command line and
skip the initial sync (in the postflight script), we could throw it away
and just use official pkg installers.

[1]: 
https://docs.travis-ci.com/user/migrate/open-source-repository-migration#q-what-will-happen-to-travis-ciorg-after-december-31st-2020

Re: Problems with Darwin 20 tarballs ?

[Zero King]

On Tue, Nov 17, 2020 at 02:09:11AM +, Christopher Jones wrote:

Hi,
Is anyone else having problems installing tarballs from the new Darwin20 
builedbot ?


Yes, see https://trac.macports.org/ticket/61500.


Oberon-macOS-11 ~/Projects/MacPorts/ports > sudo port -v install llvm-9.0
--->  Computing dependencies for llvm-9.0.
--->  Fetching archive for llvm-9.0
Warning: Your DNS servers incorrectly claim to know the address of nonexistent hosts. 
This may cause checksum mismatches for some ports. See this page for more 
information: 
--->  llvm-9.0-9.0.1_1.darwin_20.x86_64.tbz2 doesn't seem to exist in 
/opt/local/var/macports/incoming/verified
--->  Attempting to fetch llvm-9.0-9.0.1_1.darwin_20.x86_64.tbz2 from 
https://packages.macports.org/llvm-9.0
 % Total% Received % Xferd  Average Speed   TimeTime Time  Current
Dload  Upload   Total   SpentLeft  Speed
100 45.9M  100 45.9M0 0  22.5M  0  0:00:02  0:00:02 --:--:-- 22.5M
--->  Attempting to fetch llvm-9.0-9.0.1_1.darwin_20.x86_64.tbz2.rmd160 from 
https://packages.macports.org/llvm-9.0
 % Total% Received % Xferd  Average Speed   TimeTime Time  Current
Dload  Upload   Total   SpentLeft  Speed
100   512  100   5120 0  23272  0 --:--:-- --:--:-- --:--:-- 23272
--->  Installing llvm-9.0 @9.0.1_1
tar: ./+CONTENTS: Not found in archive
tar: Error exit delayed from previous errors.
Error: Failed to install llvm-9.0: child process exited abnormally
Error: See 
/opt/local/var/macports/logs/_Users_chris_Projects_MacPorts_ports_lang_llvm-9.0/llvm-9.0/main.log
 for details.
Error: Follow https://guide.macports.org/#project.tickets to report a bug.
Error: Processing of port llvm-9.0 failed
Whats also a little odd is if I go to

https://packages.macports.org/llvm-9.0/ 


I cannot actually see the tarball just downloaded ?


It was purged by Ryan.


Chris

Re: Travis CI timeouts for MacPorts builds

[Zero King]

On Tue, Sep 08, 2020 at 10:12:08PM +0200, Mojca Miklavec wrote:

On Tue, 8 Sep 2020 at 20:49, Zero King wrote:


> I forgot why we never switched from Azure to GitHub Actions.

Done in commit db7b40d8691e1fcd8b6be5e3c2a2a00a7ce0bdf4. We should
remove Travis CI and Azure Pipelines soon.


Awesome, thank you very much!

I'm just confused about one thing. The docs says that only 10.15 is supported:
   
https://docs.github.com/en/actions/reference/virtual-environments-for-github-hosted-runners
while the github actions lists 10.14. Is the truth somewhere inbetween?


GitHub Actions and Azure Pipelines share the same infrastructure, so in
fact both 10.14 and 10.15 are supported.

https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=azure-devops

I have disabled Travis failures, so PRs failing on Travis will not cause
errored checks anymore. macOS 10.15 is added to the Actions workflow,
and I will remove the Azure Pipelines integration if it is proven stable
and gets pastebin integration.

GitHub Actions can trigger webhook events, and go-github have added
support for Actions related APIs, so it should be easier to implement
the CI result comment with GitHub Actions than Azure Pipelines or
Travis.

However, GitHub Actions does not provide a list of IP addresses
AFAIK, so integration with paste.macports.org would be difficult. Maybe
I should just use the other pastebin and hardcode the URL into mpbot-ci
to avoid it being inherited in macports-ports forks, but that would
make paste.macports.org useless (at least for CI).

[1] 
https://docs.github.com/en/developers/webhooks-and-events/webhook-events-and-payloads#workflow_run
[2] https://github.com/google/go-github

On Tue, Sep 08, 2020 at 10:42:57PM +0200, Clemens Lang wrote:

GitHub Actions' IPs should be added to the pastebin allowlist. Logs
are uploaded as artifacts, but they are zipped[1], so uploading to
paste.macports.org is still preferred.


Is there a documented IP block used by GitHub Actions?


Unfortunately, I have not found any documentation about that in their
docs, but the Azure Pipelines docs did mention that they were
investigating options.

"Our Mac IP ranges are not included in the Azure IPs above, though we
are investigating options to publish these in the future."

On Tue, Sep 08, 2020 at 10:51:31PM +0200, Mojca Miklavec wrote:

On Tue, 8 Sep 2020 at 22:43, Clemens Lang wrote:

On Tue, Sep 08, 2020 at 06:48:58PM +, Zero King wrote:
> On Tue, Sep 08, 2020 at 06:39:41PM +0200, Mojca Miklavec wrote:
> > After a while Azure came around with 6 hours of timeout which was a
> > lot more useful, and the same solution was ported from Travis to
> > Azure. I forgot why we never switched from Azure to GitHub Actions.
>
> Done in commit db7b40d8691e1fcd8b6be5e3c2a2a00a7ce0bdf4. We should
> remove Travis CI and Azure Pipelines soon.

I'm not sure this was a good choice. GitHub recently announced stricter
limits on CPU minutes available though GitHub actions.


I was only aware of GitLab decreasing the limits. According to
https://docs.github.com/en/github/setting-up-and-managing-billing-and-payments-on-github/about-billing-for-github-actions
we have 200 free minutes per month? That's literally useless if true.


The 2,000 minutes limitation only applies to private repositories.


(It's not clear to me whether Azure will stay free forever. We should
probably be looking into setting up our own builders in the long run.)


That's true, but we need a volunteer and hardware resources.


Mojca

Re: Travis CI timeouts for MacPorts builds

[Zero King]

Hello,

On Tue, Sep 08, 2020 at 06:39:41PM +0200, Mojca Miklavec wrote:

On Mon, 7 Sep 2020 at 20:25, Ralph Seichter wrote:

If you ignore Travis results, why run Travis CI in the first place?


Travis was the first CI that we supported for pull requests.
@l2dy wrote the initial support as a GSOC project which included
writing tons of workarounds for Travis limitations.
He redirected output to pastebin in order to be able to even show it
(most of our output exceeds the Travis limit for how long the log can
be), he had to inject bogus writes to prevent Travis from thinking
that the job was stuck, he implemented a lot of tricks to ensure that
the bootstrapping phase was as fast as possible, ... but we could not
change the time limit itself.

After a while Azure came around with 6 hours of timeout which was a
lot more useful, and the same solution was ported from Travis to
Azure. I forgot why we never switched from Azure to GitHub Actions.


Done in commit db7b40d8691e1fcd8b6be5e3c2a2a00a7ce0bdf4. We should
remove Travis CI and Azure Pipelines soon.

GitHub Actions' IPs should be added to the pastebin allowlist. Logs are
uploaded as artifacts, but they are zipped[1], so uploading to
paste.macports.org is still preferred.

[1]: 
https://github.com/actions/upload-artifact/blob/v2/README.md#zipped-artifact-downloads


It's not that Travis is completely ignored. There are some useful
cases, like this one for example:
   https://travis-ci.org/github/macports/macports-ports/builds/724968783
(I checked a random failed build from the recent PRs.)

You can see that the build passed on 10.14, but failed on 10.11 up to
10.13. It failed quickly with
   "Xcode 9.0 or greater is needed to build carthage; only found
version 7.3.1."
which is something that the portfile should have declared and it
should have at least failed in pre-fetch phase already (ideally we
would need a declarative syntax for this).

This case is useful. Now, we do have Azure build for 10.13, so this
one is overlapping (and we should probably remove that one), but
there's no builder for 10.11 and 10.12 on Azure.

In reality most of the Travis build failures fall into two categories:
- timeout (most of the time)
- network or timing issues (sources could not be fetched with "server
not found", or the clocks didn't match, and MacPorts refuses to run if
file appear to be "from the future")

As far as I know there were attempts to address both of these. Timeout
will always be the case when a single PR touches many ports, or where
ports are simply time-consuming to build (no chance for Qt, ...) There
might be room for improvement as far as build time of dependencies is
concerned though.

On Tue, 8 Sep 2020 at 18:28, Ryan Schmidt wrote:

On Sep 7, 2020, at 11:24, Ruben Di Battista wrote:

> Would à Linux machine with some virtualization method (libvirt?) be 
acceptable as CI runner?

I can't see how, since we're trying to verify builds of ports, and there is no 
general expectation that port builds would work on non-Mac operating systems.


We are not talking about running the builds on Linux, but running the
virtual machines on Linux, and if wasn't for the legal reasons, this
would be a perfectly viable solution (provided you get all the VMs
working, to start with). But if you get it working on linux for
testing purposes, a very similar recipe might work on macOS.

Mojca

Re: PRs now going back 18 months -- let's close the clearly dead ones

[Zero King]

On Sat, Jul 25, 2020 at 01:38:58PM -0700, Ken Cunningham wrote:

There are ancient PRs that are never going to be committed in the queue.

This is just noise, and prevents us from keeping things moving.

The people who opened them seem attached to them, but they are clearly dead and 
need to be closed.

If in agreement, can one of the admins close the 50 oldest ones at least and 
let’s move on to something we can focus on.


No comment on this, but we could use the official stale GitHub Action to
automate that: https://github.com/actions/stale.


We don’t want the PR queue to start to look like the (ridiculous) ticket list, 
with dormant open tickets going back decades.

Ken

Re: Outage of braeburn.macports.org

[Zero King]

CC mailing lists.

On Sun, Aug 18, 2019 at 01:58:36PM +, Zero King wrote:

Hi Rainer,

On Sat, Aug 17, 2019 at 11:45:06AM +0200, Rainer Müller wrote:

Hello,

according to monitoring, braeburn went down at 2019-08-17 06:10 UTC for an
unknown reason. When I noticed the downtime, I was unable to find out any more
clues and issued a hardware reset of the server some time at around 09:30. It
booted normally and logs had no hint to what had happened.

All services should be back now. Please let us now if anything is not working.


The prbot.service is down. Please try to start it.


Rainer


On Sun, Aug 18, 2019 at 02:40:10PM +0100, Christopher Jones wrote:

Hi All,

Anyone know why GitHub no longer seems to be automatically setting labels on 
new pull requests ?

https://github.com/macports/macports-ports/pulls 
<https://github.com/macports/macports-ports/pulls>

?


Because braeburn was down and the bot didn't recover.


Chris





--
Zero




--
Zero


signature.asc
Description: PGP signature

Re: Setting up port builds on Azure using master branch of macports

[Zero King]

On Thu, Aug 08, 2019 at 08:59:46PM +0200, Rainer Müller wrote:

On 04/08/2019 17.34, Ryan Schmidt wrote:

On Aug 1, 2019, at 10:50, Blair Zajac wrote:


Why Azure?


We already use Azure to test pull requests, but we test against the released 
version of MacPorts base, currently 2.5.4. I guess Mojca is suggesting we add 
another builder that uses the newer MacPorts base master, to discover if some 
ports are not compatible with that.

We also already use Travis CI for pull requests, but Travis was purchased by 
another company known for allowing its services to languish and die, hence our 
desire to find alternatives.

It would need to be free and support building on macOS with root access and not 
have such a low time limit that our builds would time out. Travis for example 
has a time limit of 50 minutes which has already been problematic for some 
ports. If you know of other services that offer that, let us know.


GitHub announced GitHub Actions today, which is a CI system provided for free on
public repositories. It even supports macOS.

https://github.blog/2019-08-08-github-actions-now-supports-ci-cd/

However, the announcement does not mention any limits such as the maximum
per-job execution time, which has been our main problem with other services so
far. I guess this might be something they will still try to figure out during
the beta.


The default limit is 360 minutes. Not sure if it could be extended.

https://help.github.com/en/articles/workflow-syntax-for-github-actions#jobsjob_idtimeout-minutes


In any case, it might be worth a try. It will be available in November for
everyone. Just in case anyone wants to experiment with it earlier, I signed up
the @macports organization for the GitHub Actions Beta and we are now on the
waitlist.

Rainer


--
Zero


signature.asc
Description: PGP signature

Re: Is owner of macports.zulip.org here?

[Zero King]

On Sat, Jun 22, 2019 at 07:53:53AM +0200, Mojca Miklavec wrote:

Hi,

I wonder if the owner of macports.zulip.org is on this mailing list.


macports.zulip.org doesn't seem to exist, but I'm the admin of
https://macports.zulipchat.com/. 


Thank you,
   Mojca


--
Zero

Re: azure pipelines consistently failing

[Zero King]

On Wed, May 01, 2019 at 12:30:18PM +, Zero King wrote:

On Wed, May 01, 2019 at 10:19:53AM +0100, Chris Jones wrote:

Hi,

I've noticed over the last day or so the azure checks in PRs are 
consistently failing, e.g.


https://github.com/macports/macports-ports/pull/4225
https://github.com/macports/macports-ports/pull/4224
https://github.com/macports/macports-ports/pull/4220

I don't believe the problem is with the ports, but something is up 
with the framework itself. The failures are always very similar.


Could someone who knows how this stuff works take a look ?


Looks like Azure Pipelines service in West Europe region is degraded:
https://status.dev.azure.com/_event/117874362.



We forced a re-download of the corrupted file and propagated it across the 
impacted pools, and this has caused the machines to work properly now. The 
issue impacted pipelines for some MacOS pools in the West Europe region. The 
issue started at 2019-04-30 14:45 UTC and was resolved at 2019-05-01 12:20 UTC


Is it working now?


Not sure if it's related to build failures though.


cheers Chris


--
Zero




--
Zero


smime.p7s
Description: S/MIME cryptographic signature

Re: azure pipelines consistently failing

[Zero King]

On Wed, May 01, 2019 at 10:19:53AM +0100, Chris Jones wrote:

Hi,

I've noticed over the last day or so the azure checks in PRs are 
consistently failing, e.g.


https://github.com/macports/macports-ports/pull/4225
https://github.com/macports/macports-ports/pull/4224
https://github.com/macports/macports-ports/pull/4220

I don't believe the problem is with the ports, but something is up 
with the framework itself. The failures are always very similar.


Could someone who knows how this stuff works take a look ?


Looks like Azure Pipelines service in West Europe region is degraded:
https://status.dev.azure.com/_event/117874362.

Not sure if it's related to build failures though.


cheers Chris


--
Zero


smime.p7s
Description: S/MIME cryptographic signature

Re: fake azure pipeline failures

[Zero King]

On Sat, Mar 23, 2019 at 12:30:36PM -0500, Ryan Schmidt wrote:



On Mar 23, 2019, at 04:45, Christopher Jones wrote:


Also, it makes no sense the travis builds timeout - The build should not take 
anything close to 50mins - and again these builds seem to offer no explanation  
in any log I can find as to why they timeout, i.e. what’s exactly where they 
doing at the time they stopped ?


I agree. I do not know why more detailed logs are not being uploaded from 
Travis for these builds.


Our CI bot (build runner) receives complete messages from a Go channel,
so it doesn't support streaming. However unless the runner is aware of
when the build would time out (even just approximately), the best way to
provide more insight before the build gets killed (because of timeout)
is to stream the output to the Travis log, which would require some code
refactoring. I did add the empty *-start messages to indicate roughly
what the bot is doing.

BTW, in Azure Pipelines, if a build stage times out its log would become
unavailable (e.g. [1]). We can workaround this by making the runner exit
before the build times out. But of course it would be best for Microsoft
to fix this bug.

[1] https://dev.azure.com/macports/macports-ports/_build/results?buildId=601


P.S: Remember to use lists.macports.org list addresses, not the older ones. 
Although the old addresses forward to the new ones, some users cannot see those 
forwards due to the way their email providers' servers are configured.



--
Zero


smime.p7s
Description: S/MIME cryptographic signature

Season of Docs from Google Open Source

[Zero King]

Hi,

Google recently announced Season of Docs[1], "a new program which
fosters the open source contributions of technical writers".
Organization applications open on April 2, 2019 at 20:00 UTC[2], should
we apply for this chance to improve our documentation?

[1] https://opensource.googleblog.com/2019/03/introducing-season-of-docs.html
[2] https://developers.google.com/season-of-docs/docs/get-started/

--
Zero


smime.p7s
Description: S/MIME cryptographic signature

Re: Mail delivery of macports-changes disabled for Gmail users

[Zero King]

On Mon, Feb 25, 2019 at 08:53:12PM +0100, Rainer Müller wrote:

Hello,

if you are using Gmail or a Google hosted mail service for your domain,
your subscription to the macports-changes mailing list was likely
disabled on 2019-02-22 by mailman due to "excessive or fatal bounces".

If you still want to receive the mailing list, but are currently not
getting the emails, you have to take manual action. Please follow the
link below to the mailman options. After logging in, check that the
option "Mail delivery" is Enabled for your account.

https://lists.macports.org/mailman/options/macports-changes


The technical cause of this was an email being rejected by Google due to
a strict DMARC policy for the From address. The way Google handled this
was correct as this mail was in fact not originating from a source
whitelisted by the domain owner of the From address.

Although we configured all our lists on mailman exactly for this reason
with dmarc_moderation_action="Munge From" [1], we now discovered that
this setting is an action that only applies to mails going through the
moderation queue. However, as posting to macports-changes is meant to be
restricted, legitimate mails are pre-approved. As we have learned now,
skipping the moderation unfortunately also skips the DMARC munging that
was supposed to prevent such bounces.

In order to prevent this from happening again, I would like to no longer
sent mails with the author's address as From, but use a generic From
address and merely the author to CC. Unless someone else comes up with a
better idea, I will look into applying this in the next days.


CCing the author would send the email to them, right? I don't want to
receive these emails, and PR authors could be confused when receiving
these emails.


Rainer

[1] https://www.gnu.org/software/mailman/mailman-admin/sender-filters.html


--
Zero


smime.p7s
Description: S/MIME cryptographic signature

Re: Testing an idea

[Zero King]

On Sun, Feb 10, 2019 at 02:26:14AM +0100, Eric F (iEFdev) wrote:

Hi,

I had this idea I want to test here. When creating a Portfile and adding:
maintainers - only GitHub is recognized when adding a username like “@fooBar”.
One *could* cheat and use:

In Portfile:   maintainers{GitHost:\ @fooBar}
With "port info":  Maintainers:   Email: GitHost: @fooBar


So, I was thinking it would be great with an optional syntax to be able to add a
couple of Git host services: GitLab and Bitbucket (= the 3 big ones), so one
could use something like:

/# just as a test to get the output:/
In Portfile:   maintainers@fooBar @gh:Foo @gl:Bar @bb:Baz
With "port info":  Maintainers:   GitHub: fooBar
 GitHub: Foo
 GitLab: Bar
 Bitbucket: Baz

I've tested the prefixes by changing “macportports_utils.tcl”, but using github
for all when setting the maintainer, so the part of picking up the prefixes
works. And then I guess it just needs the 2 additional entries to port.tcl. I
haven't tested that part.

Would that be a good idea?
Or maybe it's already been discussed earlier.


I believe the maintainers field is used to contact the maintainer,
either via email or by mentioning (@) the user on GitHub. We can't
contact one with their GitLab or Bitbucket account in our PRs or Trac
tickets, so I think other Git hosting services are not relevant here.

If in the future we switch to another service for issue/PR tracking, we
may adopt a transitional scheme like this though.


· Eric

/// I put a patch here if you want to have a look/test it. Since it's not tested
- see it
// more as a conceptual patch, to visualize the idea: https://git.io/fhHHA/



--
Zero


smime.p7s
Description: S/MIME cryptographic signature

Re: Feature requests for CI bot

[Zero King]

On Sun, Feb 03, 2019 at 04:59:57PM +0100, Mojca Miklavec wrote:

Dear Zero,

Last time you asked for feature requests for our bot :)

Here are some from me:
- I would like to see the same kind of user-friendly report from Azure
as we get from Travis.


I'll try. Azure Pipelines doesn't provide an official API, but I think I
can use the GitHub check API to get the UUID (e.g.
b674ed54-8ab2-4ec0-8010-7d35a798a53c) and buildId (128), and then
download this log.

https://dev.azure.com/macports/b674ed54-8ab2-4ec0-8010-7d35a798a53c/_apis/build/builds/128/logs/7?$format=text&api-version=5.0-preview


- I sometimes add additional commits, usually revbumping some
dependent ports. I would like to know how to @mention the maintainers
of ports modified in those laster commits (at least
semi-automatically).


Try "@macportsbot retry", only members have permission to avoid abuse,
but we can change that.


Thank you very much,
   Mojca


--
Zero


smime.p7s
Description: S/MIME cryptographic signature

Re: Boost: why "--layout==tagged"?

[Zero King]

On Fri, Feb 01, 2019 at 06:11:16PM -0600, Ryan Schmidt wrote:



On Feb 1, 2019, at 15:30, Michael Dickens wrote:


OK yes we -offer- multiple versions, but only one version can be installed at a 
time right now.


No, if you install boost without the no_single variant, you will get both the 
single-threaded and the multithreaded versions. If you install without the 
no_static variant, you will get both the static and the dynamic libraries. So 
if you install without both variants, you'll get all four.



I firmly believe that the vast vast majority of folks pick their Boost variant 
and stick with it through the lifetime of that Boost version if not the whole 
MacPorts install. The number of folks who actively switch between Boost 
variants is IMHO very very small.


Oh I'm sure most users install the port with the default variants, which is to 
say that they only have the dynamic multithreaded version. If we're sure nobody 
needs the other versions we can do what you suggest. But I'm not sure of that; 
I have no data. And what you're proposing to do involves work, including 
removing the suffix from all the ports that are hardcoding it.


There are guides on GitHub asking the user to install boost with
-no_static. Search results here: 
https://github.com/search?q=port+install+boost+-no_static&type=Code

For example:

https://github.com/VowpalWabbit/vowpal_wabbit#manual-install-of-vowpal-wabbit
https://github.com/rime/squirrel/blob/master/INSTALL.md

and https://github.com/kbase/data_api:


E.g. the boost library needs to be installed as -no_static, because the
default +no_static install conflicts with thrift and possibly other
packages.


--
Zero


smime.p7s
Description: S/MIME cryptographic signature

Re: WorkSrcDir Question

[Zero King]

On Sat, Oct 27, 2018 at 08:53:55PM -0400, Mark Anderson wrote:

I got this:
github PortGroup: Error: ${worksrcpath} does not exist after extracting
distfiles. This might indicate that the author or project is different than
set in the Portfile due to a rename at GitHub. Please examine the extracted
directory in
/opt/local/var/macports/build/_opt_src_macports_macports-ports_lang_Io/Io/work
and try to correct the Portfile by either changing the author or project or
adding the worksrcdir option with the correct directory name.

How do I get a worksrcdir of IoLanguage-io-b8a18fc/


Upstream moved their repository, you should use "github.setup IoLanguage io 
..." now.

(from https://github.com/stevedekorte/io to https://github.com/IoLanguage/io)


Do I have to change the Name of the Port? I run with Debug and couldn't see
what happened.

—Mark
___
Mark E. Anderson 


On Sat, Oct 27, 2018 at 5:23 PM Ryan Schmidt 
wrote:




On Oct 27, 2018, at 16:09, Mark Anderson wrote:

> So, I'm trying to update the Io Language port, and I get a worksrcdir of:
> IoLanguage-io-b8a18fc
>
> Is there a good way to figure that name out programatically, or change
it? Or am I just stuck with it?


The github portgroup, which I see the io port already uses, takes care of
that for you. It renames the directory to something more predictable.





--
Zero


smime.p7s
Description: S/MIME cryptographic signature

Re: Verify domain for github.com/macports

[Zero King]

On Tue, Oct 23, 2018 at 08:05:21PM +0200, Rainer Müller wrote:

On 2018-10-23 12:18, Zero King wrote:

GitHub now supports verifying organization's domain[1], and Homebrew
verified their brew.sh[2]. Should we verify ours too?


macports.org is now verified for the MacPorts organization.


Thanks. This would prove that we @macports.org own the MacPorts
organization on GitHub, and vice versa.


Rainer


--
Zero


smime.p7s
Description: S/MIME cryptographic signature

Verify domain for github.com/macports

[Zero King]

Hi,

GitHub now supports verifying organization's domain[1], and Homebrew
verified their brew.sh[2]. Should we verify ours too?

[1] https://help.github.com/articles/verifying-your-organization-s-domain/
[2] https://github.com/Homebrew

--
Zero


smime.p7s
Description: S/MIME cryptographic signature

Re: Merging pull requests before 72 hours

[Zero King]

On Mon, Oct 15, 2018 at 02:16:48PM +0100, Chris Jones wrote:

Hi,

[...]


If these sorts of things aren't okay to merge pretty quickly, then
why do we have an openmaintainer designation at all? I mean, if
there's really no distinction in how you treat an openmaintainer and
a non-openmaintainer port, why have openmaintainer? Why not just have
everything closed maintainer?


The way I view openmaintainer is ports that are labeled as such can 
have (non trivial) PRs applied to them, *once the 72 hour timeout has 
expired*, without the explicit consent of the maintainer, as long as 
some sort of agreement of other members that the update is reasonable 
is reached. But the 72 hour timeout should always be adhered to for 
anything that does not classify as 'trivial' (whatever the rules are 
for this).


"If a port's maintainer contains the address
, this means that the author allows minor
updates to the port without contacting him first. But permission should
still be sought for major changes."

According to our guide, 'minor' updates to the openmaintainer port
doesn't need to wait for the 72-hour timeout, it's not even required to
notify the maintainer.

"A critical port is broken that affects many users."

We often do revbumps without contacting the maintainer if a dependency
update causes breakage.

My two cents:

We also need to clarify what changes can be committed immediately
without maintainer review (even if not openmaintainer), e.g. security
fixes that doesn't break the port or its dependents. I would consider
fixing broken ports, addressing security issues and certain trivial
changes (e.g. fixing typos in comments and broken livecheck, updating
redirected or dead URLs and revbump broken ports) for this category.

I do agree though, as Mojca has already brought up, that perhaps we 
should consider getting rid of the 'openmaintainer' tag and instead 
consider everything open by default, unless explicitly flagged as 
'closedmaintainer'. This could also be used as an opportunity to 
review which ports really need to be closed...


Chris




Perry



--
Zero


smime.p7s
Description: S/MIME cryptographic signature

Re: Merging pull requests before 72 hours

[Zero King]

On Mon, Oct 15, 2018 at 09:58:59AM +0100, Chris Jones wrote:

Hi,

On 15/10/18 06:41, Joshua Root wrote:

I agree with the points in Mojca's first message in the thread.

On 2018-10-15 09:20 , Mojca Miklavec wrote:

On Mon, 15 Oct 2018 at 00:10, Blair Zajac wrote:


We could add a rule that should help a bit that openmaintainer only lets people 
do minor version bumps, e.g. X.Y to X.(Y+1) and X.Y.Z to X.Y.(Z+1). This 
doesn’t solve the Lua 5.2 to 5.3 one, but it would prevent the Python 2.7 to 
3.7.


This is pretty useless general strategy as a general rule because
every project does the versioning in a different way. If we were to do
it this way, then every single port would need to specify what
precisely is allowed (to which versions it is ok to update).


Perhaps we could add a checkbox for "I have verified that this update
does not introduce any API or ABI incompatibilities." I expect
contributors would be unlikely to check that off untruthfully.


I think in practise that is also not possible to always be determined, 
nor I think should we make it a requirement of those submitting the 
PRs to do it, as all it would become is a barrier to people submitting 
contributions and we don't want that.


In my opinion, if the version of the package being installed changes 
at all, the 72 hour timeout should apply.


We also I think need a clear set of guidelines of exactly what sort of 
changes are allowed to be made without PR review, or sidestepping the 
72 hour timeout . e.g.


- Changes that cannot in any way alter the installed port. Like 
livecheck fixes, comments or descriptions.


- rev-bumps just to rebuild against some other change.

- Urgent bug fixes for otherwise broken ports.

and so on... Do we have a guide for something like this written done 
anywhere ?


"7.4.1. Non-Maintainer Port Updates" in our guide.
https://guide.macports.org/#project.update-policies.nonmaintainer


Chris



- Josh



--
Zero


smime.p7s
Description: S/MIME cryptographic signature

Re: Excluding obsolete port(groups) from Travis builds

[Zero King]

On Fri, Sep 07, 2018 at 03:26:21PM +0200, Mojca Miklavec wrote:

Dear Zero,

Would you be willing to implement exclusion of obsolete ports and
portgroups from Travis builds?


Please review https://github.com/macports/mpbb/pull/7 then. Please don't
merge it though, I'd rather push it directly because it's no longer
considered a hack.


Thank you,
   Mojca


--
Zero


smime.p7s
Description: S/MIME cryptographic signature

Re: squash and merge, license documentation, "size" documentation

[Zero King]

On Fri, Aug 17, 2018 at 09:44:47AM -0400, Perry E. Metzger wrote:

As many of you are aware, I merge a significant fraction of the pull
requests these days. A few requests to make it easier, these three
things on their own represent a surprising fraction of the
communication I need to have with contributors:

1. We have squash and merge disabled. This means that I often have to
coach people through doing the squash on their own. If we enabled
that, often it would not be necessary because I could do it for them.
Is there a good reason we have that disabled?


None, AFAIK. See also this thread 
https://marc.info/?l=macports-dev&m=151901677718048&w=2.


2. The guide has poor documentation on what license strings are
acceptable, and port lint doesn't check that the license string is
an acceptable string. If these were fixed, it would be much easier to
direct people to the correct license string etc.


I would check https://trac.macports.org/wiki/PortfileRecipes#licensekeyword.


3. There's no real documentation of the "size" parameter to
checksums, and I'm constantly asking people to add the size. Note
that I don't think "size" is a reasonable thing to require given that
finding two files of the same size with the same SHA-2 hash is
probably worth a doctoral dissertation at this point, but if we are
going to require it (why do we require it?), it should be documented,
and port lint should complain that it isn't there, and doing
port -v checksums should spit it out if it isn't there.


`port -v checksums` does so if any one of the checksums is incorrect.


Perry
--
Perry E. Metzgerpe...@piermont.com


--
Zero


smime.p7s
Description: S/MIME cryptographic signature

Re: Has anyone else been dropped?

[Zero King]

Hi,

GitHub pull requests are delivered by GitHub, not our mailing list.

On Sun, Aug 12, 2018 at 04:09:12PM -0400, Mark Anderson wrote:

I seem to have been dropped off the list and and I can't resubscribe.
—Mark
___
Mark E. Anderson 


--
Zero


smime.p7s
Description: S/MIME cryptographic signature

Re: Online Meeting 2018-05-26

[Zero King]

On Fri, May 25, 2018 at 11:14:51PM +0200, Clemens Lang wrote:

Hi,

On Fri, May 25, 2018 at 04:50:48PM +0200, Rainer Müller wrote:

in our last meeting, we scheduled the next meeting to be tomorrow,
2018-05-26 13:00 UTC. However, this seems to have fallen off the
radar, because we have not set any agenda yet...

One point would be the website-related topics that we postponed in the
last meeting due to time constraints.

Should we still hold the meeting or reschedule?


I won't be able to join, so I'd vote for reschedule – but then again I
already announced last time that I would maybe not be able to join, so
if there's a group, feel free to do the meeting anyway.


Should we reschedule another meeting this month?

--
Zero


smime.p7s
Description: S/MIME cryptographic signature

Re: MacPorts 2.5.0-beta1 now available for testing

[Zero King]

Hi,

On Thu, May 10, 2018 at 03:58:11PM +1000, Joshua Root wrote:

Source code and pkgs for MacPorts 2.5.0-beta1 are now
available [1]. Testing of either of these install methods is helpful.


Now that 2.5.0 is released, we should protect the release-2.5 branch in
macports-base to disable force pushing and prevent it from being deleted
accidentally.

--
Zero


smime.p7s
Description: S/MIME cryptographic signature

Re: MacPorts 2.5.0-beta1 now available for testing

[Zero King]

On Fri, May 25, 2018 at 02:05:00PM -0500, Ryan Schmidt wrote:


On May 25, 2018, at 12:57, Zero King wrote:


On Thu, May 17, 2018 at 11:36:39PM +1000, Joshua Root wrote:

It's been a week with no new tickets filed against base. I'll give it
one more week and then, if nothing comes up, tag a release candidate.

- Josh


I tried the rc1, and unar is now "broken". How can I fix it?

unar is using libstdc++ (this installation is configured to use libc++)
Error: Port unar is still broken after rebuilding it more than 3 times.


It's "broken" in that it links with libstdc++, even though MacPorts believes it will link 
with libc++ on your system. The rev-upgrade code in previous versions of MacPorts did not check for 
this kind of "broken".

Fix it by fixing the build system to use the right C++ standard library (the 
one in the ${configure.cxx_stdlib} variable).


Thanks, fixed in 
https://github.com/macports/macports-ports/commit/90b64720a4c3c4f400c4f2eaeee8b0071232ea30.

--
Zero


smime.p7s
Description: S/MIME cryptographic signature

Re: MacPorts 2.5.0-beta1 now available for testing

[Zero King]

Hi,

On Thu, May 17, 2018 at 11:36:39PM +1000, Joshua Root wrote:

It's been a week with no new tickets filed against base. I'll give it
one more week and then, if nothing comes up, tag a release candidate.

- Josh


I tried the rc1, and unar is now "broken". How can I fix it?

unar is using libstdc++ (this installation is configured to use libc++)
Error: Port unar is still broken after rebuilding it more than 3 times.

--
Zero


smime.p7s
Description: S/MIME cryptographic signature

Re: [macports-ports] 01/02: py-diff-match-patch: new port, version 20121119

[Zero King]

On Fri, May 11, 2018 at 12:07:38PM -0500, Ryan Schmidt wrote:


On May 10, 2018, at 20:37, Zero King wrote:


Zero King (l2dy) pushed a commit to branch master
in repository macports-ports.


https://github.com/macports/macports-ports/commit/5836a5624ac40d04cb12a73c4ef219c377100a16

commit 5836a5624ac40d04cb12a73c4ef219c377100a16

Author: Zero King
AuthorDate: Fri May 11 01:35:20 2018 +


py-diff-match-patch: new port, version 20121119

---
 python/py-diff-match-patch/Portfile | 33 +
 1 file changed, 33 insertions(+)


diff --git a/python/py-diff-match-patch/Portfile 
b/python/py-diff-match-patch/Portfile
new file mode 100644
index 000..a7cc717
--- /dev/null
+++ b/python/py-diff-match-patch/Portfile




+master_sites
https://files.pythonhosted.org/packages/22/82/46eaeab04805b4fac17630b59f30c4f2c8860988bcefd730ff4f1992908b


We don't want to use this style of URL, which needs to be updated every time the port's 
version is updated. Can the "pypi" fetch group be used instead?


Fixed: 
https://github.com/macports/macports-ports/commit/66b1693df04a79df4dc4538b8136c5221ae37945

--
Zero


smime.p7s
Description: S/MIME cryptographic signature

Re: [macports-ports] 01/02: py-diff-match-patch: new port, version 20121119

[Zero King]

On Fri, May 11, 2018 at 12:07:38PM -0500, Ryan Schmidt wrote:


On May 10, 2018, at 20:37, Zero King wrote:


Zero King (l2dy) pushed a commit to branch master
in repository macports-ports.


https://github.com/macports/macports-ports/commit/5836a5624ac40d04cb12a73c4ef219c377100a16

commit 5836a5624ac40d04cb12a73c4ef219c377100a16

Author: Zero King
AuthorDate: Fri May 11 01:35:20 2018 +


py-diff-match-patch: new port, version 20121119

---
 python/py-diff-match-patch/Portfile | 33 +
 1 file changed, 33 insertions(+)


diff --git a/python/py-diff-match-patch/Portfile 
b/python/py-diff-match-patch/Portfile
new file mode 100644
index 000..a7cc717
--- /dev/null
+++ b/python/py-diff-match-patch/Portfile




+master_sites
https://files.pythonhosted.org/packages/22/82/46eaeab04805b4fac17630b59f30c4f2c8860988bcefd730ff4f1992908b


We don't want to use this style of URL, which needs to be updated every time the port's 
version is updated. Can the "pypi" fetch group be used instead?


I used pypi2port in macports-contrib, and this is an inactive package
that is unlikely to get any update soon.

--
Zero


smime.p7s
Description: S/MIME cryptographic signature

Re: New project member: vishnu

[Zero King]

On Tue, May 08, 2018 at 02:24:41PM +0200, Rainer Müller wrote:

Please join us in welcoming the following new MacPorts project member:

- Vishnu M (vishnu, @Vishnum98)

We look forward to continued excellent contributions during Google
Summer of Code 2018 and beyond.

- Joshua, Ryan, and Rainer


Welcome, the list of features in macports-webapp README looks really
good.


Do you want to join the MacPorts team? If you would like to be
considered for team membership and commit access, please read this
section of the Guide:

http://guide.macports.org/chunked/project.membership.html


Was PortMgr aware of 
https://github.com/macports/macports-guide/commit/ca0e0239b69f879159927a6357f3494da59c?
 Should we revert this change or always use GitHub handle as MacPorts handle 
for future members?

--
Zero


smime.p7s
Description: S/MIME cryptographic signature

Re: [macports-ports] branch master updated: poedit: new port @2.0.7

[Zero King]

On Tue, May 08, 2018 at 08:53:14PM +0200, Rainer Müller wrote:

Hey Zero,

I appreciate that you stepped up as the maintainer of poedit after I had
given up on it! [1]

However, the poedit port now bundles full builds of other software,
including zlib, gettext, boost, icu, and even wxWidgets.

That really should be avoided, as this software is already available in
separate MacPorts ports. The libraries should be shared and reused
instead of building the same software again. Bundling is also a
nightmare for maintaining a port, as it implies that any patches applied
to the corresponding ports also need to be applied to the sources in the
poedit port. Updates will also only be delivered with updates of poedit,
so upstream bugs can linger on for a long time.


I understand that, but it now uses Xcode workspace and getting it built
with the xcode PortGroup already took me hours because I'm not familiar
with the Xcode build system and that the xcode PortGroup can't handle
workspaces natively.

From https://github.com/vslavik/poedit/blob/v2.0.7-oss/deps/README:

Note that some sources are slightly patched, too.


This means there may be problems if we use MacPorts libraries.

From https://poedit.net/download:

Windows and macOS versions can only be built from a git checkout; Unix builds 
can be done either from the checkout or from the above tarball.


The old poedit port uses tarballs, but now the upstream website states
that you can't build from tarballs on macOS. The new tarballs stripped
many files (e.g. artwork/macos/*, src/quicklook/*) compared to the
repository.

It should be possible to share libraries with other ports by modifying
the Xcode files, but I don't think these patches would be easy to
maintain.

P.S. I think being able to install Poedit without MacPorts by extracting
https://packages.macports.org/poedit/poedit-2.0.7_0.darwin_15.x86_64.tbz2
is also useful for some users.


Rainer

[1] https://trac.macports.org/ticket/43772

On 2018-05-08 05:38, Zero King wrote:

Zero King (l2dy) pushed a commit to branch master
in repository macports-ports.

https://github.com/macports/macports-ports/commit/438bed1dafbb47ae0dd3597dd1b3a08ffd9013c3

The following commit(s) were added to refs/heads/master by this push:
new 438bed1 poedit: new port @2.0.7 438bed1 is described below

commit 438bed1dafbb47ae0dd3597dd1b3a08ffd9013c3 Author: Zero King 

AuthorDate: Tue May 8 03:38:05 2018 +

poedit: new port @2.0.7 ---
 editors/poedit/Portfile| 46 
 editors/poedit/files/patch-deps-sdkroot.diff   | 15 
 editors/poedit/files/patch-deps-tool-path.diff | 23 ++
 editors/poedit/files/patch-remove-sparkle.diff | 96 ++
 4 files changed, 180 insertions(+)


--
Zero


smime.p7s
Description: S/MIME cryptographic signature

Re: How do I add something to our GitHub checklist?

[Zero King]

On Mon, May 07, 2018 at 08:41:30AM -0400, Perry E. Metzger wrote:

When pull requests come in, users are asked to fill out a short
checklist. I'd like to add a reminder to squash your commits into it
-- this has become a frequent issue with pull requests from new
contributors.


I think we should consider enabling squash merging in our repo instead,
squashing commits is not an easy task for git beginners. Also if the PR
allows edits from maintainers (enabled by default), we can force push
and update that PR ourselves.


Where do I find the checklist to edit it?


https://github.com/macports/macports-ports/blob/master/.github/PULL_REQUEST_TEMPLATE.md


Perry
--
Perry E. Metzgerpmetz...@macports.org


--
Zero


smime.p7s
Description: S/MIME cryptographic signature

Re: Instructions for creating patches (Re: trac rrdtool)

[Zero King]

On Thu, May 03, 2018 at 08:51:49AM +0200, Mojca Miklavec wrote:

On 1 May 2018 at 16:11, Rainer Müller wrote:


The guide uses "Portfile-rrdtool.diff" as an example filename [1]. Some
users seem to take that literally and submit patches with that name.

[1] https://guide.macports.org/#development.patches.portfile


Looking at this part of the guide, I would suggest that we change the
instructions. It almost definitely makes more sense to use "git diff
..." instead of "diff ...", but more importantly we probably want to
suggest creating a pull request at that point anyway.


Some contributors would edit the Portfile in 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/,
 which isn't a git repository and `git diff` won't work for them.

Maybe "git format-patch -1" is better than "git diff ..."? But that
would be even closer to a pull request.

--
Zero


smime.p7s
Description: S/MIME cryptographic signature

Re: Why didn't this PR get labeled?

[Zero King]

On Mon, Apr 30, 2018 at 06:09:09PM +0200, Rainer Müller wrote:

On 2018-04-30 15:49, Perry E. Metzger wrote:

Sometimes, I've noticed, PRs in the queue don't get automatically
labeled as expected. See this one, for example:

https://github.com/macports/macports-ports/pull/1687

Anyone know why?


The log file on braeburn says (times in UTC):

Apr 28 19:14:41 braeburn prbot-current[1214]: 2018/04/28 19:14:41 PR #1687 
opened
Apr 28 19:14:41 braeburn prbot-current[1214]: 2018/04/28 19:14:41 GET 
https://api.github.com/repos/macports/macports-ports/pulls/1687/files?per_page=30:
 404 Not Found []
Apr 28 19:16:40 braeburn prbot-current[1214]: 2018/04/28 19:16:40 sql: no rows 
in result set

Looks like GitHub send out the WebHook, but the API did not knew about the pull 
request yet...?

Rainer


On Mon, Apr 30, 2018 at 06:17:30PM +0200, Clemens Lang wrote:

Hi Zero,

On Mon, Apr 30, 2018 at 09:49:10AM -0400, Perry E. Metzger wrote:

Sometimes, I've noticed, PRs in the queue don't get automatically
labeled as expected. See this one, for example:

https://github.com/macports/macports-ports/pull/1687

Anyone know why?


Can you take a look?


As Rainer replied, GitHub didn't provide the needed information in time.
Maybe we should wait 30 seconds and retry?


From the log, it seems processing was normal. I'll include lines
mentioning this PR below:

| Apr 27 23:45:04 braeburn prbot-current[8387]: 2018/04/27 23:45:04 PR #1678 
opened
[...]

--
Clemens



--
Zero


smime.p7s
Description: S/MIME cryptographic signature

Force Mirror on Buildbot

[Zero King]

Hi,

I'd like to mirror unar's distfile for backup, but "it has already been
built and uploaded" so mirror was skipped if I force build the port on a
portwatcher and I can't force a mirror job directly.

--
Zero


smime.p7s
Description: S/MIME cryptographic signature

Re: [macports-ports] branch master updated: irrlicht: fix build on case-sensitive file systems

[Zero King]

Hi,

On Sat, Dec 09, 2017 at 09:12:10AM -0800, Ken Cunningham wrote:

will put in a reminder to do so
thanks, K


Here goes a reminder, the base bug was fixed in MacPorts 2.4.3.


On Dec 9, 2017, at 8:50 AM, Ryan Schmidt  wrote:


On Dec 9, 2017, at 10:07, Ryan Schmidt wrote:


I tried it myself and what I get is:

Error: Failed to extract irrlicht: error renaming: target 
"/opt/local/var/macports/build/_Users_rschmidt_macports_macports-ports-svn-trunk_devel_irrlicht/irrlicht/work/irrlicht-1.8.4/source/Irrlicht/MacOSX/irrFramework-Info.plist-DCQIMWNv/irrFramework-Info.plist"
 is not a directory

While "copy" is simply a less-verbose wrapper around "file copy -force", "move" is more 
than just a wrapper around "file rename", in that it contains code designed specifically to handle your 
situation: the need to change only the case of a filename on a possibly case-insensitive filesystem.

I'm not sure yet why this code is failing.


It's a MacPorts base bug which I've just fixed.

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

So after the next release of MacPorts using system should no longer be needed.





--
Zero


smime.p7s
Description: S/MIME cryptographic signature

Re: Seeing closed tickets on Trac tickets page...

[Zero King]

On Mon, Apr 30, 2018 at 10:18:51AM -0400, Perry E. Metzger wrote:

On:
https://trac.macports.org/wiki/Tickets

I see a list of tickets assigned to me, but it includes closed
tickets. When I edit the Wiki page, it shows me the query is:

TicketQuery(status=!closed,reporter=$USER,or,owner=$USER,col=id|summary|component|port|reporter|owner|time|changetime,order=changetime,desc=1,max=10,format=table)

which would seem to indicate that it should not be showing closed
tickets.

Any ideas?


https://trac.macports.org/wiki/TracQuery#QueryLanguage

status=closed,keywords~=firefox,or,keywords~=opera  query closed tickets 
that contain keyword firefox, or (closed or unclosed) tickets that contain 
keyword opera


The `or` has lower precedence. So use 
TicketQuery(status=!closed,reporter=$USER,or,status=!closed,owner=$USER,col=id|summary|component|port|reporter|owner|time|changetime,order=changetime,desc=1,max=10,format=table)
 instead.


Perry
--
Perry E. Metzgerpmetz...@macports.org


--
Zero


smime.p7s
Description: S/MIME cryptographic signature

Re: Open Letter of Apology

[Zero King]

On Fri, Apr 27, 2018 at 09:59:59PM -0400, Perry E. Metzger wrote:

So I tried to do some repo surgery to fix Marcus Calhoun-Lopez's
commits, since there were only two commits after his change.

I "git reset --hard" back past where he damaged the repo, cherry
picked the two revisions after that, and then tried to
"git push --force" -- this should have re-set the master branch to
point at a slightly different history that now didn't include Marcus'
changes.

However (I suppose not so sadly, since force pushes are dangerous), I got a
  error: GH006: Protected branch update failed for refs/heads/master.
  remote: error: Cannot force-push to a protected branch

I think this is a github security feature. But I can't do appropriate
repository surgery without it.

Anyone have suggestions for alternatives? Should we just merge a
reversal? (I may do that temporarily anyway.)


Use "git revert" for that. We intentionally disabled force pushing
because it could cause trouble for forks and our infrastructure.


Perry


--
Zero


smime.p7s
Description: S/MIME cryptographic signature

Re: Agility

[Zero King]

On Wed, Apr 25, 2018 at 09:16:08PM -0500, Ryan Schmidt wrote:


On Apr 25, 2018, at 20:07, Zero King wrote:


On Wed, Apr 25, 2018 at 11:47:21AM -0500, Ryan Schmidt wrote:

On Apr 25, 2018, at 11:23, Chris Jones wrote:


I don't think there is any need to re-invent our own system here. There is an 
already standard why of dong this, which is to declare the request as 'Work In 
Progress'. This is trivially done by adding 'WIP' to the start of the PR title.


Wouldn't it be more appropriate to use labels, rather than inserting a label 
into the title?


The problem with labels is that non-members can't apply labels themselves.


Ah.


And the WIP label needs to be removed later so changing the title is more 
convenient.


Can proper labels not be removed?


Our bot can easily add labels by parsing the PR body, but automating WIP
label removal is kind of useless (the author has to make some changes
anyway, so why not change the title). We can search with `WIP in:title`
to get a list if we use the title for this.

--
Zero


smime.p7s
Description: S/MIME cryptographic signature

Re: Agility

[Zero King]

On Wed, Apr 25, 2018 at 11:47:21AM -0500, Ryan Schmidt wrote:

On Apr 25, 2018, at 11:23, Chris Jones wrote:


I don't think there is any need to re-invent our own system here. There is an 
already standard why of dong this, which is to declare the request as 'Work In 
Progress'. This is trivially done by adding 'WIP' to the start of the PR title.


Wouldn't it be more appropriate to use labels, rather than inserting a label 
into the title?


The problem with labels is that non-members can't apply labels themselves. And 
the WIP label needs to be removed later so changing the title is more 
convenient.

--
Zero


smime.p7s
Description: S/MIME cryptographic signature

Re: Docs on submitting new ports and updates (was Re: jmol haspatch maintainer - please commit #56106)

[Zero King]

On Mon, Apr 09, 2018 at 12:10:47PM -0400, Perry E. Metzger wrote:

On Tue, 3 Apr 2018 17:40:21 +0100 Peter Brommer
 wrote:

thanks for the suggestion. In my defence, I’m following the
(obviously out-of-date) guide at
https://trac.macports.org/wiki/howto/Upgrade
<https://trac.macports.org/wiki/howto/Upgrade> but I’ll try and use
the pull requests for future updates.


I've updated that Wiki page to suggest the use of pull requests over
trac tickets -- someone might want to look at my new language and
see if it can be improved further.

Also, what are the other places where we currently describe the
process to submit new ports or updates to old ones? It would be good
to update those as well.


In our guide: https://guide.macports.org/#project.contributing / 
https://github.com/macports/macports-guide.

--
Best regards,
Zero King


smime.p7s
Description: S/MIME cryptographic signature

Re: CI system for PR builds

[Zero King]

On Sun, Apr 08, 2018 at 12:20:34PM +0200, db wrote:

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?


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.

--
Best regards,
Zero King


smime.p7s
Description: S/MIME cryptographic signature

Re: port & root

[Zero King]

On Thu, Apr 05, 2018 at 07:25:10PM +0200, Rainer Müller wrote:

On 2018-04-05 19:14, Joshua Root wrote:

My guess is that this is a bug in Tcl's file command. Deleting a
nonexistent file is not supposed to be considered an error. But by
starting two instances of port(1) at the same time, a race condition
arises. The 'file delete' command probably checks whether the file
exists, returns TCL_OK if not, and then attempts to delete the file. If
the file has been deleted by the other running instance (or indeed
anything else) between these two steps, then the actual deletion fails,
and it incorrectly returns an error.


You are right. We hit a race condition in the implementation of 'file
delete' in Tcl.

It is missing another check for ENOENT here, as done in line 381:

https://github.com/macports/macports-base/blob/4b13207d9f7f9aba1cc9eba266b3071318637a8c/vendor/tcl8.5.19/generic/tclFCmd.c#L415


@l2dy,
Is our Travis job executing multiple 'port lint' commands in parallel?
Then this is the same cause.


Not multiple lint commands, but lint and building ports (including
listing subports) are executed in parallel.


Rainer


--
Best regards,
Zero King


smime.p7s
Description: S/MIME cryptographic signature

Re: How to fetch and extract patches in archives?

[Zero King]

On Sun, Mar 18, 2018 at 03:15:25PM +, G A wrote:

What? Macports supports most archives zip, gz, bz2, etc

extract the patches from the tarball add them to the
Portname/Portfile/files/*.


That's the way I've been updating the w3m port. But the patches are
getting bigger (upstream is inactive) so it's not ideal to keep it in
the ports tree.


You should probably manually apply the patches
first to see if it breaks the build or fixes the issue. I would not blindly
apply any Linux patch.


On Sun, Mar 18, 2018 at 00:34 Zero King  wrote:


Hi,

Port w3m needs patches from Debian to fix security issues. Currently,
the patches are added to the ports tree and takes ~800KiB. Since its
size will grow, I'd prefer to fetch the patches from Debian archives
(e.g. w3m_0.5.3-36.debian.tar.xz).

I tried to add the archive and ${workpath}/.../020_debian.patch to
distfiles and patchfiles, but that didn't work because port(1) attempted
to fetch the patchfiles into ${distpath} and `DEBUG: Fetching distfile
failed: No such file or directory`.

--
Best regards,
Zero King



--
Best regards,
Zero King


smime.p7s
Description: S/MIME cryptographic signature

Re: How to fetch and extract patches in archives?

[Zero King]

On Sun, Mar 18, 2018 at 12:48:59PM +0100, Rainer Müller wrote:

On 2018-03-18 12:28, Zero King wrote:

On Sun, Mar 18, 2018 at 09:57:58AM +0100, Mojca Miklavec wrote:

On 18 March 2018 at 08:33, Zero King wrote:
I would add the patches to distfiles and include debian site in
master_sites. You then need to keep your fingers crossed that the main
distfile is also packaged as tar.xz because you need to manually
extract some of the files otherwise (MacPorts does not yet support
extracting from different types of archives).


The main distfile is tar.gz.


The debian tarball already contains the full sources. Is there a reason
to use the upstream distfile? If w3m upstream at sf.net is dead, just
switch to the Debian version that still receives patches.


No, it only contains debian-specific stuff:

drwxr-xr-x  0 0  0   0 Jan 25 09:53 debian/
-rw-r--r--  0 0  0 459 Jan 25 09:49 debian/README.Debian
-rw-r--r--  0 0  0   70430 Jan 25 09:53 debian/changelog
[...]
drwxr-xr-x  0 0  0   0 Jan 25 09:45 debian/patches/
-rw-r--r--  0 0  05732 Jan 25 09:37 
debian/patches/010_upstream.patch
-rw-r--r--  0 0  0  805357 Jan 25 09:38 debian/patches/020_debian.patch
-rw-r--r--  0 0  0  36 Jan 25 09:45 debian/patches/series


MacPorts will always try to download files listed in patchfiles from
patch_sites or master_sites if they are not already in the files/
directory next to the Portfile. For this, all entries in patchfiles are
expected to be simple filenames, not full paths. Therefore Mojca's
suggestion will not work.


Solution 1: Download the patches using patch_sites from an URL

Keep the upstream distfile, download additional patches from Debian.

dist_subdir ${name}/${version}
patchfiles  020_debian.patch
patch_sites https://.../debian/patches/

The dist_subdir option is required as these patches are likely to change
with each version. Of course you could also leave it out at first and
only add it once it is required.

The downside is that we are relying on sources.debian.org [1], the
Debian Gitlab [2] or the GitHub mirror [3] serving these files.

[1] https://sources.debian.org/src/w3m/0.5.3-36/debian/patches/
[2] https://salsa.debian.org/debian/w3m/tree/debian-stretch/debian/patches
[3] https://github.com/tats/w3m


Thanks for [1] and [2], I didn't know they exist. [3]'s debian/* tags
should work with your solutions below.

What is the downside of relying on them? Plus we have distfile mirroring
now.


Solution 2: A hack to avoid fetching patchfiles

Only the tarball from Debian is used, no additional downloads.

distfiles  w3m_0.5.3-36.debian.tar.xz
master_sites   debian:w/w3m

The following pre-patch phase should trick MacPorts into not fetching
patches by setting the patchfiles option late, but apply them in the
patch phase:

pre-patch {
   patchfiles ${worksrcpath}/debian/patches/020_debian.patch
}


Solution 3: A custom post-patch phase to apply these patches

Same as in solution 2, but instead of using the hack, the patches are
applied manually in a custom post-patch phase. This is probably the most
flexible solution.

post-patch {
   foreach p 020_debian.patch ... {
   system -W ${worksrcpath} "patch -p0 debian/patches/${p}"
   }
}


So we have several solutions:

1. keep patches in the ports tree. (not ideal, upstream is dead)
2. fetch debian/* from github.com/tats/w3m and use a hack for patches.
3. use patch_sites sources.debian.org/... salsa.debian.org/...

Any suggestions?

--
Best regards,
Zero King


smime.p7s
Description: S/MIME cryptographic signature

Re: How to fetch and extract patches in archives?

[Zero King]

On Sun, Mar 18, 2018 at 09:57:58AM +0100, Mojca Miklavec wrote:

On 18 March 2018 at 08:33, Zero King wrote:

Hi,

Port w3m needs patches from Debian to fix security issues. Currently,
the patches are added to the ports tree and takes ~800KiB. Since its
size will grow, I'd prefer to fetch the patches from Debian archives
(e.g. w3m_0.5.3-36.debian.tar.xz).

I tried to add the archive and ${workpath}/.../020_debian.patch to
distfiles and patchfiles, but that didn't work because port(1) attempted
to fetch the patchfiles into ${distpath} and `DEBUG: Fetching distfile
failed: No such file or directory`.


I would add the patches to distfiles and include debian site in
master_sites. You then need to keep your fingers crossed that the main
distfile is also packaged as tar.xz because you need to manually
extract some of the files otherwise (MacPorts does not yet support
extracting from different types of archives).


The main distfile is tar.gz. Should I mirror the patches elsewhere to
reduce the burden on our main repo? Homebrew has
https://github.com/Homebrew/formula-patches for example.


I would imagine that
   patchfiles ${worksrcdir}/.../020_debian.patch
should work, but I didn't test.


This failed too.

--
Best regards,
Zero King


smime.p7s
Description: S/MIME cryptographic signature

How to fetch and extract patches in archives?

[Zero King]

Hi,

Port w3m needs patches from Debian to fix security issues. Currently,
the patches are added to the ports tree and takes ~800KiB. Since its
size will grow, I'd prefer to fetch the patches from Debian archives
(e.g. w3m_0.5.3-36.debian.tar.xz).

I tried to add the archive and ${workpath}/.../020_debian.patch to
distfiles and patchfiles, but that didn't work because port(1) attempted
to fetch the patchfiles into ${distpath} and `DEBUG: Fetching distfile
failed: No such file or directory`.

--
Best regards,
Zero King


smime.p7s
Description: S/MIME cryptographic signature

Re: [macports-base] branch travis-ci updated (18e31dc -> b13450e)

[Zero King]

On Sat, Mar 10, 2018 at 10:33:55PM -0600, Ryan Schmidt wrote:


On Mar 10, 2018, at 09:52, Zero King wrote:


Zero King (l2dy) pushed a change to branch travis-ci
in repository macports-base.

discard 18e31dc  Update bintray deploy key
new b13450e  Update bintray deploy key

This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version.  This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:

* -- * -- B -- O -- O -- O   (18e31dc)
   \
N -- N -- N   refs/heads/travis-ci (b13450e)

You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.

Any revisions marked "omit" are not gone; other references still
refer to them.  Any revisions marked "discard" are gone forever.

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
.travis.yml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


What do I need to know about this? Was this a force push? I thought we weren't 
doing those on our main repositories because rewriting public history is bad.


It was a force push. This branch will never be merged to master so I
think it's OK. I was trying to fix deployment issues that turns out to
be Travis CI's fault (https://github.com/travis-ci/travis-ci/issues/9314).

--
Best regards,
Zero King


smime.p7s
Description: S/MIME cryptographic signature

Re: [macports-ports] branch master updated: irssi: perl5.26 revbump

[Zero King]

On Tue, Mar 06, 2018 at 04:08:04AM -0600, Ryan Schmidt wrote:


On Mar 3, 2018, at 20:59, Zero King wrote:


Zero King (l2dy) pushed a commit to branch master
in repository macports-ports.


https://github.com/macports/macports-ports/commit/9f045bef9d96ad58591bcb71dbf2fc3a67303f82

The following commit(s) were added to refs/heads/master by this push:

 new 9f045be  irssi: perl5.26 revbump

9f045be is described below


commit 9f045bef9d96ad58591bcb71dbf2fc3a67303f82

Author: Zero King 
AuthorDate: Sun Mar 4 02:59:10 2018 +


irssi: perl5.26 revbump


Why? The irssi portfile doesn't mention any specific version of perl.


port-rev-upgrade(1) told me that it's broken, probably because
port:perl5 was updated to 5.26 in 
https://github.com/macports/macports-ports/commit/d52392c211739ca19889d774a7e16d9a15756d14#diff-5a4a6e75a9ad4228d6e8fbf1016561a9.


--
Best regards,
Zero King


smime.p7s
Description: S/MIME cryptographic signature

Re: [macports-ports] branch master updated: libcaer: new port

[Zero King]

On Thu, Mar 01, 2018 at 10:25:47PM +0100, Mojca Miklavec wrote:

On 1 March 2018 at 20:23, Perry E. Metzger wrote:

On Thu, 1 Mar 2018 08:40:51 -0800 Ken Cunningham wrote:

CI is not sufficient testing to commit, sadly.

There is no xcode 9 in travis at present.
misses many things, like liscence etc
doesn't check if destrooting is right

It's OK for a minor version update of an existing port, but all new
ports or sig updates need to checked out locally, port lint
nitpicked, looked over carefully, build with trace mode,
destrooted, and installed before commiting

and all that will only find 80% of the problems.

The rest show up on the builbots after the commit.


Looking over things carefully seems reasonable. A machine can't
figure out that a Portfile should be written differently.

Having to build locally in several ways seems bad. The purpose of
automatic CI infrastructure is to free people from needing to do
such things, both because it reduces labor and because it reduces
error. The latter is the really important bit. Manual process is
error prone.


I semi-agree with both. There's certainly more that a committer can do
before clicking the button, but there's also more we could do on the
CI side to help avoiding doing the same mistakes over and over again.

Travis should probably list all the destrooted/installed files at the
end of the run, along with permissions (rwx). Zero, would you be
willing to add that to the log?


Let's discuss this during the meeting, I also have to check why it
failed to upload logs to the pastebin. From
https://travis-ci.org/macports/macports-ports/jobs/348478666#L316, it
seems to be a permission problem. Do we keep HTTP logs for
paste.macports.org? Checking the logs around that time (or start a new
build and analyze) should help.


Maybe we need more flexible (and less likely to time out) CI than
Travis can give us that includes things like port lint, traced
builds, etc?


That would be nice to have, but do you have any idea how to make a
safe setup (perhaps with a fresh/disposable VM for each PR)?

"port lint" and traced builds can be done on Travis as well.

Mojca


--
Best regards,
Zero King


smime.p7s
Description: S/MIME cryptographic signature

Re: need someone with steely git-fu to resolve a minor conflict in PR #740

[Zero King]

On Sun, Feb 25, 2018 at 05:28:26AM +, Zero King wrote:

On Sat, Feb 24, 2018 at 08:26:41PM -0800, Ken Cunningham wrote:

I have tried several times to resolve the minor conflict in this PR and I just 
keep messing it up. It looks super trivial, but ...

https://github.com/macports/macports-ports/pull/740

Please, if you do fix it, tell me what you did so I don't have to ask this 
particular silly question again.


```
git checkout -b pr-740
curl -O 
https://patch-diff.githubusercontent.com/raw/macports/macports-ports/pull/740.patch
vim 740.patch
# ^ remove the conflicting file (diff --git a/aqua/qt4-mac/Portfile ...
# until the next diff --git ...)
git am 740.patch
curl -o aqua/qt4-mac/Portfile 
https://raw.githubusercontent.com/devernay/macports-ports/8324db7c8b3452e453ce859d2137ae1ae6a76743/aqua/qt4-mac/Portfile
# ^ URL from https://github.com/macports/macports-ports/pull/740/files ("View" 
button on the right)
git add aqua/qt4-mac/Portfile
git commit --amend --no-edit
git push -f g...@github.com:devernay/macports-ports.git pr-740:qt4-mac-tiger
```

I'm using a shallow clone so I can't push to an outdated branch, but it
should work for you.


But I can generate a patch... Download the patch attached and,

```
git checkout -b pr-740
git am 0001-qt4-mac-backport-qt5-QSettings-fix-support-building-.patch
git push -f g...@github.com:devernay/macports-ports.git pr-740:qt4-mac-tiger
git checkout - # return to previous branch
```

--
Best regards,
Zero King
From fe341ea9b7b18f216603bca877a4a6745df170f0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20Devernay?= 
Date: Mon, 4 Sep 2017 13:55:20 +0200
Subject: [PATCH] qt4-mac: backport qt5 QSettings fix + support building on
 Tiger

also an alternate fix for high Sierra is presented that can be enabled
if the maintainer wishes

All the tiger-specific patches are suffixed with -tiger, and don't break 
anything when compiling with more recent SDKs.

Only one patch, patch-src_gui_dialogs_qfontdialog_mac.mm-tiger.diff, 
reintroduces in the Tiger version only a Qt bug (QTBUG-27415) which cannot be 
fixed with the Tiger SDK (the fix requires Leopard).

Patch (19) seems wrong when building frameworks and breaks the build (older 
versions of qt4-mac allowed building with libraries only, I guess this patch is 
remnant from that time). I commented it out, and did not remove the patch file 
in case someone wants to take a closer look at it.

Also, since qt4-mac only uses the JPEG 8 API, libjpeg-turbo can be used instead 
(see https://trac.macports.org/ticket/38907)

Patches (31) (backport qt5 QSettings fix) and (30) (support High Sierra) were 
taken from homebrew. I did not test building on macOS High Sierra, and thus 
left the restriction.
---
 aqua/qt4-mac/Portfile  |  26 -
 .../patch-qmake_generators_unix_unixmakke.cpp.diff | 108 +
 aqua/qt4-mac/files/patch-qsettings-null.diff   |  76 +++
 .../patch-qt4-versions-without-underscores.diff|  12 +++
 ...orelib_io_qfilesystemengine_unix.cpp-tiger.diff |  41 
 ...h-src_gui_dialogs_qfontdialog_mac.mm-tiger.diff |  34 +++
 ...rc_gui_painting_qpaintengine_mac.cpp-tiger.diff |  19 
 ...src_gui_painting_qprintengine_mac.mm-tiger.diff |  14 +++
 ...h-src_gui_text_qfontdatabase_mac.cpp-tiger.diff |  21 
 ...network_kernel_qnetworkproxy_mac.cpp-tiger.diff |  18 
 10 files changed, 366 insertions(+), 3 deletions(-)
 create mode 100644 
aqua/qt4-mac/files/patch-qmake_generators_unix_unixmakke.cpp.diff
 create mode 100644 aqua/qt4-mac/files/patch-qsettings-null.diff
 create mode 100644 
aqua/qt4-mac/files/patch-qt4-versions-without-underscores.diff
 create mode 100644 
aqua/qt4-mac/files/patch-src_corelib_io_qfilesystemengine_unix.cpp-tiger.diff
 create mode 100644 
aqua/qt4-mac/files/patch-src_gui_dialogs_qfontdialog_mac.mm-tiger.diff
 create mode 100644 
aqua/qt4-mac/files/patch-src_gui_painting_qpaintengine_mac.cpp-tiger.diff
 create mode 100644 
aqua/qt4-mac/files/patch-src_gui_painting_qprintengine_mac.mm-tiger.diff
 create mode 100644 
aqua/qt4-mac/files/patch-src_gui_text_qfontdatabase_mac.cpp-tiger.diff
 create mode 100644 
aqua/qt4-mac/files/patch-src_network_kernel_qnetworkproxy_mac.cpp-tiger.diff

diff --git a/aqua/qt4-mac/Portfile b/aqua/qt4-mac/Portfile
index cca1f479..49c03895 100644
--- a/aqua/qt4-mac/Portfile
+++ b/aqua/qt4-mac/Portfile
@@ -11,7 +11,7 @@ PortGroup   compiler_blacklist_versions 1.0
 
 nameqt4-mac
 version 4.8.7
-revision5
+revision6
 set branch  [join [lrange [split ${version} .] 0 1] .]
 
 categories  aqua
@@ -40,7 +40,7 @@ depends_lib-append  port:zlib \
 port:tiff \
 port:libpng \
 port:libmng \
-port:jpeg
+path:lib/libjpeg.dylib:jpeg
 
 # find a way to specify the OS MINOR version.  For O

Re: need someone with steely git-fu to resolve a minor conflict in PR #740

[Zero King]

On Sat, Feb 24, 2018 at 08:26:41PM -0800, Ken Cunningham wrote:

I have tried several times to resolve the minor conflict in this PR and I just 
keep messing it up. It looks super trivial, but ...

https://github.com/macports/macports-ports/pull/740

Please, if you do fix it, tell me what you did so I don't have to ask this 
particular silly question again.


```
git checkout -b pr-740
curl -O 
https://patch-diff.githubusercontent.com/raw/macports/macports-ports/pull/740.patch
vim 740.patch
# ^ remove the conflicting file (diff --git a/aqua/qt4-mac/Portfile ...
# until the next diff --git ...)
git am 740.patch
curl -o aqua/qt4-mac/Portfile 
https://raw.githubusercontent.com/devernay/macports-ports/8324db7c8b3452e453ce859d2137ae1ae6a76743/aqua/qt4-mac/Portfile
# ^ URL from https://github.com/macports/macports-ports/pull/740/files ("View" 
button on the right)
git add aqua/qt4-mac/Portfile
git commit --amend --no-edit
git push -f g...@github.com:devernay/macports-ports.git pr-740:qt4-mac-tiger
```

I'm using a shallow clone so I can't push to an outdated branch, but it
should work for you.


Thanks,

Ken


--
Best regards,
Zero King


smime.p7s
Description: S/MIME cryptographic signature

Re: [macports-ports] branch master updated: Rebuild port with boost 1.66.0

[Zero King]

On Sun, Feb 18, 2018 at 11:06:06PM -0600, Ryan Schmidt wrote:


On Feb 18, 2018, at 22:41, Zero King wrote:


On Sun, Feb 18, 2018 at 10:31:42PM -0600, Ryan Schmidt wrote:

On 17 February 2018 at 16:10, Eitan Adler wrote:

On 17 February 2018 at 13:00, Ryan Schmidt wrote:


On Feb 17, 2018, at 14:37, Giovanni Bussi wrote:


Eitan Adler (grimreaper) pushed a commit to branch master
in repository macports-ports.


https://github.com/macports/macports-ports/commit/9b747847c18a6cea577b9849e6063d1f3d8bbec3

The following commit(s) were added to refs/heads/master by this push:

   new 9b74784  Rebuild port with boost 1.66.0

9b74784 is described below


commit 9b747847c18a6cea577b9849e6063d1f3d8bbec3

Author: Giovanni Bussi
AuthorDate: Fri Feb 16 18:29:23 2018 +0100


  Rebuild port with boost 1.66.0


Please put the name of the port and a colon as the first thing in the commit message, 
i.e. "plumed: rebuild plumed-devel with boost 1.66.0"


Will do next time.


This is a confusing commit.


Agreed. I had the same confusion if you look at the PR.


Now that I've located and looked at the PR, I see that.

But I don't see a link to the PR in the commit email. Am I missing it or is it 
just not there? I don't even see any indication in the email that the commit 
originated from a PR, except I guess for the fact that I see that the Author is 
a different person than the committer.

I dislike this. A commit that closes a ticket clearly gives me the ticket URL 
that I can click to learn more. I wish the same information was provided when 
the commit relates to a PR instead of a ticket.


If you enable squash merging, it will automatically reference the PR
when you use the merge button.


In what way "reference"? It will add the PR URL to the commit message, or what?

We've brought up the topic of enabling the web-based squash merging feature 
many times before. I probably come down on the side of thinking we should 
enable it, because it will allow people like me who can't stand the git command 
line to merge PRs the way we've decided we want them merged.


And when you view a commit on github.com,
it will show you the related PR next to the branches. e.g.
https://github.com/macports/macports-ports/commit/9b747847c18a6cea577b9849e6063d1f3d8bbec3


Ok, after looking at it for awhile, and searching the entire page for the word "branches" and 
finding nothing, I finally saw the string "(#1319)" to the right of the string "master". 
So I guess now that I know that's there, I could use that. I guess I'm just still annoyed at how non-obvious 
it is.


There's a branch icon before "master" and "master" is the branch this
commit is on. If the commit is on multiple branches but not on the HEAD
branch (default branch), it will show all of them there. e.g.
https://github.com/l2dy/repo-template/commit/6bc34769c1305a937b505c57bf4ff45be127d48f

--
Best regards,
Zero King


smime.p7s
Description: S/MIME cryptographic signature

Re: [macports-ports] branch master updated: Rebuild port with boost 1.66.0

[Zero King]

On Sun, Feb 18, 2018 at 11:06:06PM -0600, Ryan Schmidt wrote:


On Feb 18, 2018, at 22:41, Zero King wrote:


On Sun, Feb 18, 2018 at 10:31:42PM -0600, Ryan Schmidt wrote:

On 17 February 2018 at 16:10, Eitan Adler wrote:

On 17 February 2018 at 13:00, Ryan Schmidt wrote:


On Feb 17, 2018, at 14:37, Giovanni Bussi wrote:


Eitan Adler (grimreaper) pushed a commit to branch master
in repository macports-ports.


https://github.com/macports/macports-ports/commit/9b747847c18a6cea577b9849e6063d1f3d8bbec3

The following commit(s) were added to refs/heads/master by this push:

   new 9b74784  Rebuild port with boost 1.66.0

9b74784 is described below


commit 9b747847c18a6cea577b9849e6063d1f3d8bbec3

Author: Giovanni Bussi
AuthorDate: Fri Feb 16 18:29:23 2018 +0100


  Rebuild port with boost 1.66.0


Please put the name of the port and a colon as the first thing in the commit message, 
i.e. "plumed: rebuild plumed-devel with boost 1.66.0"


Will do next time.


This is a confusing commit.


Agreed. I had the same confusion if you look at the PR.


Now that I've located and looked at the PR, I see that.

But I don't see a link to the PR in the commit email. Am I missing it or is it 
just not there? I don't even see any indication in the email that the commit 
originated from a PR, except I guess for the fact that I see that the Author is 
a different person than the committer.

I dislike this. A commit that closes a ticket clearly gives me the ticket URL 
that I can click to learn more. I wish the same information was provided when 
the commit relates to a PR instead of a ticket.


If you enable squash merging, it will automatically reference the PR
when you use the merge button.


In what way "reference"? It will add the PR URL to the commit message, or what?


e.g. In this PR https://github.com/AOSC-Dev/aosc-os-abbs/pull/1019, it
will rebase and change the commit message from "gc: update to 7.6.4" to
"gc: update to 7.6.4 (#1019)".


We've brought up the topic of enabling the web-based squash merging feature 
many times before. I probably come down on the side of thinking we should 
enable it, because it will allow people like me who can't stand the git command 
line to merge PRs the way we've decided we want them merged.


And when you view a commit on github.com,
it will show you the related PR next to the branches. e.g.
https://github.com/macports/macports-ports/commit/9b747847c18a6cea577b9849e6063d1f3d8bbec3


Ok, after looking at it for awhile, and searching the entire page for the word "branches" and 
finding nothing, I finally saw the string "(#1319)" to the right of the string "master". 
So I guess now that I know that's there, I could use that. I guess I'm just still annoyed at how non-obvious 
it is.



--
Best regards,
Zero King


smime.p7s
Description: S/MIME cryptographic signature

Re: [macports-ports] branch master updated: Rebuild port with boost 1.66.0

[Zero King]

On Sun, Feb 18, 2018 at 10:31:42PM -0600, Ryan Schmidt wrote:

On 17 February 2018 at 16:10, Eitan Adler wrote:

On 17 February 2018 at 13:00, Ryan Schmidt wrote:


On Feb 17, 2018, at 14:37, Giovanni Bussi wrote:


Eitan Adler (grimreaper) pushed a commit to branch master
in repository macports-ports.


https://github.com/macports/macports-ports/commit/9b747847c18a6cea577b9849e6063d1f3d8bbec3

The following commit(s) were added to refs/heads/master by this push:

new 9b74784  Rebuild port with boost 1.66.0

9b74784 is described below


commit 9b747847c18a6cea577b9849e6063d1f3d8bbec3

Author: Giovanni Bussi
AuthorDate: Fri Feb 16 18:29:23 2018 +0100


   Rebuild port with boost 1.66.0


Please put the name of the port and a colon as the first thing in the commit message, 
i.e. "plumed: rebuild plumed-devel with boost 1.66.0"


Will do next time.


This is a confusing commit.


Agreed. I had the same confusion if you look at the PR.


Now that I've located and looked at the PR, I see that.

But I don't see a link to the PR in the commit email. Am I missing it or is it 
just not there? I don't even see any indication in the email that the commit 
originated from a PR, except I guess for the fact that I see that the Author is 
a different person than the committer.

I dislike this. A commit that closes a ticket clearly gives me the ticket URL 
that I can click to learn more. I wish the same information was provided when 
the commit relates to a PR instead of a ticket.


If you enable squash merging, it will automatically reference the PR
when you use the merge button. And when you view a commit on github.com,
it will show you the related PR next to the branches. e.g.
https://github.com/macports/macports-ports/commit/9b747847c18a6cea577b9849e6063d1f3d8bbec3


One thing that
may have made it less confusing is to modify the commit message rather
than merge from the web.


Yes, the person merging a pull request is responsible for making sure the PR 
conforms to our requirements before merging it, either by asking the original 
author to do so or by doing it themselves. (The same applies to committing 
patches submitted in tickets, of course.)



--
Best regards,
Zero King


smime.p7s
Description: S/MIME cryptographic signature

Re: [macports-ports] branch master updated: remove unused patches

[Zero King]

On Mon, Feb 12, 2018 at 08:30:58AM -0500, Perry E. Metzger wrote:

On Mon, 12 Feb 2018 03:52:59 -0600 Ryan Schmidt
 wrote:


Perry, it's your responsibility to ensure commit messages conform
to our guidelines before merging a PR.



Gotcha. It's a bit irritating that there isn't a good way to edit a
commit message in the course of merging, because it seems unfriendly
to me to make people go around again for something trivial I should
be able to fix. Anyone know if there's some way to do that?


If the PR author allowed edits from maintainers (on by default), you can
force push to the PR source branch. See
https://trac.macports.org/wiki/WorkingWithGit#WorkingwithsomeoneelsespullrequestthroughitsID
and https://gist.github.com/l2dy/7da9621954ebcf1a19869f391662a41e for
some instructions.

--
Best regards,
Zero King


smime.p7s
Description: S/MIME cryptographic signature

10.13 builder on our BuildBot is failing

[Zero King]

Hi,

Our 10.13 builder on build.macports.org is failing with:

twisted.spread.pb.RemoteError: [Errno 23] Too many open files in system: 
'/opt/bblocal/var/buildworker/ports/ports-10_13_x86_64-watcher'

--
Best regards,
Zero King


smime.p7s
Description: S/MIME cryptographic signature

Re: New ocaml category?

[Zero King]

On Sat, Dec 16, 2017 at 08:36:06PM -0500, Perry E. Metzger wrote:

There are currently over 300 ocaml packages in devel/

I would like to create a new "ocaml" category and move them all into
a top level "ocaml" directory.

Questions:

0) If I am not mistaken, all that needs to be done to create the new
category is to create the "ocaml" directory. Is there any file
etc. that needs updating?


Yes, but Git ignores empty directories, so just move Portfiles over and
modify the categories lines.


1) I believe it would be appropriate to do the move with a single git
commit. Is this correct?

2) Should I explicitly add the "ocaml" category to the categories line
of all these packages at the same time? Or should that be a distinct
commit?


Yes, or else `port lint` will throw an error. e.g.
Error: Portfile parent directory mail does not match primary category net


3) Many of the packages list themselves as being in an "ml"
category. Given that OCaml really isn't standard ML at all, I'm
thinking of removing that category from them. Is that okay?

Note that a lot of these packages are crusty/old/don't build any more,
but I'll be fixing that over a long period of time.

Perry
--
Perry E. Metzgerpe...@piermont.com


--
Best regards,
Zero King


smime.p7s
Description: S/MIME cryptographic signature

Re: Build Failure on ports-10.6_i386_legacy: ocaml, py27-certifi, py27-mistune, py27-scandir, py27-tz, py27-zmq, root6, xrootd

[Zero King]

On Thu, Dec 14, 2017 at 09:37:34PM -0500, Perry E. Metzger wrote:

On Thu, 14 Dec 2017 19:16:15 -0600 Ryan Schmidt
 wrote:

On Dec 14, 2017, at 18:43, Perry E. Metzger wrote:

> So I had naively hoped that by erroring out the build of ocaml on
> MacOS < 10.7 that I'd cease to get nagged about build failures of
> the port, but apparently no such luck. I suppose that's because
> the system does still try to build the port, and it fails.
>
> Any thoughts about a way to specify that only some versions
> of the operating system can build a port, so the build bots don't
> get angry?

We don't have a way to do that right now, sorry.


Would it be reasonable to add an equivalent of supported_archs? We
could then have the buildbots notice that. Are the buildbot sources
on github? I could have a look at what would be required...


There is a ticket for this, but it has stalled for a long time:
https://trac.macports.org/ticket/15712.

--
Best regards,
Zero King


smime.p7s
Description: S/MIME cryptographic signature

Re: Temporarily blacklisting OCaml for 10.6 and before...

[Zero King]

On Wed, Dec 13, 2017 at 09:22:14AM -0500, Perry E. Metzger wrote:

For the moment, OCaml doesn't work on 10.6 and earlier. There's some
work that can fix that, but it isn't done yet.

How does one specify that a port is only for more recent operating
system versions to prevent it from building on older platforms? (I
know how to blacklist ppc for the moment using supported_archs.)


Here's a snippet excerpted from port mas:

pre-fetch {
   if {${os.major} < 15} {
   ui_error "${name} @${version} requires OS X 10.11 or later."
   return -code error "incompatible OS X version"
   }
}


Perry
--
Perry E. Metzger    pe...@piermont.com


--
Best regards,
Zero King


smime.p7s
Description: S/MIME cryptographic signature

Re: libressl port version bumps

[Zero King]

On Sat, Dec 02, 2017 at 06:03:17AM -0800, Jeremy Huddleston Sequoia wrote:

Hey Zero,

Please stop bumping libressl.  You may have not noticed, but I moved it to no 
longer be openmaintainer for a reason.  There are some things that I want to do 
to the port (and OpenSSL) and I'd prefer to not force users to go through 
rev-upgrade hell an additional time.


Acknowledged. I did notice and that's why I opened a ticket instead of a
pull request.

--
Best regards,
Zero King


smime.p7s
Description: S/MIME cryptographic signature

Re: proper Portfile lines for a weird release on github?

[Zero King]

On Thu, Nov 16, 2017 at 10:17:09PM -0500, Perry E. Metzger wrote:

camlp5 version 7.03 is located in

https://github.com/camlp5/camlp5/archive/rel703.tar.gz

What do I do in an updated Portfile to point at that?


You can use the github PortGroup[1] with strsed[2], e.g.

```
PortGroup   github 1.0
set _version7.03
github.setupcamlp5 camlp5 [strsed ${_version} {g/\.//}] rel
version ${_version}
```

[1] 
https://github.com/macports/macports-ports/blob/master/_resources/port1.0/group/github-1.0.tcl
[2] 
https://guide.macports.org/chunked/reference.tcl-extensions.html#reference.tcl-extensions.strsed

--
Best regards,
Zero King


smime.p7s
Description: S/MIME cryptographic signature

Re: New docbook-xsl (1.79.2) breaks existing XSL files

[Zero King]

On Mon, Nov 06, 2017 at 09:25:47AM +0100, Leonardo Brondani Schenkel wrote:

Ticket: https://trac.macports.org/ticket/55255

DocBook XSLs changed their URIs from `sourceforge.net` to 
`github.com`, which results in existing XML files using the former 
URIs not able to find the local copy installed by the port. This will 
trigger a download from the URI or fail if net access is disabled.


They switched to cdn.docbook.org.

This could break many existing ports and user XML files. Neomutt for 
example can no longer be built: https://trac.macports.org/ticket/55253


I'm writing to the list because this change in upstream might have far 
reaching implications, and this port has no official maintainer, so I 
want to bring as much visibility to the issue as possible and discuss 
a solution.


From https://trac.macports.org/ticket/55255:

make both URIs be supported somehow (not sure if this is even possible)


Fix proposed in https://github.com/macports/macports-ports/pull/1004.
Not sure if this is the best solution though.

--
Best regards,
Zero King


smime.p7s
Description: S/MIME cryptographic signature

BSD-{2,3}-Clause not recognized by port_binary_distributable.tcl

[Zero King]

Hi,

Currently 3 ports (py-metakernel, py-octave_kernel, ntpsec) are using
"BSD-3-Clause" as (one of) their licenses, and ntpsec also uses
"BSD-2-Clause".  These licenses are "not known to be distributable" in
port_binary_distributable.tcl.

Should we update these ports to use "BSD" or update 
port_binary_distributable.tcl?

Also port_binary_distributable.tcl doesn't recognize the "NTP" license
specified in ntpsec. Should this port use "Permissive" like ntp or
should we update port_binary_distributable.tcl?

--
Best regards,
Zero King


smime.p7s
Description: S/MIME cryptographic signature

Fwd: Re: Server issues?

[Zero King]

- Forwarded message from Dr M J Carter  
-

Date: Fri, 13 Oct 2017 13:25:22 +0100
From: Dr M J Carter 
To: Zero King 
Subject: Re: Server issues?
User-Agent: NeoMutt/20170912 (1.9.0)

On Fri, Oct 13, 2017 at 11:23:42AM +, Zero King wrote:

On Sat, Sep 09, 2017 at 08:56:15AM -0500, Ryan Schmidt wrote:
> On Sep 8, 2017, at 17:50, Rainer Müller wrote:
>
> > We could of course route the mails over braeburn. However, the mails for
> > macports-builds@ have stopped as well and there was not even a single
> > incoming connection from your static IP, so the current problem is not
> > related to spam checks at all.
>
> I didn't realize mails had stopped sending to the macports-builds
> as well. It looks like this coincides with the last time the
> server that runs the buildmaster was restarted. I don't know why
> that caused mails to stop sending.

Any update on this?


For completeness, I find postfix needs a kick on some of our newer
build systems after they've been rebooted.  Installing Server seems to
perturb it away, but I've just had an incompatibility complaint from
App Store about it.

(I'd have replied to the list, but I've been bounceed recently.  It's
altogether possible I'm subscribed under an older e-identity, and it's
a busy time of academic year.)

--
Dr Martin J Carter
Computer System Administrator
Astrophysics, University of Oxford

- End forwarded message -

Re: how to efficiently work through generating patches using git and macports build process?

[Zero King]

On Wed, Aug 30, 2017 at 02:19:39PM -0400, Michael Dickens wrote:

You can always create or add them to a .gitignore file. If at the top-
level GIT repo, this file impacts the whole repo. You would literally
add "*.o" (but without the ""s) to this file to ignore all *.o files.
Just be careful to not ignore port-original files.
Example of how I do it; slightly different than Mojca's:
{{{
sudo port extract gr-ofdm
pushd $(port work gr-ofdm)
sudo chmod -R a+rw .
cd gr-ofdm
git init
git add -A
git commit "init" > /dev/null
}}}

Then, go about editing & any change will easily be found via "git
status". You can also revert back to the "init" (or last commit) version
of a file via "git checkout -- [filename]". Getting the changes is easy,
via "git diff" ... but note that this diff is "patch -p1" style, not the
usual MacPorts "patch -p0" style. It's easy to convert between them, but
will generally be a pain if a lot of files have been changed. My git-foo
isn't very strong, but these I know & they work quite well for fixing
MacPorts ports via source.


`git diff --no-prefix` generates "patch -p0" style diff.

--
Best regards,
Zero King


smime.p7s
Description: S/MIME cryptographic signature

Re: Server issues?

[Zero King]

On Sat, Sep 09, 2017 at 08:56:15AM -0500, Ryan Schmidt wrote:

On Sep 8, 2017, at 17:50, Rainer Müller wrote:


We could of course route the mails over braeburn. However, the mails for
macports-builds@ have stopped as well and there was not even a single
incoming connection from your static IP, so the current problem is not
related to spam checks at all.


I didn't realize mails had stopped sending to the macports-builds as well. It 
looks like this coincides with the last time the server that runs the 
buildmaster was restarted. I don't know why that caused mails to stop sending.



Any update on this?

--
Best regards,
Zero King


smime.p7s
Description: S/MIME cryptographic signature

Re: [macports-ports] branch master updated: Multiple ports: add missing required variables

[Zero King]

On Thu, Oct 05, 2017 at 10:29:52PM -0500, Ryan Schmidt wrote:


On Oct 5, 2017, at 17:49, Kurt Hindenburg wrote:


Kurt Hindenburg (kurthindenburg) pushed a commit to branch master
in repository macports-ports.


https://github.com/macports/macports-ports/commit/e8d12170f2e412c25e53a770acd58cb2f40e27ea

The following commit(s) were added to refs/heads/master by this push:

 new e8d1217  Multiple ports: add missing required variables




--- a/sysutils/detach/Portfile
+++ b/sysutils/detach/Portfile
@@ -11,6 +11,7 @@ long_descriptionThe  command is a grungy little 
program for \

executing programs in the background, \
without use of a control  terminal. \
(In the style of most common daemon processes...)
+homepagehttps://www.macports.org
 master_siteshttp://ftp.ntnu.no/old/pub/unix/utils/
 checksums   md5 843c6ff1590a56c1733c958a86cd8a93
 pre-configure   { reinplace "s|/usr/local|${destroot}${prefix}|g" 
${worksrcpath}/Makefile


This is the only change here I'd disagree with. We should only use that homepage on software we 
developed. For software that doesn't have a web page, using the download location as the homepage 
is probably acceptable. It's also acceptable not to set a homepage in those cases, in my opinion. 
"port info" simply omits the homepage information in that case, and "port 
gohome" knows to display an error message, so nothing breaks if there is no homepage set.


Then you should "fix" the obsolete 1.0 PortGroup


homepage    https://www.macports.org/


--
Best regards,
Zero King


smime.p7s
Description: S/MIME cryptographic signature

Re: license question

[Zero King]

On Thu, Oct 12, 2017 at 01:26:02AM -0500, Ryan Schmidt wrote:

On Oct 11, 2017, at 21:27, Ken Cunningham wrote:


There is an additional exception from the author permitting linking
with OpenSSL:


Can't wait for this to no longer be an issue, hopefully soon...

https://www.openssl.org/blog/blog/2017/03/22/license/


https://www.openssl.org/blog/blog/2017/06/17/code-removal/


We are planning on only changing the license for the master branch, so the
other releases branches aren’t applicable.


License of OpenSSL 1.0.2 (and probably 1.1.0 too) won't change. So we can't
change the license in Portfile when they finish re-licensing on their master
branch.

--
Best regards,
Zero King


smime.p7s
Description: S/MIME cryptographic signature

Re: Force build on wrong builder

[Zero King]

On Thu, Oct 12, 2017 at 07:37:06AM -0500, Ryan Schmidt wrote:


You can imagine that this gets worse the more ports you schedule at once, and 
the more interdependencies they have. And we have lots of python and perl 
modules, and they tend to have lots of interdependencies. So your forced build 
of all python modules on the High Sierra builder scheduled 2400 builds, which 
have so far taken 68 hours, during which no builds from commits could take 
place. We can let it run, because it's almost done now, and we do need to 
attempt those builds sooner or later, but I suspect many of those builds could 
have been avoided if they had been scheduled in smaller batches.


I saw that a lot of builds were scheduled on the Sierra builder and thought you
were trying to start another batch but chose the wrong builder.

I apologize for any inconvenience I've caused.

--
Best regards,
Zero King


smime.p7s
Description: S/MIME cryptographic signature

Force build on wrong builder

[Zero King]

Hi,

Did you trigger a force build [1] on the wrong builder? I started
another one [2] on 10.13.

[1] https://build.macports.org/builders/ports-10.12_x86_64-watcher/builds/8476
[2] https://build.macports.org/builders/ports-10.13_x86_64-watcher/builds/427

--
Best regards,
Zero King


smime.p7s
Description: S/MIME cryptographic signature

[GSoC 2017] Last Progress Report

[Zero King]

Hi,

In the last few weeks of GSoC 2017, I implemented graceful shutdown in
macports/mpbot-github@a2f819d, improved the README and summarized my
work in https://github.com/l2dy/gsoc2017_mp.

I also created the travis-ci branch in macports-base and let Travis
deploy MacPorts binaries used in CI for macports-ports whenever new
commits are pushed to that branch.

I'm quite satisfied with what I've accomplished and I couldn't have done
it without all your help. Thank you, my GSoC mentors and everyone who
joined the discussions on IRC and the mailing list.

--
Best regards,
Zero King


smime.p7s
Description: S/MIME cryptographic signature

Re: travis builds time out -- then keep restarting ???

[Zero King]

On Sun, Sep 17, 2017 at 01:53:23PM +, Rainer Müller wrote:

On 2017-09-17 15:40, Umesh Singla wrote:

It's not a recent issue. I faced it 9 days ago as well. It keeps
restarting, aborting and then finally, got cancelled [0]. There are
absolutely no logs present.

I hardly think it's a Travis issue. It would have been fixed by them or
informed if that was the case.


I do not think it is our issue if it also happens for base, for which
our configuration is minimal.

Did anyone inform them? Maybe it slipped through their monitoring.


I sent an email to supp...@travis-ci.com.


Rainer


--
Best regards,
Zero King


smime.p7s
Description: S/MIME cryptographic signature

Re: New project member: kencu

[Zero King]

On Mon, Sep 11, 2017 at 01:26:32PM +, Rainer Müller wrote:

Please join us in welcoming the following new MacPorts project member:

- Ken Cunningham (kencu)


Welcome, you've made great contributions recently and I'm happy to see
you joining us.



We look forward to continued excellent contributions from these new team
members.

- Joshua, Rainer, and Ryan


Do you want to join the MacPorts team? If you would like to be
considered for team membership and commit access, please read this
section of the Guide:

http://guide.macports.org/chunked/project.membership.html


--
Best regards,
Zero King


smime.p7s
Description: S/MIME cryptographic signature

Re: Pull request types in template on GitHub

[Zero King]

On Sun, Sep 10, 2017 at 02:28:46PM +, Rainer Müller wrote:

Hello,

our GitHub pull request template [1] contains the following snippet
which is used by the macportsbot to assign the corresponding label to it.

## Type(s)

- [ ] bugfix
- [ ] enhancement
- [ ] security fix

However, GitHub interpretes this as a list of tasks. This means that
with that list alone with one entry selected, the pull request will be
displayed with the note "1 of 3" and a progress bar next to it in the
list of pull requests.

Could we switch to a different syntax to avoid that?


Sure we can, but what syntax to use instead?


Rainer

[1]
https://github.com/macports/macports-ports/blob/master/.github/PULL_REQUEST_TEMPLATE.md


--
Best regards,
Zero King


smime.p7s
Description: S/MIME cryptographic signature

[GSoC] Progress Report

[Zero King]

Hi,

In the last few weeks, I implemented maintainer timeout handling in the
PR bot and fixed several bugs. It's now deployed and should
automatically add the "maintainer: timeout" label to PRs that requires
maintainer approval and didn't receive any response from the maintainer
in 72 hours.

In the next week, I'll automate deployment of base binaries used by the
CI bot and work on graceful shutdown of the PR bot. I'll also write a
blog post in Markdown that describes the work I've done and upload it to
https://github.com/l2dy/gsoc2017_mp.

--
Best regards,
Zero King


smime.p7s
Description: S/MIME cryptographic signature

Re: [MacPorts] #54594: mariadb-10.1 @10.1.24: update to 10.1.26

[Zero King]

On Sat, Aug 12, 2017 at 02:37:12PM -0700, Bradley Giesbrecht wrote:

Is there a pull request?

Regards,
Bradley Giesbrecht (pixilla)


No, there isn't. This update fixes 3 CVEs but I don't have the time to
test this port, so I created the ticket.



On Aug 11, 2017, at 9:02 PM, MacPorts  wrote:

#54594: mariadb-10.1 @10.1.24: update to 10.1.26
--+--
Reporter:  l2dy  |  Owner:  pixilla
Type:  update| Status:  new
Priority:  Normal|  Milestone:
Component:  ports |Version:
Keywords:  security  |   Port:  mariadb-10.1
--+--


--
Ticket URL: <https://trac.macports.org/ticket/54594>
MacPorts <https://www.macports.org/>
Ports system for macOS




--
Best regards,
Zero King


smime.p7s
Description: S/MIME cryptographic signature

Re: [macports-ports] branch master updated: curl: update to 7.55.0

[Zero King]

On Wed, Aug 09, 2017 at 04:34:02AM -0500, Ryan Schmidt wrote:


On Aug 9, 2017, at 04:31, Zero King wrote:


On Wed, Aug 09, 2017 at 04:16:34AM -0500, Ryan Schmidt wrote:



On Aug 9, 2017, at 04:08, Zero King wrote:

Zero King (l2dy) pushed a commit to branch master
in repository macports-ports.


https://github.com/macports/macports-ports/commit/11e25ff61c68e3cedd4e9109574b38008ed24378

The following commit(s) were added to refs/heads/master by this push:

new 11e25ff  curl: update to 7.55.0

11e25ff is described below


You should allow the maintainer some time to update a port before you do so. 
This was just released a few hours ago, and I was working on the update, and 
was working on switching it to use the xz distfile. (I'll do it with the next 
version instead.)


Do we have an exception for security fixes?


Yes I suppose security fixes are a good reason to override the maintainer.


curl releases often come with security fixes and I referenced the CVE
Identifiers in the commit message. What's your attitude towards curl
updates with such fixes?

--
Best regards,
Zero King


smime.p7s
Description: S/MIME cryptographic signature

Re: [macports-ports] branch master updated: curl: update to 7.55.0

[Zero King]

On Wed, Aug 09, 2017 at 04:16:34AM -0500, Ryan Schmidt wrote:



On Aug 9, 2017, at 04:08, Zero King wrote:

Zero King (l2dy) pushed a commit to branch master
in repository macports-ports.


https://github.com/macports/macports-ports/commit/11e25ff61c68e3cedd4e9109574b38008ed24378

The following commit(s) were added to refs/heads/master by this push:

 new 11e25ff  curl: update to 7.55.0

11e25ff is described below


You should allow the maintainer some time to update a port before you do so. 
This was just released a few hours ago, and I was working on the update, and 
was working on switching it to use the xz distfile. (I'll do it with the next 
version instead.)


Do we have an exception for security fixes?

--
Best regards,
Zero King


smime.p7s
Description: S/MIME cryptographic signature

Re: Build base archives for CI in a separate repository

[Zero King]

On Fri, Jul 28, 2017 at 02:20:47PM +0200, Rainer Müller wrote:

On 2017-07-28 04:06, Zero King wrote:

On Thu, Jul 27, 2017 at 07:56:27PM +0200, Clemens Lang wrote:

I would argue that the repository should in fact contain the MacPorts
source code. Ideally, without change in the repository, the build
results should be exactly the same, so there should be no need to
rebuild without a change in the repository. Remember that a change in
.travis.yml is also a code change worth a commit.

I also think that macports-base is very much related to the CI for
macports-ports just in the same way that macports-base in general is
related to macports-ports.

What's your use case for re-tagging on the same commit? I.e. what change
do you expect from rebuilding without changing something in the
repository (i.e. the .travis.yml file or the source).


The tag name changed. Currently, I'm using MacPorts version + a letter
for tags (e.g. v2.4.1a). So when v2.4.2 is released, I can simply tag
v2.4.2a and the build script can read the MacPorts version from the tag
and fetch the source from distfiles.macports.org. This doesn't cover new
macOS versions though (require changing .travis.yml).


v2.4.1a seems confusing to me, as it looks like a re-release.


I may need to update the CI archives between MacPorts releases. That's
why I used an extra letter.


My suggestion would be a travis-2.4 branch (to match release-2.4) with
tags named like travis-v2.4.1 in the macports-base repository. That
should sufficiently distinguish that this branch/tag is meant for CI only.


Were we to use a branch, should we rebase onto or merge the release
branch? I don't want to distribute API keys (though encrypted) in
MacPorts releases, so I prefer that the CI branch not be merged into
master or release branches.


I guess we cannot add the secrets to the Travis execution environment,
as there can only be one configuration per repository and that would
expose the secrets on pull requests?


No, PRs won't have access to the secrets.


If keeping secrets is a big problem, using a separate repository might
indeed be a solution, but I would keep it in the MacPorts organization.


Of course I'll keep it in the MacPorts organization. The discussion
isn't over yet and right now I don't have a working implementation for
either approach.

--
Best regards,
Zero King


smime.p7s
Description: S/MIME cryptographic signature

Re: Build base archives for CI in a separate repository

[Zero King]

On Thu, Jul 27, 2017 at 07:56:27PM +0200, Clemens Lang wrote:

Hi,

On Thu, Jul 27, 2017 at 01:51:31AM +, Zero King wrote:

I prefer using a separate repository (only containing .travis.yml and
maybe patches, not MacPorts source) because I can update the binaries
by creating a new release (tag) on the same commit (MacPorts version
can be read from tag name) and keep the setup for ports CI away from
macports-base (they aren't related in my opinion).


I would argue that the repository should in fact contain the MacPorts
source code. Ideally, without change in the repository, the build
results should be exactly the same, so there should be no need to
rebuild without a change in the repository. Remember that a change in
.travis.yml is also a code change worth a commit.

I also think that macports-base is very much related to the CI for
macports-ports just in the same way that macports-base in general is
related to macports-ports.

What's your use case for re-tagging on the same commit? I.e. what change
do you expect from rebuilding without changing something in the
repository (i.e. the .travis.yml file or the source).


The tag name changed. Currently, I'm using MacPorts version + a letter
for tags (e.g. v2.4.1a). So when v2.4.2 is released, I can simply tag
v2.4.2a and the build script can read the MacPorts version from the tag
and fetch the source from distfiles.macports.org. This doesn't cover new
macOS versions though (require changing .travis.yml).

Were we to use a branch, should we rebase onto or merge the release
branch? I don't want to distribute API keys (though encrypted) in
MacPorts releases, so I prefer that the CI branch not be merged into
master or release branches.


Additionally, having a separate repository is very visible to users,
which do not care about the internals of our CI system implementation.


We already have many macports-user-* repositories that are very visible
but inactive.


> > To debug the issue at hand, you could try to inject a
> >  system "/bin/ls -laeO@ ${target_dir}"
> > right before the 'file delete' to find out if there is anything like an
> > immutable flag on this file or directory.


Have you tried this?


https://travis-ci.org/macports-staging/macports-ports/jobs/257682551#L102

Tried once by adding it to .travis.yml, nothing abnormal. I'll try
adding that to source later. It's harder to redeploy the archives than
changing .travis.yml, but not as accurate for debugging.


--
Clemens


--
Best regards,
Zero King


smime.p7s
Description: S/MIME cryptographic signature

Whether to add "by: committer" label?

[Zero King]

Hi,

The "by: committer" label only provides extra information if the PR
sender is a committer but the port maintainer is not because the port
maintainer can only see the Member label on public members of the
macports organization (18 public, 65 total).

This is a trivial use case and if all our committers set this visibility
to public, the label would be useless. So, should I add it to the PR bot
or simply ask our members to make their membership public?

--
Best regards,
Zero King


smime.p7s
Description: S/MIME cryptographic signature

Re: Build base archives for CI in a separate repository

[Zero King]

On Wed, Jul 26, 2017 at 06:19:16PM +0200, Clemens Lang wrote:

Hi,

- On 25 Jul, 2017, at 17:27, Rainer Müller rai...@macports.org wrote:


On 2017-07-22 13:26, Zero King wrote:

In [1], I patched MacPorts in an attempt to fix a bug (port(1) failed
randomly on Travis). As it seems to be a Travis-specific bug, I plan to
use a separate repository to generate MacPorts archives used in CI and
keep the patch there. This way we can update the CI-specific archives
without a new release in macports-base (e.g. when new releases of macOS
become available on Travis).

[1]:
https://github.com/macports-staging/macports-base/commit/282e498ac51ba40bdfd43008ce430ca20a7d54ce#diff-d7db55f70d83fc9dba4ef14de9febe71


Should we keep a separate branch in the base repository for this? We
could cherry-pick such hotfixes to that branch (could also be restricted
to infrastructure team). I don't think we need a whole other repository
for this and we should keep everything in one organization.


Exactly my thoughts as well. Having a separate branch allows us to quickly
deploy fixes without the overhead of a separate repository not used for
anything else.


I prefer using a separate repository (only containing .travis.yml and
maybe patches, not MacPorts source) because I can update the binaries by
creating a new release (tag) on the same commit (MacPorts version can be
read from tag name) and keep the setup for ports CI away from
macports-base (they aren't related in my opinion).


Ideally, we should set up the macports-base Travis CI to automatically build
and publish the latest commit on that branch and the macports-ports CI to
automatically use the latest archive from that branch.


From https://bintray.com/docs/terms_of_service.html:
You may not, whether by yourself or anyone on your behalf, unless otherwise 
explicitly permitted under these Terms:
(xxvii) in connection with Contributions, upload and/or store on the Site 
continuous integration artifacts or nightly builds, (i.e. you may only upload 
and store content in direct connection to official software releases).

A tag counts as official software releases. But the latest commit
doesn't.


For example, we could upload a generated archive to Bintray and update a
file that always contains the URL to the latest archive and just download
that in the Travis CI job.



Besides that, I see no reason that this change could not go into regular
base with a comment explaining why it is necessary.


Agree here, please commit the change in macports-base.


That change didn't work and I committed another fix (not verified yet):
https://github.com/macports-staging/macports-base/commit/84b040fbcb1134e5cab1cc10cfc991c2d05c4824#diff-d7db55f70d83fc9dba4ef14de9febe71

Also, the other bug (Warning: Failed to copy com.apple.dt.Xcode.plist
... [1]) is not fixed.

[1] https://travis-ci.org/macports/macports-ports/jobs/249233655


To debug the issue at hand, you could try to inject a
 system "/bin/ls -laeO@ ${target_dir}"
right before the 'file delete' to find out if there is anything like an
immutable flag on this file or directory.


This might also happen if our builds are run under a sandbox, which could
denies deleting files in this location.

--
Clemens Lang


--
Best regards,
Zero King


smime.p7s
Description: S/MIME cryptographic signature

Re: [GSoC 2017] Second Evaluation

[Zero King]

On Wed, Jul 26, 2017 at 08:58:02AM -0400, Craig Treleaven wrote:

On Jul 26, 2017, at 8:33 AM, Zero King  wrote:

Another challenge is that I'm not good at wording so while I've spent a
lot of time on documentation and comments the results aren't ideal yet.


Don’t be too hard on yourself; I would say you are doing fine.  Expressing 
yourself concisely—and precisely—is vastly important.  And it is a skill that 
we’re never finished learning.  Keep working at it and get feedback wherever 
you can.


Thank you.


Craig


--
Best regards,
Zero King


smime.p7s
Description: S/MIME cryptographic signature

Re: [GSoC 2017] Second Evaluation

[Zero King]

On Mon, Jul 24, 2017 at 09:40:24PM +0530, Jackson Isaac wrote:

Hi GSoC Students and Mentors,

Phase 2 evaluations has begun. Deadline for filling the evaluations is
July 28, 2017 16:00 UTC. The procedure remains the same as previous.
Also please summarize the work done until now, challenges faced and
how did you manage to overcome them.


I've completed my second evaluation.

Until now, I have coded and deployed the CI bot that tests pull requests
on Travis CI and the PR bot that mentions maintainers and adds labels
according to available information from the databases and GitHub API.
Some features aren't implemented yet but both bots have already
processed many PRs.

One of the biggest challenges is that I started from scratch and had to
make a lot of hard decisions like whether to use mpbb or call port(1)
directly and how to upload logs. I had to find a balance between
reliability, security, maintainability, etc. and sometimes had to
abandon some code due to design changes.

Another challenge is that I'm not good at wording so while I've spent a
lot of time on documentation and comments the results aren't ideal yet.


Please let us know if there are any issues faced.


First, The com.apple.dt.Xcode.plist related bugs [1][2] appear randomly
(with low probability). While I've tried to fix [1] with [3], I'm not
able to verify if it works right away because I can't abuse Travis CI
resources to catch a random failure. Please help.

[1] https://travis-ci.org/macports/macports-ports/jobs/245649003
[2] https://travis-ci.org/macports/macports-ports/jobs/249233655
[3] 
https://github.com/macports-staging/macports-base/commit/84b040fbcb1134e5cab1cc10cfc991c2d05c4824#diff-d7db55f70d83fc9dba4ef14de9febe71

Second, I plan to keep the Travis build config for prebuilt MacPorts
binaries used in CI in a separate repository under github.com/macports
or a branch in macports-base that is rebased onto the release branch
whenever a new version of MacPorts is released. I prefer using a
separate repository because I can update the binaries by creating a new
release (tag) on the same commit (MacPorts version can be read from tag
name) and keep the setup for ports CI away from macports-base (they
aren't related IMHO). Any suggestion?


Regards,
Jackson Isaac


--
Best regards,
Zero King


smime.p7s
Description: S/MIME cryptographic signature

Build base archives for CI in a separate repository

[Zero King]

Hi,

In [1], I patched MacPorts in an attempt to fix a bug (port(1) failed
randomly on Travis). As it seems to be a Travis-specific bug, I plan to
use a separate repository to generate MacPorts archives used in CI and
keep the patch there. This way we can update the CI-specific archives
without a new release in macports-base (e.g. when new releases of macOS
become available on Travis).

[1]: 
https://github.com/macports-staging/macports-base/commit/282e498ac51ba40bdfd43008ce430ca20a7d54ce#diff-d7db55f70d83fc9dba4ef14de9febe71

--
Best regards,
Zero King


smime.p7s
Description: S/MIME cryptographic signature

[GSoC] Progress Report

[Zero King]

Hi,

In the last two weeks, I deployed pastebin upload from Travis and we now
have full build logs available on https://paste.macports.org and linked
in Travis logs. In some builds the pastebin link was lost, I fixed this
bug and a typo that caused failed builds reported as successful (Oops!).

I also implemented some core functions of the PR bot. As usual, code is
available in https://github.com/macports-staging/mpbot-github. The bot
can now notify maintainers and add maintainer labels but port maintainer
info processing is not yet finished.

Next week Clemens will help deploy the PR bot and I'll prepare the code
for deployment and fix bugs that pop up after deployment.

I'll investigate the list subports failure on Travis too. I strongly
suspect that it's the 'error deleting "...Xcode.plist"' bug. I still
have no idea what caused this delete bug and any help is appreciated.

Afterwards, I'll implement graceful shutdown or journaling (in a
database). I'll try to implement sending emails but I might work on the
review event handler first. The functions of the bots are described in
https://github.com/l2dy/mpbot-design.

--
Best regards,
Zero King

Don't trust the From address.


smime.p7s
Description: S/MIME cryptographic signature

[GSoC] Progress Report

[Zero King]

Hi,

In the last two weeks, I fixed a few bugs in the Travis integration.

* Fixed `git checkout` when `TRAVIS_COMMIT` is not HEAD
* Fixed port listing, use `git diff` with three dots
* Fixed typo, use subport name in MIME field name
* Fixed lint error when no Portfile changed
* Fixed detection of broken Portfiles

There are still some known problems:

* Some builds printed [ERROR] but exited with 0.
* Some builds failed to list subports.

These will not be investigated until the detailed logs are uploaded to
our Pastebin.

I had problems importing the database Clemens sent me but this is now
solved.

I also gained access to one of our servers last week and will deploy the
PR bot for macports-staging first.

I will implement the webhook receiver in the PR bot next week. Then I
will focus on presenting maintainer information in PRs first as Mojca
suggested.

--
Best regards,
Zero King

Don't trust the From address.


smime.p7s
Description: S/MIME cryptographic signature

Re: Travis: failed build reported as successful

[Zero King]

On Sun, Jul 02, 2017 at 02:41:55AM +, Zero King wrote:

Except when it's a fast-forward merge, Travis would not fetch the
commits in the PR. It only fetches the merge commit and some more
commits in master.


Except for a fast-forward merge, ...

--
Best regards,
Zero King

Don't trust the From address.


smime.p7s
Description: S/MIME cryptographic signature

Re: Travis: failed build reported as successful

[Zero King]

On Sat, Jul 01, 2017 at 10:53:41PM +0200, Mojca Miklavec wrote:

On 1 July 2017 at 18:51, Clemens Lang wrote:

On Sat, Jul 01, 2017 at 10:37:04AM +, Zero King wrote:



Travis only fetches the merged ref
`git fetch origin +refs/pull/542/merge:`, so it does complicate matters.


Isn't that exactly what we want?


Except when it's a fast-forward merge, Travis would not fetch the
commits in the PR. It only fetches the merge commit and some more
commits in master.


I thought of `grep`ing the output for "Failed to parse file" and
ignore broken Portfiles not touched by the PR like this one
> Failed to parse file python/py-pydot/Portfile: can't read "_name": no such 
variable
in https://travis-ci.org/macports/macports-ports/jobs/248896726.


Is this the correct link?


Yes. Two ports failed and one of them is on our master branch.


Rather than parsing the output of portindex, could we just run

  'port info'

in the directory of the modified portfile? That would catch the parse
error as well.


If commit changed 20 directories (hopefully nobody submits another PR
like the one to remove $Id lines in a couple of thousand ports :), the
command would have to be executed in each and every one of them.


It could be executed once with all ports changed as arguments, but
`portindex` is called before downloading CI bot and its dependencies.
I'd rather kill a build early if it contains broken Portfiles.


I simply cannot decide which approach is less "hacky", but anything
that works ...


Changing portindex to return non-zero on parse error may not be what we
want. As a user, I don't want my portindex to fail (and potentially
abort further processing) if somebody accidentially commits a broken
Portfile that I don't care about.


OK, that's a somewhat valid point. Maybe something like "portindex
--strict" would be suitable then :) Something that would return
non-zero value the :) :) :)
Just brainstorming, don't take my proposal too seriously.


We can patch the file on CI and leave it as it in -base.
Please review https://github.com/macports/macports-ports/pull/550.


I would say that this is not something that we should spend too much
time on for unrelated ports. I don't care if the complete build fails
if another unrelated port was in a bad shape. It may be that the
broken port is one of dependencies. The committer could have run
"portindex" himself, or in any case can act upon the problem once
discovered pretty quickly.

What is really important is to fail the build when portindex fails on
the submitted port. The use case that triggered this discussion was an
example where I could perhaps easily push the changes if it was
another much less relevant port submitted by maintainer. (I didn't see
the problem when first inspecting the changes. If maintainer
presumably tested it and the build succeeded ...)


The question is should I spend some time on filtering out irrelevant
broken ports. The important thing is done in PR#550.


Mojca


--
Best regards,
Zero King

Don't trust the From address.


smime.p7s
Description: S/MIME cryptographic signature

Re: Travis: failed build reported as successful

[Zero King]

On Sat, Jul 01, 2017 at 10:55:36AM +0200, Mojca Miklavec wrote:

I would be slightly in favour of taking the parent of PR as a
reference (that is: the exact state of the branch of the PR, so not
even trying to create portindex from master) unless that unnecessarily
complicates matters (if so, we can simply take trunk and stop worrying
about anything; in most cases that won't make a difference anyway).


Travis only fetches the merged ref
`git fetch origin +refs/pull/542/merge:`, so it does complicate matters.


What exactly did you have in mind with filtering?


I thought of `grep`ing the output for "Failed to parse file" and ignore
broken Portfiles not touched by the PR like this one

Failed to parse file python/py-pydot/Portfile: can't read "_name": no such 
variable

in https://travis-ci.org/macports/macports-ports/jobs/248896726.


Mojca


--
Best regards,
Zero King

Don't trust the From address.


smime.p7s
Description: S/MIME cryptographic signature

Re: Travis: failed build reported as successful

[Zero King]

On Sat, Jul 01, 2017 at 09:21:42AM +0200, Mojca Miklavec wrote:

I would say that
   portindex || exit 1
should work.


Does this make a difference? `portindex` returns 0 (success) even if
parse error occurred.


When individual steps could fail and when I wanted to proceed
executing the script to the end, I usually wrote a function that
checked for failure status and only reported / generated a failure at
the end. But I guess you can safely exit if portindex fails
(potentially add some explicit sentence saying so if it's not clear
from the error message).


If portindex couldn't parse the Portfile, I'd say we shouldn't waste
Travis's resource on the PR.

Another problem is that if our master branch contains broken Portfiles
(committed between PR parent commit and Travis build), should the build
fail and warn us or should we filter the irrelevant errors?


Mojca


--
Best regards,
Zero King

Don't trust the From address.


smime.p7s
Description: S/MIME cryptographic signature

Re: Travis: failed build reported as successful

[Zero King]

On Sat, Jul 01, 2017 at 07:51:12AM +0200, Mojca Miklavec wrote:

I tried to figure out where you call (anything that calls) portindex,
but no luck :).


https://github.com/macports/macports-ports/blob/master/_ci/bootstrap.sh#L18

--
Best regards,
Zero King

Don't trust the From address.


smime.p7s
Description: S/MIME cryptographic signature