Re: "port upgrade" error message usability

[Andrew Janke]

On 1/30/22 10:16 AM, Julien Salort wrote:

Le 30/01/2022 à 10:30, Andrew Janke a écrit :

I'm the primary maintainer for Octave.app (https://octave-app.org/), 
a "native Mac app" distribution of GNU Octave 
(https://www.gnu.org/software/octave/index), and I'm getting more in 
to MacPorts recently because Octave.app is currently built on 
Homebrew and I'm considering migrating it to MacPorts, because I want 
to continue supporting macOS 10.14 with it. (10.15+ breaks some apps, 
so I want to be able to support the diehards (like me) who are 
sticking with 10.14).) 


That's very interesting. Maybe you will be able to help fix the Octave 
port.


I haven't been able to install it on Monterey. It seems to be a 
linking problem, but the Octave Portfile is too complex for me to try 
and fix it. There are open tickets for this issue, which have been 
opened for nearly a year:


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

also for arm64:

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

The log says:

:info:destroot dyld[24113]: Library not loaded: 
@rpath/libgfortran.5.dylib

[...]


Someone proposed a workaround by manually changing to the actual path, 
and it seems to work. If someone could explain clearly what this 
@rpath thing actually is, and if there is a way to fix it globally, I 
would be interested to know.


Julien

There's a fair chance I can. I've sorted out @rpath stuff on Octave 
builds before, though it's been a while. @rpath is an extra-dynamic 
location mechanism for referencing/locating shared libraries; it stands 
for "relative path" and means to look for the referenced DLL file based 
on a search path that includes locations relative to the current 
filesystem location of the referencing file, evaluated dynamically at 
library load & link time. But I forget the details.


Later this week I'll have a look around for the reference documentation 
that says exactly how it works, and what compiler options control 
whether and how @rpath is used in built binaries. I'm not sure if the 
proper fix here is to replace @rpath with a different referencing style, 
or do something to alter @rpath's search path so it includes the right 
MacPorts-controlled /opt/local subdirs for DLLs.


Cheers,
Andrew

Re: "port upgrade" error message usability

[Andrew Janke]

On 1/30/22 5:12 AM, Ryan Schmidt wrote:

On Jan 30, 2022, at 03:30, Andrew Janke wrote:


All MacPorts commands operate on a Portfile in the current directory if you 
don't specify what ports to operate on.

This was the "implicit knowledge" I was lacking here.

There is admittedly a lot to know, and several different places where things are 
documented (guide, wiki, manpages). This bit is documented in the first paragraph of 
"man port":

port is designed to operate on individual or multiple ports,
optionally within a single call, based on the requested action. If
no action is specified the port command enters shell mode, in which
commands are read via stdin. If no portdir or portname is specified
for an action, the current working directory is assumed. Batch
commands may be passed via a cmdfile. Port options are passed as
key=value pairs and take precedence over individual portname
options as specified in its Portfile and system-wide settings.
That's a perfectly clear explanation of it. Guess I should have spent 
more time reading the overall man page instead of going right to the 
"upgrade" subcommand.

"Could not find Portfile in /Users/janke" isn't too unclear, is it?

IMHO, that would be a nice improvement:

My point was that it already prints that. So I guess you're saying it would be 
clearer if we printed only that and not the other information?


Yep, exactly: the presence of the URL up front in the first line of the 
error message distracted me from the rest of the message and its "no 
portfile found here", and I wasn't sure if the whole thing represented 
one single error message about a single error condition, or if I was 
seeing a sequence of two errors, one about some network/URL thing, and 
then a second one that was some fallout or sequelae of the first.

Maybe we can special-case the situation where no ports are specified and the 
currently directory doesn't contain a Portfile and print something more 
helpful, like:

Error: No ports were specified and the current directory /foo/bar does not 
contain a Portfile
That sounds like a nice improvement to me. IMHO this error message form 
is more concise, yet contains more specifically-relevant info about what 
the error means in the context of this specific attempted operation, and 
seems more readable.

There's no reason to suspect that a user who doesn't specify a port meant to specify the 
pseudoport "outdated". I think it might not necessarily even be known at the 
time that the list of specified ports is processed which command that set of ports will 
be handed to.

Fair enough. That might be an assumption I'm bringing with me from the Homebrew 
world.

What I mean is: the user might have typed "port info" or "port uninstall" or any other 
port command. "outdated" is not a reasonable default (or reasonable suggested value) for each of 
the commands. If you're saying that different port commands should have different suggested values when no 
port is specified, then we would have to decide what each of those would be and see if the code that prints 
the error message has access to the information about which command is being run.
Ah. Yeah, this current behavior seems sensible them; switching to a 
per-command default sounds like both a lot of work, and a 
possibly-breaking user-visible behavior change.


Cheers,
Andrew

Re: "port upgrade" error message usability

[Andrew Janke]

On 1/30/22 4:04 AM, Ryan Schmidt wrote:

On Jan 30, 2022, at 02:24, Andrew Janke wrote:


Hi, MacPorts developers,

Long-time Homebrew user and recent MacPorts convert here.

Welcome! I'm interested in your impressions of MacPorts as a Homebrew user and 
if you have any suggestions for changes we can make to make your MacPorts 
experience more enjoyable.


Thanks!

