* Gerben Wierda via macports-dev:
> In other words: isn’t it at some point becoming important to have some
> sort of process where we can support this?
Wearing my hat of GnuPG for OS X maintainership:
I for one will be happy to start sign installation packages and similar
artifacts as soon as
* Stephen A. Langer:
> Are all the mistakes that I made in the initial submission baked into
> my fork? Pmetzger advised me to start over, but it's not clear to me
> at which point I should start over.
Hard to say without knowing your repository state.
Here is how I have set things up for
* Marius Schamschula:
> It is suggested that channels be moved to libera.chat.
For what it's worth, I have registered my nick on libera.chat, and I am
just now witnessing Gentoo Linux channels being created and operator
roles assigned, mirroring what exists currently on Freenode.
-Ralph
* Ryan Schmidt:
> I wasn't aware that discussions on the mailing list were difficult to
> access.
I don't think they are difficult to access, if one is using a suitable
setup. Personally, I use Notmuch (https://notmuchmail.org) specifically
for all my mailing list subscriptions, with my IMAP
* Ryan Schmidt:
> Little Snitch is also mentioned being present by the user who reported
> https://trac.macports.org/ticket/60509 so that could indeed explain
> why only a few users see the problem.
https://obdev.at/support/littlesnitch/245914647368270
Apple has apparently made significant
I checked https://trac.macports.org/wiki/TracTickets for details, but it
looks like I cannot change status and resolution for a Trac ticket which
is currently assigned to me. Is this deliberate? The "modify ticket"
section of the web UI only offers me the option to reassign the ticket
to somebody
* Mojca Miklavec:
>> If I can assist, let me know, but I don't think it likely at this
>> point.
>
> Because you lack time or for some other reason?
I would make the time for MacPorts. My assumption is just that I still
know to little about how the MacPorts builds work to be of assistance,
and
* Ryan Schmidt:
>> Tries being the operative word here. ;-)
>
> What are you trying to say?
Did I step on somebody's toes? I am saying that the build that concerns
me timed out setting up the dependencies. That, from my understanding,
means the dependencies were either unavailable in binary
* Mojca Miklavec:
> What we need is:
> - a list of recipes to set up images for a bunch of different macOS
> versions (as far back into history as possible)
> - a recipe for how to fire up a VM, do something basic (port install
> foo) and trash the result
Looking at the Travis CI config and the
* Mojca Miklavec:
> It tries to install dependencies as binaries, provided the binaries
> are available.
Tries being the operative word here. ;-)
> We should figure out:
> - which dependencies time out
> - why they are not installed from (the private) binary package repository
I'm guessing
* Ryan Schmidt:
> I feel that the Azure Pipelines are already giving us good results on
> current systems, and we could probably turn off the Travis builds for
> the systems that Azure also covers.
That seems like a reasonable approach to me.
-Ralph
* Mojca Miklavec:
> If you volunteer to do some research / work in this area ... that
> would likely be the most significant step in "increasing your chances"
I actually have some experience in this field. I use GitLab (Omnibus
edition), Docker, and GitLab Runners inside Docker for CI/CD. That's
* Joshua Root:
>> [1] https://travis-ci.org/github/macports/macports-ports/jobs/724689780
>
> It's just a matter of how long your port takes to build (including
> installing all its dependencies).
Notmuch, which is what was built in the job [1], is small and builds in
less than a minute on my
I fail to remember the last time one of my builds successfully passed
Travis CI. All I see are timeouts [1]. Other peoples' jobs apparently
make it through Travis OK, so I wander what I can do to increase my
chances?
[1] https://travis-ci.org/github/macports/macports-ports/jobs/724689780
-Ralph
* macpo...@parvis.nl:
> i would like these 10.11 and 10.13 as vm guest under 10.15.
Why as a VM guest? Have you considered installing and booting different
macOS versions on separate partitions of the same machine? You can even
install macOS on external harddisks.
Another option I find
* Saagar Jha:
> Though it’s not the default, you can actually tell MacPorts to use Git
> to sync your ports [...]
I had a glimpse at the guide. Am I correct to assume that it would be
possible to use a shallow Git clone?
-Ralph
* Mojca Miklavec:
> I would not dismiss the initial effort as a GSOC project as long as
> the student can prove the competence to do some good work and
> reasonable potential to stick with the project afterwards.
The way I understand GSoC projects is that smaller, self-contained work
is
* Ryan Schmidt:
> [...] I would have hoped that GSoC would be used as an opportunity for
> us to finally implement changes that we have wanted to do for years
> but never got around to doing, rather than to propose new projects
> whose ramifications have never been discussed before.
Quite so.
* Ryan Schmidt:
> We might also add a way for a developer to indicate for which ports
> developer mode should be turned on. A developer might wish, for
> example, to be notified of issues relating to the ports they maintain
> but not the ports that others maintain.
That can be useful. Is that
* Ryan Schmidt:
> I wonder if we should add a "developer mode" to MacPorts -- something
> that developers could enable in macports.conf.
I for one would like to be able to peek into what is happening under the
hood when working with Portfiles, so increased logging of technical
details sounds
* Remko Scharroo:
> I have submitted four pull requests 4+ days ago, and they have not
> been approved.
Four whole days you say? :-) My oldest open pull request on GitHub (not
MacPorts related) was created in April 2019, and nobody has deigned to
even comment so far. MacPorts PRs are usually
* Ken Cunningham:
> I bet almost nobody ever looks at them, much less uses them.
Well, I certainly do. On any UNIX-like system I expect at least man-
pages for every installed command line utilty, configuration file, etc.
Having locally installed docs is a requirement for working offline. I
* Bjarne D. Mathiesen:
> Am I correct in assuming, that if I have to edit my submission, I'll
> have to do it this way [...]
Not quite. Assuming your output of "git remote -v" looks like this:
origin g...@github.com:BjarneDMat/macports-ports.git
you can just keep on editing branch "dovecot2"
* Blair Zajac:
> Well, please at least open a bug to request the upgrade :)
Fair enough. https://trac.macports.org/ticket/58921
-Ralph
* Clemens Lang:
> Re-iterating on that, the problem is likely SCons [...]
I appreciate all your guys' input.
After some much-needed sleep, I have decided that I do find having a
Portfile for MongoDB 4.2.0 on macOS an interesting challenge, but given
my time constraints I'll stick with the
Dang, forgot the link:
[1] https://github.com/mongodb/mongo/blob/master/docs/building.md
* Blair Zajac:
> Is this port only for you and you’ll not commit it to the Git repo?
As of now, I am only trying that particular build for myself.
> Which package is this?
I am trying to build MongoDB 4.2.0 by modifying the existing Portfile
(that's version 4.0.12). According to the docs[1],
* Blair Zajac:
> You’ll want to avoid the PATH approach as it requires that
> ${prefix}/bin/python be symlinked to a Python 3.x, which isn’t always
> the case.
Not always, but it is for me:
$ ls -dl /opt/local/bin/python
lrwxr-xr-x 1 root admin24B 11 Jul 16:50 /opt/local/bin/python@
I am wrestling with a port that requires Python >=3.5 to build, and
Python 3.7 is the chosen one:
$ which python
/opt/local/bin/python
$ python --version
Python 3.7.4
Looks good to me. However, the build log shows the following:
:info:build Python 3.5 or greater required, but you have
* Jack Howarth:
> Short of fully reinstalling MacPorts is there a way to recreate the
> "macports" user?
You can create users via the Users & Groups system settings, or using
the 'dscl' (Directory Service command line) utility as root.
-Ralph
* Bruce Miller:
> (And ideally, I'd avoid the whole version business, since LaTeXML
> *should* work with any version of perl after, I think, 5.10)
If you are able to determine a minimum required Perl version 5.x.y,
might adding 'use 5.x.y;' (e.g. via a patch) for a compile time version
check
Working on the Notmuch port, I fixed a problem of the upstream configure
script calling mktemp with insufficient (for older OS X versions)
parameters [1]. Once that hurdle was passed, the builds ran into a
limitation for socket file name length. I opened another PR [2] in which
Chris Jones
I wanted to take a shot at updating the Pandoc port from version 1.12 to
2.7.1, but the GHC prerequisite build fails.
:info:build deriveConstants: fd:31: hClose: invalid argument (Bad file
descriptor)
:info:build make[1]: ***
[includes/dist-derivedconstants/header/DerivedConstants.h] Error
33 matches
Mail list logo
