Re: XZ Utils Compromised Releases

[Rainer Müller]

On 29/03/2024 18.52, Blair Zajac wrote:
> In https://www.openwall.com/lists/oss-security/2024/03/29/4
>  it says
> 
> == Bug reports ==
> 
> Given the apparent upstream involvement I have not reported an upstream
> bug….
> 
> 
> I suggest not waiting for an upstream release and instead revert our
> commit and add an epoch line.

You are right. That is the best way as we cannot be sure what else just
has not been discovered in the backdoor-ed releases.

Joshua already pushed the downgrade to xz @5.4.6 with the epoch bumped.
Thank you!

https://trac.macports.org/ticket/69619
https://github.com/macports/macports-ports/commit/a1388aee09c9e921e3a9d47cf9d37e5d3f3c10ad

Rainer

Re: XZ Utils Compromised Releases

[Rainer Müller]

On 29/03/2024 18.40, Fred Wright wrote:
> 
> On Fri, 29 Mar 2024, Frank Dean wrote:
> 
>> I received a security announcement on the Debian mailing list [1].  It
>> appears versions 5.6.0 of XY Utils and later may be compromised.  I
>> also found a discussion on Openwall [2].
>>
>>
>> [1]:
>> https://lists.debian.org/debian-security-announce/2024/msg00057.html
>> 
>>
>> [2]: https://www.openwall.com/lists/oss-security/2024/03/29/4
>> 
>>
>>
>> I'm afraid that's all I know.  Just a heads-up.

Wow. That's an awful story.

The exploit seems to specifically target Linux systems only ("[...] it
is likely the backdoor can only work on glibc based systems.").

> In [1] they mention reverting to 5.4.5 to fix it.  It's not 100% clear
> from that whether 5.4.6 is affected, but it sounds like it's not.  Since
> MacPorts is currently at 5.4.6, the port is probably OK as long as it
> doesn't do any overzealous upgrading.

The xz port was updated to 5.6.1 just two days ago:
https://github.com/macports/macports-ports/commit/784e59f99e51adbadc663b1b689d66363adf193a

Based on the current information, the risk seems low for macOS system.
Should we still be cautious and revert to version 5.4.6 and bump the
epoch to force a downgrade for everyone? Or do we expect a new upstream
release soon to sort this out?

Rainer

Re: Getting updated cargo.crates

[Rainer Müller]

On 30/11/2023 18.46, Austin Ziegler wrote:
> I was opening a new PR to update a Rust dependency today and could not
> figure out how to update the `cargo.crates` section. Digging through the
> cargo-fetch portgroup pointed me
> to 
> https://github.com/macports/macports-contrib/tree/master/cargo2port/cargo2port.tcl
>  
> ,
>  which fails to run because the Cargo.lock format appears not to be the same 
> as it was when written.

Indeed, the cargo2port in contrib does not support the V2 format:
https://trac.macports.org/ticket/60335

There is a note in the README.md right next to it, but it seems like
this is easily overlooked. Please use the port cargo2port instead:
https://ports.macports.org/port/cargo2port

I found an old reference to macports-contrib in the cargo_fetch port
group and openend a PR:
https://github.com/macports/macports-ports/pull/21686

But there might be more links to the script, so keeping the
cargo2port.tcl in macports-contrib is probably more confusing than it
helps. The README.md next to it will not help users following a direct
link to the script.

How can we improve the situation with cargo2port in macports-contrib?
a) delete the cargo2port directory completely
b) stick a note directly into cargo2port.tcl

Rainer

Re: Help with zef Portfile

[Rainer Müller]

On 25.11.23 16:07, Joshua Root wrote:
The default destroot phase builds a string to pass to 'system' by 
combining destroot.cmd, destroot.args, etc. In this case, it might be 
easiest to use those for the rakudo command, and create the symlinks in 
a post-destroot block?


Also note that all files have to be put into ${destroot} during the destroot 
phase. The files will afterwards be put into an archive from this ${destroot} 
and will only later be moved to the real ${prefix} when activating the port.

When moving these symlink commands to a post-destroot phase, these should look 
like this:

post-destroot {
ln -s "${prefix}/share/perl6/site/bin/zef"   "${destroot}${prefix}/bin/zef"
ln -s "${prefix}/share/perl6/site/bin/zef-m" 
"${destroot}${prefix}/bin/zef-m"
}

Rainer

Re: More classes of maintainer

[Rainer Müller]

[Resending, K-9 Mail from mobile sent it with an empty HTML version.]

On 06/11/2023 12.49, Mark Anderson wrote:
> The other thing that is different now is GitHub issues and projects have
> come a long way in terms of features - we can probably implement
> everything we do on Trac on Github as well. 

Well, that is what I was asking... I am not aware of improvements. What
has changed with GitHub Issues?

How would we find issues for specific ports? There is only a lose
full-text search. Imagine how that will work for a port named "add"
(real example) or any other common English word.

You cannot assign issues to non-member maintainers (at least they would
have to leave a comment first). We already experience the same situation
for pull-requests where mentions are used as a workaround.

GitHub Projects are nice, but we are not an agile development team doing
sprints. If we moved the tickets for base it would be replacement for
the milestones on Trac.

But I don't see how GitHub Projects would help us with the issues for
ports, which are most of the tickets being filed every day.

> As I recall Github issues didn't have all the features we needed. It
> also would help us not need to manage our own Trac instance.

The other big part of Trac is the wiki. GitHub also has a wiki, but only
on the level of repositories. However, our wiki also covers many topics
that overlap between base, ports, etc.

Conversion of the wiki to GitHub with Markdown syntax would certainly be
possible, but to me that feels like hiding it even more and will not
give it more exposure.

Rainer

Re: More classes of maintainer

[Rainer Müller]

On November 6, 2023 12:49:26 PM GMT+01:00, Mark Anderson  
wrote:
>The other thing that is different now is GitHub issues and projects have
>come a long way in terms of features - we can probably implement everything
>we do on Trac on Github as well.

Well, that is what I was asking... I am not aware of improvements. What has 
changed with GitHub Issues?

How would we find issues for specific ports? There is only a lose full-text 
search. Imagine how that will work for a port named "add" (real example) or any 
other common English word.

You cannot assign issues to non-member maintainers (at least they would have to 
leave a comment first). We already experience the same situation for 
pull-requests where mentions are used as a workaround.

GitHub Projects are nice, but we are not an agile development team doing 
sprints. If we moved the tickets for base it would be replacement for the 
milestones on Trac.

But I don't see how GitHub Projects would help us with the issues for ports, 
which are most of the tickets being filed every day.

>As I recall Github issues didn't have all the features we needed. It also
>would help us not need to manage our own Trac instance.

The other big part of Trac is the wiki. GitHub also has a wiki, but only on the 
level of repositories. However, our wiki also covers many topics that overlap 
between base, ports, etc.

Conversion of the wiki to GitHub with Markdown syntax would certainly be 
possible, but to me that feels like hiding it even more and will not give it 
more exposure.

Rainer

Re: More classes of maintainer

[Rainer Müller]

On 02/11/2023 21.19, Herby G wrote:
> I actually do think moving tickets and issues from Trac to GitHub Issues
> is a good idea, and would increase engagement for the project.

We evaluated this option thoroughly back in 2016 when we moved the code
repositories to GitHub. As far as I remember it was Ryan who even did a
test run of a conversion of all the Trac tickets to GitHub Issues. The
evaluation phase of different tools went on for weeks.

But the results and the experience with GitHub Issues were not to our
satisfaction. In the end, we decided to keep Trac for the tickets. The
hope was that hosting our own Trac instance would also offer more
flexible options for future improvements, while with GitHub Issues we
would be locked in.

We integrated our Trac instance more closely with GitHub and invested
effort to improve the trac-github plugin (login, roles based on GitHub
teams, closing tickets on merge, links for commit hashes, etc.).

For reference, this was the announcement of the migration to GitHub in
the mail archive:
https://lists.macports.org/pipermail/macports-dev/2016-August/033405.html

Did the situation change since our assessment back then? As far as I am
aware, there is still not a way to categorize GitHub Issues except with
labels. How would we manage the ~4000 open tickets for ports with GitHub
Issues?

Rainer

Re: `port archive` ?

[Rainer Müller]

On 20/10/2023 15.14, René J.V. Bertin wrote:
> It happens that I'd like to "install" a variant of a self-built port without 
> actually activating it (e.g. when libraries are in use and I have no 
> immediate need to activate that different variant).
> 
> Looking through the code I saw there must exist a `port archive` command that 
> isn't documented in the manpage. Does that do what I'm looking for or does it 
> just make the tar bundle under $prefix/var/macports/software ?

Yes, 'port archive' would do what you are looking for. You are correct
this is actually missing in port(1), but please see the separate man
page port-archive(1).

Rainer

Re: accessing $argv0 from Portfile?

[Rainer Müller]

On 15.08.23 15:01, René J.V. Bertin wrote:

Is there a way to get the path to MacPort's tclsh interpreter from within a 
Portfile, other than by using a `glob` to find it in 
$prefix/libexec/macports/bin ?

(not to do anything naughty, just to run a Tcl test/benchmark.)


You can use ${prefix}/bin/port-tclsh.

Rainer

Re: Read environment variables from a file in launchd?

[Rainer Müller]

On 17/07/2023 20.58, Zhenfu Shi wrote:
> I’m looking for a way to import environment variables for a process started 
> by launchd. systemd on Linux has EnvironmentFile key which allows env vars to 
> be read from a file, can launchd do something similar?
> I’m asking this because my cloudflared port has command line options 
> hardcoded into its launchd script which gets overwritten on every upgrade. If 
> I can somehow make those options read in from another file I can make them 
> configuable to the users.

Unfortunately, I do not think this is easily possible with launchd.

The only solution I can think of would be to wrap it with a shell script. Or 
use an external start script that reads the arguments from a file.

ProgramArguments

/bin/sh
-c
source /opt/local/etc/foo/options && exec /opt/local/bin/foo 
$FOO_OPTIONS



Rainer

Re: iTerm2

[Rainer Müller]

On 23/06/2023 02.06, Mark Anderson wrote:
> iTerm2 is getting increasingly hard to support building using macports
> to where I'm not even using the build - I've just been trying to fix it.
> The big issue is that building it on the latest box with the latest
> Xcode works great, but the developer rightly assumes that they can just
> send that binary out to everyone and if you can't build it, well,
> download the binary.
> 
> So I'm wondering what exactly to do. We could download the binary for
> all but the latest Xcodes/Macs or if you force it with a source build
> flag? I think that might be the answer.

The upstream binary includes Sparkle and has a self-updater. This will
either not work when installed by MacPorts (due to permissions on the
.app) or it will work interfere with MacPorts, because it installs a new
version without a port upgrade.

Rainer

Re: Xcode (14.0.1) is too old

[Rainer Müller]

On 01/11/2022 14.02, Chris Jones wrote:
> Xcode 14.1 is indeed the recommended version for macOS13, as its the
> only one containing the macOS13 SDK (AKAIK). However, Apple apparently
> hit a few issues with it last minute and thus has not released a public
> version of it yet, so for now you need to download and install the 14.1
> Xcode RC2 (and CLT if you also have a version of this intalled) from
> developer.apple.com

I added a note about this problem to the wiki page VenturaProblems:

https://trac.macports.org/wiki/VenturaProblems#Xcode14.1

Rainer

Re: revision control downloads

[Rainer Müller]

On 22/03/2022 22.23, Ryan Schmidt wrote:
> On Mar 22, 2022, at 13:08, Daniel J. Luke wrote:
> 
>> On Mar 21, 2022, at 9:20 PM, Ryan Schmidt wrote:
>>> Ports that fetch their sources from a revision control system do not enjoy 
>>> the protection of checksums. Although ports that fetch source from a 
>>> revision control system specify which tag or commit hash to fetch, it is 
>>> conceivable that a developer with sufficient access to that repository 
>>> could delete an old tag and replace it with a new tag of the same name that 
>>> contains different software. This is one of the reasons why we recommend 
>>> ports fetch using distfiles, and the vast majority do. We might consider 
>>> recommending that ports that fetch directly from a git repository 
>>> (fetch.type git) never use a tag, and always use the commit hash 
>>> corresponding to that tag, since replacing the contents of the repository 
>>> while keeping the same sha1 hash is, as far as I know, still impossible in 
>>> the general case. (Yes, it is possible to engineer a sha1 collision, but 
>>> only if you can carefully control both the old and new files. Generating a 
>>> sha1 collision against some existing old file is a very different matter.)
>>
>> I haven't reviewed the current literature but one thing is certain - attacks 
>> only get better. We should strongly discourage any use of revision control 
>> as the source.
> 
> As I said we do already and have for a long time strongly discouraged using 
> revision control systems for downloads.