I've been lurking on MacPorts for a while, and my general impressions 
are that MacPorts is the more "pro" product: more functionality and 
customizability, and better commitment to back-compatibility and 
long-term support. But the tools are less user-friendly and less "fun" 
(where's my beer emojis?), and portfiles are a bit harder to work with 
that Homebrew formula files (not without reason, from what I can tell). 
(I'm not just a Homebrew user; I was one of the core Homebrew 
maintainers for a few years.)


I'm the primary maintainer for Octave.app (https://octave-app.org/), a 
"native Mac app" distribution of GNU Octave 
(https://www.gnu.org/software/octave/index), and I'm getting more in to 
MacPorts recently because Octave.app is currently built on Homebrew and 
I'm considering migrating it to MacPorts, because I want to continue 
supporting macOS 10.14 with it. (10.15+ breaks some apps, so I want to 
be able to support the diehards (like me) who are sticking with 10.14).)


>  All MacPorts commands operate on a Portfile in the current directory 
if you don't specify what ports to operate on.


This was the "implicit knowledge" I was lacking here.

> "Could not find Portfile in /Users/janke" isn't too unclear, is it?

IMHO, that would be a nice improvement: when I'm working with the `port` 
command in a shell, I'm thinking in terms of port names and maybe local 
files; a local filesystem path is more comprehensible to me than a URL 
(even if it's a "file://..." URL; in theory I know what that means, but 
maybe not all users will, and just seeing it in URL instead of local 
file paths kinda throws me off, because that makes me think it's doing 
some networking thing that I don't understand).

There's no reason to suspect that a user who doesn't specify a port meant to specify the 
pseudoport "outdated". I think it might not necessarily even be known at the 
time that the list of specified ports is processed which command that set of ports will 
be handed to.
Fair enough. That might be an assumption I'm bringing with me from the 
Homebrew world.


Cheers,
andrew

Re: "port upgrade" error message usability

[Andrew Janke]

On 1/30/22 4:04 AM, Ryan Schmidt wrote:

On Jan 30, 2022, at 02:24, Andrew Janke wrote:


Hi, MacPorts developers,

Long-time Homebrew user and recent MacPorts convert here.

Welcome! I'm interested in your impressions of MacPorts as a Homebrew user and 
if you have any suggestions for changes we can make to make your MacPorts 
experience more enjoyable.


Thanks!
> "Could not find Portfile in /Users/janke" isn't too unclear, is it?

IMHO, that would be a big improvement:

There's no reason to suspect that a user who doesn't specify a port meant to specify the 
pseudoport "outdated". I think it might not necessarily even be known at the 
time that the list of specified ports is processed which command that set of ports will 
be handed to.

"port upgrade" error message usability

[Andrew Janke]

Hi, MacPorts developers,

Long-time Homebrew user and recent MacPorts convert here.

Minor usability issue with the `port` program, I think: I suspect that a 
common operation for regular MacPorts users to do is "upgrade all my 
stuff to the latest version".


I tried doing this with `port selfupdate`; `port upgrade`, and got this 
error message:


[~] $ sudo port selfupdate
--->  Updating MacPorts base sources using rsync
MacPorts base version 2.7.1 installed,
MacPorts base version 2.7.1 downloaded.
--->  Updating the ports tree
--->  MacPorts base is already the latest version

The ports tree has been updated. To upgrade your installed ports, you 
should run

  port upgrade outdated
[~] $ sudo port upgrade
Can't map the URL 'file://.' to a port description file ("Could not find 
Portfile in /Users/janke").

Please verify that the directory and portfile syntax are correct.
To use the current port, you must be in a port's directory.
[~] $

I'm a dev with 25 years of coding and sysadmin experience, and I don't 
know what to do with that error message. I dunno what a regular user is 
supposed to do with that. (Yes, I saw the "To upgrade your installed 
ports" output from the selfupdate command, but still.)


Maybe the error message here could be modified to include a "maybe you 
meant `port upgrade outdated`" message or something like that? Where's 
the 'file://'" coming from, anyway? Does `port upgrade` operate on some 
port definition found in the current working directory by default? I did 
not provide a URL as an input to the `port upgrade` command, so it's a 
little unexpected that I got an error complaining about a URL here.


Cheers,
Andrew

Re: Help wanted from Mojave users

[Andrew Janke]

On 5/23/21 1:15 AM, Joshua Root wrote:
> On 2021-5-23 14:53 , Andrew Janke wrote:
>>
>> I have a 10.14.6 VM running Xcode 11.3.1 prepped to test this; results
>> coming soon.
>
> Thank you.
>
>> Minor issue while trying to find a MacPorts 2.6.4 installer: The "our
>> packaged downloads" link in the "Installing MacPorts" section of
>> https://www.macports.org/install.php, pointing to
>> https://github.com/macports/macports-base/releases/download/v2.7.0/, is
>> 404. Is this just because the 2.7.0 release has been yanked or
>> something? Or maybe GitHub has changed the URL pattern here?
>
> Fixed, thanks for pointing it out. 2.7.0 has not been yanked (the
> binary installer for 10.14 was built against the 10.14 SDK and so
> doesn't suffer from the issue.)
>
> - Josh
I think my test was successful; please see Trac for details. Please let
me know if I need to change the test process at all; this is my first
time installing MacPorts from source.

Cheers,
Andrew

Re: Help wanted from Mojave users

[Andrew Janke]

On 5/22/21 11:08 PM, Joshua Root wrote:
> Could someone with a 10.14 system running an Xcode version that
> defaults to building against the 10.15 SDK please try installing the
> tip of the release-2.7 branch on top of a MacPorts 2.6.4 installation?
> Report the results in the comments here:
> 
>
> A speculative fix has been checked in, but it has yet to be confirmed
> to fix the issue by someone who experienced it "in the wild". I'd like
> to get a new release with the fix onto rsync ASAP so nobody else
> selfupdates to a broken state, but confirmation of the fix is needed
> first.
>
> - Josh

I have a 10.14.6 VM running Xcode 11.3.1 prepped to test this; results
coming soon.

Minor issue while trying to find a MacPorts 2.6.4 installer: The "our
packaged downloads" link in the "Installing MacPorts" section of
https://www.macports.org/install.php, pointing to
https://github.com/macports/macports-base/releases/download/v2.7.0/, is
404. Is this just because the 2.7.0 release has been yanked or
something? Or maybe GitHub has changed the URL pattern here?

I think I found the 2.6.4 installer by going to
https://github.com/macports/macports-base/releases/ instead.

Cheers,
Andrew

Re: Freenode IRC

[Andrew Janke]

On 5/19/21 2:44 PM, Rainer Müller wrote:

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


I agree: running ZNC yourself is for advanced users, and is a barrier to 
entry. Having this stuff out of the box for all users is better.


Cheers,
Andrew

Re: Freenode IRC

[Andrew Janke]

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.


Cheers,
Andrew

On 5/19/21 2:02 PM, Mark Anderson wrote:
I think I favor option B. But I don't have to maintain it. I would 
prefer not to go to something like slack, but one of the more modern 
IRC replacements when I can at least read history is nice. So rocket 
chat? Or gitter?


—Mark
___
Mark E. Anderson mailto:m...@macports.org>>
MacPorts Trac WikiPage 
GitHub Profile 



On Wed, May 19, 2021 at 1:58 PM Rainer Müller > wrote:


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: Framing the MacPorts discussion

[Andrew Janke]

I have a small stack of Mac Minis I got to use as a buildbot farm for 
Octave.app; I might be able to have them pull double duty for MacPorts 
depending on your change volume.


Cheers,
Andrew

On 5/19/21 1:16 PM, Mark Anderson wrote:
Yeah - we are certainly short staffed everywhere - I try to add more 
and more of my time to the project but aside from my ports, I'm still 
in learning mode digging through all the asciidoc and tcl and 
everything. I'm trying to build some tools to help me, but again, more 
time.


Once we move to the latest build bot, we might want to see if we can 
get other volunteers to host some hardware, but the problem is, we're 
going to have to hit up ebay or something and the infrastructure will 
be tougher.


I'm honestly not sure how we can manage to staff up more at all - I 
mean this is a FOSS problem all over for non-company sponsored projects.


—Mark
___
Mark E. Anderson mailto:m...@macports.org>>
MacPorts Trac WikiPage 
GitHub Profile 



On Tue, May 18, 2021 at 2:35 AM Ryan Schmidt > wrote:


MacPorts is short-staffed in all areas, not just infrastructure.

Our Buildbot system works. It produces all the binaries we are
able to.

Our buildbot system was already substantially redesigned when we
took it over from Apple in 2016 and will be substantially
redesigned again as we upgrade to the latest version of the
buildbot software.

We already have a small infrastructure team who are interested in
working on improving the buildbot system and our other
infrastructure, and do so.

We already use GitHub Actions for CI. We cannot use it to replace
buildbot because it only offers recent OS versions and because it
does not offer persistent machines.

I personally am not comfortable adding other build machines to our
buildbot system that I do not control. When I control the
machines, I know what is installed on them and that they are set
up correctly. Having build machines located outside of my local
network also poses additional challenges, as I've learned by
having our Apple Silicon build machine outside of my network,
challenges which I would prefer to minimize, not increase.

We currently use one build machine per OS version / arch, and have
the hardware needed to do that. Adding more hardware such that we
have more than one build machine per OS version / arch is not
something our buildbot system was ever designed to accommodate,
and would introduce problems.

Using Linux and commodity hardware is not applicable because it
the macOS EULA only permits running macOS on Apple hardware, as we
currently do.

Re: Becoming a legal entity and accepting donations (was: Re: Buildbot Performance)

[Andrew Janke]

Software Freedom Conservancy exists largely to help FLOSS orgs do this
sort of thing safely and conveniently, while retaining independent
governance. I believe Homebrew had a good experience with them, and
Buildbot itself is a member. Was that one of the options considered when
this question came up before?

https://sfconservancy.org/

Amazon AWS supports FLOSS projects by providing free AWS Promotional
Credits to FLOSS projects. It looks like you could maybe use these to
buy mac1.metal EC2 instances, and that would give you full-machine root
access. But I dunno; those are expensive instances and the provisioning
level and conversion process seems a little complicated. The AWS
mac1.metal VMs are Intel-based, not Apple Silicon.

https://aws.amazon.com/blogs/opensource/aws-promotional-credits-open-source-projects/

I dunno how much credits Amazon would want to give you, but MacPorts is
a name with some pull, and Amazon has deep pockets. Couldn't hurt to ask?

Cheers,
Andrew

On 5/17/21 8:22 PM, Mark Anderson wrote:
> Yeah, I was thinking of the US as well, and I meant non-profit, which
> doesn't have tax deductible donations but is assumed to not make
> money. The problem is there is a lot of work around becoming a legal
> entity and accepting donations or whatever. I honestly have no idea
> how much work exactly - but certainly not zero. I have no idea how
> non-US entities work.
>
> —Mark
> ___
> Mark E. Anderson mailto:m...@macports.org>>
> MacPorts Trac WikiPage 
> GitHub Profile 
>
>
>
> On Mon, May 17, 2021 at 2:02 AM Ryan Schmidt  > wrote:
>
> On May 16, 2021, at 14:46, Mark Anderson wrote:
>
> > I keep wondering if we became like a not-for-profit If we could
> get someone like MacStadium or Amazon or something to donate
> server time to us. Or accept donations from Github sponsorship. I
> could look into what that would take, although it might be way
> more trouble than it's worth. I think my current corp lawyer knows
> non-profit law - I could bring it up next time I see them.
>
> MacStadium already donates the use of an Apple Silicon Mac mini to
> us. I am not aware of whether Amazon offers free persistent Mac
> servers with root access to open source projects.
>
> Accepting donations through GitHub Sponsors or any other means
> would, I suspect, require the formation of a legal entity for
> MacPorts, which would be the owner of the business bank account we
> would probably have to open. We've discussed becoming a legal
> entity a few times over the years but it hasn't been done. If we
> do it, my preference would be for MacPorts to be a U.S. entity,
> since I am in the U.S. and since MacPorts was started by Apple and
> is for the benefit of Apple users and Apple is a U.S. company. A
> different suggestion was that we should join an existing free
> software organization and leave all the legalities up to them, and
> funnel donations through them. I don't think that idea was
> supported by everyone so that didn't happen either.
>
> If we accepted donations, we would have to develop guidelines for
> how the donations could be spent.
>
> Being recognized as a not-for-profit is a whole 'nother can of
> worms. First one has to form a legal entity, then one has to apply
> to be recognized as a not-for-profit (which incurs additional
> fees) and make a case for why that should be, a process which can
> take years, and the answer to the application could be no. For
> example there was increased scrutiny of non-profit organization
> applications in the field of open source software in 2010; see
> https://opensource.org/node/840 .
> That's what I recall from researching the process in the U.S. It
> may differ in other countries.
>

Re: Homebrew Disables OSXFuse ports

[Andrew Janke]

On 5/17/21 1:44 AM, Ryan Schmidt wrote:
> On May 16, 2021, at 21:49, Mark Anderson wrote:
>
>> Given some of our recent back and forth, I found this interesting: 
>> https://github.com/Homebrew/homebrew-core/pull/74812
> Meh. They have different priorities than we do. No reason for us to follow 
> what they do.
>

+1 to this. I'm a sometimes user of some of these OSXFuse-using
projects, and would like to see them continue to be supported in some
package manager.

Cheers,
Andrew

Re: Publicizing MacPorts

[Andrew Janke]

On 4/19/21 3:54 PM, Craig Treleaven wrote:
>
>> On Apr 19, 2021, at 2:51 PM, Jason Liu > > wrote:
>>
>> On Mon, Apr 19, 2021 at 1:25 PM Craig Treleaven > > wrote:
>>
>> Also, why should we consider that MacPorts is in competition with
>> Homebrew?  Both MacPorts and Homebrew seem to have a sufficient
>> number of contributors to keep going for the foreseeable future. 
>> Nether packaging system has to "win" nor does the other have to
>> "lose".  The projects do have differing philosophies that may
>> make one more suitable than the other for particular users.
>>
>>
>> Although this is a nice sentiment, I believe the reality is that
>> MacPorts is in fact in competition with Homebrew. And not just
>> Homebrew, but with other package managers as well, such as Munki, and
>> even to some extent other deployment products such as Jamf/Casper and
>> Jenkins. My belief is that the total number of systems running macOS
>> as its operating system is the entire "pie" of systems that could
>> potentially use one of these macOS package managers. In addition, the
>> vast majority of users will only use one package management product,
>> hence my opinion of why it's a pie with a limited number of potential
>> users that gets divided up. The possible exception to only using one
>> product per machine might be, say, in an enterprise setting (you can
>> read my personal anecdote below for an example).
>>
>> In addition, it has traditionally been the case that package
>> management systems say on their websites that installing multiple
>> package managers on one machine can cause problems... e.g. MacPorts
>> doesn't work well with Fink and Homebrew, Homebrew doesn't work well
>> with Fink and MacPorts, etc. People on this mailing list are tech
>> savvy enough to deal with the potential conflicts that might occur
>> regarding environment variables, $PATH order, etc. but the vast
>> majority of users won't be, and thus would stick to using only one
>> package manager. If one product "wins" by getting installed on a
>> particular system, then the others "lose”.
>>
>
> I wasn’t trying to suggest that a user should install multiple package
> managers.
>
> MacPorts needs contributors and maintainers to go forward.  We don’t
> _need_ users!  It is the same amount of work to create or update a
> package regardless of the number of users.  Several of the packages I
> maintain have very few reported users…sometimes only me.  
>
> As long has we have a decent volume of people contributing to MacPorts
> the project will continue.  As a port maintainer, it is gratifying to
> think that my work may be benefiting others.  It is not that important
> whether it is 10 people or 10,000.  I think that many of our
> maintainers do so because they need the ports that they are working
> on.  IOW, they’d do so even if there were no other users.  Obviously,
> several of our most prolific maintainers have different motivations.
That would be my concern here. Keep the project alive with an active
maintainer community. But I'm a bit different; I want to do work on
projects that are visible and actively helping users; that's (partially)
how I decide where to put my time.
> To be cynical, I think Homebrew users are more commonly command line
> newbies and therefore probably generate a high volume of simple and
> repetitive questions.   AKA ’support desk hell’!  Perhaps we are
> fortunate that MacPorts users tend to be a little more savvy.  ;)
Speaking as a former Homebrew core maintainer – not actually the case!
We got almost no 101-level support requests; Google and StackOverflow
take care of those just fine. The majority of requests coming in to
Homebrew are actually PRs to bump versions on packages (a significant
number of Homebrew users like to be contributors too, and there's almost
a competition to get to new package releases first), and most of the
rest are semi-obscure build and linkage problems, problems with macOS's
System Integrity Protection stuff, or legit workflow issues with the tools.

Though I agree that MacPorts is definitely the "pro" product in this
area, so I expect its users are even more savvy.

Cheers,
Andrew

Octave port: website search results, 6.2.0, and Tablicious

[Andrew Janke]

Hi, MacPorts maintainers,

First off, thanks for all your hard work!

Couple questions about your Octave port.

Octave 6.2.0 is out; released on Feb 20. Looking at 
https://ports.macports.org/port/octave/summary, it seems like the 
MacPorts port is still on 6.1.0. When can we expect it to update to 
6.2.0? Anything I can do to help out with that process? I ask because we 
just had a user ask on the octave-maintainers list about a 
build-from-source issue with 6.2.0 from source on Mac in a MacPorts 
environment, and I would really like to be able to tell them "just 
install the official port!".


Question 2: When I go to https://ports.macports.org/ and type "octave" 
in the "Search Ports" field, leaving the radio button on "Search by 
port-name" and hit enter, it brings up results for all the octave-* 
add-on packages, but not the octave port itself. What's up with that?


Question 3: I was going to ask you about getting my Tablicious package 
in to MacPorts even though it's not an official Octave Forge package, 
but oh, wow, it's already there! 
https://ports.macports.org/port/octave-tablicious  – Is there anything I 
can do as a package maintainer to make it easier to produce a quality 
port here? And out of curiosity, how did you find Tablicious in the 
first place? It's not exactly in common use (yet!).


The Homepage listed for Tablicious in its port description is incorrect. 
It's not https://octave.sourceforge.io/tablicious/, because Tablicious 
is not in Octave Forge (yet). The Homepage is currently just the GitHub 
repo, https://github.com/apjanke/octave-tablicious. (If a GitHub repo 
isn't acceptable for this, let me know and I'll whip up a proper little 
web site for it.)


Cheers,
Andrew

Re: Desolate Condition

[Andrew Janke]

On 1/26/21 9:41 PM, Craig Treleaven wrote:
> I have used MacPorts to package a substantial application (MythTV).  As an 
> overview, MythTV and all its dependencies were installed to a custom prefix 
> (/opt/dvr)*.  A couple of helper apps (Applescripts, if you want the full 
> truth) are the only things installed under /Applications/MacPorts/MythTV.  
> The package installer recreates this layout on the destination machine.  I 
> don’t see why you couldn’t continue with your current layout, however.
>
> MacPorts provides support to create a standard package installer (port mpkg) 
> or dmg (port mdmg).  See man port-mpkg for the basics.  If it helps, I wrote 
> a wiki page with a few of the issues that I encountered:
>
> https://trac.macports.org/wiki/howto/CreateInstallers

Cool, thanks! I think this will be helpful.

> Ping me if you have questions.
>
> Craig
> * In a custom prefix, _everything_ has to be built from source.  The initial 
> build will take a _long_ time.  A very long time.

Ohh, I'm used to that. As a packager I'm okay with eating that build time.

Cheers,
Andrew

Re: Desolate Condition

[Andrew Janke]

On 1/26/21 3:50 PM, Nils Breunese wrote:
> 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.
> I think it’s a great idea to always send pull requests to update upstream 
> docs and readme files with installation instructions for MacPorts when you 
> start maintaining a port. So, to all maintainers: take a look at the ports 
> you maintain and whether the upstream docs and readme have installation 
> instructions for MacPorts.
>
> Nils.

Possibly relevant: I'm co-maintainer of Octave.app, a "native" Mac app
distribution of GNU Octave (https://octave-app.org/). It's currently
built on top of Homebrew.

I'm tentatively planning on migrating Octave.app to be built on top of
MacPorts in the near future. Partially because I think MacPorts is a
more stable, configurable, "pro" tool more suitable to building
redistributable apps (which is explicitly not supported by Homebrew),
but mostly because I refuse to upgrade from macOS 10.14 (because I'm an
Aperture user) and Homebrew's going to drop support for 10.14.

The way this thing works is that I set up a whole Homebrew installation
under a custom prefix at "/Applications/Octave-.app" and then
wrap that up as an app bundle.

Do y'all have any advice for me?

If this transition happens, a "Powered by MacPorts!" banner goes on the
bottom of our website. I have absolutely no clue how many users we have,
but I know that at least a couple hundred European college students
along with some scientists in the US are using it.

Cheers,
Andrew

Re: Desolate Condition

[Andrew Janke]

I didn't know that! I must be behind the times with the state of
MacPorts. Thanks for the update.

Cheers,
Andrew

On 1/26/21 10:54 AM, Marius Schamschula wrote:
> Andrew,
>
> MacPorts provides pre-built packages for more macOS versions than
> Homebrew.
>
> However, MacPorts is very careful not to provide packages where the
> upstream license prohibits us from doing so.
>
> Other pre-built packages are not provided if they depend on said
> packages to be build by our buildbots.
>
> Installing on my Mac using MacPorts is much faster than on my servers
> under FreeBSD where everything literally has to be build locally, as
> pre-built packages may be up three months out of date.
>
>> On Jan 26, 2021, at 9:40 AM, Andrew Janke > <mailto:fl...@apjanke.net>> wrote:
>>
>>
>>
>> On 1/26/21 10:12 AM, Christopher Nielsen wrote:
>>>> /Ken Cunningham wrote:
>>>> /
>>>> homebrew is in shambles.
>>>>
>>>> their long-touted "no-sudo" and "no PATH" advantage from installing
>>>> into /usr/local has been eliminated by Apple as the horrible
>>>> security threat it always was. They have to retool into
>>>> /opt/homebrew and make 10,000 builds respect the build args now.
>>>>
>>>> They stripped out all their universal handling code a few years
>>>> ago, can't put it back, and so can't do the critical universal
>>>> builds any more. They tell everyone universal is wasteful, lipo
>>>> things manually, and run the x86_64 homebrew on Apple Silicon.
>>>>
>>>> So MacPorts, which works great from 10.4 PPC to 11.x arm64, is the
>>>> place to be.
>>>
>>> Personnally, I’ve never actually tried HomeBrew, as I didn’t want
>>> anything installed into core OS areas. And after choosing  MacPorts
>>> years ago - 10+ at this point? - I’ve always been very happy with
>>> the experience. Enough so that I’m finally giving back, as a
>>> contributor!
>>>
>>> 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.
>>>
>>> Thoughts?
>>
>> Hi! Long-time user of both Homebrew and MacPorts here; former
>> Homebrew maintainer.
>>
>> It's definitely a PR issue; Homebrew is winning on that front.
>>
>> IMHO, the other thing is that Homebrew is /fun/ to use and accessible
>> to less-technical users. Friendlier command output, low-jargon
>> documentation, sense of humor, fun emojis. MacPorts feels like more
>> of a "pro" thing and serious sysadmin tool, and its command output
>> can be kind of technical and intimidating. I think the Homebrew
>> approach is attractive to a lot of general Mac users, especially
>> those approaching a package manager for the first time.
>>
>> Another big thing is that Homebrew ships binaries for everything, so
>> you can do a full Homebrew install of a big toolchain in just a few
>> minutes, where it might take hours to compile. MacPorts still builds
>> everything from source, right?
>>
>> Those are the reasons I always recommend Homebrew to new Mac package
>> manager users, even though I think both are good tools.
>>
>> Cheers,
>> Andrew
>

Re: Desolate Condition

[Andrew Janke]

On 1/26/21 10:12 AM, Christopher Nielsen wrote:
>> /Ken Cunningham wrote:
>> /
>> homebrew is in shambles.
>>
>> their long-touted "no-sudo" and "no PATH" advantage from installing
>> into /usr/local has been eliminated by Apple as the horrible security
>> threat it always was. They have to retool into /opt/homebrew and make
>> 10,000 builds respect the build args now.
>>
>> They stripped out all their universal handling code a few years ago,
>> can't put it back, and so can't do the critical universal builds any
>> more. They tell everyone universal is wasteful, lipo things manually,
>> and run the x86_64 homebrew on Apple Silicon.
>>
>> So MacPorts, which works great from 10.4 PPC to 11.x arm64, is the
>> place to be.
>
> Personnally, I’ve never actually tried HomeBrew, as I didn’t want
> anything installed into core OS areas. And after choosing  MacPorts
> years ago - 10+ at this point? - I’ve always been very happy with the
> experience. Enough so that I’m finally giving back, as a contributor!
>
> 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.
>
> Thoughts?

Hi! Long-time user of both Homebrew and MacPorts here; former Homebrew
maintainer.

It's definitely a PR issue; Homebrew is winning on that front.

IMHO, the other thing is that Homebrew is /fun/ to use and accessible to
less-technical users. Friendlier command output, low-jargon
documentation, sense of humor, fun emojis. MacPorts feels like more of a
"pro" thing and serious sysadmin tool, and its command output can be
kind of technical and intimidating. I think the Homebrew approach is
attractive to a lot of general Mac users, especially those approaching a
package manager for the first time.

Another big thing is that Homebrew ships binaries for everything, so you
can do a full Homebrew install of a big toolchain in just a few minutes,
where it might take hours to compile. MacPorts still builds everything
from source, right?

Those are the reasons I always recommend Homebrew to new Mac package
manager users, even though I think both are good tools.

Cheers,
Andrew

Re: Can we enable CI for legacy systems?

[Andrew Janke]

On 1/25/21 10:31 AM, Ryan Schmidt wrote:
> On Jan 25, 2021, at 01:55, Joshua Root wrote:
>
>> On 2021-1-25 18:48 , Andrew Janke wrote:
>>> How do you download the installers for Big Sur and for older versions of 
>>> macOS? I've always had to go through the App Store to download installers, 
>>> and what it makes available for me is dependent on the current OS version 
>>> and hardware of my Mac. And half the time, when I try to create a new VM 
>>> using an old version's installer, the installer process tells me "This 
>>> installer has been damaged" and refuses to continue. (This happens on 
>>> installer copies that had worked in the past. I assume it's some sort of 
>>> certificate problem.)
>>> I ask because I've been trying to set up a VM-based build farm for Octave 
>>> and Octave.app (https://octave-app.org/) and not having much luck.
>> Recent versions can be downloaded here: 
>> <https://support.apple.com/en-au/HT211683>
>>
>> The rest are available at <https://developer.apple.com/download/more/>.
> OS versions are only available in the developer download area for paid Apple 
> developer program members. Free Apple developer program members can't access 
> OS installers there and should use the support article above (to download 
> 10.10 or later) or the Purchased tab of the Mac App Store (to download 
> 10.7-10.9). Only older OS installers that you previously downloaded from the 
> Mac App Store will be in the Purchased tab.
>
> Apple redesigned how the App Store works in macOS Mojave, so there can indeed 
> be some difference in the what you get from the App Store depending on 
> whether you download on 10.14-or-later or 10.13-or-earlier.
>
> The certificate Apple used to sign its installer packages expired October 24, 
> 2019. Any Apple installers for the OS or anything else that you may have 
> saved that were signed with that certificate are now unusable. Throw them out 
> and download new versions of those installers now; most of them have been 
> re-posted signed with newer certificates.
>
Ah, that explains it. Guess I'll re-up my Developer membership...

Andrew

Re: Can we enable CI for legacy systems?

[Andrew Janke]

Hi Ken,

On 1/24/21 11:34 PM, Ken Cunningham wrote:
>> I try to fix build issues on old systems. The problem is that it’s very 
>> difficult to
>> do it since I need to merge blindly something and wait for the buildbots.
> If you would like to set up a VM or several to help do this, it is
> very easy, I found.
>
> I like Parallels, and it does VMs from 10.5 to BigSur on my 2010
> MacPro 5,1 running Mojave.
>
> I put them all on one 1TB SSD.
>
> All the systems from 10.7 to BigSur are available free from Apple, as
> are the Xcode setups, the documentation, and the command line tools.
>

How do you download the installers for Big Sur and for older versions of
macOS? I've always had to go through the App Store to download
installers, and what it makes available for me is dependent on the
current OS version and hardware of my Mac. And half the time, when I try
to create a new VM using an old version's installer, the installer
process tells me "This installer has been damaged" and refuses to
continue. (This happens on installer copies that had worked in the past.
I assume it's some sort of certificate problem.)

I ask because I've been trying to set up a VM-based build farm for
Octave and Octave.app (https://octave-app.org/) and not having much luck.

Cheers,
Andrew

Re: Hardcoding Xcode.app

[Andrew Janke]

Just one data point here, but as a sometimes Mac developer, I need to 
have multiple versions of Xcode installed side-by-side, and always 
rename them to Xcode-.app; there's no /Applications/Xcode.app 
on my boxes. This isn't a standard thing, so on my system, `xcode-select 
-p` is the only reliable way of locating my Xcodes. I think other devs 
from the Homebrew side do the same thing, so you may have users in a 
similar situation too.


I believe that calling `xcode-select -p` is the standard system-provided 
way of locating Xcode and/or its related toolchain.


Cheers,
Andrew

On 10/9/20 3:58 PM, Christopher Chavez wrote:

Can MacPorts hardcode references to Xcode.app, by assuming it is at 
/Applications/Xcode.app (as when installed from the App Store), and/or that it 
will remain wherever it was found and won't ever be moved/deleted?

I would think the answer is "no": it is outside of MacPorts' control, and some 
users have reason to switch between multiple installed Xcode versions.

See https://trac.macports.org/ticket/58378#comment:7 . I think I have come 
across other instances of this issue, but can't remember where.


Christopher A. Chavez

Re: Call for designers for our ports website

[Andrew Janke]

Hi y'all,

I was a core Homebrew maintainer at the time they added analytics. Just
want to say that Saagar is right; there were a *lot* of Homebrew users
who did in fact have a problem with it.

Cheers,
Andrwe


On 6/12/20 9:03 PM, Saagar Jha wrote:
> I believe the lack of change there is almost certainly a matter of the 
> project’s personal stance rather than “nobody having a problem with it”. In 
> fact, after the change was merged in there was a fairly long discussion about 
> first disclosing that there were analytics collected at all (which did 
> eventually get implemented) and then switching off of Google Analytics or 
> making it opt-in, which weren’t. Actually, there were multiple discussions 
> but they like the original were generally closed as “WONTFIX” and this has 
> been the policy to this day.
>
> Personally, I would be fairly disappointed if MacPorts went opt-in as such 
> policies suffer from statistical issues in addition to the obvious 
> privacy-related ones.
>
> Saagar Jha
>
>> On Jun 12, 2020, at 16:48, Ken Cunningham  
>> wrote:
>>
>> Just FYI Homebrew has always been opt-out for stats. Nobody seems to have a 
>> problem with that sufficient to make them change that policy.
>>
>> We'll never know if that is why they seem to have 10 x the users on their 
>> stats page.
>>
>> K

Re: Default language for GIMP installed by MacPorts

[Andrew Janke]

On 10/3/19 8:00 PM, Thomas R. Murphy wrote:
> Hello Macports Dev,
>
> I just got around to trying to use my MacPorts intstall of GIMP (gimp
> @2.10.12_0) and encountered the slight difficulty of it starting in
> Arabic using the default "system language" setting. I started it from
> the command line with export LANG=en_US.UTF-8 and switched it to default
> to en_US. My system language settings are "English (US) — Primary" with
> a customized region (for my desired date/time formatting) with Arabic,
> Khmer, and Urdu as alternates in that order (from who knows what
> keyboard fooling around I tried). Any idea what caused GIMP to skip down
> to my second language?
>
I suspect this has to do with how the GNU gettext internationalization
library is being used by GIMP. I've seen this happen with other programs.

gettext uses the following priorities for choosing a localized translation:

1. A localized translation in your primary language
2. A localized translation in one of your alternate languages, in
priority order
3. The original language of the program text

Probably what is happening is that GIMP provides localized translation
files for one or more languages in your alternate language list, but
does not define an English localization translation file (instead
relying on the fallback behavior to get English). In that case, gettext
will find that alternate-language localization in step 2, and it will
take precedence over the default-language fallback of English.

This could be fixed at the GIMP level by having it provide a dummy empty
localization file for English, which would be matched to your primary
language in step 1. Alternately, your $LANG workaround is effective.

Cheers,
Andrew

Re: Octave 5.x on MacPorts

[Andrew Janke]

On 5/13/19 1:45 AM, Joshua Root wrote:
> On 2019-5-13 08:40 , Andrew Janke wrote:
>> Would you be willing to do something to improve the situation on
>> MacPorts? As things stand right now, I don't think MacPorts is shipping
>> a usable GUI-mode Octave. And there are GUI-mode users out there. This
>> could include:
>>
>> * Adding an Octave 4.4.x port alongside the main Octave 5.x port
> 
> This seems reasonable, though to be fully functional there would also
> need to be Octave 4 subports of all the octave-* module ports, which may
> also need to be older versions. Please file a ticket (or even better, a
> PR making the necessary changes) and Cc the MacPorts Octave maintainer
> MarcusCalhoun-Lopez.

Right. Would want all those modules, too.

I will attempt to make a PR, including all the octave-* modules. Given
that I'm new to MacPorts, this will probably take me several days, so
please be patient. Thanks for your openness to this request.

Cheers,
Andrew

Octave 5.x on MacPorts

[Andrew Janke]

Hi, MacPorts devs,

I'm a GNU Octave user and co-maintainer of Octave.app, a "Mac native"
distribution of Octave. I'd like to discuss the situation for the
current version of Octave on MacPorts.

MacPorts currently provides Octave 5.x.

Octave runs in two modes: GUI and CLI (a terminal application). Both
work fine in Octave 4.4.x, but with Octave 5.1.0, the GUI mode has
developed significant stability issues on Mac specifically. It freezes
frequently, often upon initial application startup. It's bad enough that
the Octave 5.1 GUI is pretty unusable on Mac.

This seems to be an issue with Octave itself, and not particular
packaging or distribution mechanisms. It affects Octave.app,
Homebrew-installed Octave, and Octave built manually from source. I've
tested it using a MacPorts installation, and that seems to have the same
stability problems.

Here are upstream/sidestream bug reports for this, for reference:

GNU Octave: https://savannah.gnu.org/bugs/?56270
Octave.app: https://github.com/octave-app/octave-app/issues/24

In Octave.app, we're tentatively planning to continue shipping Octave
4.4.1 as our GUI-mode Octave, and ship a CLI-only version of Octave 5.1.
It's not a trivial bug, so we don't expect it to be resolved upstream
any time soon.

Would you be willing to do something to improve the situation on
MacPorts? As things stand right now, I don't think MacPorts is shipping
a usable GUI-mode Octave. And there are GUI-mode users out there. This
could include:

* Adding an Octave 4.4.x port alongside the main Octave 5.x port
* Adding an option or default to build Octave 5.x against Qt 5.11
instead of Qt 5.12 (which seems to improve, but not fully fix, the problem)
* ??? other ideas your Octave port maintainers have ???

Cheers,
Andrew Janke

Re: Slack-like chat (also for GSOC)

[Andrew Janke]

On 5/12/19 3:49 PM, Mojca Miklavec wrote:
> I looked at Zulip chat which was used for GSOC meeting. That one would
> also only retain the last few thousand messages unless we payed an
> amount that we could not afford as a project.
> Mattermost probably doesn't offer any free SaaS option?
> Discord would probably work as a free service, but I'm not too keen about it.
> 
> I wouldn't mind cloud solutions, but it probably boils down to either
> paying, or being limited by X, or hosting it yourself.

You might consider Matrix as a first candidate, then? I've been playing
around with the various Slack clones for my own group recently, and my
understanding is that the free hosted SaaS version of Matrix on
matrix.org both retains all messages permanently, and has a good
migration path if and when you decide to host your own Matrix instance:
when users on your own instance ("homeserver") join Rooms originated on
the matrix.org instance, that will cause propagation of the entire Room
history to your server. You just need to make sure you configure the
room so that all members can see the entire room history, not just since
they joined; I don't recall if that's the default. If you configure it
so that all members can see the entire history of the room, you then
have a public archive.

And Matrix seems to be the open source-iest of this crop of clones.
They're all about the open federated protocol, which is being developed
in public and ostensibly to be handed over to an independent foundation
eventually, and then provide an open-source client on top of that.

> Mattermost probably doesn't offer any free SaaS option?

Mattermost only offers a free 30-day trial for their SaaS option. Their
model is really more about self-hosting, and selling a hosting service.

Cheers,
Andrew