Re: Code signing
* 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 Apple stops charging a 99 EUR yearly subscription fee for open source project maintainers. -Ralph
Re: having trouble with pull requests
* 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 MacPorts, but it also applies to
contributions I make to other Git repositories.
$ cd /path/to/my/macports
$ git remote -v
origin g...@github.com:rseichter/macports-ports.git (fetch)
origin g...@github.com:rseichter/macports-ports.git (push)
upstream g...@github.com:macports/macports-ports.git (fetch)
upstream g...@github.com:macports/macports-ports.git (push)
# Make sure we're on master first.
$ git checkout master
# Fetch changes from official MacPorts repository ("upstream").
$ git fetch upstream
# Merge changes into master.
$ git merge upstream/master
# Push updated master to my own MacPorts fork ("origin").
$ git push origin master
# Create and checkout new branch for my changes.
$ git checkout -b mybranch-123
# Check and/or change commit history. This can be done multiple times.
$ git rebase -i origin/master
# Push branch to my MacPorts fork.
$ git push -u origin mybranch-123
After that, I can open a pull request. I can also keep rebasing and
pushing changes to mybranch-123 until both I and the reviewer are
satisfied (use "push -f ..." if necessary after a rebase).
Keeping upstream/master and origin/master in sync and rebasing usually
does the trick, and it might be all you need.
-Ralph
Re: Freenode IRC
* 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
Re: GitHub discussions
* 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 server storing data in maildir format. Thousands of messages? No problem at all. -Ralph
Re: macOS Big Sur 11.0.1 crashes when MacPorts tries to install p5.28-locale-gettext
* 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 changes to the way firewalls work, and has also introduced an internal whitelist of Apple services which can no longer be blocked. German speaking users can for example check recent publications on heise.de. -Ralph
How to close a Trac ticket assigned to me
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 else. -Ralph
Re: Travis CI timeouts for MacPorts builds
* 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 that "you guys" have matters in hand. If you think that I can actually help, and if there is documentation or source code available, please let me know. I'm ready for some reading. ;-) -Ralph
Re: Travis CI timeouts for MacPorts builds
* 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 form, or that the attempt to access said binary form failed. Hence my comment above, in an attempt to make light of the situation, as the smiley indicates. > We would need to see logs of the installation of the dependencies to > know why they're taking so long, but I don't see any such logs, and > don't know where or how that's happening or not happening. That makes tackling the underlying issue difficult, of course. > We don't "ignore Travis results". Mojca Miklavec wrote (quote) "Generally we mostly ignore Travis results, so there's no real reason to worry in your case.", which led me to believe that you generally mostly ignore Travis results. How silly of me. :-) -Ralph
Re: Travis CI timeouts for MacPorts builds
* 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 raw Travis logs, I don't see much. Are more detailed log files available? The magic seems to happen in the code hosted in mpbot-github. -Ralph
Re: Travis CI timeouts for MacPorts builds
* 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 that "we" means the devs who maintain the build config. If I can assist, let me know, but I don't think it likely at this point. At a glance, I'd expect a glib2 build from source to be quite a drag. The various xorg-* ports might also take some time. I don't see why the latter would be required, given that the build apparently did not use the +emacs variant? > Generally we mostly ignore Travis results, so there's no real reason > to worry in your case. If you ignore Travis results, why run Travis CI in the first place? I suggest to either fix the underlying issue or remove Travis builds. That would at least free up some server resources, for the benefit of other projects which actually rely on their Travis builds. -Ralph
Re: Travis CI timeouts for MacPorts builds
* 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
Re: Travis CI timeouts for MacPorts builds
* 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 basically the setup which gitlab.com uses (albeit sans their S3-based caching), and it can handle serious builds. Doing research re MacPorts would require knowledge about the MP build infrastructure, which I don't yet have. I'd be willing to look into it, though, if that infrastructure is properly documented somewhere. -Ralph
Re: Travis CI timeouts for MacPorts builds
* 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 MacBook once the prerequisites are installed. Perhaps you'd like to try it for yourself. Is the Travis-based build just installing the dependencies (as in: the binary packages), or does it also build the dependencies from source? I suspect the latter. I actually tried that here, and it took ages, even on my octa-core machine. -Ralph
Travis CI timeouts for MacPorts builds
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
Re: macos as vm guest
* 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 interesting is macOS-Simple-KVM [1], if you happen to have a spare Linux box sitting around. [1] https://github.com/foxlet/macOS-Simple-KVM Not exactly what you asked for, but I still hope this helps a bit. -Ralph
Re: [MacPorts] #60590: Macports mirrors are down?
* 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
Re: GSoC Proposal: Rewrite key parts of MacPorts in Python
* 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 preferred. Rewriting MacPorts is way out of scope for that. It is too big a task for a "summer" project, requires solid knowledge about the existing MacPorts environment and experience in software design. I would not entrust a student with that type of work. -Ralph
Re: GSoC Proposal: Rewrite key parts of MacPorts in Python
* 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. Not meaning any disrespect to Alex (I have never seen any of his code), but if the developer team would actually let him have a shot at rewriting parts of MacPorts in Python, I'd look for ways to sever my connections with MacPorts. Homebrew seems nice. My own experience in software development spans more than 35 years, some of them focused on Python, and think that rewriting significant aspects of MacPorts in Python is neither desirable nor an achievable goal for a "summer of code". Proper design alone with all its necessary peer review stages could take months. My advice to GSoC participants: Choose a smallish task with clearly defined goals that can be completed and documented in the alotted time. Work to meet the highest quality standards, and actually make life a little better for end users. Don't aim for the stars. MacPorts devs have spent many, many years on the existing ecosystem, and while there is of course room for improvement, proposing a rewrite is, as far as I am personally concerned, a mere demonstration of bravado that does not inspire confidence in me. -Ralph
Re: Developer mode
* 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 not something Trac should handle? If a ticket references a specific port, is the designated maintainer not automatically added to the ticket? > You mentioned updating manifests. I don't know what a manifest is but > MacPorts ports only have a Portfile. We did recently introduce the > "port bump" developer command to assist with updating checksums While MacPorts lists distribution archive checksums as part of each Portfile, Gentoo uses a separate Manifest file for that (one reason being that Gentoo offers multiple versions per ebuild, hence multiple checksums are required). "repoman manifest" adds new checksums and/or removes obsolete ones, for convenience. If "port bump" does the same, that's news to me, but a nice feature I have been waiting for. > We don't have a tool to automate commit messages. We expect developers > to write them manually, including referencing any related Trac > tickets. I'm not sure I understand how an automated tool could know > which ticket(s), if any, a commit is related to. Let's use https://trac.macports.org/ticket/58921 as an example, a ticket I opened and you processed and closed (thanks for the update by the way). If this was a Gentoo ticket, you could have used the following: $ cd /path/to/your/ports/mongodb $ repoman -c 58921 commit This would have created the following type of Git commit message template and opened it in your editor: dev-db/mongodb: Closes: https://trac.macports.org/ticket/58921 Package-Manager: Portage-2.3.79, Repoman-2.3.18 Signed-off-by: Ryan Schmidt I am aware that MacPorts does not use sign-off lines, this is just an example of how repoman pre-populates commit messages. Also, the prefix "dev-db/mongodb:" is Gentoo-specific, it would just be "mongodb:" for MacPorts. The point is that repoman will choose the correct prefix for the user. The option "-c" adds the correct "Closes" line for a given ticket number, while "-b 58921 -b 1234" would add Bugs: https://trac.macports.org/ticket/58921 Bugs: https://trac.macports.org/ticket/1234 i.e. non-closing references to existing tickets. As I mentioned before, repoman also performs a "port lint" equivalent. It is simply a tool to make recurring operations like basic QA checks and commits more convenient for the user (it does for example report local untracked files which you may have forgotten to add). The user is of course still responsible for providing useful commit messages, both short summary and verbose description. Sorry if this moved a bit away from the original developer mode subject. I just work a lot more in Gentoo than in MacPorts, and I always miss repoman's watchful presence when I work with Portfiles. ;-) -Ralph
Re: Developer mode
* 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 useful to me. That includes deprecation warnings,
suggested update paths, etc.
> In "developer mode", "port lint" or other checks could be run as part
> of every install.
Gentoo Linux provides a tool called 'repoman' [1] that is similar to
'port lint' in some aspects. It also provides convenience functions like
updating manifests (mostly source tarball checksums) and a wrapper for
VCS commits that pre-populates commit messages with the ebuild name
(similar to Port name), sign-off lines, and links to referenced/closed
issues in Gentoo's Bugzilla. I find repoman to be very useful, and if
the developer mode you suggested comes with similar utility, I would
welcome it.
[1] https://wiki.gentoo.org/wiki/Repoman
-Ralph
P.S.: Output of 'repoman --help' in the current version:
usage: repoman [options] [mode]
Modes: ci | commit | fix | full | help | manifest | manifest-check | scan
optional arguments:
-h, --helpshow this help message and exit
-a, --ask Request a confirmation before commiting
-b , --bug
Mention a Gentoo or upstream bug in the commit footer;
takes either Gentoo bug number or full bug URL
-c , --closes
Adds a Closes footer to close GitHub pull request (or
compatible); takes either GitHub PR number or full PR
URL
-m COMMITMSG, --commitmsg COMMITMSG
specify a commit message on the command line
-M COMMITMSGFILE, --commitmsgfile COMMITMSGFILE
specify a path to a file that contains a commit
message
--digest Automatically update Manifest digests for modified
files
-p, --pretend don't commit or fix anything; just show what would be
done
-q, --quiet do not print unnecessary messages
--echangelog
for commit mode, call echangelog if ChangeLog is
unmodified (or regardless of modification if 'force'
is specified)
--experimental-inherit
Enable experimental inherit.missing checks which may
misbehave when the internal eclass database becomes
outdated
--experimental-repository-modules
Enable experimental repository modules
-f, --force Commit with QA violations
-S, --straight-to-stable
Allow committing straight to stable
--vcs VCS Force using specific VCS instead of autodetection
-v, --verbose be very verbose in output
-V, --version show version info
-x, --xmlparseforces the metadata.xml parse check to be carried out
--if-modifiedonly check packages that have uncommitted
modifications
-i, --ignore-arches ignore arch-specific failures (where arch != host)
--ignore-default-opts
do not use the REPOMAN_DEFAULT_OPTS environment
variable
-I, --ignore-masked ignore masked packages (not allowed with commit mode)
--include-arches ARCHES
A space separated list of arches used to filter the
selection of profiles for dependency checks
-d, --include-dev include dev profiles in dependency checks
-e , --include-exp-profiles
include exp profiles in dependency checks
--unmatched-removal enable strict checking of package.mask and
package.unmask files for unmatched removal atoms
--without-maskbehave as if no package.mask entries exist (not
allowed with commit mode)
--output-style {column,default}
select output type
--mode {ci,commit,fix,full,help,manifest,manifest-check,scan}
specify which mode repoman will run in (default=full)
For more help consult the man page.
Re: Four pending PRs for 4+ days
* 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 handled with dizzying speed, compared to other projects I contribute to. -Ralph
Re: RFC: MacPorts policy should be that docs should not be built or installed by default
* 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 know from personal experience that building documentation is sometimes a burden, depending on how "creative" the author chose the formats, but man-pages and/or HTML should be possible. Gentoo Linux package maintainers (such as myself) are expected to include documentation if at all possible. By means of the "docs" USE- flag, users can then choose whether or not to have the documentation built/installed. -Ralph
Re: [pull 5236] seeking advise
* 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" and using rebase: git checkout dovecot2 # ... make changes ... git commit git rebase -i HEAD~2 Replace HEAD~2 with the actual number of commits you want to rebase. Squash commits as necessary, combining them to logical units. Finally, use git push -f origin dovecot2 to force-push the branch's modifications to GitHub. Forced pushes won't hurt if you are the only one working on that branch. -Ralph
Re: How to enforce a particular Python version during port build
* Blair Zajac: > Well, please at least open a bug to request the upgrade :) Fair enough. https://trac.macports.org/ticket/58921 -Ralph
Re: How to enforce a particular Python version during port build
* 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 official binaries for now (see https://www.mongodb.com/download-center/community). I am guessing it was mostly my dark, Gentoo Linux side that was pushing me towards building from the sources. ;-) -Ralph
Re: How to enforce a particular Python version during port build
Dang, forgot the link: [1] https://github.com/mongodb/mongo/blob/master/docs/building.md
Re: How to enforce a particular Python version during port build
* 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], building MongoDB requires Python 3.7. There's obviously more to it than just changing 'depends_build'. I can of course build MongoDB manually, but where's the fun in that? ;-) -Ralph
Re: How to enforce a particular Python version during port build
* 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@ ->
/opt/local/bin/python3.7
Does this not mean it should work on my machine unless something is
screwing with the PATH variable?
> Instead tell it to use ${prefix}/bin/python3.7. You’ll have to poke
> into the project to see how to tell it specifically which Python
> binary to use.
Are you saying that I cannot enforce/extend PATH in the Portfile? I'd
rather not patch the sources if I can avoid it.
-Ralph
How to enforce a particular Python version during port build
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 Python 2.7.16 Seems like Apple's Python 2.7 is being used. I have already tried adding 'build.env PATH=/opt/local/bin:$env(PATH)' to the Portfile, but this did not resolve the issue. What am I missing? -Ralph
Re: user "macports" does not exist
* 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
Re: Peculiar perl version issue
* 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 solve your issue? See https://perldoc.perl.org/functions/use.html -Ralph
Socket name length limitations and MacPorts buildbot
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 suggested I ask for help here.
A full socket file name (path + filename + NUL string terminator) may
only be 104 bytes long, as defined in .
struct sockaddr_un {
unsigned char sun_len;/* sockaddr len including null */
sa_family_t sun_family; /* [XSI] AF_UNIX */
charsun_path[104]; /* [XSI] path name (gag) */
};
Alas, buildbot uses working directories which can crack that limit:
/opt/local/var/macports/build/_Users_vsts_agent_2.152.1_work_1_s_mail_notmuch/notmuch/work/notmuch-0.29
103 bytes, not counting the trailing NUL, so there is no way to create
any socket file within the build's working directory. I tried using /tmp
as a base at first, but it looks like Apple's method of using a symlink
pointing to whatever long-named directory can exceed the sun_path size
limit as well.
Has anybody else experienced this using MacPorts' buildbot, and if so,
do you have any idea how to resolve this problem?
Thanks for your input.
-Ralph
[1] https://github.com/macports/macports-ports/pull/4573
[2] https://github.com/macports/macports-ports/pull/4576#issuecomment-500635778
Error building Haskell for Pandoc
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 1 I found https://trac.macports.org/ticket/48899 but I am unsure if I should add the build log file there or if a new ticket would be better? I am also wondering about the chances of actually finding somebody willing to work on Haskell, seeing that the existing ticket was filed four years ago? Personally, I don't know enough about GHC. -Ralph P.S.: I know there is a Pandoc installer for macOS available, but it looks like conversion to PDF does not work out of the box.