As these days most web frontends allow to download a tarball, we could
also think about discouraging fetching from VCS completely.

>> We could shorten the window where a person could get sources that don't 
>> match what the maintainer expected with a little infrastructure magic. 
>> Roughly in order of presumed level of effort:
>>
>> - provide a place for maintainers to manually upload distfiles that they can 
>> generate from a source checkout
>> - provide some port command for maintainers to upload distfiles (as a 
>> convenience for the above upload process)
>> - have a process that automatically generates distfiles from the checked out 
>> source and puts it on our mirrors (builder could probably do this since it's 
>> already going to check out the source), then have base look for the distfile 
>> on our mirrors first (even if the portfile specifies to check out from a 
>> revision control system)
> 
> Rainer did some work on automating the creation of distfiles from revision 
> control systems but it has not been touched in some years. Since Rainer 
> hasn't been very active here lately maybe someone else would like to pick it 
> up and finish the work.
> 
> https://github.com/macports/macports-base/tree/vcs-fetch

Right, what Daniel describes in the last point is basically what is
implemented in the vcs-fetch branch. I think the compare view is the
better starting point for the code:

https://github.com/macports/macports-base/compare/vcs-fetch

MacPorts will fetch from a VCS, but creates a reproducible tarball with
bsdtar. This allows to mirror a source tarball for all of fetch.type
git/svn/hg/bzr/cvs if they point to a fixed revision as they should. The
checksum of this tarball is in the Portfile as usual.

The general idea is that the existing mirroring job would create such a
reproducible tarball from the VCS that is distributed normally. On the
user end, fetch looks for a tarball on the mirrors first before
attempting a fetch from VCS.

For fetch.type git it also implements the additional feature to also
download submodules, which has been a requirement that could not be
specified with the fetch.* options [1].

The problem is that this branch has become stale, fully attributed to my
lack of interest and shift in priorities. This feature was started back
in 2016 at the MacPorts Meeting together with Mojca, but according to
the git log I last worked on it in 2018 ...

I am fairly confident the vcs-fetch branch could be rebased onto the
current master. I really don't mind if someone else wants to pick this
up, no, I would rather be glad to see this finished.

Rainer

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

Re: code signing and the future of MacPorts

[Rainer Müller]

Hello,

here is an older concept from 2016 I had written for gdb/lldb as Apple began to 
require code-signing for debuggers. This applies to more actions by now, but 
with the same requirements. The replies are also relevant and discuss 
alternatives.

https://lists.macports.org/pipermail/macports-dev/2016-September/033518.html

I still think adding a local private key to the trust store for code-signing at 
install/activation time is the only option. I do not see that code-signing 
binary archives created on the buildbots would be a feasible approach. This 
would essentially turn MacPorts into a binary-only distribution. Most parts are 
not ready for that and features like rev-upgrade rely on local rebuilds.

Rainer

New project member: judaew

[Rainer Müller]

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

 - Vadim-Valdis Yudaev (judaew@, @judaew)

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

- Joshua, Ryan, and Rainer


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

PackagingCon 2021

[Rainer Müller]

Hello,

on November 9 & 10 this year there will be the first PackagingCon, a
virtual event to bring developers from different projects together. The
organizers are still looking for submissions on packaging related topics
in slots of 20-30 minutes. As it is a virtual event, all presentations
will be streamed. The deadline for submissions is August 31.

Would anyone be interested to submit a presentation related to MacPorts?

https://packaging-con.org/
https://twitter.com/packagingcon

Rainer

Re: New ports.macports.org website

[Rainer Müller]

On July 20, 2021 1:15:50 AM GMT+02:00, Saagar Jha  wrote:
>This looks awesome! We had some discussion earlier of what kinds of
>things we should be posting to social media, and I think major new
>redesigns and efforts at modernization are a great thing to highlight.
>I’d suggest posting this to Twitter, or I could figure out how to do
>that too if you want.

I posted this on Twitter here:
 https://twitter.com/macports/status/1417603005134905350

We could still need a more detailed post on the news section of the website. 
Any volunteers for a draft? Please submit a pull request here:

https://github.com/macports/macports.github.io

Rainer

Re: delete in post-destroot is ineffective, how to make it effective?

[Rainer Müller]

On 12/07/2021 11.49, Jim DeLaHunt wrote:
> I am breaking a single upstream codebase into subports. I want each
> subport to contribute some of the overall complement of files. But the
> "make install" of the codebase installs more files than I want. Thus I
> think the right thing to do is to declare a post-destroot which delete
> the excess files from each subport.

Sounds reasonable, but be aware that subports in MacPorts do not work
like splitting a package with .rpm or .deb. These other systems compile
once and then sort the files into different binary packages.

But with MacPorts, each subport will be built separately. With the same
build command, each subport will take the same time to compile from
source, even if you later only need a few files in destroot. Therefore
it would still be a good idea to only build what you need for each subport.

> My Portfile has an entry like this:
> 
>     post-destroot {
>     set sharedir ${prefix}/share
>         delete ${prefix}/lib/libfreeciv.a
>         delete ${sharedir}/doc ${sharedir}/man ${sharedir}/locale
>     }

At this point, the files are still not installed on the system, but
reside in the staging directory named ${destroot}, which is at
work/destroot/ as you already found out below.

You need to use absolute paths ${destroot}${prefix}/... here. ${prefix}
is always an absolute path, that's why it can be combined without an
explicit separator. For example, it should look like this:

  delete ${destroot}${prefix}/lib/libfreeciv.a

> But, when I run "sudo port destroot freeciv-server", then look at what I
> believe is the destroot:
> 
> ls $(port work freeciv-server)/destroot/opt/local/share
> 
> the directories which I wanted to delete are still present.
> 
> I look in the main.log for this subport. I don't see any diagnostics
> from those delete directives.

This was an attempt to delete files directly from the prefix, which is
/opt/local by default. But trying to delete non-existing files will not
result in an error. Therefore it silently passed doing nothing.

Rainer

Re: Segfaults on FreeBSD

[Rainer Müller]

On 24/06/2021 03.30, Marius Schamschula wrote:
> I’m a gdb noob, particularly as it relates to Tcl scripts.

Of course you could also achieve the same checks by adding some printf
statements to the C source. :-)

> When I load
> 
> gdb /opt/local/libexec/macports/bin/tclsh8.5 ./tclsh8.5.core
> 
> And set my breakpoint
> 
> (gdb) break mktemp.c:99
> 
> And tell gdb to run, I get a tclsh prompt. If I launch
> /opt/local/bin/portindex
> 
> I get
> 
> [Detaching after fork from child process 85805]
> Creating port index in
> /opt/local/var/macports/sources/github.com/macports/macports-ports
> child killed: segmentation violation

By default, gdb will only debug the parent process across a fork. You
can change this with the following commands before running the program:

  set follow-fork-mode child
  set detach-on-fork off

This way gdb will stay attached to all processes that are forked and
also to the parent. You can view them with 'info inferior' and switch
between them with 'inferior '.

Rainer

Re: live check fetch failures

[Rainer Müller]

[resent because the list address in CC was wrong]

On 19/06/2021 17.02, Ken Cunningham wrote:
> I don't subscribe to any of MacPorts' email lists, or any others.
> 
> So any comments come in new. Didn't realize that was troubling anyone,
> but thank for letting me know it is.

If you are not subscribed directly and are reading this from the mail
archive, you can click the email address of the sender at the top to
start a proper reply with your mail client.

For example, this is the first mail in this thread in the archive. You
will get a mailto: link with the proper In-Reply-To header that will
keep your reply in the thread for others.

https://lists.macports.org/pipermail/macports-dev/2021-June/043592.html

HTH,
Rainer

Re: Segfaults on FreeBSD

[Rainer Müller]

On 19/06/2021 17.58, atmail.dreamhost.com wrote:
> Every now and then I try to get MacPorts to build and run on FreeBSD.
> 
> Getting it to build requires less than a handful of edits.
> 
> However, when running portindex I get a Segfault with a Signal 11.
> 
> Here’s what gdb says (after recompiling with debug symbols enabled)"

> [...]

So it is failing at this point inside the Tcl_NewStringObj():
https://github.com/macports/macports-base/blob/v2.7.1/src/pextlib1.0/mktemp.c#L99

gdb already tells us that the pointer 0xa51b60 doesn't look good. But
mktemp() is never supposed to return anything else than either the
pointer given or NULL [1].

Could you try to break in gdb here in line 99 (after the call to mktemp)
and compare the variables sp and template? They must point to the same
memory address.

You could even check whether there is a proper C string terminated by
'\0' in memory... but actually gdb already told us it is not, because it
cannot access memory at this address. :-/

Rainer

[1] https://www.freebsd.org/cgi/man.cgi?mktemp(3)

Re: Old Macports Site

[Rainer Müller]

Please use Reply All to keep the discussion on the mailing list.

On 06/06/2021 19.59, Jonathan Moore wrote:
> where are the guides and category lists
> 
> I can't find anything with the new search
> 
> 
> Thank You,
> 
> 
> Jonathan Moore

Sorry, I still do not understand. Which search do you mean?
Can you give us the URL of this page?

Rainer

Re: Old Macports Site

[Rainer Müller]

On 06/06/2021 02.38, Jonathan Moore via macports-dev wrote:
> Would you please put the old MacPorts Site up with all of the detail so
> people can continue reading the mac internals.

Which site do you refer to? As far as I am aware, we did not remove
anything.

Rainer

Re: MacPorts Base: Support for a lower level of debug output, like ui_trace, or ui_debug2/ui_debug3?

[Rainer Müller]

On 24/05/2021 17.13, Christopher Nielsen wrote:
> Has there been any thoughts/interest in implementing another level (or two) 
> of debug output, providing more detail than we get at Debug? That would allow 
> us to optionally output more diagnostic info in various areas, such as our 
> portgroups, without flooding the logs when running at our present Debug level.
> 
> I’ve found this extremely helpful in the various projects I’ve worked on over 
> the years. And it would certainly benefit us too.
> 
> In many of the common logging frameworks, such a level is sometimes called 
> Trace. That terminology might be confusing within MacPorts, given that we 
> support trace mode. So perhaps we would want to name it differently. (Debug2 
> and Debug3?)
> 
> But naming aside, has anyone else considered the general idea? Thoughts?

I would see it from another perspective. Why skip verbose mode and go
straight to debug mode? If more information is regularly required,
shouldn't we instead move more log messages to verbose mode instead of
hiding them in the debug log only?

Rainer

Re: MacPorts 2.7.1 - Availability for GitHub CI Jobs, as well as Buildbots?

[Rainer Müller]

On 27/05/2021 20.10, Ryan Schmidt wrote:
> On May 27, 2021, at 02:34, Joshua Root wrote:
> 
>> On 2021-5-27 08:52 , Christopher Nielsen wrote:
>>> While I realize MacPorts 2.7.1 was just released, is there an ETA on when 
>>> it will be available for both CI, as well as our buildbots?
>>> There’s certainly no rush. But the bug fix for issue 56793 (slow installs 
>>> of ports with tens of thousands of files) would be hugely beneficial 
>>> across-the-board.
>>> Also, it looks like the GitHub CI jobs may still be utilizing 2.6.4…?
>>
>> Buildbots selfupdate once a day. For CI, someone needs to automate up a 
>> replacement for Bintray.
> 
> Oh right. In the absence of automation, I'm happy to replace the files 
> manually, but I don't know how to generate them.

The tarball was built with this workflow from the travis-ci branch,
which also deployed it to bintray. This automation needs a replacement.

https://github.com/macports/macports-base/blob/travis-ci/.github/azure-workflows/main.yml

It was originally running on Travis CI, hence the name of the branch,
but this was actually running on Azure.

Rainer

Re: Freenode IRC

[Rainer Müller]

On 26/05/2021 11.19, Joshua Root wrote:
> On 2021-5-26 14:39 , Thomas R. Murphy wrote:
>> As continued malicious behavior continues on the current network for
>> #macports, I'm quite interested in seeing a move for the project.

I agree, it is about time now.

> The channel is all set up on Libera, we just need to move the rest of
> the bots over.
I moved the mplog bot to Libera.Chat. It is now announcing commits in
#macports and #macports-commits, as it did previously.

I also updated the wiki page and added that to the IRC channel topic:
https://trac.macports.org/wiki/Chat

Website still needs to be updated via the macports-www repository.

Rainer

Re: bash and bashdb ports

[Rainer Müller]

On 21/05/2021 14.48, Giuseppe 'ferdy' Miceli wrote:
> could someone be so kind to enlighten me about the bash port?
> 
> if i am not mistaken the bash50 sub-port is obsolete and could be removed.
> 
> i stumbled on it while installing bashdb which depends on bash50 which 
> conflicts with bash.
> 
> i worked around changing in my local repository the dependency from bash50 to 
> bash and was about to PR the modified bash and bashdb ports, but frankly 
> speaking i do not know if that would be the right think to do.
> 
> thank you very much in advance,

bashdb is not compatible with bash >= 5.0 and fails to build. This is
the only reason the bash50 subport still exists.

The situation has often been like this in the past and it took some time
until bashdb caught up to the latest bash release.

Rainer

Re: Freenode IRC

[Rainer Müller]

On 19/05/2021 20.25, Andrew Janke wrote:
> Have you considered using ZNC or another IRC "bouncer"? It'll retain and
> replay history for you so you can get offline messages and have a
> consistent message history between computers and devices. Pretty easy to
> install if you have a Linux server somewhere, and hardly uses any resources.

I am also using ZNC myself. It definitely makes the experience with IRC
better, but the effort is shifted to the individual user. Even having
access to a server to self-host a bouncer is not common.

With RocketChat as an example, everyone gets these features out of the
box without taking additional action.

Rainer

Re: Freenode IRC

[Rainer Müller]

On 19/05/2021 15.43, Marius Schamschula wrote:
> It has come to my attention, on Twitter, that freenode.net
> , were MacPorts hosts it’s IRC channels, is having
> some serious issues [1]. The admins have resigned and control may now be
> in questionable hands.

Right, we need to take action and move away from Freenode. This also
opens a few opportunities for us on how to go forward.


a) Move #macports to Libera.Chat
While there are also other IRC networks, the new Libera.Chat appears to
become the direct successor of Freenode. Many projects are moving right now.

b) Declare RocketChat as official chat
We already have a RocketChat instance at chat.macports.org, which has
been running for a while in parallel and we already gathered a few
users. [1]

c) Evaluate further options
IRC is old, lacks modern features. Self-hosted RocketChat requires
regular maintenance. Matrix could be another federated alternative.


Rainer

[1] The RocketChat #general channel is supposed to be bridged to the IRC
channel, but this is broken at the moment.
See https://trac.macports.org/ticket/62908

Re: Publicizing MacPorts

[Rainer Müller]

On 20/04/2021 12.40, Steven Smith wrote:

That’s begging the question of an effective communications strategy. A 
distributed model of random volunteers is perfect for aggregating git commits. 
It’s highly ineffective at communicating important news from that organization.

If MacPorts wants to communicate better, it must post important announcements 
like “MacPorts supports the new Apple silicon M1” at a MacPorts website, and 
someone with a macports.org address must send emails to a few tech reporters 
that say “look at this please.”


If you pledge to handle this kind of marketing, I would have no problem to hand 
out an @macports.org address for that. By the way, having our own mail domain is 
not that common for open source projects. Most projects hosted on services such 
as GitHub/GitLab/etc. will never have that. I really do not think it is of that 
much significance.



We would be grateful if more users/contributors could join the boat
and actively help in areas where they feel that they could contribute
to the project (in one way or another).


That’s precisely why a more effective and realistic commutations strategy is 
desirable.


I don't disagree. But it needs at least one person invested enough to start it 
and then some more to follow-through with it.



If someone is willing to step up and write blog posts, articles
(potentially based on a few rounds of questions/answers/document
revisions), etc., that would certainly be more than welcome.


I’d wager that many people would write these, but the channel and 
infrastructure for this do not now exist: no MacPorts News/Announcements page, 
no blog page, a somnambulant Twitter feed, https://twitter.com/macports, and no 
peer review control mechanism. This can be accomplished by providing such tools 
to divide-and-conquer, with an open peer review mechanism for contributors 
without commit authority.


We have the news section on the website [1]. Posts can be submitted with pull 
requests to the corresponding repository [2]. At the moment, it is only in use 
for release announcements that are also posted on macports-announce [3]. I don't 
think anyone would object against posting more.


I know the Twitter account is not as active as it could be. I personally do not 
find the time to post there regularly. I can grant you access to the account 
through TweetDeck if you want to make it more active. There is a list of people 
with access on the SocialMedia wiki page [4]. Currently the only rule is that 
tweets should have a signature by their author.


As you can see, some infrastructure exists. It needs community members to step 
up and provide content to fill these channels.


Rainer

[1] https://www.macports.org/news/
[2] https://github.com/macports/macports.github.io
[3] https://lists.macports.org/pipermail/macports-announce/
[4] https://trac.macports.org/wiki/SocialMedia

Re: Publicizing MacPorts

[Rainer Müller]

On 19/04/2021 15.14, Steven Smith wrote:

If you have contacts to tech reporters, please use them. I don't have any. If 
Ars Technica or any other news site wants to cover MacPorts, they can do that 
any time.


This is the wrong attitude.

MacPorts must tell them, not some random user/contributer like me.


In my opinion, users have to spread the word to make MacPorts more popular.


And the press likely won’t think an issue is important or interesting enough to 
cover if the related organization doesn’t think it’s interesting enough to post 
an announcement about it.


They are much more likely to post an article if they know users will be 
interested in it.


So, if MacPorts were to make an announcement now, what would you put in there? 
Can you show us a draft? "MacPorts works like it always has" is barely newsworthy.


Rainer

Re: Publicizing MacPorts

[Rainer Müller]

On 19/04/2021 12.45, Steven Smith wrote:

"Champion" how?

"MacPorts should be making [the case]" how?


The same way everyone else does: make noise, push news, promote, let the tech 
reporters know. Follow the Woody Allen rule for success.


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/ 



If you have contacts to tech reporters, please use them. I don't have any. If 
Ars Technica or any other news site wants to cover MacPorts, they can do that 
any time.


Maybe we could sent out news to macports-announce about support of new macOS 
releases as well as the arm64 architecture. But at which point would you do it? 
There are continuously updated ports with support or fixes for arm64. The 
announcement for 2.6.4 in November [1] briefly mentioned the support for arm64. 
But I don't know what more to say, because... it just works? ;-)


MacPorts 2.0 that introduced binary archives also got news coverage, which was 
mostly because we increased the major version number. Homebrew did the same 
thing now, because they had to make changes to support an additional 
architecture, thus they got the news coverage. MacPorts did not need that many 
changes to support arm64, because it had the general support for multiple 
architectures already.


Rainer

[1] 
https://lists.macports.org/pipermail/macports-announce/2020-November/57.html

Re: port status process question

[Rainer Müller]

On 17/04/2021 14.59, tsteven4 wrote:
What is the reason that the recent builds of gpsbabel_app from gpsbabel: update 
to 1.7.0 · macports/macports-ports@2c4528c · GitHub 
 
don't show up on Install gpsbabel-app on macOS | MacPorts 
?  For example, Buildbot: 
ports-11_x86_64-watcher Build #4375 (macports.org) 



At this point we simply don't know the reason. Apparently only port information 
for macOS 10.15 is being updated. The issue is being tracked here:


https://github.com/macports/macports-webapp/issues/273

Rainer

Re: map download link to distname

[Rainer Müller]

On 07/04/2021 08.04, Ryan Schmidt wrote:
> On Apr 6, 2021, at 10:44, Rainer Müller wrote:
> 
>> On 06/04/2021 01.39, Ryan Schmidt wrote:
>>> Regarding the specific download link you mentioned, 
>>> https://gitlab.com/graphviz/graphviz/-/package_files/8183714/download, I 
>>> see that link on the graphviz web site at 
>>> http://www.graphviz.org/download/source/ but I don't know where they got 
>>> it. I can't find that link within their gitlab site. I don't know whether 
>>> that is what in github parlance would be called a release download or 
>>> whether it is yet another different type of download which is specific to 
>>> gitlab for which there is not an equivalent within github.
>>
>> This is also the first time I have seen this. Apparently graphviz publishes 
>> this
>> as a "package" on GitLab, which contains artifacts archived after CI pipeline
>> runs. You can locate the resulting files via the "Package Registry" section 
>> in
>> the menu.
>>
>> https://gitlab.com/graphviz/graphviz/-/packages/1365772
> 
> Yes, I found "Package Registry" in the GitLab menu, but all I found there was 
> tons of development version artifacts. I could not see a way to show stable 
> version artifacts.

You are right, the list is long, I should have mentioned more details.

I discovered that a descending sort order by version causes 2.46.1 and 2.47.0 to
show up on top. The development builds all use a lower 0.0. version 
number.

This way graphviz publishes their tarballs seems rather unique. I have a
suspicion that this is not actually the way this GitLab functionality is meant
to be used. I would not add functionality for this special case to the gitlab
port group unless we discover more projects that use it like this.

Rainer

Re: map download link to distname

[Rainer Müller]

On 06/04/2021 16.38, Jonathan Stickel wrote:
> On 4/5/21 17:39, Ryan Schmidt wrote:
>> master_siteshttps://gitlab.com/graphviz/graphviz/-/package_files/${package_id}/download?dummy=
>>
> 
> Thank you, this is the piece that I was missing. I was not familiar with URL
> query strings. Maybe this is something useful to include in
> 
> https://trac.macports.org/wiki/CommittersTipsAndTricks
> 
> ? I can add something to the page and submit for review.

It is explained on the PortfileRecipes page that Ryan already linked earlier:

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

One problem is that this page is not visible enough. The documents for new
project members should have a link to that. I could not find any reference from
the guide either...

Rainer

Re: map download link to distname

[Rainer Müller]

On 06/04/2021 01.39, Ryan Schmidt wrote:
> Regarding the specific download link you mentioned, 
> https://gitlab.com/graphviz/graphviz/-/package_files/8183714/download, I see 
> that link on the graphviz web site at 
> http://www.graphviz.org/download/source/ but I don't know where they got it. 
> I can't find that link within their gitlab site. I don't know whether that is 
> what in github parlance would be called a release download or whether it is 
> yet another different type of download which is specific to gitlab for which 
> there is not an equivalent within github.

This is also the first time I have seen this. Apparently graphviz publishes this
as a "package" on GitLab, which contains artifacts archived after CI pipeline
runs. You can locate the resulting files via the "Package Registry" section in
the menu.

https://gitlab.com/graphviz/graphviz/-/packages/1365772

Rainer

New project member: harens

[Rainer Müller]

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

 - Haren Samarasinghe (harens@, @harens)

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

- Joshua, Ryan, and Rainer


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

Re: Looking to resolve Qemu on AppleSilicon build failure

[Rainer Müller]

On 18/02/2021 05.23, Joshua Root wrote:
> On 2021-2-18 08:33 , Blake Garner wrote:
>> I have been unsuccessfully trying to figure out how to resolve this issue 
>> with
>> qemu builds on AppleSilicon hardware.
>>
>> https://trac.macports.org/ticket/62116 
>> 
>>
>> My suspicion is that the build is not using the correct architecture when
>> setting up the include directories for part of the build. This is based on
>> some of the build log output. As noted in the ticket I was able to build qemu
>> on the same system outside of MacPorts so again that points me to some of the
>> configurations in the port.
>>
>> Any suggestions on what to look for here? Seems like I should be able to
>> compare the output of the configure scripts to isolate differences between 
>> the
>> working and not working builds?
> 
> Are you building with the same configure args as the port? The --cpu= option 
> is
> the first obvious thing I see that might be relevant. Maybe qemu needs to 
> update
> its config.guess and config.sub, or maybe it just wants you to say "aarch64"
> instead of "arm64".

That's it exactly, QEMU's build system expects this to be --cpu=aarch64.

There is already an open work-in-progress pull request that addresses this,
among other related issues for the Apple M1. It wasn't linked at the Trac ticket
yet, but I added that just now.

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

Rainer

Mails rejected today due to SpamCop blocklist

[Rainer Müller]

Hello,

there was a problem with our mail server today. Any mail handled today may have
been rejected in error due to a problem at the SpamCop blocklist. Their domain
name expired, which had the effect that all sending IPs were blocked.

For mailing list posts sent today, please look for any bounce message or double
check with the mailing list archive that it has been received. Direct replies in
threads going to other mail servers succeeded, which is why some replies of
today might have missing context.

Also be aware that you might have missed notifications from GitHub if they go to
your @macports.org address.

Sorry for the inconvenience. We temporarily disabled this blocklist, so as of
now no problems should occur. Please contact us on IRC or RocketChat [1] if you
still have problems.

Rainer

[1] https://trac.macports.org/wiki/Chat

Re: Desolate Condition

[Rainer Müller]

On 26/01/2021 16.12, Christopher Nielsen wrote:
> One advantage that HomeBrew does have, though, is cachet: There are so many
> times when articles - or even organizations, such as Google - simply recommend
> using HomeBrew… with no mention of MacPorts.
> 
> So, my feeling is that we need to up our public relations game. Do we have an
> active social media presence, for example? (Twitter in particular?)>
> Of note, while I’m not an expert in social media relations, I’d happily
> volunteer to help with it.

Yes, we do have a Twitter account [1], but we are not using it much. Mostly we
announce new releases and maintenance stuff there.

I added a new SocialMedia wiki page [2] to document the existence of such social
media presence. This also has the list of users that already have access and the
signatures they use for tweets.

Help with this would be very welcome! I can give out access to more users via
TweetDeck [3], if you tell me your Twitter handle.

Rainer

[1] https://twitter.com/macports
[2] https://trac.macports.org/wiki/SocialMedia
[3] https://tweetdeck.twitter.com

Re: ACTION REQUIRED: Set your SMTP password

[Rainer Müller]

On 18/11/2020 19.14, Mojca Miklavec wrote:
> I sent my previous email using the new SMTP settings from GMail, but I
> didn't see any reply, so I went to check the mailing list archives to
> see whether my email went through, to start with.
> 
> Given that the email reached the mailing list, apparently the settings
> worked, however your reply to me was *the only message* in the whole
> thread that ended up in my spam box. I would understand it if GMail
> tried to block you entirely (for whatever reason), but I don't get it
> why just the reply to me directly deserved the special treatment.
> 
> While checking the rest of the spam (which I forgot to do for quite a
> while) I discovered another reply from Ryan where I was CC-ed, and a
> bunch of trac tickets (all of which CC-ed me), most of them from
> today, and a couple from the past few days.
> 
> I kept clicking "Not spam", and I can imagine that it takes a while
> for their algorithms to retrain, but in any case newer emails from
> Trac kept being classified as spam.
> I have a feeling as if GMail was trying to sabotage the incoming email
> alias after I changed the SMTP settings for the outgoing mail.
> 
> I'll keep an eye on the spam box in the next few weeks.

I just made another little adjustment to the postfix configuration to anonymize
the origin IP of the sender. This might help with the spam problem, because some
spam checks actually use that information and give bad scores if mails originate
from dial-up IPs. Additionally, it offers more privacy for team members as their
IP address used for submission will not be exposed.

Rainer

Re: Scheduled downtime on Jun 11, 8 UTC

[Rainer Müller]

On 08/06/2020 20.03, Rainer Müller wrote:
> it has been a while since we did a full operating system upgrade on our server
> braeburn.macports.org, which provides most of our self-hosted services. We are
> taking the opportunity to do so this Thursday. As the duration is hard to
> predict, the end date is a conservative estimation.
> 
> Start: 2020-06-11 08:00:00 UTC
> End:   2020-06-11 16:00:00 UTC (expected)
> 
> You can convert the event to your local timezone here:
> https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200611T08
> 
> This will affect the website and guide at macports.org, Trac, the mailing 
> lists,
> mail forwards and the PR bot automation including log file storage from 
> Travis.
> 
> GitHub can be used as usual, but any WebHook sent from GitHub to Trac during 
> the
> downtime will fail and will have to be re-triggered manually once the system 
> is
> online again. 'port selfupdate' and port updates in general will not be 
> affected
> and will work as usual.

The maintenance is now finished. Website and guide were actually available the
whole time via the CDN. As you can read this, mailing lists and mail forwards
are also back again.

Trac is now deployed with a new threading workers approach based on gunicorn
that should hopefully improve performance and reduce memory usage. Please report
back if you get any errors or timeouts.

Rainer

Scheduled downtime on Jun 11, 8 UTC

[Rainer Müller]

Hello,

it has been a while since we did a full operating system upgrade on our server
braeburn.macports.org, which provides most of our self-hosted services. We are
taking the opportunity to do so this Thursday. As the duration is hard to
predict, the end date is a conservative estimation.

Start: 2020-06-11 08:00:00 UTC
End:   2020-06-11 16:00:00 UTC (expected)

You can convert the event to your local timezone here:
https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200611T08

This will affect the website and guide at macports.org, Trac, the mailing lists,
mail forwards and the PR bot automation including log file storage from Travis.

GitHub can be used as usual, but any WebHook sent from GitHub to Trac during the
downtime will fail and will have to be re-triggered manually once the system is
online again. 'port selfupdate' and port updates in general will not be affected
and will work as usual.

As the mailing lists and mail forwards are going to be down, you can still reach
us on IRC in #macports on Freenode or via RocketChat at chat.macports.org during
the downtime.

Rainer

Re: make xorg-server a dependency of x11 ports?

[Rainer Müller]

On 20/05/2020 15.30, Ken Cunningham wrote:
> Should xorg-server should be made a dependency of some key x11 component, so
> that when people install an x11 application, xorg-server installs and it
> actually works for them “out-of-the-box”.

I doubt even with the dependency it will not work "out of the box" as expected,
because installing xorg-server requires a logout/login cycle to get the updated
launchd environment as documented in the port notes of xinit. Hiding the
installation of the X server may cause people to also overlook this essential 
step.

Rainer

Re: Github macportsbot not running

[Rainer Müller]

On 29/04/2020 04.07, Chris Jones wrote:
> Looks like the macportsbot has stopped running again , as The latest MRs are 
> no longer being labelled. Could someone kick it back into life ;)

Thank you for the notification! I started it now. prbot had failed to start
after a reboot of the host system:

prbot-current[1453]: 2020/04/28 09:02:54 pq: the database system is starting up

This happened before, but I don't know how we can make this more robust. We
already use After=postgresql.service in the corresponding systemd unit, but
apparently that is not enough. Either there is some other indicator when
postgres has finished its startup, or prbot should retry if it encounters this
error message, or as a last resort we have to add some arbitrary delay.

Rainer

Re: A currently unstable CI?

[Rainer Müller]

On 03/04/2020 11.20, Ryan Schmidt wrote:
> True, but 10.15 is missing because we have failed to produce a 10.15 version 
> of MacPorts base for it to use. Short term, we should do that. Long term, we 
> should fix it so that the CI systems can use the standard version of MacPorts 
> base and don't need custom versions.

The problem is that we cannot build base for 10.15 as it is unsupported by
Travis. I think the only choice would be to move this to Azure as well.

https://github.com/macports/macports-ports/pull/6389#issuecomment-586781197

Even better would be if we could host the binary base tarball as an artifact on
Azure itself instead of relying on bintray as yet another service.

Rainer

Re: Port mechanism explanation needed

[Rainer Müller]

On 24/03/2020 17.33, 陈国凯 wrote:
> I found no maintainers for port stlink and I wanted to take it if possible.
> However, I am quite confused with the portfile mechanism of this port.
> 
> After reading the wiki, I know that this portfile specifies a Github Repo 
> from which the port system obtains source code. While there are two problems 
> left for me.
> 
> 1. I tried editing portfile locally, changing the version number but port 
> would only try fetching the source code from mirrors of MacPorts, rather than 
> fetching directly from Github upstream. Is there a way for me to test my 
> modifications locally? And how does the mirroring mechanism work? If one 
> changed the portfile configuration and merged changes into port tree, would 
> the mirrors be synced automatically?

You can skip the MacPorts mirrors with this flag, which is especially useful for
development as at that stage distfiles will never be available on any of our
mirrors yet:
  $ sudo port fetch --no-mirrors stlink

Any push to master triggers a build for binary packages of changed Portfiles,
which will also download all referenced distfiles. These will afterwards be
fetched by other mirrors from the master mirror.

> 2. I cannot figure out to whom the checksums belongs. I downloaded all 1.6.0 
> source code from Github release page while none of them matches the checksum 
> specified in the portfile. How can I obtain the file with the expected 
> checksum from Github (not from mirrors because I intend to make an upgrade 
> afterwhile so that I should find a way to configure checksum)

In general, to get a better understanding, what is happening, run the command in
verbose (port -v) or even debug (port -d) mode.

You can also get a list of all files and their mirror URLs with the port action
'port distfiles'.

HTH,
Rainer

Re: Migrating the guide to AsciiDoc

[Rainer Müller]

On 21.02.20 21:05, Rainer Müller wrote:
> On 17.02.20 23:13, Mojca Miklavec wrote:
>> I didn't yet check how the latest conversion looks like, so I cannot
>> really make a good informed decision, but I would vote for proceeding
>> with .adoc.
> 
> For comparison, I just put the AsciiDoc based guide online here:
> https://guide-test.macports.org/

Because of a misconfiguration in the CDN, the official guide was pulled
from this test version over the weekend. Sorry for that, I did not
expect the CDN would use this domain.

However, there was only one report on IRC because of this and that was
only because the chunked version was missing and some links were broken.
That must mean the quality is already good enough. ;-)

Anyway, I just updated the guide-test domain once again to also include
the chunked version of the guide.

> [...]
> The known steps that will need manual work are documented here. Please
> feel free to add anything else you find in the current guide-test to
> this list. Or just sent a reply with feedback.
> 
> https://github.com/macports/macports-guide/blob/master/guide/adoc/README.md

Rainer

Re: Migrating the guide to AsciiDoc

[Rainer Müller]

On 17.02.20 23:13, Mojca Miklavec wrote:
> I didn't yet check how the latest conversion looks like, so I cannot
> really make a good informed decision, but I would vote for proceeding
> with .adoc.

For comparison, I just put the AsciiDoc based guide online here:
https://guide-test.macports.org/

> 1.) Could we (at the time when the final migration is done) put the
> old fully functional generated manual somewhere for reference, so that
> we know what to strive for even after we change the underlying
> scripts?
> 
> 2.) Do we already have a process/job in place to generate the docs from .adoc?

@Ryan
Could you please install the asciidoctor port on the 'jobs-guide'
builder? I think this should be the only new dependency.

Other than that, we only need to add the 'make guide-fromadoc' target to
the build job (or rather, redefine 'make all' accordingly in the Makefile).

> I believe that we could crowd-source cleaning the docs at least to
> some extent provided that the basics are taken care of. If doing sane
> fixes to docbookrx is not feasible in the very near future, it would
> help if we could simply freeze the docbook sources (I don't care if
> that time is simply now), freeze the manual, generate a new manual
> from the .adoc sources in that branch and publish it at a different
> temporary URL, so that developers can see the results and maybe even
> contribute fixes / PRs without having to get the courage to run the
> conversion process themselves. Once the result is somewhat
> satisfactory or the decided deadline passes (whichever comes first),
> (clean and) merge the branch to master and publish the new manual at
> the old URL (and maybe the old one at a different one for comparison
> for a limited time period).

Some of changes I made to docbookrx are specific to the MacPorts Guide,
for example to deal with the XML include structure. I do not think it is
worth to try to find a generic solution for that.

The known steps that will need manual work are documented here. Please
feel free to add anything else you find in the current guide-test to
this list. Or just sent a reply with feedback.

https://github.com/macports/macports-guide/blob/master/guide/adoc/README.md

Rainer

Re: Gitlab

[Rainer Müller]

On 16.02.20 17:02, Mark Brethen wrote:
> How would you set up a portfile to fetch from gitlab?
> Example: https://gitlab.com/DavidGriffith/frotz

If you navigate to the release, you will find the associated assets. If
the project does not provide a release tarball there, you can use an
auto-generated source tarball based on the git tag.

As an example for frotz, the relevant options for the fetch phase would
look like this:

namefrotz
version 2.51

homepagehttps://gitlab.com/DavidGriffith/frotz
master_siteshttps://gitlab.com/DavidGriffith/frotz/-/archive/${version}/
use_bzip2   yes


HTH,
Rainer

Re: Migrating the guide to AsciiDoc

[Rainer Müller]

On 25.04.18 04:35, Rainer Müller wrote:
> On 2018-04-22 09:29, Mojca Miklavec wrote:
>> As requested during yesterday's meeting, here's the result of
>> automatic conversion of our guide from xml (docbook) to asciidoc:
>>
>> https://github.com/macports/macports-guide/tree/master/guide/adoc
>>
>> This was initially explored by Aljaž and gives quite nice results
>> out-of-the-box, but there are still some issues with conversion that
>> will have to be addressed either by fixing docbookrx itself or
>> manually.
> 
> I fixed some of the issues by slightly modifying the XML. None of these
> should change the output produced by DocBook, but help docbookrx to
> understand the XML.
> 
> I started to document the issues with the conversion in the README. This
> is not exhaustive, please add more things to this list if you spot them.
> 
> https://github.com/macports/macports-guide/blob/master/guide/adoc/README.md
> 
> On one hand, some issues can only be fixed manually once we are sure we
> are not going to run docbookrx again. On the other hand, I noticed that
> it would be easier to fix other issues in docbookrx instead of
> post-processing the *.adoc files.
> 
> However, some of the issues require tweaks to docbookrx that are
> specific to the MacPorts guide, as they depend on assumptions how
> certain elements are used.
> 
> I pushed some commits with such changes that are specific to the
> MacPorts guide to my fork of docbookrx on the macports-guide branch:
> 
> https://github.com/raimue/docbookrx/tree/macports-guide

I fixed another problem with literals as `startupitem.*` was not
interpreted as expected by AsciiDoctor and has to be written as
`+startupitem.*+`:
https://github.com/asciidoctor/asciidoctor/issues/1045

This style is now applied to all string literals by my patched
docbookrx. The alternative would be to use only backticks in the
conversion and fix broken occurrences by hand afterwards. I opted for
the safe variant, although the syntax is not as lean as it could be.


It has been almost two years... I would like to suggest we finally
decide on a flag day on which I will do a final conversion of the
DocBook to AsciiDoc and after that only the AsciiDoc version is kept in
the repository. All remaining issues can then be worked on in the
AsciiDoc files.

Please test out the conversion from AsciiDoc to HTML and compare the
result with the previous DocBook version:
make guide-fromadoc && open guide/html/adoc/index.html

The README.md file documents known issues and things that will need
manual work after the final conversion. Feel free to add anything else
you can spot:
https://github.com/macports/macports-guide/blob/master/guide/adoc/README.md

If we are still not ready to make the switch, I would like to give up
this experiment and delete all *.adoc files from the repository as the
current state seems to be rather confusing for contributors.

Rainer

New project member: ra1nb0w

[Rainer Müller]

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

 - Davide Gerhard (ra1nb0w@, @ra1nb0w)

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

- Joshua, Ryan, and Rainer


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

Re: right way to add a library to src/

[Rainer Müller]

On 16/01/2020 13.20, Mihir Luthra wrote:
> I was trying to add some code to a new directory in macports-base/src/ dir 
> such
> that I can use it in both porttrace.tcl(as a tcl cmd) and darwintrace.c.
> 
> Basically it is a library that needs to be dynamically generated(because it 
> uses
> `__attribute__((constructor))`)
> 
> I see 2 choices:
> 
> 1) To generate .o files in the new directory and use those in 
> darwintracelib1.0
> and pextlib1.0. As both darwintrace and pextlib are ultimately dynamic
> libraries, it should work I suppose.
> 
> 2) To create a separate dylib file which I am not sure how to handle linking 
> to
> both darwintrace code and pextlib. Like what are the standard lib storage
> locations for macports src? Should I simply add it to tcl package path and 
> link
> it in Makefiles of both darwintracelib and pextlib? 
> 
> What would be the right way to do this? Also, is there any reference on how to
> conform to macports Makefile structure?

Without taking a closer look, I think there is only one other file that is
shared between darwintrace and pextlib. Unfortunately, there is no good solution
to this in the current structure. What it currently does is to copy the *.c file
around during compilation, but I think this is a really horrible workaround.

I think the better option would be to have a new subdirectory for a library with
the shared code that is then linked (statically) into both darwintrace and 
pextlib.

Rainer

Re: invalid certificate chain during port-fetch

[Rainer Müller]

On 29.12.19 10:50, René J.V. Bertin wrote:
> On Saturday December 28 2019 21:51:07 Ryan Schmidt wrote:
> 
>> If I understood the patch correctly, it adds a fallback so that if fetching 
>> via the curl library fails, then it tries fetching via the curl command line 
>> program. To my knowledge MacPorts has never had code for using the curl 
>> command line program, only the curl library.
> 
> It does, and if it didn't then I guess this snippet must have been proposed 
> during a discussion on a mailing list, or maybe it had already been 
> contributed.
> 
> Either way, the idea makes sense even if the implementation leaves to be 
> desired, no?

I see no reason for such a fallback. We use libcurl, why should we
duplicate the code to additionally support curl?

The real problem here is that your operating system is out of date and
cannot communicate with servers that require modern crypto. Going
forward, this will affect many more applications and not only MacPorts.

See also:
https://trac.macports.org/ticket/51516

Rainer

Re: Developer mode

[Rainer Müller]

On 20/11/2019 01.21, Ralph Seichter wrote:
> * 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?

Unfortunately we do not have any plugin in Trac to assign maintainers
automatically. There was a previous attempt at getting this into Trac a few
years ago, but it got not deployed due to constraints at macOS forge, which we
used for hosting back then.

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

I am not sure if that code is still compatible with the more recent Trac
version... It would probably also need to be adapted to the PortIndex SQL schema
(or whatever the webapp is now using?).

>> 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.

Yes, 'port bump' is supposed to edit the Portfile with the new checksums.

>> 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.

Sounds very useful to have such a tool. But as always, this can just be written
and does not necessarily have to be part of port(1). The same thing happened in
Gentoo, many tools were just written independently. I am just mentioning this to
encourage contributions for such quality-of-life scripts that do not rely on
becoming more familiar with macports-base first.

Rainer

Re: Outage of braeburn.macports.org

[Rainer Müller]

Hello,

something similar as in August happened today and I issued another reset of the 
machine. 

I already started prbot manually, as it tried once again to start before 
postgres was running. I am only on my phone, so I could not fix it properly 
right away.

Please check if any other service is missing.

Rainer

Re: Github CI/CD

[Rainer Müller]

On 17/08/2019 21.33, Mark Anderson wrote:
> So I got let into the beta and I messed around a bit.
> 
> https://github.com/markemer/macports-cicd-test/commit/3afe383d66fc1c073bf33af821fc6701e4b9acc0/checks
> 
> I was able to get macports-base to build. In 2 min. I'm going to give regular
> Macports a try as well. We probably don't want to build base every time, but I
> was just trying to get things to work.

Nice! Thanks for checking it out. This looks quite promising already.
> Also, I'm going to ask if we can get a container without Brew / and also try 
> to
> uninstall it.

We also have to uninstall Homebrew on Travis on every single run when testing
PRs for macports-ports. That is already part of the _ci/bootstrap.sh script
which could be reused. Although the YAML actions look more fancy.

These are the comlete steps we need on Travis, but I think nothing should be
specific to Travis here and it could just work in the same way.

https://github.com/macports/macports-ports/blob/master/.travis.yml

The only restricted action executed by the CI runner would be the log file
uploading, which is necessary on Travis due to a 4 MiB limit on the log output.
Is there a similar limit on GitHub CI? I am not aware we hit any limits on Azure
so far...?

Rainer

Outage of braeburn.macports.org

[Rainer Müller]

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.

Rainer

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

[Rainer Müller]

On 2019-08-09 11:23, Ruben Di Battista wrote:

What are the longest ports to build?

In my experience paraview and mame, also probably the compilers. And
they should fit the 360 minutes, right?


I do not think any single port build will take that long. However, we 
first need to install all dependencies before we can actually test the 
submitted port. In case there are no binary packages for the 
dependencies, these also have to be compiled from scratch first and that 
might take a long time.


Rainer

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

[Rainer Müller]

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.

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

Re: Request for enabling some web hooks for the new buildbot test setup

[Rainer Müller]

On 02/07/2019 09.41, Mojca Miklavec wrote:
> Would it be acceptable to enable some web hooks in the base & ports
> repository for testing?
> 
> On Tue, 2 Jul 2019 at 08:41, Rajdeep Bharati wrote:
>> On Tue, Jul 2, 2019 at 11:21 AM Rajdeep Bharati wrote:
>>>
>>> Hi,
>>> I had a query: are webhooks enabled in the MacPorts repos?
>>
>> I guess it's not.
>> Would it be possible to add webhooks in the base and ports repositories:
>> payload url: http://34.67.147.76/change_hook/github
>> send push and pull request events
>>
>> Thanks, Regards
>> Rajdeep

I was not able to reach anything at this IP, but it seems to be assigned to
Google, so I assume this is meant to be hosted in Google cloud?

Even if just for testing, I think we should assign a DNS name so we can easily
redirect this somewhere else if needed without editing web hooks in multiple
places on GitHub. As I understand this is just your personal playground, I would
add the domain name:
  build-rajdeepbharati.macports.org  A  34.67.147.76

What kind of payload and which events are required? I would assume JSON format
and just the "push" event as for the existing buildbot? Or will this already
make use of the preferable GitHub Checks API and needs the corresponding
"Check run"/"Check suite" events?

> I believe that the following piece of code is an extensive user of the
> web hooks:
> https://github.com/macports/mpbot-github
> This is a bot written in go (a past GSOC projects from 2017) which
> attaches various labels to PRs and takes care for CI builds of ports
> on Travis, parsing the logs and publishing summary of build results
> from Travis as comments on PRs.

Web Hooks are used to notify external services of events happening at GitHub.
The "reverse" operation to update status information and add comments uses the
GitHub API.

Rainer

Re: macOS 10.15 Read Only root

[Rainer Müller]

On 30/06/2019 04.15, Ryan Schmidt wrote:
> On Jun 29, 2019, at 19:53, Mark Anderson wrote:
> 
>> Do we have any plans with how to deal with 10.15 not allowing us to create 
>> /opt if it doesn’t exist? Or does /opt just come with the file system? I 
>> can’t remember.
> 
> macOS does not come with an /opt directory.
> 
> I was not aware that macOS Catalina will prevent the creation of such 
> directories, but I haven't read up on the new system yet. If that is true, 
> then that sounds like a problem for us.

/opt will not reside on the read-only volume, but with the new concept of a
"firmlink" it will be placed on another volume.

I was told the full list of these writable paths using firmlinks can be found in
/usr/share/firmlinks.

Rainer

Re: Slack-like chat (also for GSOC)

[Rainer Müller]

On 14.06.19 13:01, Nils Breunese wrote:
> 
> Chris jones wrote:
> 
>> ( The main problem I have, is not something specific to Riot or whatever 
>> forum we use, but more we need to perhaps give some thought to the channels. 
>> Currently there is really only one, which gets (some) chat but also messages 
>> for each and every commit. I don't think the average user needs to see each 
>> and every commit. I think we probably need to split these, for instance into 
>> Dev and User channels, to match the mailing lists perhaps. )
> 
> I’d go even more granular: create a dedicated channel for commits and 
> everyone can decide whether to follow that or not.
I am not sure how useful such a dedicated channel would be if only
automated messages will be posted and no discussion takes place.
Sometimes the mplog messages are even used during conversations, like
"see this commit, now it is fixed".

For those that really do not want to see these messages, I would
recommend to add mplog to their your ignore list. That works in IRC
clients and also in Riot.

The bot is operated by me, but if others also think that the bot is
annoying, I do not insist on keeping it running or moving it to another
channel.

Rainer

Re: Slack-like chat (also for GSOC)

[Rainer Müller]

On 14.06.19 11:10, Chris Jones wrote:
> ( The main problem I have, is not something specific to Riot or whatever
> forum we use, but more we need to perhaps give some thought to the
> channels. Currently there is really only one, which gets (some) chat but
> also messages for each and every commit. I don't think the average user
> needs to see each and every commit. I think we probably need to split
> these, for instance into Dev and User channels, to match the mailing
> lists perhaps. )

I would be afraid that by removing the development discussions, the
channel would appear mostly dead. The traffic is already quite low.

If at all, I would keep #macports as user channel and create another
#macports-dev for deeper discussions of internals.

However, development discussions happen rarely and are usually started
by something that would rather be categorized as a user question. Which
means we would have to force ourselves to move the discussion to another
channel as soon as it gets to a development topic...

Rainer

Re: upt-macports project update and feedback request

[Rainer Müller]

On 06.06.19 04:36, Karan Sheth via macports-dev wrote:
> Community feedback is requested on the following topics:
> 
> 1. The naming convention of Python ports
> For upt to be able to process dependencies correctly and add missing
> packages recursively, it is important to have a consistent naming scheme
> for ports. Currently, that is not completely the case, although most
> ports follow “py-”. In some cases though we keep the
> capitalization, for some others we convert it to all lowercase;
> additionally, some ports do not follow this convention (e.g.,
> py-dateutil, where PyPI is “python-dateutil” or “py-codestyle”, where
> PyPI is “pycodestyle”).
> 
> Our proposal is to use “py-” for all Python ports
> going forward and renaming the ones that currently do not follow this
> convention. Are there any concerns, objections, and/or considerations
> here we might have missed? In any case, we will need to do some renaming
> to get everything consistent (irrespective of what convention we
> choose), but it will help for maintainability in the long run.

How would you identify existing ports that need a rename?

Keep in mind that a rename that only changes the port directory name to
lowercase might be a bit tricky as the filesystem is usually
case-insensitive.

> 2. Packaging of Ruby ports
> There is an “upt-rubygems” frontend in upt that we can leverage to
> generate Ruby portfiles and we are currently looking into this. As many
> of the current Ruby ports are outdated and are supporting EOL versions
> of Ruby, my mentor @reneeotten suggested the following: 
> "Disclaimer: I am not very familiar with Ruby and only spend an hour or
> so looking through the PortGroup and some of the ports; so this is by no
> means fully worked out, but it seems to me that the PortGroup could use
> some attention to start with. I’d suggest updating the current PortGroup
> (or probably better to add a new one as ruby-1.1.tcl) in which we add
> support for the most recent Ruby version (2.6) and ideally drop support
> for EOLed versions, including the 1.x branch."
> 
> Any feedback from MacPorts/Ruby users at this time on both the proposal
> to drop older versions and things to consider for the PortGroup or Ruby
> packaging, in general, would be highly appreciated.

Adding Wataru Kimura to CC as maintainer of our ruby* ports and also
lots of modules. What is your take on getting rid of old ruby versions?

Going for a ruby-1.1.tcl sounds like a reasonable way to get incremental
steps that avoid too much interference with the existing rb-* ports.
> Finally, if you’re interested in this GSoC project, please take a look
> at the repository (https://github.com/macports/upt-macports) or install
> the “py37-upt” port and give it a try. The template for PyPI/Python
> ports is complete, the templates for CPAN/Perl and RubyGems/Ruby are
> fairly complete, but we’re still working out some details. Feedback from
> the community is very welcome!

I would recommend to rename this port to "upt" and install the binary
without suffix. As a user, I do not care which version of python the
tool uses or that it is even written in Python at all. I just want to
run the "upt" executable.

I am aware this comes up a lot lately, but I think the distinction
between tools and modules is important. I would never expect a py-*
prefix on ports such as meld, diffoscope, or bzr.

Rainer

Re: openssl source install with trace mode bugged

[Rainer Müller]

On 03.06.19 15:50, Mihir Luthra wrote:
> I noticed that on a “new" MacPorts installation, if we try to install
> openssl with flags   -st, it will fail.
> 
> Problematic lines in main.log with debug on are :-
> 
> :info:configure darwintrace[30583:0x10fc915c0]:
> posix_spawn(/opt/original-base/var/macports/sip-workaround/502/usr/bin/perl5.18)
> = 2
> 
> 
> :info:configure perl: posix_spawn:
> /opt/original-base/var/macports/sip-workaround/502/usr/bin/perl5.18: No
> such file or directory

Indeed, I was able to reproduce this problem on macOS 10.12 Sierra in a
completely new prefix. The file is just not there.

This file is a copy of the original file in /usr/bin in order to evade
the SIP protection that prevents DYLD_* variables in the environment.
Normally it should be copied if it does not exist or if the file in
/usr/bin is newer. Somehow this seems to have failed for some reason
that needs to be determined.

> Also this won’t occur if I install perl5.28 port separately. It doesn’t
> depend on that port but configuring in port perl5.28 does certain steps
> that makes installing port openssl possible. So even if I terminate
> installing of port perl5.28 after it is done configuring, it would be
> possible to install port openssl.

I would assume this step creates the copy of perl5.18 that was missing
before. It should not matter which port you configure as long as it uses
/usr/bin/perl5.18 in trace mode.

> I tried checking main.log with debug enabled but it crashes possibly due
> default logging being in stderr and causing interference with port
> install. I tried changing default logging location but doesn’t seem to
> work for me.

I did not understand what you tried in this paragraph.
What do you mean by "crashes"?

Rainer

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

[Rainer Müller]

On 03.04.19 01:07, Ryan Schmidt wrote:
> This happened again yesterday.

And again today... :-/

Because I am clearly not making progress here, if anyone wants to help
this would be the script that wraps git-multimail to handle the mails to
macports-changes:

https://github.com/macports/trac.macports.org/blob/master/plugins/hooks/trac-github-update.py

It receives the GitHub WebHook payload in JSON format on stdin, as
documented here:
https://developer.github.com/v3/activity/events/types/#pushevent

The goal would be to change the From: address to something static, but
maybe still keep the pusher address available in the body.

Rainer

Re: Packaging buildbot-www

[Rainer Müller]

On 28.05.19 09:11, Rajdeep Bharati wrote:
> I am packaging buildbot 2.x as a port. However, a key part of buildbot 2
> is the web interface, buildbot-www, which uses many javascript
> dependencies (those aren't available as MacPorts packages yet). Please
> find the attached image which shows the dependencies.
> 
>  Screenshot 2019-05-28 at 11.36.55 AM.png
> 
> 
> What would be the right way to package this? Would it be a python port?
> Would it be better to package all of the above JS libraries?

Out of curiosity, where does this screenshot come from?

To me it looks like all of these (minified) JavaScript libraries and
also FontAwesome are already included in the release tarball. You do not
need to create ports for these, the software will use the included copies.

$ tar xf buildbot-www-2.3.1.tar.gz
$ $ tree buildbot-www-2.3.1/buildbot_www/static
buildbot-www-2.3.1/buildbot_www/static/
├── d3.min.js
├── fonts
│   ├── FontAwesome.otf
│   ├── fontawesome-webfont.eot
│   ├── fontawesome-webfont.svg
│   ├── fontawesome-webfont.ttf
│   └── fontawesome-webfont.woff
├── img
│   ├── favicon.ico
│   ├── icon.png
│   ├── icon.svg
│   ├── icon16.svg
│   └── nobody.png
├── index.html
├── scripts.js
├── styles.css
└── tests.js

Rainer

Re: URGENT -- massive merge commit on macports/macports-ports

[Rainer Müller]

As a reference for everyone, we are talking about this commit in this
thread:
https://github.com/macports/macports-ports/commit/8636b39946229023fecc2c8c5d99be1b0a0bccd1

On 22.05.19 01:06, Christopher Jones wrote:
> Its a merge commit, i.e. the committer at some point pulled in changes to a 
> branch which they subsequently pushed to master without rebasing.

Jann, I assume you just ran 'git pull' which created this merge commit.
The better option would have been to run 'git pull --rebase' to avoid
this merge and place your new commit on top of the existing
macports-ports master.

It is indeed a bit complicated and git does not make it easy to
understand it. Please see our documentation that we prefer the rebase
operation:
https://trac.macports.org/wiki/WorkingWithGit#updating

> Its ‘OK’ in that its not a real commit. The changes you see in GitHub won’t 
> really happen (if you look in detail they are commits already in master).

I assume GitHub displays it like this because the merge is "reversed" to
their usual workflow. The previous macports-ports master is on the right
hand side of the merge. Therefore it looks like the macports-ports
master was merged into another branch.

As another example, it did not look that horrific in the notification on
macports-changes (HTML only):
https://lists.macports.org/pipermail/macports-changes/2019-May/179654.html

> Avoiding these is why we rebase, i.e. if your setup is configure to work 
> directly from a git checkout running ’sudo port sync’ under the hood runs 
> ‘git pull —rebase —autostash origin master’ (if your git is new enough). 
> 
> We don’t really want these commits in the master history, but at this point 
> removing it (rewriting history in master) would be a bad idea and possibly 
> lead to trouble, so best to leave it, and hope the committer learns not to do 
> it again ;)
I agree, there is not much we can do against this without rewriting
history and force-pushing, which would break the next pull operation for
everyone. Also it did not even do any damage, it just looks strange on
the GitHub web interface.

Rainer

Re: PRs

[Rainer Müller]

On 19.05.19 20:40, Mark Anderson wrote:
> Who is currently working on out CI/CD stuff like Travis, etc? And where
> is it? There are some things I'd like to propose/do, like making the
> maintainer timeout label automatic and making it possible to re-run CI
> from GitHub commits.

The bot is maintained by Zero King (@l2dy). The maintainer timeout label
is in fact supposed to be applied automatically. Is this job not working
as expected?

https://github.com/macports/mpbot-github/blob/master/pr/cron/maintainer_timeout.go

Rainer

Re: PRs

[Rainer Müller]

On 19.05.19 20:45, Christopher Chavez wrote:
> On 5/19/2019 1:40 PM, Mark Anderson wrote:
>> making it possible to re-run CI from GitHub commits.
> 
> As a PR submitter, one workaround I'm aware of is rebasing the PR
> commit(s). I'm not sure that's something members can/should try though,
> so a better solution is probably still preferred…

I would not consider this a workaround, but the best choice we have.

Re-running the build with the exact same revision would not be that
useful. Without changes to the source, I would expect the same result.
As the ports tree and therefore the dependencies have usually advanced
since the PR was submitted, it makes sense to do a rebase first before
attempting another build.

In theory it is possible to restart a build on the Travis CI web
interface with the same revision, but I am not even sure if all members
have access to that?

Rainer

Re: Slack-like chat (also for GSOC)

[Rainer Müller]

On 18.05.19 00:04, Rainer Müller wrote:
> On 17.05.19 23:54, Umesh Singla wrote:
>> I tried setting one up. Well, it only takes one to sign up (email
>> optional) and create rooms. Please give it
>> a try: https://riot.im/app/#/room/#macports-public:matrix.org. This
>> one's a public room, you can see the messages but not talk until you
>> sign up. 
> 
> You do not need to create a new room. Please just join the existing
> #freenode_#macports:matrix.org, which is bridged to our IRC channel.>
> I think this is the best approach, because we already have a large user
> base in the IRC channel. The Matrix bridge is ideal for those who wish
> to use a more mordern client or do not want to run their own bouncer to
> always stay connected.

I noticed now that only users registered with NickServ where allowed to
speak on the IRC channel. This might also have prevented new users
connected via Matrix to speak, unless you also registered with NickServ.
In case you could join the channel but were unable to send messages,
please try again now.

We had enabled this due to a spam wave a few months ago. I hope we can
relax this limitation now without getting the spam bots again. Sorry, I
had not thought of disabling this before.

Rainer

Re: Slack-like chat (also for GSOC)

[Rainer Müller]

On 2019-05-14 22:32, Mojca Miklavec wrote:

On Tue, 14 May 2019 at 18:11, Rainer Müller wrote:

>>> Would it be realistic to install such a service on breaburn if needed?
>>> (Or is it too complex / too much work?)
>>
>> I'd prefer a SaaS offering here. Self-hosting just increases the
>> maintenance burden and I don't think we need the configurability.

For the self-hosted options, Rocket Chat would be an option. However,
when we used it at work, after a while I started to miss some kind of
threading for longer conversations. Although we also usually do not 
have

long conversations or that much activity on IRC, so maybe this is not
that important here.


I don't have any experience with Matrix, but I maybe I should try it 
once.


I'm not familiar with Rocket Chat either, but if you missed a feature,
I trust your opinion.

I do believe that longer conversations are important. Think of GSOC,
where the same project runs for 5 months or longer. It does make sense
to keep it well-organised.

Zulip offers topics (which they heavily advertise as one of their
"superpowers") which I find to be quite a nice "substitute" for
threads like those in emails. If we pick that one, I would certainly
go for GitHub OAuth and IRC mirror.

I would discard the idea of using Slack. Based on general feedback
that probably leaves the following top candidates?
- Matrix (might work without self-hosting)
- Zulip
- Mattermost

Rainer, you did not answer about whether you would be willing to try
to install / maintain one of those on the server if we wanted to
self-host the chat?


Of course, I would be in favor of something where we do not need to do 
the maintenance. But if there is no option that is free and offers all 
features we want, it would be possible to host it on our server. 
Preferably with authentication with GitHub to ease administration of 
groups and privileges.


Regarding Matrix: is anyone willing to set up one ("in the cloud") for 
testing?


You could just use the matrix.org as a homeserver, which is open for 
registrations by all. The best client I am aware of would be 
https://riot.im, which uses matrix.org as default and can register new 
accounts. It offers a solution for all of Web/Desktop/Mobile. Joining 
the FreeNode IRC Bridge should be possible from all homeservers and with 
any client though, via a special channel name.


https://github.com/matrix-org/matrix-appservice-irc/wiki/Bridged-IRC-networks

Rainer

Re: Slack-like chat (also for GSOC)

[Rainer Müller]

On 2019-05-14 18:11, Rainer Müller wrote:

For the self-hosted options, Rocket Chat would be an option. However,
when we used it at work, after a while I started to miss some kind of
threading for longer conversations. Although we also usually do not 
have

long conversations or that much activity on IRC, so maybe this is not
that important here.


Turns out the newest version of Rocket Chat already has 
"sub-discussions" for this, so my point above is not fully valid. I have 
not worked with the latest version, so my experience with Rocket Chat 
might be more limited than I thought.


Rainer

Re: Slack-like chat (also for GSOC)

[Rainer Müller]

On 12.05.19 21:49, Mojca Miklavec wrote:
> On Sun, 12 May 2019 at 21:15, Clemens Lang wrote:
>> On Thu, May 09, 2019 at 11:38:16PM +0200, Mojca Miklavec wrote:
>>> I know that our official channels only include mailing lists, IRC and
>>> PR/ticket discussion so far, but I'm curious about your stand with
>>> respect to setting up a service like Zulip Chat / Rocket Chat / ...
>>> for aiding the GSOC communication when higher frequency of potentially
>>> simple questions would be needed. I know IRC could fulfill such a
>>> task, but it doesn't work too well for me. (I'm offline when at work,
>>> cannot really use phone efficiently for communication etc..)
>>
>> I don't have particularly strong feelings about any of these solutions
>> with a slight tendency towards an open source solution.
> 
> I would prefer OpenSource as well.
> 
> My experience from work was that we started with Slack (which btw.
> works very nice) and initially everyone said that we would use it just
> as real-time chat and that nobody would ever need the archives. That
> is: until someone needed them. At that point the solution was
> considered way to expensive to be used long-term and we switched to
> something else.

I think Slack workspaces are also always invite only, but please correct
me if I am wrong (maybe only for paid plans?). Assuming we might want to
replace IRC one day as the official development and support chat, that
would not work well.

I think it is important that this would be open for anyone interested to
join, with private group chats as an optional feature.

>> I do see the
>> benefits compared to IRC also from experience at work. If that's
>> something we as a community agree on, I wouldn't mind switching my IRC
>> presence.
> 
> We don't need to all agree at once. I don't see anything wrong with
> giving it some testing first and decide what's best (no need to ask
> everyone to turn IRC off :).

I recently tried the Matrix IRC Bridge to FreeNode IRC. By using riot.im
it actually works quite well and was easy to set up. It also solves the
"always-on" problem of IRC as it acts like a bouncer.

>>> Would it be realistic to install such a service on breaburn if needed?
>>> (Or is it too complex / too much work?)
>>
>> I'd prefer a SaaS offering here. Self-hosting just increases the
>> maintenance burden and I don't think we need the configurability.

For the self-hosted options, Rocket Chat would be an option. However,
when we used it at work, after a while I started to miss some kind of
threading for longer conversations. Although we also usually do not have
long conversations or that much activity on IRC, so maybe this is not
that important here.

Rainer

Re: New Portfiles

[Rainer Müller]

On 11.03.19 01:13, MacPorts wrote:
> I don't remember why I ended up making a new port for html-tree.
> 
> There seem to be two different modules at cpan that use the name
> Web::Scraper. One uses Web::Scraper::LibXML. The port I created includes
> the module that uses Web::Scraper::LibXML.

It is in fact the same Web-Scraper module on CPAN. The existing port
p5-web-scraper already includes the Web::Scraper::LibXML interface.

$ port -q contents p5.26-web-scraper |grep LibXML
  /opt/local/lib/perl5/vendor_perl/5.26/Web/Scraper/LibXML.pm
  /opt/local/share/perl5.26/man/man3/Web::Scraper::LibXML.3pm

However, it is not functional as the HTML::TreeBuilder::LibXML
dependency you want to add is indeed missing at the moment.

$ perl5.26 -e 'use Web::Scraper::LibXML;'
Can't locate HTML/TreeBuilder/LibXML.pm in @INC (you may need to install
the HTML::TreeBuilder::LibXML module) [...]

I would advice to only add the dependency on p5-html-treebuilder-libxml
to the existing p5-web-scraper port after the former has been merged.

Rainer

Re: Google Summer Of Code

[Rainer Müller]

On 28.02.19 10:35, Mojca Miklavec wrote:
> Dear Ryan,
> 
> On Thu, 28 Feb 2019 at 02:39, Ryan Schmidt wrote:
>> On Feb 27, 2019, at 17:07, Mojca Miklavec wrote:
>>>
>>> Now it's really time to:
>>> - Put a short news with a logotype on at least https://www.macports.org 
>>> (Ryan?)
>>
>> I don't think I was involved in that before; I don't know what we've done 
>> before. I would ask that someone else do it.
> 
> How does our website get deployed / who has permissions to change it?
> Me or Umesh can modify the contents, but I'm not sure how the rest of
> the process goes until it ends on the website.

Everything pushed to the macports-www repository will be deployed via a
buildbot job [1] to our server automatically.

> Also, what's your stand with respect to merging
> https://github.com/macports/macports-www/pull/13? I would be in
> favour, but we should really not delay such things. Either we decide
> to merge it or do something else, but we should not let valuable
> potential contributors wait until they give up.

+1

There are now objections in the pull request, so I am in favor of
merging this as it is.

Rainer

[1]
https://github.com/macports/macports-infrastructure/blob/master/buildbot/master.cfg#L701-L727

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

[Rainer Müller]

On 26.02.19 02:55, Zero King wrote:
> 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.

Yes, you are right. Thanks for pointing this out. Using CC is not a
solution.

The goal [1] was to additionally include the author in a reply with the
least effort, but the Reply-To field is already taken by the
macports-dev mailing list.

I guess we will just have to copy and paste the mail address from the
body in the future.

Rainer

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

Mail delivery of macports-changes disabled for Gmail users

[Rainer Müller]

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.

Rainer

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

Re: Universal packaging tool (for pypi, cpan, ruby, ...)

[Rainer Müller]

Hey,

On 12.02.19 03:40, Cyril Roelandt wrote:
> I'm the author of upt.

Thanks for joining the discussion!

> On 2019-02-10 21:24, Mojca Miklavec wrote:
>> Hi,
>>
>> Last week I was sitting in cafeteria with the author of a new python
>> package "upt" (Universal packaging tool) whose aim is to provide
>> automatic conversion from one of the repositories like pypi, cpan,
>> ruby gems, npm, ... into any other package manager.
>>
>> https://framagit.org/upt
>> https://fosdem.org/2019/schedule/event/package_software_with_upt/
> 
> The video is not online yet, but should appear on the FOSDEM page soon.
> A quick summary: upt is a collection of modules. Some are "frontend"
> modules and parse upstream package archives (PyPI, CPAN, ...), others
> are "backend" modules, and create a source package suitable for a
> downstream distribution (Fedora, OpenBSD, and maybe soon, MacPorts!).

This is a great initiative. One of our problems has always been that
these tools kind of need to be written in the native language of the
upstream package (Python, Perl, ...), because that is the only language
with bindings to parse the package specfications. Unifying this with the
frontend/backend approach sounds like a good idea.

>> For us this could at some point replace pypi2port & cpan2port (less
>> important), but more importantly we have no such tool for ruby gems (I
>> believe?), and maybe someone would write a frontend for npm or another
>> tricky "package manager" one day.
> 
> It is worth noting that, because of the modular nature of upt, every
> time someone adds/updates a frontend, the improvements are available for
> every single backend (including the MacPorts one Mojca is working on).
> This means that all distro developers end up sharing their hard work.
> 
>>
>> What's currently not implemented are non-python / non-perl
>> dependencies, and an easy way to upgrade (it can create the package
>> for the first time, but if you make lots of changes, it doesn't know
>> how to "merge" the manual changes with changes in the upstream
>> package).
> 
> Regarding non-Python dependencies in Python packages, I do not think
> setuptools allows developers to specify them. Maybe I'm mistaken?

I think external libraries would be specified in the ext_modules=[]
argument that is passed to setup(), where each Extension can list
external libraries for linking.

https://docs.python.org/3.6/extending/building.html#building-c-and-c-extensions-with-distutils

Of course, the package(s) actually providing the shared library may be
different depending on the downstream distribution...

> Regarding updates, I think I did not answer your question at FOSDEM.
> Sorry about that, it was a bit of a stressful talk, as you may
> remember :) How does pypi2port work with upgrades?

Our generators do not assist with upgrades in any way. You could only
generate a Portfile for the new version again, but then manual work is
required to merge the changes into the existing Portfile.

Rainer

Re: Tcl removes a level of backslashes when accessing a string as a list

[Rainer Müller]

On 02.02.19 02:52, Ryan Schmidt wrote:
> You'd think I'd understand tcl's lists and strings by now. But no. A list is 
> a string and a string is a list. Or maybe it isn't.
> 
> I'm having trouble with livecheck.regex. Since it's a regular expression, 
> it's pretty common for it to contain backslashes. The backslashes are being 
> removed when I don't expect them to be.
> 
> In src/port1.0/livecheck.tcl MacPorts calls [join ${livecheck.regex}]. Why 
> does it do that? I guess it does that so that we can define a regular 
> expression that contains spaces, without having to enclose it in quotes. 
> MacPorts options are lists, so when we write:
> 
> livecheck.regex this is a valid regular expression
> 
> what we're really setting livecheck.regex to is a list with 6 items. MacPorts 
> helpfully transforms that into a single string for us.

When checking why this uses the join, I noticed I have been on this a
long while ago and tried to "fix" this behavior:

https://github.com/macports/macports-base/commit/961c0ac0bee13e5322c7fd0c997285ed7e44c94e

https://github.com/macports/macports-base/commit/6deef386fea9319b5eb74c98ca4164f6586898c6

I do not really remember the details anymore, but apparently I reverted
back to lists because Portfiles already used an additional level of
escapes... Maybe we should have fixed the Portfiles instead.

> Except that in so doing, it removes one layer of backslashes. Using the tclsh 
> repl we can see that making a string with a backslash works fine:
> 
> $ tclsh
> % set a {hello\.world}
> hello\.world
> % puts $a
> hello\.world
> 
> But if we access it as a list using lindex or join it loses the backslash:
> 
> % lindex $a 0
> hello.world
> % join $a
> hello.world
> % 

lindex or join have to convert the string to a list first. This implies
substitution of backslash escaped characters because they have special
meaning in the string representation of lists.

For example, "x hello\ world y" is the same list as "x {hello world} y",
but in two different string representations. In the first form, the
backslash is used to escape the space character.

Things would be easier if we were always working with list operations,
because these operations will preserve the special characters with
escape sequences when needed. When putting to together a string and only
then converting it to a list, you need to take care of the escaping
yourself.

% set a {}
% lappend a hello
hello
% lappend a {world}
hello world
% lappend a {hello\.world}
hello world {hello\.world}
% puts $a
hello world {hello\.world}
% lindex $a 2
hello\.world
% join $a
hello world hello\.world

Rainer

Re: Q about a (new) portgroup file

[Rainer Müller]

On 27.01.19 14:33, Eric F (iEFdev) wrote:
> 
> On 1/27/19 14:21 , Christopher Jones wrote:
>> If you don’t think it is quite ready, but you want to start to get
>> feedback, then that is exactly with WIP PRs are for. Just remember to
>> start the title with ‘WIP” and also add the wip label to the PR.
>>
>> Chris
> Thanks!
> 
> Ok, here it is: https://github.com/macports/macports-ports/pull/3510
> Hope that was ok. At least it passed the checks. :)

FYI, Travis CI will only test changed Portfiles, as you can see on this
build the collected port list is empty. Such a pull request not changing
any ports, but only port groups or other metadata files, will always pass.

Rainer

Re: depspec generator?

[Rainer Müller]

On 14.01.19 10:33, René J.V. Bertin wrote:
> I think MacPort "base" already has most of the code required to generate a 
> depspec list from a new/upgraded port's destroot, as a means of verification 
> and convenience for port maintainers. (A bit like my own 
> port-check-conflicts.tcl 
> [https://github.com/RJVB/macstrop/blob/master/macports/bin/] which checks for 
> activation conflicts).
> 
> Does something like this already exist, especially with an option to filter 
> out indirect dependencies (= those already satisfied through dependency 
> inheritance)?

This functionality does not exist, but in theory this is kind of what
the post-destroot checks are supposed to catch. This work just never got
polished and merged to master.

https://trac.macports.org/wiki/SummerOfCode2011#depcheck
https://github.com/macports/macports-base/compare/gsoc11-post-destroot

The idea was to produce warnings when dynamic libraries were linked
without the providing port being in depends_lib of the port it self or
in any of the recursive dependencies.

Note: The name "postdestroot" was kind of a placeholder and this is in
need of a better name to avoid confusion... "verify"? "linkcheck"?

Rainer

Re: Online MacPorts meeting? This Saturday?

[Rainer Müller]

On January 10, 2019 10:00:54 PM GMT+01:00, Mojca Miklavec  
wrote:
>Should we stick with 15:00 (3 p.m.) UTC for the meeting or does anyone
>have any other requests?
>
>For those who can attend, please raise your hands (publicly or
>privately).

Works for me, I will attend.

>We met via Google hangouts last time, right?
>I can create and send a link.

+1

Thank you for organizing the online meeting!

Rainer

New project member: mark

[Rainer Müller]

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

 - Mark Anderson (mark@, @markemer)

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

- Joshua, Ryan, and Rainer


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

Scheduled downtime on Dec 14

[Rainer Müller]

Hello,

due to maintenance on the network in the data center where our server is
hosted, there will be a 20-minute disconnection in the time frame given
below.

Start:  2018-12-14 03:00:00 UTC
End:2018-12-14 05:00:00 UTC (expected)

This will mostly affect the website, Trac, and the mailing lists. GitHub
can be used as usual, but any WebHook sent from GitHub to Trac during
the downtime will fail and will have to be re-triggered manually once
the system is online again.

Rainer

Re: macports rot

[Rainer Müller]

On 03.12.18 17:00, Jonathan Stickel wrote:
> I would like to express some concerns about trends I've noticed in the
> Macports community. I've been a Macports user and contributor for many
> years. I understand the imperfect nature of open-source projects run by
> volunteers. Interest and contributions, both by developers and periphery
> contributors, waxes and wanes. It seems to me that Macports is waning.
> With the move to github, developer and port-maintainer attention to
> tickets on trac really dropped off. This was partially made up for by
> increased attention and fast turnaround with pull requests. Recently,
> even pull requests are languishing. Reasonable fixes are ignored, or, if
> problems with the contributions are identified by developers and
> maintainers, the problems are pointed out with no effort to provide
> constructive input.
>
> I try to help where and when I can. When something is not working for
> me, I try my best to find a fix and contribute a pull request. I also
> respond in a reasonable time to tickets and PRs for ports for which I am
> maintainer. I think this is quite reasonable and the best I can do
> considering my paying job. I know that I do not have enough time to act
> as a developer, and so I am not asking for that.

Your observation might be right, but maybe this just becomes more
visible now on GitHub. Just take a look at the number of open tickets on
Trac. There are also many tickets with proposed ports or fixes. However,
if the submitter does not have enough interest to follow through, the
ticket will just hang there.

I feel like many "oldschool" developers already left the platform,
because more and more functionality is put behind some wall that only
Apple can penetrate. Gatekeeper, signed Kernel Extension, and SIP impose
limits on what you can do with macOS, while non-Apple developers do not
even get proper logging when APIs become forbidden and blocked.

I guess that users coming to macOS now are used to graphical interfaces
and do not have a strong background in using the command line. I am sure
many are more happy with Homebrew, where they do not even have to use
sudo! ;-)

Somehow the Homebrew community managed to get their ubiquitous marketing
on almost every software project website. Compare this with the MacPorts
website, which has not seen any redesign in more than 10 years...

Although a good package management system should not need to advertise
itself, as every software would be available without users being told
where to look – the package manager should be their first choice.

> So where is Macports headed? I think the core architecture and systems
> of Macports are well built. It just needs a little more attention. How
> can we achieve that? Has Homewbrew simply siphoned off too much user and
> developer base? I don't know.

I would also like to point out that there was also no discussion on the
recent thread that we have a problem with the process to on-board new
project members... That is one of the most important things that needs
to be solved as it affects the whole community.

Similarly on the recently failed online meeting and especially the topic
of joining the Software Freedom Conservancy or more general to form any
kind of legal entity.

The project definitely needs more steering. But to be fair and
transparent on this, I am personally not able to provide this at the moment.

Rainer

Re: extract gzip files

[Rainer Müller]

On 30.11.18 18:09, Mark Brethen wrote:
> This doesn’t work:
> 
> extract.suffix= .gz
> extract.cmd   = gunzip
> extract.pre_args  = -c
> extract.post_args = "> ${workpath}"

This cannot work as ${workpath} is a directory and you cannot redirect
output to a directory, you would have to specify a regular file.

Can you rely on the extracted filename that is stored in the .gz? Then
most extract options can be left on the default values:

extract.pre_args -d
extract.post_args
extract.mkdir yes

By default, the extract command will be executed inside extract.dir,
which would be ${workpath}. The extract.mkdir option will create
${worksrcpath} first and extract to the new directory. This should
simplifies the following configure/build/destroot commands that will be
executed in ${worksrcpath} by default.

Rainer

Re: trying to understand the --no-exec activate option (on by default?)

[Rainer Müller]

On 29.11.18 22:59, René J.V. Bertin wrote:
> That's what I understand from the embedded help but also what I'm trying to 
> confirm in the code.
> As said, I'm not seeing output from post-activate phases when I reactivate a 
> port after having deactivated it.

Have you tried unconditional output first? Works fine for me here.

> From what I understand the default is that the corresponding option variable 
> ("ports_activate_no-exec") isn't even defined. It's unclear to me what the 
> other 2 expressions check for in that same if in proc action_activate; maybe 
> they're the reason my post-activate phases aren't executed after each 
> activation?

Correct, these variables will only be defined when the argument is given
on the command line. The code that sets ports_${action}_${key} is in
proc parse_options in port/port.tcl.

Not sure which expressions you mean, but the call to registry::installed
is used to verify that the given portname/version combination is
actually available in the registry.

Rainer

Re: trying to understand the --no-exec activate option (on by default?)

[Rainer Müller]

On 29.11.18 23:25, Fred Wright wrote:
> In the particular case of code signing, would it be possible to do that
> in the post-destroot phase, so that the signature would remain across
> activations and deactivations, or does the signature mechanism defend
> against that (even though a verbatim copy of signed code should still be
> signed)?

No, it cannot be done in the destroot, as that are the files that will
be put into an archive for redistribution. Whatever signing identity you
are using might not be valid everywhere.

We had a lengthy thread about code signing quite a while ago with a few
different proposals:
https://lists.macports.org/pipermail/macports-dev/2016-September/033518.html

Rainer

Re: trying to understand the --no-exec activate option (on by default?)

[Rainer Müller]

On 29.11.18 11:08, René J.V. Bertin wrote:
> I'm trying to understand how/where the activate --no-exec option is set, I 
> have the impression it's on by default.

To clarify the double negative here, the post-activate phase will be
executed by default.

Rainer

Re: Dealing with a click-through license

[Rainer Müller]

On 26.11.18 03:26, Randolph M. Fritz wrote:
> No, you can download it. The license is an old BSD license, so it's
> pretty good, but users are required to read and accept it. Is there any
> way to accommodate this, or do I simply have to say that we can't
> distribute a portfile for the system?

Even if the distfile cannot be downloaded, you could still write a
Portfile, but users would be required to download the file manually.

As an example, see the geoexpress-sdk port that does something similar:

https://github.com/macports/macports-ports/blob/b11b60aec24d59304043c28492741554e0e616e2/gis/geoexpress-sdk/Portfile

Rainer

Re: convert a static library to a dynamic one?

[Rainer Müller]

On 18.11.18 20:36, Mark Brethen wrote:
> The spooles src creates a static ‘spooles.a’ library. I want to get a dynamic 
> library out of it. In BSD, for a .so library you would use:
> 
> ld -Bshareable -o libspooles.so.1 -x -soname libspooles.so.1 --whole-archive 
> spooles.a
> 
> For macports I tried
> 
> system -W ${worksrcpath}_SHARED ld -dylib -force_load spooles.a -o 
> libspooles.1.dylib
> 
> ld fails with an error:
> 
> :info:build ld: symbol(s) not found for inferred architecture x86_64
> :info:build Command failed: ld -dylib -force_load spooles.a -o 
> libspooles.1.dylib
> :info:build Exit code: 1
> :error:build Failed to build spooles: command execution failed
> 
> How do I have to modify above command so I will get the desired result?

I would have extracted the object files from the archive and created a
dynamic library using libtool (that is /usr/bin/libtool, not to be
confused with GNU libtool).

  ar -x spooles.a
  libtool -dynamic *.o -o libspooles.1.dylib

You most likely should also set additional arguments such as
-install_name and -compatibility_version/-current_version if you want to
distribute the result in a port.

HTH,
Rainer

Re: [GitHub] Subscribed to macports/macports-legacy-support notifications

[Rainer Müller]

On 07.11.18 22:31, Ryan Schmidt wrote:
> 
> 
> On Nov 7, 2018, at 15:22, Rainer Müller wrote:
> 
>> On 07.11.18 22:10, Rainer Müller wrote:
>>> What is the plan? Should we also connect this new repository with Trac?
>>
>> Ah, just found the ticket:
>> https://trac.macports.org/ticket/57537

The new repository is now also connected to Trac via the usual WebHook.
It is not connected to buildbot or pr-bot, as I have no idea if these
services would be ready for it or if it would even be useful.

> Yes, that would be a good idea. Do we also want a new component in Trac for 
> this? I think maybe yes. Or do we group it in with contrib?

As ports are expected to download this, a separate repository makes sense.

> It's probably a good idea for each project to get its own repo like this. I 
> feel that we should probably break individual projects out of 
> macports-contrib into their own repos as well.
+1

Rainer

Re: Macports-mgr

[Rainer Müller]

On 04.11.18 16:09, Mark Anderson wrote:
> I sent a message to Macports-mgr in July and haven't heard back. I know
> it can take a long time, but how long is a long time?

It is already way too long. The goal is to answer within one week.
PortMgr has failed way too often with this. In many cases it is just a
couple of templated mails to macports-infra and macports-dev that are
needed to make progress with requests... Flipping the bit to grant
access is comparatively fast.

Honestly, I am tired of the whole process. I also do not know how to
proceed or what we should be doing differently to make this work.
I suggested to change it before, for example to handle it publicly on
macports-dev instead. But we are still stuck with this, although it is
not working.

Personally, my time to contribute to MacPorts was especially limited
over the last couple of weeks as I started a new job. My daily work
machine is also no longer a Mac now, which also takes away some of the
incentive.

Rainer

Re: Fwd: [GitHub] Subscribed to macports/macports-legacy-support notifications

[Rainer Müller]

On 07.11.18 22:10, Rainer Müller wrote:
> What is the plan? Should we also connect this new repository with Trac?

Ah, just found the ticket:
https://trac.macports.org/ticket/57537

Rainer

Fwd: [GitHub] Subscribed to macports/macports-legacy-support notifications

[Rainer Müller]

What is the plan? Should we also connect this new repository with Trac?

Rainer


 Forwarded Message 
Subject: [GitHub] Subscribed to macports/macports-legacy-support
notifications
Date: Wed, 07 Nov 2018 12:47:03 -0800
From: GitHub 
To: rai...@macports.org


Hey there, we’re just writing to let you know that you’ve been
automatically subscribed to a repository on GitHub.

macports/macports-legacy-support
MacPorts support for missing functions in legacy macOS versions
https://github.com/macports/macports-legacy-support

Re: How to resolve a technical conflict

[Rainer Müller]

On 03.11.18 14:27, Perry E. Metzger wrote:
> So an instance of something that hasn't happened much has appeared,
> and I'd like some guidance both on the individual instance and on the
> problem in general.

[...]

> 1. How does one adjudicate this particular dispute?
> 2. How does one adjudicate such disagreements in general?
> 
> At the moment, our process gives a port maintainer absolute say over
> how a port is maintained, but I don't think that's always reasonable.
> However, we have no mechanism for settling a disagreement.

As far as I am aware, we were always able to find a solution that works
for both the maintainer and other developers requesting changes.

I would appreciate if we could try to find a compromise here as well.
As long as the variant is enabled by default, the contents and
functionality of the port will not change. Such a variant should also
not require much, if any, maintenance effort.

Rainer

Re: How do base commits get released?

[Rainer Müller]

In addition to what Ryan already said, let me add a few more pointers.

On 2018-11-02 03:41, George Plymale II wrote:
> Furthermore, upon examining the commits between 2.5.3 and 2.5.4 it is
> apparent that some commits on the master branch are missing:
> https://github.com/macports/macports-base/compare/v2.5.3...v2.5.4

These tags point to commits on the release-2.5 branch. The release
branch is created when master is deemed to be stable. Afterwards,
changes from master will only be backported (with git cherry-pick) to
release branches when we need them in a release, for example bug fixes.

https://github.com/macports/macports-base/tree/release-2.5

> So what's going on? I guess this must be part of Macports' release
> system and only certain commits are picked for release. I can't think of
> any other explanation, at least. Why is this done? How long does it take
> (and what are the criteria) before a base commit is actually released? I
> don't see any documentation describing the release process. I'm glad at
> least to know that my changes were not infected with any heisenbugs, but
> after all this investigation I'd like to know what's going on! Consider
> my curiosity piqued, I guess :)

The release process documentation is kept in the macports-base repository:

https://github.com/macports/macports-base/blob/master/portmgr/ReleaseProcess.md

Rainer

Re: loading checksums table from pre-checksum block?

[Rainer Müller]

On 2018-10-27 09:16, René J.V. Bertin wrote:
> I have a port with lots of subports for which I keep the checksums in a 
> table-like structure in a dedicated file, so as to keep the Portfile a bit 
> more manageable (and to be able to generate said table with a script when 
> it's upgrade time).
> 
> Currently I have an explicit check that tests if the file exists in 
> $filespath before sourcing it, to prevent errors when run from the registry.

Indeed, sourcing additional files is incompatible with storing the
Portfile in the registry. Don't do it.

> Doing it from a pre-checksum block would be more elegant and more efficient, 
> but I cannot seem to figure out how to get the `source` command to apply to 
> the correct context. 
> 
> How should I do that? I tried versions of the below with and without the 
> quotes or the uplevel, none works:

pre-checksum would be run in a deeply nested context inside the port1.0
module. This is an implementation detail and Portfiles should not rely
on that. If you need to modify state outside of the proc, use a "global"
variable.

Rainer