Getting MacPorts logo into font-linux

[Mojca Miklavec]

Hi,

While trying to get MacPorts listed as a source for some software, it
turned out that I would likely need to display its logo in a
consistent way compared to other distributions.

Do you think it would be feasible to get our logo (potentially the
"MP" one) added to
https://github.com/lukas-w/font-logos/tree/master/vectors
?

I have re-created the logo from scratch once (in TeX, using the
correct font), so I should be able to get the small one drawn into SVG
as well. Or do we perhaps have some official source for the logotype?

Thank you,
Mojca

Re: Weird outdated state of ports (in webapp)

[Mojca Miklavec]

Hi,

I'm sorry, please ignore my question.

I strongly suspect that my browser was simply caching content for too
long and browsing back and forth never actually updated the contents
with the latest version.

Opening the site from another browser revealed new contents, and after
pressing the initial browser hard enough it eventually gave up as
well.

Mojca

On Thu, 3 Nov 2022 at 22:49, Mojca Miklavec wrote:
>
> Hi,
>
> I was looking at
> https://ports.macports.org/port/kicad/details/
> which says that we are shipping kicad 6.0.7 (while we have 6.0.8),
> builds point to logs for 6.0.7,
> livecheck reports that 6.0.8 is the latest version (but it is 6.0.9).
>
> None of these updates are super fresh, so I'm wondering if something
> is perhaps stuck on the server.
>
> Mojca

Weird outdated state of ports (in webapp)

[Mojca Miklavec]

Hi,

I was looking at
https://ports.macports.org/port/kicad/details/
which says that we are shipping kicad 6.0.7 (while we have 6.0.8),
builds point to logs for 6.0.7,
livecheck reports that 6.0.8 is the latest version (but it is 6.0.9).

None of these updates are super fresh, so I'm wondering if something
is perhaps stuck on the server.

Mojca

Re: Removed ports still listed on ports.macports.org

[Mojca Miklavec]

Hi,

V ned., 30. okt. 2022 01:02 je oseba Nils Breunese napisala:

> Hi,
>
> The openjdk port was removed on August 25th after it had been obsoleted a
> while ago (https://github.com/macports/macports-ports/pull/15910), but I
> just noticed that https://ports.macports.org/port/openjdk/details/ still
> shows the openjdk port information from when it last existed.
>
> I see there are more ports listed on https://ports.macports.org <
> https://ports.macports.org/> that have been removed from the ports tree,
> e.g. https://ports.macports.org/port/openjdk7-zulu/. Does
> ports.macports.org  have some kind of
> mechanism that should clean up the entries for ports that no longer exist?
>

The port pages were kept on purpose (to let users find deleted ports easily
and potentially resurrect them instead of having to reinvent the wheel, for
historic / arcival reasons, ...), with the intention to clearly mark that
they have been deleted and they should not appear in searches within the
site unless explicitly requested.

Maybe the feedback should look different? Or do you have some other
suggestion?

Mojca

Re: ports.macports.org gives strange port dependencies

[Mojca Miklavec]

On Mon, 26 Sept 2022 at 20:54, Chris Jones wrote:
>
> FWIW I personally would also favour more correct over a bit faster any day of 
> the week…
> so if switching back to rsync would allow the stats to reflect say the most 
> recent OS precisely,
> for me thats a price worth paying.

To me by far the best option would be to fix portindex to work
correctly when the -p flag is passed. I assume that we could easily
hardcode the default compiler on each darwin OS and start from there.

The current situation means that we are basically shipping a somewhat
wrong portindex to "every single user" out there, even if that
portindex was generated on Darwin.

Note that we do all kinds of stuff on the server (run portindex,
process portindex, run livecheck, play a bit with git commits, ...)
and if one can rely on running portindex locally, it's easy to process
one commit at a time and remember when a port got added, deleted,
modified etc. One is deprived from all those nice options if one needs
to depend on an external portindex generated at some random point in
the past.

Switching back to the pregenerated portindex might break the processes
in some hard-to-spot ways. I'm not saying that we should stick with
the current implementation for every cost, but I would prefer to think
twice if we couldn't perhaps solve the problem at the source and make
ourselves life easier rather than using some patchy workarounds.

Regarding ports belonging to each OS version. I totally agree that
having the port page display different information based on the OS
version would be pretty cool functionality. The decision to start with
a single version of PortIndex was somewhat deliberate though. We had
to choose between a simpler approach (MVP: minimum viable product) and
bigger chances to end up with a nicely functional website vs. to tons
of added complexity bundled with an increased risk of ending up with a
semi-non-functional site at the end of the summer. If someone is
willing to step up and add better support for different OS versions
now, that would certainly be more than welcome.

Mojca

Re: ports.macports.org gives strange port dependencies

[Mojca Miklavec]

On Sun, 25 Sept 2022 at 23:27, Joshua Root wrote:
>
> Compiler selection doesn't depend only on the platform, it looks at the
> actual versions (and existence) of the compilers available on the
> system. It's just another way in which a static PortIndex can't reflect
> the dynamic values of Portfile variables.

So basically that means that the PortIndex that we distribute via
rsync is also wrong?

Mojca

Re: perl5 default version

[Mojca Miklavec]

Hi,

I would like to clarify a few points before being able to proceed:

#1
Some ports are probably not yet handling perl correctly in the sense
that they might have been built on the buildbot and keep depending on
modules from perl5.28, while the user only has perl5.34 installed.
Will something bad happen if I remove the +perl5_28 variant from the
perl5 port before those ports are "fixed"? I would just like to know
if I can merge https://github.com/macports/macports-ports/pull/15264
as is or if I need to wait with variant removal a bit longer (if I
need to remove one commit from the PR).

#2
Let's assume there's an average port that doesn't care which version
of perl is being used, but that port has a bunch of dependencies on
various perl modules (so when perl is upgraded, at least a revbump is
needed). What syntax should we use?

(a) Some ports use
set perl_branch 5.34
depends_build port:p${perl_branch}-xml-parser
The advantage is that a portgroup isn't needed, but one cannot use
${perl5.bin} if needed, for example.

(b) Other ports use
PortGroup perl5 1.0
perl5.branches 5.34
depends_build port:p${perl5.major}-xml-parser

(c) Yet other ports use
PortGroup perl5 1.0
perl5.major 5.34
depends_build port:p${perl5.major}-xml-parser

Can we agree which syntax is best (b, c, something else, ...)? Some
maintainers argued that including the PortGroup sounded like an
overkill, but it would be of enormous help if we could identify all
relevant ports with some simple grepp-ing in the future, and having
ports use "perl5.branches", "perl5.major", "perl_branch", "pbranch",
"perlver", ... tons of other variable names as well as hardcoded perl
versions etc. isn't exactly helping.

#3
A number of ports still need some love, any help would be appreciated.
Not because it's hard to do, but because there are a number of ports to check.
https://github.com/macports/macports-ports/pull/15265
Before we devote them some love, we would need to clarify #2 though.

Thank you,
Mojca

On Sun, 3 Jul 2022 at 14:31, Mojca Miklavec  wrote:
>
> Hi,
>
> First of all: thanks a lot for the effort of migrating 100+ ports to perl 
> 5.34.
> (I'm now confused because I got an email from Jeremy and two days
> later Joshua did all the work.)
>
> I bumped a few more in
> https://github.com/macports/macports-ports/pull/15265
> and updated perl to 5.36 in
> https://github.com/macports/macports-ports/pull/15264
>
> I would be grateful for some reviews and testing (I didn't do any), so
> that we could merge this quickly.
> I also suspect that a number of ports that just "piggy-back" on
> default perl version might need a revision bump, but I leave it to
> others to figure that out (some are listed in the above PR).
>
> Once these two PRs get merged, I would be grateful for a bit more help
> to remove dependencies on anything older than perl 5.34, so that we
> could delete thousands of perl subports before adding new ones for
> p5.36-*.
>
> Once we have the subports for 5.36 available, we can of course repeat
> the exercise of switching to 5.36 ;)
> There's no hurry for the latter, but it would at least be nice to get
> to the point where we get rid of < 5.34 and introduce support for
> 5.36.
>
> Thanks,
> Mojca
>
> On Mon, 27 Jun 2022 at 21:54, Mojca Miklavec wrote:
> > On Mon, 27 Jun 2022 at 20:25, Jeremy Lavergne wrote:
> > >
> > > Is there a plan on when we will change the default variant version of 
> > > perl5?
> >
> > I would say "as soon as we migrate the ports". But I don't know the
> > answer to the latter. Ideally it would have been a long time ago.
> >
> > > Was about to update a package that depends on perl packages, and ensure
> > > it was using the same as our default. However, it's been ahead for quite
> > > some time already. Also looks like perl 5.36 is latest stable upstream
> > > while our perl5 port seems to point to 5.28.
> >
> > 5.36 is on me.
> > But switching at least a hundred ports is a fair share of effort that
> > I cannot do alone.

What to do with Mono (and msbuild) on ARM64?

[Mojca Miklavec]

Hi,

One of the projects that I'm working on requires mono as a build dependency.
At the moment mono is broken on ARM64 in MacPorts (I suspect that it
works under HomeBrew).

I fixed it:
https://github.com/macports/macports-ports/pull/14952/
but there's a comment in the port saying
> please update msbuild when updating mono
and I'm unable to cope with that one (I don't know how to update msbuild).

While I can handle that local patch for myself, I would hate to send
instructions to other developers working on macs explaining how to
patch mono (or abandon the idea of using macports) if they want to
build the sources.

Would it be acceptable to upgrade just mono without msbuild to avoid
having a broken mono on M1?

Mojca

Re: perl5 default version

[Mojca Miklavec]

Hi,

First of all: thanks a lot for the effort of migrating 100+ ports to perl 5.34.
(I'm now confused because I got an email from Jeremy and two days
later Joshua did all the work.)

I bumped a few more in
https://github.com/macports/macports-ports/pull/15265
and updated perl to 5.36 in
https://github.com/macports/macports-ports/pull/15264

I would be grateful for some reviews and testing (I didn't do any), so
that we could merge this quickly.
I also suspect that a number of ports that just "piggy-back" on
default perl version might need a revision bump, but I leave it to
others to figure that out (some are listed in the above PR).

Once these two PRs get merged, I would be grateful for a bit more help
to remove dependencies on anything older than perl 5.34, so that we
could delete thousands of perl subports before adding new ones for
p5.36-*.

Once we have the subports for 5.36 available, we can of course repeat
the exercise of switching to 5.36 ;)
There's no hurry for the latter, but it would at least be nice to get
to the point where we get rid of < 5.34 and introduce support for
5.36.

Thanks,
Mojca

On Mon, 27 Jun 2022 at 21:54, Mojca Miklavec wrote:
> On Mon, 27 Jun 2022 at 20:25, Jeremy Lavergne wrote:
> >
> > Is there a plan on when we will change the default variant version of perl5?
>
> I would say "as soon as we migrate the ports". But I don't know the
> answer to the latter. Ideally it would have been a long time ago.
>
> > Was about to update a package that depends on perl packages, and ensure
> > it was using the same as our default. However, it's been ahead for quite
> > some time already. Also looks like perl 5.36 is latest stable upstream
> > while our perl5 port seems to point to 5.28.
>
> 5.36 is on me.
> But switching at least a hundred ports is a fair share of effort that
> I cannot do alone.

Using on macOS 10.13 with clang++-mp-13

[Mojca Miklavec]

Hi,

I'm trying to build some sources that require  on 10.13
using clang 13 (I can try with clang 14, but I doubt that it helps).

What's the correct way to compile the following minimal example? Do I
need to link against a newer libc++ somehow?

If it's not feasible to do that, I'll target a newer OS, I was just
silently hoping to have some success ;)

Thank you,
Mojca

#include 
#include 

int main() {
auto cwd = std::filesystem::current_path();
printf("%s", cwd.c_str());
return EXIT_SUCCESS;
}

> clang++-mp-13 test.cpp -o test
test.cpp:5:16: error: no member named 'filesystem' in namespace 'std';
did you mean 'std::__fs::filesystem'?
auto cwd = std::filesystem::current_path();
   ^~~
   std::__fs::filesystem
/opt/local/libexec/llvm-13/bin/../include/c++/v1/filesystem:268:1:
note: 'std::__fs::filesystem' declared here
_LIBCPP_BEGIN_NAMESPACE_FILESYSTEM
^
/opt/local/libexec/llvm-13/bin/../include/c++/v1/__config:816:58:
note: expanded from macro '_LIBCPP_BEGIN_NAMESPACE_FILESYSTEM'
  _LIBCPP_BEGIN_NAMESPACE_STD namespace __fs { namespace filesystem {
 ^
1 error generated.

> clang++-mp-13 -std=c++17 test.cpp -o test
Undefined symbols for architecture x86_64:
  "std::__1::__fs::filesystem::__current_path(std::__1::error_code*)",
referenced from:
  std::__1::__fs::filesystem::current_path() in test-1b2bbf.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Any Django volunteers to co-mentor for Google Summer of Code?

[Mojca Miklavec]

Hi,

I wanted to ask if we happen to have any volunteers to co-mentor a
Django project for GSOC
for further improvements of https://ports.macports.org/

We have some mentoring force right now, but not enough to apply for
GSOC unless we can recruit at least one more devoted person.
The potential co-mentor doesn't necessarily need any experience with
MacPorts (so we could look outside of the existing community), but
being able to provide quality feedback and suggestions in the area of
web development would be of enormous help.

Thank you,
Mojca

Re: perl 5.34 branch

[Mojca Miklavec]

On Sat, 13 Nov 2021 at 17:38, Renee Otten wrote:
>
> There is an open PR for that: 
> https://github.com/macports/macports-ports/pull/11534. I am not sure if there 
> are unresolved issues (it needs to be rebased for sure) or if we’re just 
> waiting for the backlog of the buildbots after to change to openssl3 to clear 
> up.

Ryan and Ken had some ideas about what needs to be changed in the
perl[5.34] port, but I'm not exactly following and I would prefer if
Ken would be willing to finalize the required changes.

Mojca

Re: GitHub Sponsors

[Mojca Miklavec]

On Sat, 13 Nov 2021 at 17:33, Vincent Habchi wrote:
>
> You can also consider registering the MacPorts association outside the US, 
> e.g. (I don’t toot my own horn, it’s just an example I’m familiar with) in 
> France, associations are tax-exempt, and, barring the need of one local 
> person to handle all the bootstrap paperwork (like opening an account, 
> registering the association and so on), members can live anywhere in the 
> world.

I've been in favour of establishing a French non-profit org (1901).
We've had one for more than 10 years and there's nearly no overhead.
One needs a trustworthy representative person with an address in
France, at least a president and an accountant (living anywhere in the
world), the bylaws need to be written, but other than that it's super
liberal and convenient.

(In some countries there's a need for "ridiculous amounts of money"
just to pay some professional accountant, bank fees etc. just for the
basic existence even if there's no income.)

Mojca

Re: Help offered

[Mojca Miklavec]

Dear Giuseppe & Michele,

On Tue, 7 Sept 2021 at 12:02, Giuseppe 'ferdy' Miceli wrote:
>
> I can work on the migration from perl 5.28 to 5.34.
>
> should michele fancy to start working on macports with this tasks, i can 
> volunteer to do it together with him so i can support him in these first 
> steps!
>
> please be aware i am not a guru at all, but i can surely give michele an hand 
> as general overview of the project and basic tasks (e.g. working with 
> macports git)

On Tue, 7 Sept 2021 at 18:00, Michele Venturi wrote:
>
> I like shell scripting, it looks like a good first task.

Thanks a lot for the offer!

We need to get this merged first (it should basically be ready, but I
want confirmation from Ken and Ryan):
https://github.com/macports/macports-ports/pull/11534
before other changes can start flowing in, but in principle you can
already start working/testing from that branch.

I need to make a Trac ticket for transition to 5.34 (not a dependency
for your work either), see
https://trac.macports.org/ticket/58361

All ports that depend on 5.28 (some on 5.30 or 5.32 by now?) need to
start pointing to 5.34, and revision needs to be increased for all
those ports. Some ports depend on each other (notably some Apache
stuff, I forgot what exactly) and they need to be changed at the same
time (that is: not one port today and one after a few months; a few
commits apart is fine).

Changing some of the ports in various ways to make them more
consistent with each other and easier for scripting the changes later
is valid (ideally that should be done in a separate commit).

We have a command that lists all the ports depending on a particular
perl version. See the above ticket for an example. That's the list of
ports you could start with.

If anyone will work on a slightly more serious scripting that would be
usable in the long term, I would slightly prefer to see it done in
Python than Perl (Tcl would also be valid if that would help you
interact directly with MacPorts).

Thank you,
Mojca

Re: Help offered

[Mojca Miklavec]

Dear Michele,

On Mon, 6 Sept 2021 at 13:20, Michele Venturi wrote:
>
> What is a good way to start partecipate in your
> project? I'd like to give you a hand regularly. 

Welcome to MacPorts and thanks a lot for your willingness to help the
project grow.

There are various ways to help, depending on your personal interests.
I'll list just a few that come to my mind first:

1.) If you are familiar with web programming (either Django, or just
pure design tasks), we would happily have someone contribute to
https://ports.macports.org/
(https://github.com/macports/macports-webapp) or to
https://www.macports.org. My personal wish would be to slowly migrate
more contents from the macports.org website to a common platform (but
I'm not sure if everyone agrees about that just yet).

2.) We need someone willing to take the time to finalize the migration
from docbook to asciidoc for our documentation (some parts of
conversion still go wrong and need to be either handled in the
converter, or manually). We would also welcome anyone willing to
update the contents (or actually rewrite larger portions) of
documentation.

3.) We have 20k+ ports. Many of them are outdated or broken and could
use some love. What most people contribute to are updates to various
ports that they personally care about.
One of the special tasks that doesn't require almost any special
knowledge and just takes a lot of time to do, would be migration of
all ports that depend on perl from perl 5.28 to 5.34. Most of the time
it's sufficient to just replace the version in all portfiles (and
ideally, but not necessarily test whether the modified port still
builds), but there are likely hundreds and any helping hand would be
mostly welcome.

4.) One area where we lack the workforce most is the macports base
code (the heart of the project that makes it even possible to use
MacPorts), written in Tcl.
https://github.com/macports/macports-base

5.) We're looking for someone willing to play around with macOS VMs,
in particular the older ones: 10.6 (or even 10.4/10.5 for utter geeks)
and newer. We currently run CI jobs just on what GitHub provides (2 or
3 latest OSes), but it would be nice to set up disposable VMs where we
could fire up a VM, build the ports from CI, and destroy the VM.

The list is not anywhere extensive or complete, and it's probably
heavily personally biased. I can write more about any individual point
once you explain your interests and skillset (or what you are
interested in learning on the go).

Mojca

Re: Why does Texinfo explicitly depend on perl 5.30?

[Mojca Miklavec]

On Sat, 4 Sept 2021 at 09:19, Vincent Habchi  wrote:
>
> Well, all is said in the subject :)

This was changed in

https://github.com/macports/macports-ports/commit/6fe093f0d3afdea30cef8526a400f3d62f2d5f62

My personal guess: no special reason other than trying to use a newer
version given that it was available.
It's a bit unfortunate if some ports use one version and others
another, but in particular 5.30 is already obsolete.

We need to add a minor fix to perl, then add subports for 5.34 and
finally migrate all ports to depend on 5.34.

Mojca

Re: New ports.macports.org website

[Mojca Miklavec]

On Tue, 20 Jul 2021 at 11:00, Lothar Haeger wrote:
>
> May I suggest that you add a (link to a) description to 
> https://ports.macports.org/statistics/ports that explains what "...users who 
> submitted stats…" exactly means and how to enable submitting stats as a user 
> (and how to check if stats are enabled), and maybe stress that we use an 
> opt-in model, and that this makes the stats look as unimpressive as they are.
>
> Uncommented, theses stats look like macports is simply irrelevant in the 
> greater scheme of things (the most requested port has been installed 32x per 
> day during the last month, #10 on the list just 6x, #100 less than twice per 
> day).

Would you be willing to create a mock-up (some hard-drawn /
photoshopped example of where to put what / how it should look + what
text to put there) with a more detailed suggestion?

> Actually I think moving to an opt-out scheme for new installations would be 
> overall better to raise useful stats.

It would certainly be better to raise useful stats, but this has been
discussed before and we don't want to go that route, at least not yet.

> If that's not an option, I'd like to see the port command regularly 
> suggesting to enable stats to end users that did not do so already, e.g. with 
> a simple "Do you want to enable anonymous stats now? (y/n)" prompt every once 
> in a while.
>
> Also: is there no way to raise stats on the server side, like 
> archives/distfiles requested or something similar that allows to put the user 
> stats into perspective and calculate an approximation to the real numbers?

There's no way to get exact/real numbers, but there are ways to get
partial download statistics of the mirrored binaries and distfiles
which are a lot more impressive.
Zero (@l2dy) implemented that at the last MacPorts meeting, but the
results were never publicly deployed. Someone would have to take the
project over.

> If stats remain meaningless because of a too small sample size, they should 
> rather removed from the web site, imho.

I disagree. Even with a relatively small sample size (and potentially
skewed numbers due to many enthusiasts opting in on all of their
legacy hardware ;) I still find it incredibly useful.

Mojca

Re: New ports.macports.org website

[Mojca Miklavec]

Hi,

On Tue, 20 Jul 2021 at 18:54, Christopher Nielsen wrote:
>
> Just took the new site for a spin, and all I can say is - WOW! It looks 
> great, the design is very logical (if not perfect!), and it’s rich in 
> functionality.
>
> It’s clear that a LOT of good thought/discussion went into the UI design, and 
> boy did it pay off! Kudos to everyone involved in the effort!

The design was basically done by Arjun alone, so all the kudos go to him.

(Amar suggested creating a simple version of the port page which was
certainly an interesting idea. Hardly anything else from the mentors'
side. It's really cool to have such a talented student join the
project ;)

Mojca

New ports.macports.org website

[Mojca Miklavec]

Dear MacPorts users and developers,

I'm really thrilled to see the new version of the ports website
finally being deployed at
 https://ports.macports.org

I'm extremely grateful for the excellent work that Arjun did during
the GSOC summers of 2019 and 2020. He kept maintaining the code after
GSOC and made the migration to his own server (the previous server was
running out of resources to be able to cope with the additional
requirements introduced in the last summer).

Many thanks also to Amar with a much deeper understanding of Django
and related technologies who co-mentored the project in 2020 and made
sure that we ended up with a product of much higher quality than any
one of us could have achieved.

Some exciting new features involve:
- Dark mode.
- Better REST API.
- Remove dependency on Google Charts (blocked in some parts of the world).
- More advanced / extensive search & filtering for ports.
- Find ports that provide a particular file.
- The site runs livecheck and reports outdated ports.
- Ability to log in with GitHub OAuth and follow your favourite ports.
You can check whether they are outdated or broken on some platforms,
making it easier to see where contributions are needed.

You can read a bit more about the project on Arjun's blog:
https://arjunsalyan.com/gsoc20-report/

The code lives at
https://github.com/macports/macports-webapp

We would be most happy to see contributions to this project, both in
terms of programming as well as for design, ideas etc.
Arjun did an impressive job already (everything from backend to
design), but if we have some talented designers around, please speak
up.

I would also like to invite everyone who hasn't done that already to
opt-in for anonymous statistics submissions:

sudo port install mpstats

Thank you,
Mojca

PS: The old version will still live at
https://port-old.macports.org
for a little while, just in case.

Re: Azure pipeline failing due to parse error

[Mojca Miklavec]

Hi,

On Mon, 5 Jul 2021 at 07:45, Manoj Karthick wrote:
>
> Hi! I was updating the antibody port, PR:  
> https://github.com/macports/macports-ports/pull/11516 and the Azure Pipeline 
> check seems to be failing during portindex due to an error parsing an 
> unrelated port.

I didn't check this particular error, but MacPorts 2.7.x has been
released recently which added support for some new syntax in port
files. We usually wait 2 weeks before switching to the new syntax.
However we've been facing some issues upgrading the version of
MacPorts for Azure pipelines, so that one still runs on 2.6.x and most
likely fails to parse the syntax that was only supposed to work on
2.7. You can probably ignore that error for now.

Mojca

Re: Buildbots Down?

[Mojca Miklavec]

On Tue, 22 Jun 2021 at 14:46, Christopher Nielsen wrote:
>
> Were the recent buildbot failures related to the perl 5.32 commit…?

What do you mean by "recent buildbot failures"? Yes, many p5.32-*
subports failed to build, but those were by far not the only failures.

Buildbot master itself isn't down, it's working fine for me, but some
workers are in fact offline.

Mojca

Re: llvm-9.0 on 10.6.8 shows red -- but it builds

[Mojca Miklavec]

> > That probably counts as a bug in the Tcl script that returns the list
> > of subports to be built.
>
> I'm not aware of a bug in that script.

Do you have any clue or any alternative explanation why llvm-9.0 would
be missing on this list?
https://build.macports.org/builders/ports-10.6_x86_64-watcher/builds/9920

The port must have been built some time between 9907 and 9920:
https://build.macports.org/builders/ports-10.6_x86_64-watcher/builds/9907

The port grepcidr was built in
https://build.macports.org/builders/ports-10.6_x86_64-watcher/builds/9918
and the timestamp of the binary from 10.6_x86_64 is 2020-09-07 07:55

The timestamp of llvm-9.0 is 2020-09-07 07:56.

python38 was probably the first port built in portwatcher 9920.
Its timestamp is 2020-09-07 08:14.

Ports from 9919 are probably not distributable, so we don't have any
timestamps there.

Mojca

Re: llvm-9.0 on 10.6.8 shows red -- but it builds

[Mojca Miklavec]

On Tue, 18 May 2021 at 07:15, Ken Cunningham wrote:
>
> People are quoting 
> 
>   the lack of llvm-9.0 for SnowLeopard on macports as a sign of the demise of 
> older systems, and it does for some reason show red here:
>
> https://ports.macports.org/port/llvm-9.0/builds
>
> but it builds fine, along with most later llvms and all of the earlier ones, 
> and it exists on the packages server in all archs:

To me it looks like it was broken for a very short period of time on
all systems from 10.6 to 10.9 (tons of ports were broken).
https://build.macports.org/builders/ports-10.6_x86_64-watcher/builds/9907

It must have been fixed some 30 hours later judging from the
timestamps. I see that Ryan scheduled a rebuild of many failed jobs in
https://build.macports.org/builders/ports-10.6_x86_64-watcher/builds/9920
including llvm-9.0, but llvm-9.0 is missing on that list of subports.

I suspect that's because llvm-9.0 must have been the default compiler
for one of the ports built somewhere inbetween those two portwatcher
jobs (logs for portbuilder are gone already, so we cannot investigate
those any longer), and it was built and uploaded successfully as part
of building another unrelated ports, but we most likely don't account
for a broken compiler (as a port dependency) being built explicitly in
a standalone portbuilder job.

(There are only 12 portwatcher jobs to investigate if we wanted to
find which port was that ;)

That probably counts as a bug in the Tcl script that returns the list
of subports to be built.

> If anyone knows how to make the ports.macports.org website show it in green, 
> that would be appreciated.

The fastest one would be by revbumping that port ;)

The whole logic for showing the port as green currently requires
having an entry of a successful port build in a database. But
apparently we never had such a build, and you cannot force build a
port that already exists on the package server either.

Sure, there's also a problem that Joshua pointed out that needs
addressing, but even that fix wouldn't solve this particular instance.

Mojca

(My feature request for the webapp would be to allow an explicit URL
to show older builds of a port. But it makes sense to deploy the new
site first.)

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

[Mojca Miklavec]

On Mon, 17 May 2021 at 10:39, Ruben Di Battista wrote:
>
> Just as a side note, here in France I just created a non-profit association 
> for a project I'm working on related to the organization of an event, and the 
> process is almost free and reasonably fast. In a matter of few weeks we had 
> the association published on the official governmental gazette and a bank 
> account, also free of keeping charges.
>
> Same thing in Italy.

We have a non-profit in France and I would say that it's
extreeemely easy to run one there compared to almost any other
country.
The only downside is that one needs a person physically located there
who's willing to do some stuff occasionally, but it's orders of
magnitude less paperwork than in any other country that we
investigated about.

In Italy it gets a bit more complicated in my opinion (but still quite ok).

Another huge benefit of having an org in Europe is that organizing
meetings in Europe is much easier and cheaper with an European bank
account.
(That said, with Covid and everything, I'm not sure how likely we are
to organize further in-person meetings any time soon.)

If we are to organize a meeting here in Europe, having a legal entity
in the USA hardly helps. It's expensive to collect money for the fee,
and also expensive to pay the hotel & other costs. Also, signing any
contracts with the accommodation facility becomes a lot more tricky.

(Last time we organized the meeting via an Italian non-profit.)

> I perfectly agree with the will of having the legal entity in US,

It's also perfectly fine to run two non-profits in two countries at
the same time. But of course each one brings its own time commitment
and real costs (bank account etc.).

> but I think the process in Europe might be less expensive at least, probably 
> faster.

I believe that we discussed a while ago that having a non-profit in
the US would cost us some 1000 USD just for the bookkeeping or so (not
sure whether that price was per year or per month, but either of those
is a non-trivial amount of money unless you really have a lot of
income).

In France we simply have board members that do all the roles on a
volunteer basis.
Of course, if we had a large traffic (lots of donations and expenses)
that might not have been viable, but then we could also easily afford
to pay for one.
The important part is that it's easy enough to do the job that one
doesn't need to be a trained professional to do it.

(What I'm slightly more worried about is the manpower to run a
non-profit, no matter how little work that is.)

Mojca

Re: Publicizing MacPorts

[Mojca Miklavec]

On Sat, 24 Apr 2021 at 13:04, Georges Martin  wrote:
>
> Le 22 avr. 2021 à 17:46, Steven Smith  a écrit :
>
> Another reason major news like M1 support must be announced.
>
>
> May I ask: how do we *define* "M1 support" in MacPorts? What are the 
> *metrics* used to support that statement?
>
> - How does the MacPorts base "support the M1"? (I know I had to install it 
> from git then switch to the master branch for other reasons -- not a typical 
> user installation)
>
> - Is it when you set buildfromsource to always, build_arch to arm64 and 
> everything run smoothly afterwards? :-)

You go to https://www.macports.org/install.php, download the pkg and run it.

It's usually before the official release of the new OS that one needs
to install MacPorts base from source, but that's mainly because one
needs to sign some kind of agreement with Apple that prevents
developers from doing certain things and reveal details about the beta
to public. Or at least it's my understanding that we may not
distribute binaries for beta versions before the official release.

Building base from source is useful for anyone who wants to help with
testing or development though.

> - How does a port "supports the M1"? Is it when it can be built, tested and 
> installed on a M1? Even if it's just compiled as x86_64 and running on 
> Rosetta? Or is it when it can be successfully built, tested and installed as 
> native and/or +universal  on both M1 and Intel?

Yes, when it builds without any hassle & intervention on M1, and the
resulting software works. Bonus points if it comes as a binary. If
certain software cannot be built natively, but still works as x86_64,
I would also call this supported. But keep in mind that it's actually
a lot more work to ensure that a particular port can be built for
another architecture, than it is to make it build natively. Plenty of
ports just worked, while some other software may never get ported
properly.

> - How many ports are building on M1 today? (can a user do a search on 
> architecture on ports.macports.org?) Before installing, how can a user know 
> if a port is building/testing successfully on M1? (can he do a `port info 
> --name --supported-archs` on a port?)

You can go to
https://ports.macports.org/ports/all_builds/
and select 11_arm64 as the builder (it's a pity that we don't have a
direct link, but that could be added).

The arm64 builder was missing for a short while (it's 270 commits
behind at the moment of writing), but it's slowly catching up:
https://build.macports.org/waterfall?tag=11
and some ports that haven't seen any updates in a long while might not
have been attempted to build (that might happen in a few days).

> - What if a port is not building on M1 because upstream is not ready yet? 
> (libffi, openjdk16, ghc comes to mind) What if ports are not building because 
> major dependencies are not? (thinking of you, libffi) Is it documented 
> anywhere?

If either upstream is not ready, or if one of the dependencies (even
if that dependency means a broken compiler) is broken, then the port
is broken. The best reference we have at the moment is probably
https://ports.macports.org/port/ghc/

You can combine the information from:
- port health that tells you whether the port built successfully on
the buildbot worker in question
- installation statistics submitted by users (where you can see that
nobody has ghc installed on arm64, for example)
- the list of Trac tickets

> - How are M1 porting priorities defined? Do we have "M1 priorities" or "M1 
> call for help" for maintainers? Is there a M1 "Hot Problems" page for users 
> and maintainers like we have for macOS releases?

We don't have any "M1 priorities" list at the moment.
We have some kind of approximation of the most popular ports here:

https://ports.macports.org/statistics/ports/?days=30=-total_count=-req_count=port
and I believe that we added some information about whether the port is
broken or not to the new ports page that hasn't been deployed yet (I'm
not 100% sure).

> To be clear: I am **not** complaining. I switched to M1 a month and a half 
> ago and decided to contribute to the effort as much as I can: I installed 
> from git, set up buildfromsource to always and build_arch to arm64, then 
> switched to git master. After Ken's call for help on ICU, I set my variants 
> to +universal, recompiled everything that could be (but had to stop because 
> of libffi...).  I'm trying to natively build all the ports I was using on 
> Catalina/x86_64, I'm not there yet (today, py{38,39}-pandas do not build 
> anymore because of OpenBLAS...) and I am not complaining: it's part of the 
> game... :-)

One of the problems with "call for help" at the moment is that we have
way too many tickets open, and it's basically impossible to
figure out which ones are most important to look into.

For anyone possessing a M1 mac probably the best way to contribute by
far is to help build those ports which that 

Re: Publicizing MacPorts

[Mojca Miklavec]

On Tue, 20 Apr 2021 at 12:41, Steven Smith wrote:
>
> > What Ryan is trying to say is that "MacPorts" is in fact just a set of
> > random volunteer contributors
>
> 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.”

I'm not saying that we need 40+ volunteers to write a single paragraph
each, and I don't think that would work well either.

But maybe you (or someone else reading this) would be willing to stand
up and volunteer to organize whatever needs to be done to improve our
communication with the broader community. We probably need just ONE
person with a clear vision, some ideas and a tiny bit of time to boost
the visibility and news from the community.

Would you be willing to lead the effort? I'm sure that others would
gladly help, but it needs to start somewhere and with someone with
sufficient motivation, resources and ideas to carry things out.

Mojca

PS: we have https://www.macports.org/news/, but it's probably not that
helpful. And Clemens is posting news on his personal blog from time to
time. We can certainly improve that if someone willing to write the
contents (with the help of others) shows up.

Re: Publicizing MacPorts

[Mojca Miklavec]

On Mon, 19 Apr 2021 at 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.

What Ryan is trying to say is that "MacPorts" is in fact just a set of
random volunteer contributors, each with his/her own talents (and many
of those without time/motivation to write or without writing skills),
with a varying level of expertise and available time to devote to the
project. There is not even any legal entity in the background (there
probably should be one at some point).

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

If you have good ideas about how to improve and promote the project,
there is no reason why you couldn't take part in the joint effort to
make the product better in the long run.

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.

Mojca

Re: Publicizing MacPorts

[Mojca Miklavec]

On Mon, 19 Apr 2021 at 12:45, Steven Smith wrote:
>
> If a comparable announcement to this was made for MacPorts, I missed it:
>
> https://arstechnica.com/gadgets/2021/02/mac-utility-homebrew-finally-gets-native-apple-silicon-and-m1-support/

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

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

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

Mojca

Re: Built archive not uploaded

[Mojca Miklavec]

On Sat, 27 Mar 2021 at 18:39, Jason Liu wrote:
>
> It seems that the 10.15 build for port:oidn either failed or something went 
> wrong when uploading the built package to the public archive:
>
> https://packages.macports.org/oidn/
>
> Could someone with access to the builders

It's publicly accessible here:
https://build.macports.org/waterfall
(albeit not very user-friendly to search for a given port).

I didn't try to look into details, but note that the 10.15 builder has
more than 500 jobs in the backlog, so it might also be just a matter
of time.

Mojca

Ports for buildbot 3

[Mojca Miklavec]

Hi,

Buildbot 3 (that is slightly incompatible with buildbot 2) has
recently been released.

We currently ship:
- buildbot-0.8, buildbot-slave-0.8
- buildbot, buildbot-worker (+ dependencies) that provide version 2

So we are basically lacking buildbot 1.x and the new 3.x.

I don't see any need to ship version 1.x which is very similar to 2.x,
but version 3.x removed a lot of deprecated APIs (from what I
understand a well-written configuration should still work on 3.x, so
it's not as bad as the migration from 0.8 to 1.x).

I would like to update to version 3.x, but I would be grateful for
agreement about what ports we want to end up with before doing any
changes to the ports.

(I'm still trying to figure out whether buildbot-worker 3.x is
incompatible with buildbot master 1.x or 2.x. If it's compatible, we
don't need to provide version 2 of the worker.)

Thank you,
Mojca

Running macOS inside a Docker container

[Mojca Miklavec]

There's an interesting piece of news on slashdot:

Open-Source App Lets Anyone Create a Virtual Army of Hackintoshes

https://news.slashdot.org/story/21/03/11/2148210/open-source-app-lets-anyone-create-a-virtual-army-of-hackintoshes

https://github.com/sickcodes/Docker-OSX

This might potentially simplify doing CI on pull request on local
infrastructure, the major disadvantage for us is that nobody did the
work yet to make the older versions of Mac OS X work (according to the
author of OSX-KVM that should be feasible). Here's a cool tutorial
that might help understand the needs:
https://dortania.github.io/OpenCore-Install-Guide/
but it still needs quite some work to be done.

Mojca

Re: Dovecot Update Fails to Build in CI, Trace Mode

[Mojca Miklavec]

Dear Steven,

On Thu, 4 Mar 2021 at 13:07, Steven Smith  wrote:
>
> Re: https://github.com/macports/macports-ports/pull/10132
>
> I’m trying to update dovecot. A vanilla `port install` works perfectly and 
> produces perfectly working binaries.
>
> However, both CI and trace mode builds fail at the same point below. After 
> the build errors out, I’m able to run the exact same command successfully, 
> and the yacc file looks fine:
>
> sudo -u macports bison -o event-filter-parser.c event-filter-parser.y

I don't see bison listed as a build dependency in that port.
I'm not sure if that's the problem in your case, but it's pretty
common scenario that if a port needs a dependency that isn't declared
in the Portfile, it might work on your computer and fail in the CI.

Mojca

Re: Very Large Number of Python ports Don't Exist in ${python.default_version } (py39)

[Mojca Miklavec]

On Tue, 2 Mar 2021 at 11:21, Ryan Schmidt  wrote:
> On Mar 1, 2021, at 09:49, Joshua Root wrote:
>
> > Once that's done, there's no problem adding lots of them in a single commit.
>
> It can be difficult to get approval from a large number of maintainers for a 
> single PR. If you're going to submit a PR that does a mass update for this 
> that affects ports of many maintainers, to make it as simple as possible for 
> everyone and to avoid the possibility of it being rejected or delayed I 
> strongly advise you to limit the commit to ONLY adding py39 support and not 
> performing any other changes. (Don't update a port, don't fix formatting, 
> don't add dependencies, etc.)
>
> You may want to do it in small enough batches that the CI infrastructure can 
> test within the allotted build time. If not, we will have to take you word 
> for it that they do all in fact build, so please be absolutely certain that 
> you have verified that they do build before submitting.

We sometimes do batches of all the 1000+ perl ports as that's
infeasible to do manually (nobody will test 1000+ ports if they build
and work correctly on his computer).
(I would usually check the buildbot results and open tickets for those
that fail.)

Mojca

Re: Regarding Hello World Task

[Mojca Miklavec]

Dear Rishabh,

On Wed, 17 Feb 2021 at 19:36, Rishabh Garg wrote:
>
> Hello everyone,
>
> I am Rishabh Garg, a BITS Pilani University student. I want to contribute to 
> the Macports projects.
>
> I wanted to know about the tasks that are to be completed before sending the 
> application for this year's GSoC projects.

Thanks a lot for contacting us this early.

Unfortunately we are not applying to GSOC this year as we seem to be
running short on volunteers to mentor the students this summer.

If you would nonetheless like to contribute, it helps to at least
roughly know your interests, so that we can guide you further.

Mojca

(PS: sorry for re-post, I wrote from the wrong email)

Re: PortIndex wasn't updated for 4 days?

[Mojca Miklavec]

On Fri, 19 Feb 2021 at 04:10, Zhenfu Shi wrote:
>
> Hi all,
> I've been noticing that no ports have been upgraded on my systems for a 
> few days, and checking rsync.macports.org/macports/release/tarballs/ confirms 
> that, the index was last updated on Feb 15. Just wondering what’s going on?

Extreme weather conditions:

https://lists.macports.org/pipermail/macports-users/2021-February/049571.html

Mojca

Re: Regarding Contribution to MacPorts

[Mojca Miklavec]

Dear Dhruv,

On Wed, 10 Feb 2021 at 09:50, Dhruv Sachdev wrote:
>
> Hello
> I am Dhruv Sachdev, 2nd year student in Computer Engineering at Mumbai 
> University.I want to start out with open source development and I am really 
> excited to contribute to great organisations and also develop my skills .  I 
> was going through the GSoC archives and I found your organisation and 
> previous projects. I find it very interesting and would love to contribute. I 
> just wanted to know that if you can please share what are the ideas you are 
> thinking about this year for GSoC and what tech stacks you would be needing 
> to complete the same.

Thank you very much for reaching to us.

I cannot say it for sure, but I'm not yet sure whether we'll have the
required mentor resources available for this year's GSOC.
In case we do have some volunteers, the available projects and skill
sets required will mostly depend on them.

Was anyone on this list thinking of volunteering as a mentor this year?

That said, you are always welcome to contribute even if we don't
participate at GSOC.

Mojca

Re: Can we enable CI for legacy systems?

[Mojca Miklavec]

On Wed, 27 Jan 2021 at 15:45, Ken Cunningham wrote:
>
> Clemens linked in some documentation to the github application runner that 
> said it ran on 10.13+ only.

I'm aware that most of the systems require a relatively recent macOS
(buildbot worker runs on ancient systems without any major issues
though).
I actually wanted to point that out also for the gitlab runner.

But then it hit me that if you only use the worker/runner on the host
computer (which can run any macOS version) which starts a fresh VM and
sends the build instructions to that VM, I guess that an ancient VM
might still work?

Mojca

Re: Can we enable CI for legacy systems?

[Mojca Miklavec]

On Mon, 25 Jan 2021 at 17:02, Ruben Di Battista
 wrote:
>
> Hi Ryan, thanks for your answer.
>
> If I configured a server I own to run CI jobs for old systems (I was thinking 
> about using a custom Gitlab runner libvirt 
> https://docs.gitlab.com/runner/executors/custom_examples/libvirt.html for 
> that and maybe), it's gonna be something useful that Macports could 
> potentially use?

Yes, definitely.

There are a couple of independent requirements:
(a) we need the software / CI jobs definitions
(b) we need the hardware to run those jobs on
(c) ideally a not-too-complicated way to set up & fire up VMs with
different macOS versions would be really handy
(both in terms of a set of scripts to set up a new VM, as well as
the sequence to fire up the VM / build the port / destroy the copy)

I suspect that we would be able to find some hardware somewhere once
we have the software written.
The last point sounds like most of the work.

Maybe GitLab runner isn't able to run on the oldest macOS that we
support, but if you run it on the host just to fire up a VM, that
might be ok.

I see that GitLab supports CI on top of GitHub repository:

https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/github_integration.html

Maybe that's not as straightforward as if the repo was stored on
GitLab directly, but it still sounds perfectly fine if you get it
working.

Even if you just start with your own clone of the GitHub repo inside
GitLab and get it working, this would still represent some 90 % of the
job (majority of [a] and complete [c]).

> PS: Does Github Action support custom "executors" to eventually run libvirt?

I'm not so familiar with GitHub Actions, but we are currently using
buildbot for the official builds. That one certainly offers native
libvirt support:
https://docs.buildbot.net/latest/manual/configuration/workers-libvirt.html

(Just getting the images done will likely take some non-trivial amount of time.)

Mojca

Re: FYI -- Parallels 16 now supports BigSur as a VM on older systems

[Mojca Miklavec]

On Sun, 6 Dec 2020 at 23:28, Christopher Nielsen wrote:
>
> Also, Parallels 16 still runs on MacOS 10.13, which is presently a 
> requirement for me.

You can run VMWare 10 or 11 on 10.13, but that one apparently doesn't
officially support any newer macOS as a guest (VMWare 10 doesn't
support 10.14, for example), and it definitely won't run on a 2008
Mac.

And the list of supported guest operating systems for VMWare 12
excludes the oldest ones.

It seems that Parallels is more friendly to old software & hardware,
so I believe I know what I'll use next, thanks a lot for the hint.

> As for a support matrix, the vendors’ respective knowledge bases (and/or 
> Google) are your best resource. But here’s an updated Parallels KB article, 
> providing host/guest info:
>
> https://kb.parallels.com/124223

That's a lot more than what VMWare offers, thanks. I'm trying out my
first VM there right now.

Mojca

Re: FYI -- Parallels 16 now supports BigSur as a VM on older systems

[Mojca Miklavec]

On Sun, 6 Dec 2020 at 22:37, Christopher Nielsen wrote:
> > On 2020-12-06-S, at 16:16, Mark Anderson wrote:
> >
> > Is there a good way to get 10.6 - 10.16 installed in Parallels — I really 
> > don't want to download all of them from the app store, if that's even 
> > possible.
> >
> > —Mark
>
> In my case, I’ve kept an archive of old MacOS installers, combo updates, etc, 
> so I used those.

I'm currently using VMWare (and I don't mind switching to Parallels in
case they have this covered in a better way), but the question is
similar.

I tried to install a new VM with Big Sur, but:
- the VM version I have on my box doesn't let me select any newer
macOS version than what I have installed (to some extent this is
understandable: they couldn't have known all the caveats of Big Sur
years back)
- the latest VMware Fusion 12 is no longer compatible with my OS (ok,
I would somehow accept that, at some point I do need to upgrade)
- but even if I upgrade to, say, 10.15 or 11 now, VMware Fusion 12 no
longer supports 10.6, for example, which is the single one that I
would *really* like to keep

I know that several developers here have the full collection of VMs
dating back to 10.5 or so. Even after solving the problem of finding a
suitable image (which Apple doesn't really make easy even if you just
want to revert to something that you already had on that same machine)
... what's the best way to keep a variety of VMs working?

Does anyone have a matrix of what VMWare/Parallels versions support
which macOS version as host / guest?

Mojca

Re: ACTION REQUIRED: Set your SMTP password

[Mojca Miklavec]

Dear Clemens,

On Wed, 18 Nov 2020 at 07:14, Clemens Lang wrote:
> On Wed, Nov 18, 2020 at 06:36:08AM +0100, Mojca Miklavec wrote:
> > Awesome, thank you very much for setting this up. GMail users
> > (including almost every GSOC student) were in fact unable to set up
> > sending emails from their macports alias, Google disabled that
> > functionality many years ago.
>
> Right, somebody should check whether the SMTP now re-enables doing this
> from the GMail web interface.

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.

Mojca

Re: ACTION REQUIRED: Set your SMTP password

[Mojca Miklavec]

Dear Clemens,

On Wed, 18 Nov 2020 at 04:37, Clemens Lang wrote:
>
> If you have a @macports.org email address, please do the following steps
> now:
>
>  - Ensure your @macports.org email address has been added to your GitHub
>account and is verified on GitHub.
>  - Go to https://smtpselfservice.macports.org/, log in using GitHub, and
>set your SMTP password.
>  - Configure your mail client to send mail from your @macports.org
>address as documented at
>https://smtpselfservice.macports.org/settings.

Awesome, thank you very much for setting this up.
GMail users (including almost every GSOC student) were in fact unable
to set up sending emails from their macports alias, Google disabled
that functionality many years ago.

It would be nice to document this for future users, maybe somewhere under
https://trac.macports.org/wiki/CommittersGuide or
https://trac.macports.org/wiki/NewCommittersGuide
or wherever it seems more suitable.

Thanks again,
Mojca

Time to remove Travis support?

[Mojca Miklavec]

Hi,

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

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

Mojca

Fwd: [GSoC Mentors] Announcing GSoC 2021 with a few changes

[Mojca Miklavec]

-- Forwarded message -

Hello GSoC Mentors and Org Admins,

We are pleased to announce Google Summer of Code 2021 ,
the 17th consecutive year of the program!

As many of you might have heard if you attended the Mentor Summit a couple
of weeks ago (or chatted with someone who did) we are making a few changes
for the 2021 program. We’ve spent a lot of time evaluating the GSoC program
and have been looking at where we can make some changes to help meet the #1
goal of GSoC - bring new, diverse contributors into your communities that
stay in your communities after their GSoC program ends. And with the
challenges of the pandemic and the strains it has put on everyone’s time
(students, mentors and org admins alike) we are looking to provide more
flexibility in 2021.

What are the changes for 2021 from 2020?

   1. *Smaller project size** - *all students participating in the 2021
   program will be working on a 175 hour project (instead of a 350 hr
   project). This change will also result in a few other changes including the
   student stipend being cut in half.


   - Currently we are missing out on many wonderful students who could
   never commit to such a huge project and time commitment but would be great
   contributors to your community. This is a significant change as we now are
   no longer strongly encouraging students to focus only on GSoC over their
   summer. Students have many other responsibilities especially during the
   pandemic that make it hard for them to spend 30 hours a week on a project.
   - We realize this is going to require all of you to think about smaller
   projects and update your project ideas which is why we wanted to give you
   3+ months to start talking it through with your communities.
   - The mentor stipends will be adjusted to $400 per student mentored. In
   feedback from the mentor summit it was pointed out that the effort from
   mentors will not be half as much even though the project size is cut in
   half so we adjusted from $250 to $400.


   1. *Shortened coding period* - the *coding period will be 10 weeks* with
   a lot more flexibility for the mentor and student to decide together how
   they want to spread the work out over the summer. Some folks may choose to
   stick to a 17-18 hour a week schedule with their students, others may
   factor in a couple of breaks during the program (for student and mentor)
   and some may have students focus 30 hours a week on their project so they
   wrap up in 6 weeks. This also makes it a lot easier for students with
   finals or other commitments (weddings, etc.) to adjust their schedules.
   2.

   *2 evaluations  (instead of 3)* - There will be an evaluation after 5
   weeks and the final evaluation will take place after the 10th week. We are
   also no longer requiring students complete their first evaluation (though
   we encourage them to do so), so if a student doesn’t complete the first
   evaluation they will not automatically be removed from the program. They
   are still required to complete the final evaluation.
   3.

   *Eligibility requirements* - In 2020 there are many ways students are
   learning and we want to acknowledge that so we will be allowing students
   who are 18 years old AND currently enrolled (or accepted into) a
   post-secondary academic program as of May 17, 2021 or have graduated from a
   post-secondary academic program between December 1, 2020 and May 17, 2021
   to apply to the GSoC program.


   - What this means is that now the program will be open to folks
   participating in a variety of different academic programs, not just
   accredited university programs. This includes licensed coding camps,
   community colleges, and many other programs that may not be accredited yet
   but are post-secondary academic programs.

These changes were made to help find more diverse students who we hope will
stay involved in your communities after their GSoC ends. We look forward to
these changes and will definitely be getting feedback from all of you as
the 2021 program goes on to see what is working and what we should consider
adjusting for any possible future program.

The program announcement

, timeline ,
marketing materials
 (slide
deck, flyers), FAQs ,
and short videos 
with tips for mentors and students are all available. You'll also notice
the 2020 program has now been archived
.

*Organizations* -- If you would like to apply for the 2021 program please
start thinking about the ~175 hr projects you would like students to work
on and also reach out to your community members to ask 

Re: Updating OpenSSH port to 8.4p1

[Mojca Miklavec]

Dear Blake,

On Wed, 30 Sep 2020 at 19:56, Blake Garner wrote:
>
> I see that the port for OpenSSH has no maintainer and hasn't been updated in 
> a while. Reviewing the docs it looks reasonable for me to try and update the 
> port and submit it. Is anybody else already working on it?

I cannot answer about whether anyone else is working on this, but new
contributors are always welcome and greatly appreciated.

> Advice for a updating a port the first time beyond what's on the site?

Apart from updating the port itself we also need to increase the
revision of all the ports depending on OpenSSH (and ideally check
whether they still build after the update).
(Updating the dependencies may be done in a separate commit, but it
needs to be taken care of.)

As the first approximation you could get the list of dependent ports here:
https://ports.macports.org/port/openssh/
(The list may not be 100% accurate, so another grep for openssh inside
the ports tree may not hurt.)

On the website you can also check the list of open tickets:
https://ports.macports.org/port/openssh/tickets
We are not asking you to address any of those, but sometimes an update
resolves an issue, or there's already an update request in the trac
that can be closed.

Mojca

Re: Travis CI timeouts for MacPorts builds

[Mojca Miklavec]

On Tue, 8 Sep 2020 at 19:25, Ralph Seichter wrote:
>
> * Mojca Miklavec:
>
> >> If I can assist, let me know, but I don't think it likely at this
> >> point.
> >
> > Because you lack time or for some other reason?
>
> I would make the time for MacPorts. My assumption is just that I still
> know to little about how the MacPorts builds work to be of assistance,
> and that "you guys" have matters in hand.

Our manpower is pretty limited.
There are many contributors to ports, but not so many who contribute
to the base & infrastructure. It's a very small group of people with
full-time jobs and other hobbies. To the best of my knowledge nobody
is actively working on solving this particular challenge to better
address building PRs (it's doable, it just requires some time
investment).

So any helping hand would be extremely welcome.

> If you think that I can
> actually help, and if there is documentation or source code available,
> please let me know. I'm ready for some reading. ;-)

I definitely believe that new contributors can bring in a lot of
useful stuff, and if you are willing to tackle this challenge, we
would certainly be very very grateful.

I can provide some pointers to the existing code, but I'm pretty sure
that it would be more of a hindrance than of any actual help. To
clarify: you can either decide to start improving the existing tools
(and in that case having a better understanding of them is a must),
but proof-of-concept for disposable images for building ports in PRs
doesn't require any special knowledge about the current codebase.

There are the following parts that need to be addressed:

(1.)
  (a) prepare a set of images with different macOS versions (for as
far back in history as it gets, but start with one)
  (b) for later: find the easiest way to keep updating MacPorts and
macOS inside the base image on regular bases
(2.)
  (a) figure out how to fire up a disposable image, build a
hello_world.cpp on it, report build success/failure and destroy the VM
  (b) figure out how to do that using either
http://docs.buildbot.net/latest/manual/configuration/workers-libvirt.html
or something equivalent

The repository for infrastructure is mostly here (again, no need to
understand any of it right now unless you want to contribute there
directly with other improvements):
https://github.com/macports/macports-infrastructure
I'm not sure if we have some really good pieces of documentation about
how it all works (there is some internal documentation for those who
run the server), but feel free to ask if there is any part of the
project where you would like to contribute to in particular.

Ryan is currently working on a rewrite of buildbot setup, so the above
link is already "old" in a sense.

Mojca

Re: Travis CI timeouts for MacPorts builds

[Mojca Miklavec]

On Tue, 8 Sep 2020 at 22:43, Clemens Lang wrote:
> On Tue, Sep 08, 2020 at 06:48:58PM +, Zero King wrote:
> > On Tue, Sep 08, 2020 at 06:39:41PM +0200, Mojca Miklavec wrote:
> > > After a while Azure came around with 6 hours of timeout which was a
> > > lot more useful, and the same solution was ported from Travis to
> > > Azure. I forgot why we never switched from Azure to GitHub Actions.
> >
> > Done in commit db7b40d8691e1fcd8b6be5e3c2a2a00a7ce0bdf4. We should
> > remove Travis CI and Azure Pipelines soon.
>
> I'm not sure this was a good choice. GitHub recently announced stricter
> limits on CPU minutes available though GitHub actions.

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

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

Mojca

Re: Travis CI timeouts for MacPorts builds

[Mojca Miklavec]

On Tue, 8 Sep 2020 at 20:49, Zero King wrote:
>
> > I forgot why we never switched from Azure to GitHub Actions.
>
> Done in commit db7b40d8691e1fcd8b6be5e3c2a2a00a7ce0bdf4. We should
> remove Travis CI and Azure Pipelines soon.

Awesome, thank you very much!

I'm just confused about one thing. The docs says that only 10.15 is supported:

https://docs.github.com/en/actions/reference/virtual-environments-for-github-hosted-runners
while the github actions lists 10.14. Is the truth somewhere inbetween?

Mojca

Re: Travis CI timeouts for MacPorts builds

[Mojca Miklavec]

On Tue, 8 Sep 2020 at 19:11, Ralph Seichter wrote:
>
> * Ryan Schmidt:
>
> >> Tries being the operative word here. ;-)
> >
> > What are you trying to say?
>
> Did I step on somebody's toes?

I'm not aware why you would step on anyone's toes, but I also didn't
understand what you tried to say in that sentence.

> I am saying that the build that concerns
> me timed out setting up the dependencies. That, from my understanding,
> means the dependencies were either unavailable in binary form, or that
> the attempt to access said binary form failed. Hence my comment above,
> in an attempt to make light of the situation, as the smiley indicates.
>
> > We would need to see logs of the installation of the dependencies to
> > know why they're taking so long, but I don't see any such logs, and
> > don't know where or how that's happening or not happening.
>
> That makes tackling the underlying issue difficult, of course.

You can in fact look at the equivalent builds from Azure, for example here:
https://dev.azure.com/macports/macports-ports/_build/results?buildId=9200=logs=dde54236-b8c5-5879-af99-818e7b59912f=204c7e84-6a60-5987-1292-f9e129aab6e1

At the bottom you have a pastebin link with the build log of the port itself.
However the logs from building dependencies are apparently missing. I
thought those were available as well.
I'm not 100% sure, but maybe we deliberately removed those at some
point because it was consuming significant resources and it was deemed
nearly useless. (I'm not saying that's true in your case.)

> > We don't "ignore Travis results".
>
> Mojca Miklavec wrote (quote) "Generally we mostly ignore Travis results,
> so there's no real reason to worry in your case.", which led me to
> believe that you generally mostly ignore Travis results. How silly of
> me. :-)

Just to clarify my oversimplification.

We don't literally ignore the results.

If the Travis builds succeed ... we usually ignore the details :) :) :)

If the Travis build fails, we would usually look into the reason for
the failure, however:

(1) In nearly all the cases (not all though!!!) the reason for the
failure is either timeout or some network or timing issue. If that
happens, we would "ignore" the fact that Travis build failed. What
this mostly means is that users should not worry that their PR won't
be accepted just because Travis decided to put a red cross to the CI
job. In some cases the port would be manually checked by someone else
to ensure that it builds. We could have payed a bit more attention to
the individual builds to see if there is some flaw and we could have
forced the dependencies to build faster.

(2) In some other cases there would be a real build failure, but again
this most often means that it would fail everywhere, so we would see a
failure on Azure as well.

(3) There's another large class of cases where the software is only
supported on, say, 10.14 and newer. In those cases the Azure build
would succeed (just because it only uses the newer OS versions) and
the Travis build would fail (as it tries to build on older builders).
But again, if someone is porting software that upstream doesn't bother
supporting on older OSes, we won't generally block the PR just because
the older macOS versions are no longer compatible.

There certainly are cases where the results are useful. It's just not
as often as we wish it would be.

Mojca

Re: Travis CI timeouts for MacPorts builds

[Mojca Miklavec]

On Mon, 7 Sep 2020 at 20:25, Ralph Seichter wrote:
> * Mojca Miklavec:
>
> > We should figure out:
> > - which dependencies time out
> > - why they are not installed from (the private) binary package repository
>
> I'm guessing that "we" means the devs who maintain the build config.

Oh, no, that's the wrong interpretation.
"We" includes anyone interested in helping out.
There are certain tasks (like enabling some external service on the
github, connecting with some new hardware, ...) that can only be done
by a small group of people with administration access, but everything
else happens via pull requests (or sometimes direct commits) or new
code / repositories.

The community depends exclusively on volunteers. Many of the
contributors who devoted more time in the past and made some major
contributions have a lot less time to spend with the project nowadays,
so anyone willing to help out is mostly welcome.

> If
> I can assist, let me know, but I don't think it likely at this point.

Because you lack time or for some other reason?
If you think you could help, we would be most grateful.

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

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

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

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

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

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

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

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

On Tue, 8 Sep 2020 at 18:28, Ryan Schmidt wrote:
> On Sep 7, 2020, at 11:24, Ruben Di Battista wrote:
>
> > Would à Linux machine with some virtualization method (libvirt?) be 
> > acceptable as CI runner?
>
> I can't see how, since we're trying to verify builds of ports, and there is 
> no general expectation that port builds would work on non-Mac operating 
> systems.

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

Mojca

Re: Travis CI timeouts for MacPorts builds

[Mojca Miklavec]

On Mon, 7 Sep 2020 at 18:25, Ruben Di Battista wrote:
>
> I was wondering... Would à Linux machine with some virtualization method 
> (libvirt?) be acceptable as CI runner?

This is something we've been looking at, among others.
Now, a Linux machine with libvirt is probably not entirely legal, but
a mac with libvirt should be, and I guess it would work in exactly the
same way.

We tried to follow these instructions:
https://github.com/kholia/OSX-KVM
and we got it mostly working, it's just annoyingly slow because the
image gets downloaded as part of the process (I don't know if you can
easily cache it if the installation fails).

The other thing is that I'm not sure if one could get this working
with older OS versions, or how to handle ARM.

Running the image on macOS should be acceptable.

> Any of you has experience in terms of performance?

I wouldn't worry too much. It's not like we are getting thousand PRs
per day. And if that becomes the bottleneck, we could always set up
another worker for the same macOS version.

We are already running the existing builders inside virtual machines.
It may take two weeks when the new macOS comes out (and days after
1000+ perl submodules get new subports), but the machines keep up with
the load. The only bottleneck was PowerMac.

> Also, Gitlab CI allows to attach personal runners to project very easily 
> (just a package to install from the os package manager) . How does it work 
> for Github?

GitHub doesn't have the CI as "tightly integrated" as the gitlab runners.
Basically you can "attach" almost any given CI.
If you look at commit history, you'll see green checks and red crosses.
If you click on those, you'll see the list of builds with links to our
buildbot builds.

Those are the "official builds" of the packages. We could have
something similar for the CI.

On Mon, 7 Sep 2020 at 18:52, Ralph Seichter wrote:
>
> * Mojca Miklavec:
>
> > If you volunteer to do some research / work in this area ... that
> > would likely be the most significant step in "increasing your chances"
>
> I actually have some experience in this field. I use GitLab (Omnibus
> edition), Docker, and GitLab Runners inside Docker for CI/CD. That's
> basically the setup which gitlab.com uses (albeit sans their S3-based
> caching), and it can handle serious builds.
>
> Doing research re MacPorts would require knowledge about the MP build
> infrastructure, which I don't yet have. I'd be willing to look into it,
> though, if that infrastructure is properly documented somewhere.

The part that requires research hasn't been implemented yet, so the
good news is that you don't need any special knowledge about the
existing infrastructure :)

What we need is:
- a list of recipes to set up images for a bunch of different macOS
versions (as far back into history as possible)
- a recipe for how to fire up a VM, do something basic (port install
foo) and trash the result

The next step would be to perhaps integrate this into buildbot, but
there's no need to use exactly buildbot for this. Anything else that
does the job would also serve just fine.

Mojca

Re: Travis CI timeouts for MacPorts builds

[Mojca Miklavec]

On Mon, 7 Sep 2020 at 18:44, Ralph Seichter wrote:
> * Joshua Root:
>
> >> [1] https://travis-ci.org/github/macports/macports-ports/jobs/724689780
> >
> > It's just a matter of how long your port takes to build (including
> > installing all its dependencies).
>
> Notmuch, which is what was built in the job [1], is small and builds in
> less than a minute on my MacBook once the prerequisites are installed.
> Perhaps you'd like to try it for yourself.
>
> Is the Travis-based build just installing the dependencies (as in: the
> binary packages), or does it also build the dependencies from source?

It tries to install dependencies as binaries, provided the binaries
are available.

The job [1] clearly times out during installation of dependencies.
We should figure out:
- which dependencies time out
- why they are not installed from (the private) binary package repository

> I suspect the latter. I actually tried that here, and it took ages,
> even on my octa-core machine.

There are some packages that are not distributable for licence
conflicts. On your own machine they would always be installed from
source unless we figure out that the licence conflict resolution is
too greedy and fix it by either removing some dependencies or by
explicitly declaring a dependency as a non-conflicting one.

But on Travis & Azure those dependencies should be fetched from the
private archive. If we find out why they are not, we might easily find
the cure for your particular case (or maybe for many other cases as
well). We could start by investigating the logs revealing which
packages built from source on Azure.

Generally we mostly ignore Travis results, so there's no real reason
to worry in your case. It's just that we might be able to solve a
larger cluster of builds if we diagnose & fix the problem.

(We should probably write the list of dependencies as they are being
installed on stdout inside the CI script, without the debug output of
course.)

Mojca

Re: Travis CI timeouts for MacPorts builds

[Mojca Miklavec]

On Mon, 7 Sep 2020 at 10:46, Ralph Seichter wrote:
>
> I fail to remember the last time one of my builds successfully passed
> Travis CI. All I see are timeouts [1]. Other peoples' jobs apparently
> make it through Travis OK, so I wander what I can do to increase my
> chances?

By far the best thing would be to implement the functionality that
would allow firing up a clean VM, do the build, close the VM & destroy
it, and run this on our own buildbot workers.

This requires both manpower to implement the functionality as well as
additional hardware resources to run the builds.
If we solve the first part, I guess we should be able to solve the
second one as well.
If you volunteer to do some research / work in this area ... that
would likely be the most significant step in "increasing your chances"
... probably up to 100% for the ports that have no chance in building
in < 50 minutes on a super slow hardware owned by Travis :)

Mojca

Re: MacPorts webapp project updates

[Mojca Miklavec]

On Fri, 14 Aug 2020 at 15:10, Craig Treleaven  wrote:
> On Jul 12, 2020, at 2:55 PM, Arjun Salyan  wrote:
>
>> Hello all,
>>
>> This is in continuation to my previous emails regarding updates about the 
>> webapp. The temporary version is deployed at http://macports.silentfox.tech/
>
> Is the temporary version of the new web app down at the moment?

Sadly yes. The free trial that Amar had expired a few days ago and we
are waiting for Amar to set up the app again on a new server (first
for testing and very soon after that for real).

> Does our new web app highlight which packages are available as binary 
> installs?

Good point. We should be able to get that piece of information, but I
don't remember seeing that or having it on our roadmap. It would be
nice though, and probably not that much work to add this piece of
information.

> For example, version 3.16.0 of the port logrotate is available as a binary 
> install for Darwin 10 through 19:
>
> http://packages.macports.org/logrotate/
>
> I imagine it would be more difficult to show that all the dependencies needed 
> for a particular port are also available as binary installs.

It cannot be calculated once, in any case. A change somewhere deep
down in dependency chain could easily break binary distributability.
I also don't imagine an easy database call to retrieve this
information. So we would likely need a python function recursing
through the dependencies, and then this should be updated on regular
basis. It sounds a bit convoluted and probably not extremely high on
priority list.

On the other hand, maybe at some point we should be storing a list of
all dependencies of a particular port. Then, whenever any port is
updated, we would also update any port that has that one anywhere in
dependency list.

(Please note that we are only listing dependencies for the latest OS.
And even then we had potential issues with the server not running on
macOS and thus rendering a different list of ports. I think this has
been addressed, but it still means that a port that's distributable on
one OS may not be distributable on another one. Distributability per
OS could be done, but list of dependencies would require quite some
changes to the database. I was thinking about this problem from the
start, but I didn't want to overcomplicate the design of the app
itself.)

> Nonetheless, I think it might be worthwhile to show what _is_ available in 
> binary.  It would make an interesting top level statistic, if possible.

I agree.

> Of course, we ought to footnote somewhere that binary installs are only 
> available if installing the default variant to the default prefix.
>
> The ongoing discussions about reinventing the ‘brew cask’ wheel suggested to 
> me that perhaps we should better help users to understand that the majority 
> of packages on MacPorts DO NOT have to be compiled on the user’s system.

I'm also still desperate about the problem with git (= I still fail to
understand why we must be almost the only package manager out there
that is not allowed to distribute git in binary form).

Mojca

How should we handle subports / stub ports on the website?

[Mojca Miklavec]

Hi,

Arjun recently added a new simplified port view, see for example:
http://macports.silentfox.tech/port/py-numpy/
and it has been pointed out (rightly so) that we should not be encouraging
users to run
sudo port install py-numpy
but rather make it clear that the port contains a number of more useful
subports.

So here's a list of questions:
(1) How do we know which ports are stub ports?
(2) In what ways exactly should the treatment of such cases be different?

Ad (1):
The first question is the most important one. We could start by hardcoding
py-* and p5-* as stubs and expand the manually curated(?) list later on.
Ideally I would like to see some property implemented in the macports base,
so that PortIndex could know out-of-the-box when something is a stub port.

Also, Arjun recently added the super cool new functionality to subscribe to
ports and get notified when the ports are updated, or see which ones from
the list that you are interested in are outdated. The problem is that
subscribing to py38-numpy for example will not tell you that the port is
outdated since the livecheck gets disabled for subports.

It would be helpful if ports would internally say "the version of this port
is the same as the version of some-other-port" rather than disable the
livecheck completely. Then one could run livecheck either in default or
"extended" mode to either list the notification once (just for the main
port) or multiple times (or rather: it would be able to tell you whether
py38-numpy is out of date).

Ad (2):
What exactly should be different? In any case I would be inclined to list
all subports from the same file on the same page. So if users end up
looking at lilypond, they'll also get a link to lilypond-devel. If they'll
be looking at py38-numpy, they'll also get all the py*-numpy subports. But
the stub port should be explicitly different, it should not suggest users
to install that port. How exactly would you make the page look?

In what other ways should such stub ports be different? What do we do with
the statistics pages? In the case of perl it's technically still allowed to
install p5-foo (which just installs that one port plus another one that's
more useful).

I guess that users should still be able to subscribe to stub ports to see
whether they have been outdated.

Thank you,
Mojca

Re: MacPorts webapp project updates

[Mojca Miklavec]

Dear Frank,

On Sun, 19 Jul 2020 at 00:27, Frank Schima wrote:
>
> Looks really good. I love dark mode!
>
> Some quick comments:
>  - Remove all commas as a separator. A space works great.

What counts as "all"? For maintainers, variants?

>  - Sort the variants alphabetically and also ports that depend on the 
> currently selected port.

The variants could certainly be sorted, but dependencies seem already
sorted to me.

Unless you expected them to be sorted vertically rather than horizontally?
That's debatable, but copy-pasting gives you the correct order.
Or where (which port) do you see an issue with the list not being sorted?

>  - Clicking on a variant does not really make sense to me. It seems to go 
> back to the search page.
> The description of the variant should at least appear when you hover over a 
> variant. Maybe they should not even be clickable links?

It gives you all the ports with a particular variant. Most of the time
this is useless, I agree, but there's also no reason to remove the
functionality now that we have it in place. There are rare occasions
where you would want to unify some functionality and then you might
want to check, say, how many ports use +doc and how many ports use
+docs etc.

(At some point we discussed whether having a clickable licence to show
all ports with the same licence made sense.)

The problem with variant descriptions is that this information is
missing from the PortIndex. Here's an example of the file used for
importing the port data:

http://nue.de.rsync.macports.org/macports/release/ports/PortIndex_darwin_18_i386/PortIndex.json

Arjun recently added MacPorts to the Dockerfile for the sake of being
able to run livecheck (and potentially other useful tasks like
generating the PortIndex more frequently than what the main server is
offering), so the built-in installation of MacPorts could potentially
be used to harvest the data about variant descriptions.

Maybe we could first import the list of all ports on the first
installation, then start harvesting information about variants once
the first import is done, and then update that information whenever
the Portfile is touched in git.

>  - Python stub ports don’t really make sense. Search for, say, py-numpy. 
> That’s a stub port. It should probably state that you would never install it 
> - so don’t display “sudo port install py-numpy” for it because users should 
> never actually do that in this case. But instead you want to pick py36-numpy, 
> py37-numpy, etc. Show all of the real ports as clickable links. Currently it 
> does not even allow you pick any of them.

We just discussed adding a clickable list of all subports today.

But how do you know that py-numpy is a stub port? By hardcoding a
function like the following [pseudocode]:

def is_stub_port:
return (path ~= "^python\/py-.*" and name ~= "^py-.*") or
(path ~= "^perl\/p5-.*" and name ~= "^p5-.*")

and adding more exceptions as they get discovered?

Arjun has only recently added the simplified overview with
instructions for installing a port. Until we had that page, having
non-modified pages for stub ports still made sense. And it still makes
sense in many cases now. For example, users should still be able to
add py-numpy to their watchlist to receive notifications about whether
that particular port has been updated. But I agree that we should not
confuse users by telling them to run "sudo port install py-numpy".

>  - When clicking on the Trac tickets tab, I find it jarring that a window 
> pops up that you have to click out of. Just make it a tab that displays the 
> selectable tickets (or no tickets). I shouldn’t have to click “Close” to get 
> out  of this special mode.

We discussed the annoyance of clicking "Close" just today for another
button ("More ..." for getting the full description).

While I don't personally care that much, I also found it more useful
to see it displayed inside a separate tab as is the case on
https://ports.macports.org/port/py-numpy/tickets
for example.

Thanks a lot for the feedback!

Mojca

Re: MacPorts webapp project updates

[Mojca Miklavec]

Hi,

This is just a reminder that we would be extremely happy for further
feedback about the new page.

Arjun has added some pretty awesome new features. (Dark mode has been
supported since yesterday etc.)

It would be great to hear what you think while Arjun is still actively
working on the project :)

Mojca

PS: Also, we are still looking for some talented designer to join the
effort and make the page even more awesome than it already is.

On Sun, 12 Jul 2020 at 20:56, Arjun Salyan  wrote:

> Hello all,
>
> This is in continuation to my previous emails regarding updates about the
> webapp. The temporary version is deployed at
> http://macports.silentfox.tech/
>
> *New features:*
>
> *Accounts:*
> Users can now create accounts on the webapp using email/password or login
> with their GitHub handles.
>
> *Watchlist and notifications:*
> Logged-in users can add ports to the watchlist. Notifications are
> displayed whenever a port gets updated. An overview of the followed ports
> is displayed with filters for "broken builds", "outdated livecheck" etc.
>
> *"Followed by me" ports*
> Logged-in users can get an overview of the ports that they maintain (this
> is done by matching their emails and GitHub handles with those supplied in
> the Portfiles).
>
> *"Splash screen" (upcoming)*
> It was pointed out that our current port page (
> http://macports.silentfox.tech/port/cctools/) contains a lot of technical
> information which might not be useful for the general user. This reduces
> the odds of user acquisition. So, we plan to add a page with a focus on the
> software version and installation instructions. It will have a link to the
> existing page under "Details". Maintainers and advanced users will be able
> to by-pass this page (setting a cookie with the preferred page) and reach
> the details page directly. Existing links will be maintained in this
> process.
>
> Feedback and suggestions would be very constructive.
>
> Thank You
>
>

Re: randomly bumping things to require perl 5.30 vs 5.28 requires everyone to have both installed ...

[Mojca Miklavec]

On Mon, 22 Jun 2020 at 21:34, Daniel J. Luke wrote:
>
> We'd just need to either revbump everything that needs a rebuild when a new 
> minor perl version comes out (all the p5- ports to start)

I would say that we happily accept a pull request that "just bumps"
all dependents of perl5[.x].
Then all the ports will magically work with 5.30.

I seriously mean that. In the past I've done some batch updates, but
it's still hundreds of ports, and it's a non-trivial amount of work
even if the individual updates are trivial. At least in the ports I
touched I tried to ensure that the perl version is only mentioned once
and the variable is being reused elsewhere, so you just need to
replace 5.28 with 5.30, revbump and see if the ports stil builds (in
most cases it does; there are some clusters of software that need to
use the exact same version of perl at once).

> OR some enhancement to base to make it so the revbump is unnecessary.

That's not feasible. Unless the enhancement is to uninstall all ports
and reinstall them from scratch.

Mojca

Call for designers for our ports website

[Mojca Miklavec]

Dear MacPorters,

As part of a GSOC project Arjun has been working on great new features
for our web application with information about ports.

The application from last year has been deployed at
https://ports.macports.org/
while the new testing site is temporarily located at
http://macports.silentfox.tech/

The website already looks nice, but if we had some talented designers
among our users willing to help us go one step beyond what we have
right now, we would be extremely grateful for either just some advice
or potentially some more extensive help. There are a lot of minor
tweaks that could be done, but neither of us is a designer, and I'm
not able to give any competent advice about how to best improve the
layout.

Here are some concrete examples of subpages:
- http://macports.silentfox.tech/port/root6/
- http://macports.silentfox.tech/port/gnuplot/stats/?days=365_ago=0
- http://macports.silentfox.tech/search/?installed_file==root=on

Thank you very much in advance,
Mojca

Re: MacPorts webapp project updates

[Mojca Miklavec]

Dear Ryan,

On Mon, 18 May 2020 at 21:47, Ryan Schmidt wrote:
> On May 17, 2020, at 11:48, Arjun Salyan wrote:
>
> > We also plan to add a caching engine so that exploring the webapp remains 
> > smooth even with the ever-growing port statistics data. This makes the need 
> > for a new host even more important.
>
> Not sure specifically what you're planning with regard to caching, but note 
> that we already have an arrangement with the MaxCDN content delivery network 
> and we currently use it for www, guide, distfiles and packages. We can also 
> use it for the ports webapp if desired. It would just be a matter of tuning 
> the settings to decide how long the data should be cached.

The caching is primarily not so much about big data files (or actual
troubles with tons of visitors) as it is about whether the query "Show
me on which macOS versions the wine port is broken" needs to be
executed in the database every single time any random visitor opens or
refreshes the port page (even if the port didn't see any changes for
months and meanwhile thousands of visitors query the page). I don't
know to what extent MaxCDN can help here given that the main problem
is the lack of memory required to even run the site on the existing
server.

We can certainly check whether we could make use of MaxCDN (I don't
know to what extent a page that's dynamic in nature can be supported
there), but the immediate "urgency" is to find an alternative hosting
solution altogether.

Mojca

GSOC 2020 & web app improvements

[Mojca Miklavec]

Dear Arjun, dear MacPorters,

I would like to congratulate Arjun for being accepted into GSOC 2020
with the project of improving the ports.macports.org website. He has
already been with us last year and made an awesome tool which he's
about to improve this year. We are also enormously helpful to have an
external expert on board, Amar Takhar, who volunteered to mentor the
project and without whom we really couldn't have done this, along with
Rajdeep who participated as a student last year.

Due to specific situation this year and the uncertainty of the
government and university rescheduling the semester, Arjun already
started working at full speed while at home, so the summer might end
up a bit earlier than officially scheduled.

The code is being developed inside the existing repository
https://github.com/macports/macports-webapp/
The temporary site will run at
http://macports.silentfox.tech/
In addition to the communication via the mailing list we'll try using
the real-time chat at
https://chat.macports.org/channel/webapp
I'll ask Arjun to keep the list up-to-date with at least bi-weekly
emails, but feel free to join the chat or ask further questions at any
time.

The initial phase mostly concentrates on refactoring, speeding up and
cleaning up the code, also in order to make it easier for others to
contribute new code, while new features will be added once the code
base gets solid.

We received five proposals in total. I would like to thank all the
other students who applied this year. We were slightly more
conservative with the selection this year than we usually are,
partially due to the uncertain circumstances. We are still willing to
help you and work with you outside of the official GSOC program, so if
you would like to proceed with the projects, we will gladly help you
on the way.

Also a big thanks to all the volunteer mentors and org admin.

Mojca

Re: GSoC Proposal: Rewrite key parts of MacPorts in Python

[Mojca Miklavec]

Hi,

On Thu, 2 Apr 2020 at 20:37, Joshua Root wrote:
>
> I would say it's OK for a GSoC project to be completely original and
> never discussed before; the problem with this one is just the scope. You
> would need to spend the entire summer (if not more) just doing design in
> order to do it right, but the primary assessable output of the project
> is code. Naturally you need to do some design before you code, and other
> tasks like documentation of the code, but you need to write the code.
>
> It's also OK for a GSoC project to have research elements. A successful
> project may produce code that never actually gets put into production --
> maybe in the course of implementation it becomes clear that the entire
> approach is flawed. Learning that is still valuable.
>
> In this particular case, if the student can suggest a subset of the
> project with a small enough scope to be completed over the summer, that
> will still produce working code, it could be considered. I have no idea
> what that would look like, but it may be possible. As Ryan implied, an
> important question is "Which parts should be rewritten in Python, and why?"
>
> - Josh

I just want to say that I completely agree with Josh here.

I would love to see MacPorts (re)written in Python, this has been my
wish since years, but I realize that I neither have sufficient
expertise nor time to do it (I guess I could gain the expertise, but
that would again require insane amounts of time). And it's not like we
have an army of developers willing to do this at this very moment, but
if it was written in Python (in a nicely structured way), I guess that
the number of contributors to base would grow quite a bit.

I would say that the main reason why this hasn't been discussed (loud)
before is that developers understand how much work this is, and it
takes quite some expertise and quite some work to get it done right.
And rewriting is probably even more challenging than writing it from
scratch, since one would want to keep compatibility with the existing
packages, and ideally reproduce the exact same results. (We did in
fact discuss this during the last meeting, but not as realistic to
happen any time soon.)

But it's not entirely impossible to do it either. I mean ... MacPorts
base has been written at some point. HomeBrew has been written at some
point. Plenty of other package managers have been written from scratch
at some point. I would not dismiss the initial effort as a GSOC
project as long as the student can prove the competence to do some
good work and reasonable potential to stick with the project
afterwards. GSOC could be done partially as a research project. But
it's of course critical to have a very good student working on this.

If we would ever want to have the base rewritten (independent of
whether or not it happens in the scope of GSOC) and not want to end up
with yet another competitor to MacPorts, we would want to keep the
Portfile syntax working (one could later remove some hard-core tcl
from ports if there was an alternative to achieve the same). One could
potentially start with using Python to add useful new functionality
that's still missing and is either very annoying to write in Tcl, or
has a bigger contributor potential if written in Python; we could for
example support something like "port health " that would
fetch the data from the web api and report to the user whether the
port and its dependencies are know to build or break, whether there
are any critical bugs open in Trac, ... (just as a random example).
Some further action could later be replaced step by step, and in
parallel some bottom-up design would need to be built in Python to
slowly migrate over. (I'm not competent enough to mentor such a
project though.)

It's definitely not an easy task, but if the student can prove
competence to solve some problems in a superior way ...

Mojca

Thank you for applying for GSOC @ MacPorts

[Mojca Miklavec]

Dear students,

(I have put everyone in Bcc just in case, even though you are
generally encouraged to use public communication.)

I would like to thank each and every one of you for applying for the
GSOC 2020. We have received 5 applications this year (I'm sorry for my
own absence during this period), and the mentors are expected to
review them in the following days. The official results about the
selection process will be revealed on the 4th of May. The students are
encouraged to stay involved with the community both before and after
the official coding time.

While the official deadline for submission of the proposals is now
over, I would like to stress out that apart from the proposals
themselves, by far the most important criteria for selecting the
candidates will be showcasing your skillset through some
proof-of-concept code or via pull requests, depending on what project
you are targeting and in coordination with mentors. Last year most of
the activity happened already during the proposal submissions (I would
say that most of the last year's students contributed enough to get
them passed through the 1st evaluation before the coding even began
:), while many proposals arrived much later this year, so we would be
willing to give everyone cca. 2 weeks extra time to showcase your
work. Some projects are pretty demanding, so we would like to make
sure that the candidates can cope with all the challenges.

For Buildbot the contact persons are Povilas, Pierre & Amar (but maybe
use #buildbot on IRC and the buildbot mailing list), for MacPorts
base/core the contact persons are Marcus & Sat, for Django it is Amar
& Rajdeep (& me). Jackson serves as the admin. Again, I believe that
the mailing list might be more suitable than private emails if you
want to get more feedback from the community.

Mojca

Re: Update of port ehcache

[Mojca Miklavec]

On Mon, 30 Mar 2020 at 12:21, Jackson Isaac wrote:
>
> Is there a way non-members can assign themselves to a ticket ?

Probably not, but there are other problems. Even if you assign a
ticket to someone without the required permissions, that person still
won't be able to do anything about it (ticket cannot be closed,
modified in any reasonable way etc.)

I don't think there is a real need to assign tickets to people who
want to work on them. Leaving a note saying something "I'm working on
this" or sending a reference to the pull request should do. A proper
commit message on pull request will also close the ticket
automatically when done.

Mojca

Re: Migrating the guide to AsciiDoc

[Mojca Miklavec]

On Mon, 17 Feb 2020 at 21:05, Clemens Lang  wrote:
>
> Hi,
>
> On Sat, Feb 15, 2020 at 01:52:44AM +0100, Rainer Müller wrote:
> > 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.
>
> I agree. We should switch and then just fix the issues that are still
> open. I think we can live with suboptimal formatting for a while until
> somebody has the chance to fix it, especially if it's much easier to fix
> due to the more modern asciidoc syntax.

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.

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?

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

Mojca

Re: Packaging py-keyring

[Mojca Miklavec]

Dear David,

On Sat, 1 Feb 2020 at 22:15, David Gilman wrote:
>
> I've been taking a stab at packaging poetry, a package manager for
> Python.  It has a dependency on the py-keyring port which is
> maintained by reneeotten.
>
> The recent release of keyring v21 dropped support for Python before
> version 3.6.  Renee came up with a clever trick in the portfile: if
> the py35-keyring is being requested, install v20, the last compatible
> version instead:
>
> https://github.com/macports/macports-ports/blob/master/python/py-keyring/Portfile
>
> However, the maintainers of poetry want to keep backwards
> compatibility with old versions of Python.  They've explicitly pinned
> their dependency on v20 releases of keyring in order to keep poetry
> running on old Pythons.  If I want poetry to use the existing v20
> keyring I'll have to explicitly depend on python35 for everything
> which is a non-goal.

The way you explained it, I would assume that poetry developers use
v20 releases for their own purposes, but you didn't explicitly mention
whether v21 is in fact incompatible with the latest version.

I assume you wouldn't even be asking this if v21 was compatible, but
then again, I would expect from developers that while they might be
using v20 by default in their workflow, they should at least attempt
to remain compatible with the latest release of their dependencies (or
they might just as well declare to be compatible with python 2.7 only
...).

Various distributions cannot afford to stick with zillions of versions
of ancient packages for the same software (unless one goes the route
of npm and simply installs the full ecosystem and a 1 GB bundle of
packages for each tiny website separately).

> Does anyone have any suggestions on how the py-keyring package can be
> changed to support all of this?  I can copy the entire Portfile and
> rename it py-keyring20 and depend on that but I wonder if there's a
> way to extend the existing Portfile.

You could probably create a subport like py38-keyring20 inside
py-keyring. But it would make sense to figure out whether there's no
way to convince upstream to remain compatible with the latest release.

Mojca

GSOC mentor candidates

[Mojca Miklavec]

Hi,

In order to apply for GSOC we need to publish an up-to-date idea list.

MacPorts base make a significant (80%?) portion of the ideas list, so
it would be nice if we could make it clear as soon as possible whether
we have ideally two mentors willing to mentor base projects.

Marcus, Sat, or anyone else: please raise your hands if you would be
willing to participate this year as mentors, else we need to archive
those ideas and only leave a much shorter list.

Thanks in advance,
Mojca

Re: GSOC 2020

[Mojca Miklavec]

Dear Pierre,

On Tue, 7 Jan 2020 at 18:47, Pierre Tardy wrote:
>
> Hi,
>
> GSOC 2020 has been announced, I haven't seen a thread yet on macports being 
> an org.

We last discussed GSOC during the MacPorts meeting in Bohinj in
October where we went through the ideas list.

> We discussed the topic within Buildbot community, and we think we don't have 
> enough of our users as student, and are not attractive enough to be effective.
> But last years experience partnering with Macports was great, and we would 
> like to renew it.
>
> I don't know if this still makes sense for you to have a CI-dedicated GSOC 
> project idea, but Buildbot team will be officially happy to help with 
> mentoring of such project.

I'm still a bit afraid about our mentor forces, but I believe we will apply.
I'm a bit ashamed for not having deployed the setup yet, but
independent of there:
- there is still a number of issues which haven't been addressed last
year, for example the waterfall hasn't been completed / fully polished
yet for our needs
- there is still a lot to be done on the basic configuration for our
needs (including potentially working on VMs)

I would be in favour of publishing one project similar to last year's
one which would continue building on where we left off last year.
We would need to go through the feature requests / bug reports from
buildbot again and potentially (re)tag them properly. Plenty of them
already contain the GSOC tag.
But we would also need to check those few PRs that haven't been merged
yet (I believe there is still some small number there which
occasionally gets attacked by the stale bot).

What we need to do better this year is make it clear in advance where
the communication will happen as IRC didn't always work for everyone.
Aljaž has set up Rocket.chat on a private server (so hopefully no
issues with corporate and country firewalls; you were not the only one
blocked from Discord), and we could probably add IRC mirroring there
and allow reading the discussion with greater eas.

I wanted to attend the meeting on Tuesday, but I managed to notice I
missed it only after I received the email with the minutes.
(I'm also a bit confused about the timing which kind of shifts between
16 and 17 UTC, but not entirely consistent with daylight saving time
changes.)

Mojca

Re: invalid certificate chain during port-fetch

[Mojca Miklavec]

On Sun, 29 Dec 2019 at 13:46, Rainer Müller wrote:
> 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.

Except in this case it requires 10.12., which is newer than what our
existing infrastructure hardware supports?
Yes, I know that not even 10.11 is supported any longer, so that one
also counts as outdated.
And the port in question is not even in our port tree, but that's
irrelevant to the discussion.

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

Thinking of it ... the reported/suggested patch doesn't sound as bad after all.

Considering the potential alternatives of:
- manually downloading and copying the files (out of question, too
much work, cannot be automated)
- constantly fighting with broken updates & not being able to test anything
- shipping our own bundled copy of libcurl (dismissed many times as
not feasible)
- introducing a cyclic dependency & chicken-and-egg problem of using
curl or wget as we ship it (not possible)
- installing a second copy of macports just for the sake of being able
to build libcurl, manually building the full compiler toolchain just
for that simple program, manually compiling macports and getting the
change overridden each time MacPorts  is outdated (the only acceptable
solution that's annoying at least)
...
then trying to repeat the download with either ${prefix}/bin/curl or
${prefix}/bin/wget or whatever "default curl" points to (which would
always resolve to /usr/bin/curl if port curl is missing) doesn't sound
like such a bad idea to me. It could be a non-default configuration
option that only interested users on older systems would turn on, or
that would only be turned on by default on older systems ... to make
their user experience slightly better.

(Keep in mind that while this is definitely not our main focus, we are
probably the best package manager as far as support for older OSes is
concerned.)

Mojca

Re: Undefined symbols for architecture x86_64 on jsonnet submission

[Mojca Miklavec]

On Sat, 23 Nov 2019 at 15:53, Joshua Root wrote:
> On 2019-11-24 01:35 , Mojca Miklavec wrote:
> > On Sat, 23 Nov 2019 at 14:56, Steven Smith wrote:
> >>
> >>
> >> Here’s the current not-working Portfile:
> >>
> >> https://github.com/macports/macports-ports/blob/4a9cd2d6b34e6d48e22bfb608529e900f49f8dcb/devel/jsonnet/Portfile
> >
> > It builds perfectly fine for me (I built it with "sudo port -vt
> > destroot"), it only fails during the destroot phase (considering what
> > it tries to do, rightly so):
> >
> > mkdir -p /usr/local/bin
> > cp jsonnet jsonnetfmt /usr/local/bin/
> > cp: /usr/local/bin/jsonnet: Permission denied
> > cp: /usr/local/bin/jsonnetfmt: Permission denied
> > make: *** [install] Error 1
> >
> > You need to do at least two things:
> >
> > 1.) Replace lines like
> >  mkdir -p $(PREFIX)/bin
> > with
> >  mkdir -p $(DESTDIR)$(PREFIX)/bin
> > (and ask upstream to fix that).
> >
> > 2.) Add something like
> > build.env PREFIX=${prefix}
> > to your Portfile.
> >
> > However the paste which you linked is using CMake,  while the linked
> > Portfile is using make, so it's not really comparable.
>
> I'm pretty sure the CMakeLists is just buggy. The missing symbols are
> defined in libjsonnet.cpp, while is compiled to libjsonnet.cpp.o, but
> there's just no attempt to include any libraries or .o files other than
> libjsonnet++.cpp.o when linking libjsonnet++.0.14.0.dylib.

I also miss something simisar to
target_link_libraries(libjsonnet++ PRIVATE libjsonnet)
in the CMakeList (something similar is even commented out), but that's
in fact something that upstream needs to fix.

Mojca

Re: Undefined symbols for architecture x86_64 on jsonnet submission

[Mojca Miklavec]

On Sat, 23 Nov 2019 at 14:56, Steven Smith wrote:
>
>
> Here’s the current not-working Portfile:
>
> https://github.com/macports/macports-ports/blob/4a9cd2d6b34e6d48e22bfb608529e900f49f8dcb/devel/jsonnet/Portfile

It builds perfectly fine for me (I built it with "sudo port -vt
destroot"), it only fails during the destroot phase (considering what
it tries to do, rightly so):

mkdir -p /usr/local/bin
cp jsonnet jsonnetfmt /usr/local/bin/
cp: /usr/local/bin/jsonnet: Permission denied
cp: /usr/local/bin/jsonnetfmt: Permission denied
make: *** [install] Error 1

You need to do at least two things:

1.) Replace lines like
 mkdir -p $(PREFIX)/bin
with
 mkdir -p $(DESTDIR)$(PREFIX)/bin
(and ask upstream to fix that).

2.) Add something like
build.env PREFIX=${prefix}
to your Portfile.

However the paste which you linked is using CMake,  while the linked
Portfile is using make, so it's not really comparable.

Mojca

Re: keeping software forks under MacPorts repo?

[Mojca Miklavec]

On Sat, 9 Nov 2019 at 17:54, Ken Cunningham wrote:
>
> In #57751 Michael and I have been talking about how keeping up the patchset 
> for qt4 would probably be easier with our own fork of it, with our patches 
> added on.
>
> QT4 has a github repo here  and we could fork that 
> to MacPorts repo, and add our patches on there. Then we could draw from that 
> repo for builds instead of the way we do it now. We both think this would be 
> easier.
>
> I see Haiku already does that exact thing for some of their ports.
>
> Hopefully leaving aside a discussion about older systems / lots of patches/ 
> etc for the moment, is there any interest in having these occasional forks 
> under MacPorts github repo?
>
> Otherwise either Michael or I can do it ourselves, but that might have access 
> issues someday...
>
> On a similar note, we have a couple of ports in the same boat (llvm*, for 
> example). In those, Jeremy has his own fork with our patches, and uses a 
> script to generate the patchsets — but that’s tricky, because I can’t access 
> his repo very easily, so my patches are “extras” to his…

As long as someone is responsible for the individual repositories, I
would personally support this idea. But we would probably want to
prefix the repository names (something like "fork_qt", "fork_llvm") to
clearly distinguish them from our main repositories. Is it possible to
set up a cron job to keep the upstream branches and tags fully up to
date (but without deleting our own branches, and ideally without
accumulating deleted upstream branches)?

Mojca

Re: Update with same filename but different URL path not picked up

[Mojca Miklavec]

On Fri, 8 Nov 2019 at 21:53, Nils Breunese wrote:
>
> Hello,
>
> I’m the maintainer for AdoptOpenJDK in MacPorts and I'm trying to update the 
> OpenJ9-based OpenJDK subports. The URL's for the patched files have a 
> different path, but the filenames themselves are the same as the current one. 
> (Yes, AdoptOpenJDK should have updated the filenames as well, and they will 
> in the future.)
>
> Example subport: openjdk8-openj9
> Currently in MacPorts: 
> https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u232-b09_openj9-0.17.0/OpenJDK8U-jdk_x64_mac_openj9_8u232b09_openj9-0.17.0.tar.gz
> Newer patched version: 
> https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u232-b09.1_openj9-0.17.0/OpenJDK8U-jdk_x64_mac_openj9_8u232b09_openj9-0.17.0.tar.gz
>
> When I update master_sites to include ‘.1' it seems MacPorts doesn’t care 
> that the URL path has changed and uses the previous version. I guess this is 
> because files are cached/mirrored based on filename only? Is there any way 
> around this?

Yes, follow the procedure for stealth updates:
https://trac.macports.org/wiki/PortfileRecipes#stealth-updates

Mojca

Re: How to handle ports that are still broken because of the icu upgrade

[Mojca Miklavec]

On Fri, 25 Oct 2019 at 08:50, Joshua Root wrote:
>
> It's worth noting that the buildbot will never run into this problem
> because it deactivates all installed ports between builds.

Thanks a lot for the hint.

Simply deactivating a bunch of compilers lead to successful
compilation of libxml2.

Mojca

Re: How to handle ports that are still broken because of the icu upgrade

[Mojca Miklavec]

On Wed, 23 Oct 2019 at 03:49, Ryan Schmidt wrote:
>
> icu was recently updated to a new major version. As a result its install_name 
> changed and anything that links with it needs to be rebuilt against the new 
> version.
>
> All ports that declare a dependency on icu already had their revisions 
> increased for this reason. So if you are encountering a port that rev-upgrade 
> identifies as broken due to linking with an older icu, please take a moment 
> to investigate why and perform the correct fix, and don't only increase the 
> revision to rebuild it, which just kicks the can down the road until the next 
> time icu is updated.

I'm not sure if it falls into this category, but the most annoying
problem for me has been clang-9.0 on legacy systems. It depends on
libxml2 which is broken due to icu update, but I cannot rebuild
libxml2 because the compiler is broken. I thought that bootstrapping
was supposed to address this, but apparently it doesn't.

I'm somewhat lost about how even manually address the problem. Should
clang-9.0 use /opt/local/libexec/libcxx-bootstrap/lib/libxml2.2.dylib?

Mojca

Exclusion of clang compilers for ppc

[Mojca Miklavec]

Hi,

I fail to understand why this change was rejected / why we want to
have clang on the default list of fallback compilers for PPC, rather
than falling back to, say, gcc 6 or 7:
https://github.com/macports/macports-ports/pull/5590

Mojca

Re: Index Broken on 10.5

[Mojca Miklavec]

On Sun, 20 Oct 2019 at 17:47, Kenneth F. Cunningham
 wrote:
>
> Leopard Intel can run clang-7.0, and nothing newer at present. When I get 
> time, I will probably fix newer clangs.
>
> See 
> 
>
> for my suggestions on how to run Leopard Intel successfully on macports at 
> present.

There are two things that would be of enormous help once you figure
the above out:

1) Having a binary builder to get the precompiled binaries readily
available (not that much man-hours involved, more a question of
available hardware resources, Ryan mentioning that he had no suitable
image available, and some questioning the rationale of running such an
old VM ...)

2) Allow relocating binaries between different prefixes, at least some
basic ones (HomeBrew supports that). That would require more man-power
to write it.

Mojca

Re: 10.15 builder

[Mojca Miklavec]

> On 17 Oct 2019, at 2:07 pm, Jack Howarth wrote:
>
>I noticed that https://build.macports.org/builders doesn't show a 10.15 
> builder yet. Is there a schedule for when one will become available?

I want to add that while analysing the CDN logs during the meeting
(many thanks to @l2dy) we saw more than 5k failed downloads of perl
binaries for Catalina per day, and that's not even all users. It would
really help if we could start serving those users faster than they
give up ...

(Another screenshot is here
https://twitter.com/macports/status/1184134778385252353)

On Thu, 17 Oct 2019 at 21:40, Chris Jones wrote:
>
> On a similar note, it would be great to get a 10.15 builder for the azure 
> builds in github PRs. Whats needed to set these up ?

I guess we just need to add a line to

https://github.com/macports/macports-ports/blob/0a922a19d342b6cd5afc50d8b8d8c1de6ad0131c/azure-pipelines.yml#L10
but until we have the binary builders on buildbot ready, it's probably
pointless since just about everything will simply time out.

@l2dy was also testing github actions:
https://github.com/macports/macports-ports/pull/5510

Mojca

Re: Running buildbot-worker via launchctl

[Mojca Miklavec]

e
On Sat, 5 Oct 2019 at 17:01, Ken Cunningham wrote:
>
>> If I run it manually then it works as expected.
>
> Permissions issue, maybe with pid file?

On the good side: the exact same configuration works on 10.6, so no
clue why it doesn't on 10.13.

But the folder is owned by buildbot, the pid file doesn't exist, and
when I run the command manually, I also run it as a buildbot user.

Mojca

Re: Setting system gcc when `port select --set gcc app-gcc*` is set

[Mojca Miklavec]

On Thu, 3 Oct 2019 at 19:50, Steven Smith wrote:
>
> I have a build failure on a system with `port select --set gcc mp-gcc9` set:
>
> :info:build 
> /opt/local/lib/gcc9/gcc/x86_64-apple-darwin18/9.2.0/include-fixed/ma
> th.h:45:10: error:
> :info:build  fatal error: sys/cdefs.h: No such file or directory
> :info:build45 | #include 
> :info:build   |  ^
>
>
> This is with the port hlint, which uses port group haskell_cabal:
> https://github.com/macports/macports-ports/blob/master/_resources/port1.0/group/haskell_cabal-1.0.tcl
>
> The build works if I make sure that “gcc” points to /usr/bin/gcc.
>
> How should this be done in MacPorts to avoid this issue?

Convince upstream to address
https://github.com/haskell/cabal/issues/1325

While cabal should be able to pick its own favourite compiler, it
should not prevent the user to specify what precisely is needed /
wanted. Who says that all compilers are called "gcc"?

Other than that ... I don't know. Make a temporary bin folder insider
the build tree, make a symlink gcc -> ${configure.cc}, prepend that
folder to PATH. We also have an issue with git, not just with C.

Mojca

Re: Running buildbot-worker via launchctl

[Mojca Miklavec]

On Wed, 2 Oct 2019 at 03:30, Joshua Root wrote:
> On 2019-10-2 11:19 , Mojca Miklavec wrote:
> > sudo launchctl load -w
> > /Library/LaunchDaemons/org.macports.buildworker.name.plist
> > sudo launchctl start org.macports.buildworker.name
> >
> > But I keep getting the following error in /var/log/system.log
> >
> > Service exited with abnormal code: 1
> > Service only ran for 0 seconds. Pushing respawn out by 10 seconds.
>
> Nothing in the twistd.log for the worker?

It doesn't seem to come far enough to even open the log file, I guess.

Mojca

Running buildbot-worker via launchctl

[Mojca Miklavec]

Hi,

I tested buildbot-worker quite a bit, but maybe / apparently never
with launchctl.

The part that I don't quite understand is the following:

* I've been running buildbot-slave 0.8 for a few years as a
LaunchDeamon without any issues.

* I now tried to upgrade the setup to buildbot-worker 2. I create a
new worker dir with

sudo port install buildbot-worker
mkdir -p /opt/buildbot/workers/name
cd /opt/buildbot/workers/name
sudo -u buildbot buildworker create-worker -r . example.com:9989
slavename pass

added a plist file (the only difference between version 0.8 and 2.x
was the python version, service name and worker directory):

sudo launchctl load -w
/Library/LaunchDaemons/org.macports.buildworker.name.plist
sudo launchctl start org.macports.buildworker.name

But I keep getting the following error in /var/log/system.log

Service exited with abnormal code: 1
Service only ran for 0 seconds. Pushing respawn out by 10 seconds.

* If I run it manually via

cd /opt/buildbot/workers/name
sudo -u buildbot /opt/local/bin/twistd-3.7 --nodaemon \
--no_save--python=buildbot.tac --pidfile=buildslave.pid

then it works as expected.

I ran out of ideas about how to debug "Service exited with abnormal code: 1"

Mojca

Re: *-graveyard ports retired

[Mojca Miklavec]

On Mon, 30 Sep 2019 at 22:36, Joshua Root wrote:
>
> The p5-graveyard and py-graveyard ports have been removed as they no
> longer serve a useful purpose. The buildbot skips replaced ports
> automatically and thus doesn't generate the error reports that motivated
> the creation of the graveyards.

Why did you want error reports?
I thought the idea was to collect obsolete ports at a single place, so
that they would automatically get uninstalled.

> If you believe that setting replacements is useful for the users of your
> module port, you can do so in the individual portfile. Existing
> replacements have been moved to their portfiles of origin.

It would be nice to add better support to the two respective
portgroups, so that one could easily add obsolete ports with a simple
one-liner.

Mojca

MacPorts Meeting 11th-16th October

[Mojca Miklavec]

Dear MacPorters,

I would like to remind everyone that we are hosting the 3rd
international meeting in Bohinj, Slovenia, from Friday 11th to
Wednesday 16th of October.

We'll be located in one of the nicest corners of the small country in
central Europe, next to a glacier lake, surrounded by the Alps, with
lots of options for hiking, cycling, etc. before the meeting, or
during the meeting if you happen to bring your own family.

We tried hard to make the meeting acceptable to everyone, with just
150 EUR for both accommodation and full board for five nights.

We expect participants from China, India, Indonesia, Germany, Italy,
Slovenia, ...

It's a wonderful opportunity to start hacking together and get your
long-awaited features done.

https://trac.macports.org/wiki/Meetings/MacPortsMeeting2019

Please consider spending an awesome extended weekeng with us and register here:

https://forms.gle/JbSLkykLSZRu7Q4b8

Mojca

Re: CMake Question

[Mojca Miklavec]

On Sun, 29 Sep 2019 at 13:56, Mark Anderson wrote:
>
> So I have a CMake build that builds fine when I build it locally by hand 
> using ccmake, but as I try to turn it into a port file using the cmake 
> portgroup it fails. Does anyone know of a way to make ccmake spit out a 
> command line of what it used to generate?

Doesn't
sudo port -v build 
give you what you are looking for?

Maybe
sudo port -d build 
but that one is usually way too noisy.

Mojca

Re: MacPorts For 10.15 Catalina

[Mojca Miklavec]

On Thu, 26 Sep 2019 at 15:16, Shichao Dou wrote:
>
> I have a question to ask. I upgraded macOS to 10.15 Catalina Beta, but I 
> found that my MacPorts were not working.
>
> Want to know if there is a 10.15 Catalina update plan? When will it be 
> released?

MacPorts should work on 10.15 if you compile and install the macports
base from source:
https://www.macports.org/install.php#source

Because of the NDA we are not allowed to provide binaries, but the
sources should work, and the new binaries are expected very soon after
the release gets out of beta phase.

You should of course expect some problems here and there (in
particular the gcc compiler no longer works out of the box with the
release of the new xcode version), mostly because various software
authors have probably not yet adapted their source code to the
potentially stricter compiler, changes of the API in the new OS
release etc.

Mojca

Re: Publishing links to non-encrypted websites for MacPorts downloads

[Mojca Miklavec]

On Thu, 26 Sep 2019 at 07:19, Ryan Schmidt wrote:
> On Sep 26, 2019, at 00:04, Mojca Miklavec wrote:
>
> > I ended up navigating to
> >https://www.macports.org/install.php#installing
> > which points to
> >
> > https://github.com/macports/macports-base/releases/download/v2.6.0/MacPorts-2.6.0-10.6-SnowLeopard.pkg
> > which doesn't work on 10.6 without some additional software being
> > installed first.
> >
> > Now, the file is already at
> >
> > http://distfiles.macports.org/MacPorts/MacPorts-2.6.0-10.6-SnowLeopard.pkg
> > which I remembered from the last time, but I don't see any link to it
> > (I'm not saying there's not one, but if it is, it's definitely not
> > obvious to users).
>
> It's because I fail at git again. I pushed the change to my fork instead of 
> the main repo. I've pushed it to the main repo now.

Thank you.

> > (PS: we need a big visible Download button on the first page at some point 
> > ...)
>
> There's a download button at the top right of every page.
>
> Yes, we need to redesign the web site. I believe you already showed me 
> somebody else's redesign, which looked good.

... and we should pick up that thread again :)

https://lists.macports.org/pipermail/macports-dev/2019-May/040674.html

Mojca

Re: Publishing links to non-encrypted websites for MacPorts downloads

[Mojca Miklavec]

On Thu, 26 Sep 2019 at 06:26, Ryan Schmidt  wrote:
>
>
>
> On Sep 25, 2019, at 00:43, Mojca Miklavec wrote:
>
> > I already mentioned this in the past, but I would like to repeat.
> > When someone opens our homepage and wants to download MacPorts using
> > Safari on, say, 10.6, the download link from GitHub doesn't work, and
> > it's not trivial for users to find out the alternative link
> > (http://distfiles.macports.org/MacPorts/).
> >
> > Could we please publish both links to download MacPorts on our homepage?
>
> When Joshua releases a new version, he tags the release on GitHub and uploads 
> the files there, and switches the links on our web site to point to GitHub. 
> When I download the files to our distfiles server, I switch the links on the 
> web site back to our distfiles server. Is that not sufficient?

I ended up navigating to
https://www.macports.org/install.php#installing
which points to

https://github.com/macports/macports-base/releases/download/v2.6.0/MacPorts-2.6.0-10.6-SnowLeopard.pkg
which doesn't work on 10.6 without some additional software being
installed first.

Now, the file is already at
http://distfiles.macports.org/MacPorts/MacPorts-2.6.0-10.6-SnowLeopard.pkg
which I remembered from the last time, but I don't see any link to it
(I'm not saying there's not one, but if it is, it's definitely not
obvious to users).

Mojca

(PS: we need a big visible Download button on the first page at some point ...)

Publishing links to non-encrypted websites for MacPorts downloads

[Mojca Miklavec]

Hi,

I already mentioned this in the past, but I would like to repeat.
When someone opens our homepage and wants to download MacPorts using
Safari on, say, 10.6, the download link from GitHub doesn't work, and
it's not trivial for users to find out the alternative link
(http://distfiles.macports.org/MacPorts/).

Could we please publish both links to download MacPorts on our homepage?

Thank you,
Mojca

Re: Preparing for 2.6.0 beta

[Mojca Miklavec]

On Fri, 20 Sep 2019 at 03:38, Ryan Schmidt  wrote:
>
>
>
> On Aug 24, 2019, at 23:20, Joshua Root wrote:
>
> > On 2019-8-25 03:00 , Mojca Miklavec wrote:
> >> Would it be possible to set up at least one builder with 10.6 running
> >> MacPorts master, building all ports with libc++ (apparently default by
> >> now in master), just not uploading the archives to the public site, or
> >> potentially uploading them to a 10.6 subfolder? That is, instead of
> >> putting the file under
> >>
> >> http://packages.macports.org/clang-3.4/clang-3.4-3.4.2_12.darwin_10.x86_64.tbz2
> >> we would put it under
> >>
> >> http://packages.macports.org/10.6/clang-3.4/clang-3.4-3.4.2_12.darwin_10.x86_64.tbz2
> >> or something else than 10.6 (darwin10.x86_64, 10.6.x86_64, ...).
> >>
> >> That way we could at least have all the packages ready by the time
> >> when we do the switch.
> >
> > I guess that depends on how much time Ryan has to work on this.
>
> In my opinion, it would have been a good idea to develop a plan for having 
> the archives for libc++ on older systems at different URLs (either 
> subdirectories or different archive filenames). That way, we could have 
> deployed new builders to build the libc++ archives for older systems prior to 
> the release, so that they would be available at release.
>
> However, since Joshua decided to flip the switch for libc++ on older systems 
> without such a plan being in place, we won't have archives for libc++ on 
> older systems available at release of 2.6.0, and users will just have to wait 
> for the builds to finish or build things themselves.

I would certainly not back out from the changes.
But if you Ryan have time to set up at least one virtual builder for
10.6 running the RC (ideally three, but one would already make a huge
difference), the files could be placed to a different location
immediately from the buildbot server, and we could at least give it a
bit of a headstart as I expect various troubles.

I guess the release could wait for a small number of days, and during
that time we could still get quite some important ports built, and fix
some major issues that will pop up in any case, and it's better to fix
them sooner than later.

If this could be done quickly, we could still add something like "if
OS X < 10.9 and x86_64, then fetch binaries from a different location"
to the macports base.

Out of curiosity: since the binaries will have to change, but names
won't - how will our buildbot setup even behave? I expect that for the
start, unless we delete all the existing 10.6 packages from the
server, many packages won't even be rebuilt if we "force build" them,
since the file will be found on the server. And even if it will get
rebuilt: will it be replaced on the server with the new one?

I also expect quite some performance issues because the full compiler
chain will need to be deactivated for every single trivial port, but
that's not as critical (as long as we don't run into bootstrapping
issues for each cycle).

Mojca

Re: latex is driving me batty -- ! Package fontspec Error: The font "DejaVu Sans" cannot be found.

[Mojca Miklavec]

On Fri, 13 Sep 2019 at 01:32, Ken Cunningham wrote:
>
> I'm working on making a newer bootstrap version of ghc for SnowLeopard.
>
> The ghc 8.0.1 build finishes on 10.6.8, but it wants to build the PDF 
> documentation next, and texlive is erroring building the PDF.
>
> I know nothing about texlive. I know I might turn off the docs, but -- it 
> took many hours to build ghc, and I would like to fix texlive.

Saying that texlive is driving you nuts is like saying that MacPorts
is giving you headaches when some buggy software is troubling you :)

TeX Live is just a collection of zillion binaries and packages.

I assume that the failure comes from XeTeX/XeLaTeX? (The only other
alternative I imagine would be LuaTeX. The font loading mechanisms
differ significantly between the two in some aspects, so that would be
an important piece of information.)

XeTeX supports specifying font names in two different ways:
- as file names (without extension)
- as actual font names (which may include spaces etc.)
The low level syntax is slightly different, but most importantly: when
you specify fonts by file name, they are searched for from the TEXMF
tree (i.e. files that are shipped with TeX Live).
When you specify font name, XeTeX uses fc-config to find that font
name, and unless fc-config is configured to look for files inside
texmf trees (or somewhere else where you have those fonts installed
and fc-config sees them), searching for font by name is not really
going to help much.

http://ctan.org/tex-archive/macros/latex/contrib/fontspec/fontspec.pdf

Your patch to replace font names by file names should work fine. If
you wanted font names to work out of the box, we might need to
properly configure fc-config.
It could also be that you are compiling with LuaTeX when the syntax
would only work with XeTeX, not sure.

Mojca

Re: haskell 7 world -> moving to 8!

[Mojca Miklavec]

On Fri, 13 Sep 2019 at 04:02, Ken Cunningham
 wrote:
> On 2019-09-12, at 7:51 AM, Mojca Miklavec wrote:
>
>
>
> Cool!
>
> Doesn't it work if you simply use this working ghc-bootstrap to build version 
> 8?
> Or is Haskell too picky about what version of compiler you require to
> build something newer, and you can only go forward one tiny step at a
> time?
>
>
> The Haskell bootstrap rule appears to be two major steps at a time, and for 
> whatever reason they skip odd numbered minor versions.
>
> Bootstrapping up to a current ghc from our previous ghc 7.8.3 looks like it 
> may not be overly difficult, in the end, at least it went pretty smoothly:
>
> $ port -v installed ghc
> The following ports are currently installed:
>   ghc @7.8.3_6 platform='darwin 10' archs='x86_64' 
> date='2017-11-19T13:47:09-0800'
>   ghc @8.0.2_0 (active) platform='darwin 10' archs='x86_64' 
> date='2019-09-12T18:04:13-0700'
>
>
> It all goes pretty easily, but it does take some time.
>
> This ghc compiler I'm building looks like it should work on all 64bit systems 
> 10.6+, I think. Have to see.

We would need to put the generated binary somewhere and use that one
for the actual/final build from the Portfile. That would speed up
things for everyone ...

> I think this might deliver a newer ghc 8.6.3 for older systems (actually 
> 8.8.1 is out now, so I might just go all the way to there)  and then once we 
> have a bootstrap we can just use the current haskell infrastructure & stack.

> On the way-out-there fringe, who knows about i386: There is an 8.8.1  i386 
> bootstrap binary for debian, so it appears possible to ponder that, at least.

On 10.6 it might in fact be possible to cross-compile for both i386
and PPC. At least their official suggestion is to cross-compile from a
platform that already works.

Mojca

Re: haskell 7 world

[Mojca Miklavec]

On Thu, 12 Sep 2019 at 05:26, Ken Cunningham wrote:
>
> For users of the systems that can't run the current haskell 8.x software (at 
> present at least) I extracted what i believe is the bulk of the haskell 7.x 
> world and have it as a portfile overlay.
>
> It seems to work.  pandoc installs and runs on 10.6.8, for example, as does 
> HedgeWars.
>
> Perhaps it might be of use for someone -- maybe some motivated person might 
> know how to use that working ghc @7.8.3 and build it forward to some current 
> haskell compiler.
>
> clone this  and overlay it if 
> you like.

Cool!

Doesn't it work if you simply use this working ghc-bootstrap to build version 8?
Or is Haskell too picky about what version of compiler you require to
build something newer, and you can only go forward one tiny step at a
time?

In general they are suggesting cross-compilation to get support to new
platforms.

Mojca

Re: [2.6.0-beta1 & LibcxxOnOlderSystems] stack fails to build

[Mojca Miklavec]

On Wed, 4 Sep 2019 at 18:30, Ken Cunningham wrote:
>
> The new ghc infrastructure is broken on 10.6, and at a quick glance, it looks 
> like it starts building at 10.8, which is actually not too bad, and better 
> than I thought:  
>
> I am not sure if i will ever get around to trying to fix the older systems, 
> and I would doubt if anyone else ever will. It might or might not be possible 
> to do so.
>
> There was some minor talk of resurrecting the ghc v7 infrastructure, but I 
> think that is a dead duck idea as the whole family of hs-* ports needed for 
> it are disappearing too.
>
> So -- you might be out-of-luck there, unless I break my leg or something :>

I guess this would be required to support 10.7 and older:
https://gitlab.haskell.org/ghc/ghc/wikis/cross-compilation
We would need a newer machine to backport to 10.6 first, then from
10.6 do the rest of i386/ppc if necessary.

This one seems to have been compiled on 10.7:
https://www.haskell.org/ghc/download_ghc_7_8_4#macosx_x86_64

Support for the hs-* family might be feasible with Karan's work (he
will also be at the MacPorts meeting in Slovenia in October), but it
probably won't help a bit without a suitable compiler running on that
platform.

Mojca

Re: [2.6.0-beta1 & LibcxxOnOlderSystems] stack fails to build

[Mojca Miklavec]

On Thu, 5 Sep 2019 at 07:02, Bjarne D Mathiesen
 wrote:
>
> Mojca Miklavec wrote:
> > On Wed, 4 Sep 2019 at 11:29, Bjarne D Mathiesen wrote:
> >> --with-gcc /usr/bin/gcc  --allow-different-user
> >>
> >> I've also tried "port -t install stack +bootstrap"
> >>
> >> is "--with-gcc /usr/bin/gcc" the problem ?!?
> >
> > I thought this was fixed to point to the chosen compiler?
> > But it's unlikely that this has anything to do with the problem.
> >
> >> and how do I solve it ?!? : port install libgcc ?!?
> >
> > Judging from the logs linked from
> > https://ports.macports.org/port/stack/ it's likely this particular
> > error:
> >
> > fatal: unable to access 'https://github.com/snoyberg/filelock.git/':
> > error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert
> > protocol version
> >
> >
> > Some context from
> > https://build.macports.org/builders/ports-10.8_x86_64_legacy-builder/builds/101522/steps/install-port/logs/stdio:
> >
> > Cloning 97e83ecc133cd60a99df8e1fa5a3c2739ad007dc from
> > https://github.com/snoyberg/filelock.git
> > Received ExitFailure 128 when running
> > Raw command: /usr/bin/git clone
> > https://github.com/snoyberg/filelock.git
> > /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_stack/stack/work/.tmp/with-repo21735/cloned
> > Standard error:
> > Cloning into 
> > '/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_stack/stack/work/.tmp/with-repo21735/cloned'...
> > fatal: unable to access 'https://github.com/snoyberg/filelock.git/':
> > error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert
> > protocol version
> >
> > The built-in SSL support is no longer sufficient on < 10.9. Can you
> > try if running /opt/local/bin/git/clone on the same repository works
> > as expected?
> > In case it does, the next question would be how to convince the build
> > system to use git from a non-default location.
>
> 1) /usr/bin/git doesn't seem to exist on 10.6.8
> 2) port install git
> 3) which git => /macport/bin/git
> 4) #=> git clone https://github.com/snoyberg/filelock.git/
> Cloning into 'filelock'...
> remote: Enumerating objects: 13, done.
> remote: Counting objects: 100% (13/13), done.
> remote: Compressing objects: 100% (10/10), done.
> Receiving objects: 100% (127/127), 24.31 KiB | 1.06 MiB/s, done.
> remote: Total 127 (delta 2), reused 11 (delta 1), pack-reused 114
> Resolving deltas: 100% (52/52), done.
>
> 5) symlink : ln -s /macports/bin/git /usr/bin/git
> #=> ls -l /usr/bin/git
> lrwxr-xr-x ... /usr/bin/git -> /macports/bin/git
>
> 6) port -cuvN install still immediately segfaults
> It doesn't look as if it even reaches that "git clone ..." point

Judging from the logs it seems that it fails at git clone on 10.8, and
segfaults on 10.6 and 10.7, which probably means that the bootstrap
binary has only been compiled for 10.8 and newer. Fixing the
certificate issue might be doable in an easier way than getting the
compiler to work on 10.6.

What might work (but I don't really know) is to download 10.6 SDK on a
new OS, install some version of stack there, and then force the
selection of C compiler, SDK, and target to compile a binary for 10.6.

It seems to me that one needs to start with a working compiler to
build a (newer) compiler, similar as you need a working C/C++ compiler
to build gcc or clang from source, except that they don't ship a
version compatible with older systems. I doubt that there is any
serious technical issue, but more of a lack of upstream interest.

Mojca

MacPorts Meeting 11th-16th October 2019

[Mojca Miklavec]

Dear MacPorters,

We are happy to announce the 3rd international MacPorts meeting in
Bohinj, Slovenia, from 11th to the 16th of October. (Meeting starts on
Friday 11th with the dinner and ends on Wednesday after lunch.)

Some basic information (to be completed):
https://trac.macports.org/wiki/Meetings/MacPortsMeeting2019
Registration form:
https://forms.gle/JbSLkykLSZRu7Q4b8

We'll announce the exact fee soon, but for early-bird registrants it
should hopefully not exceed 200 EUR for five days covering food &
accommodation.

We are really going inter-continental this year, with expected
developers from China, Indonesia and four people from India. After an
extremely successful GSOC summer almost all students and most mentors
are expected to be present.

The meeting is an excellent opportunity to meet fellow developers &
users, brainstorm together & hack together for a couple of days to
make the software and its ecosystem even better.

Bohinj is one of the nicest places in Slovenia, also really nice to
bring your family members (it would have been even better in the
middle of summer or winter, but then it would be overcrowded anyway
:). It's next to the lake, in the middle of the mountains and within a
national park, relatively easily reachable also with means of public
transportation (but we'll try to pick up as many participants as we
could).

If you have any questions, feel free to ask.

Mojca

Re: Preparing for 2.6.0 beta

[Mojca Miklavec]

On Sat, 24 Aug 2019 at 05:45, Joshua Root wrote:
>
> I think we're pretty close to being ready to make a new stable branch

+1 :)

> are there any other changes that really need to go in
> before the beta?

It would be kind of cool if we could display a message inviting users
to submit statistics for the new site when they upgrade.

But that's neither urgent nor written yet.
(If anyone has time to write it, it would be cool, but definitely no
need to delay the release for it.)

Mojca

Re: Preparing for 2.6.0 beta

[Mojca Miklavec]

On Sat, 24 Aug 2019 at 16:40, Ryan Schmidt wrote:
> On Aug 24, 2019, at 08:55, Joshua Root wrote:
> > On 2019-8-24 21:59 , Mojca Miklavec wrote:
> >
> >> I would be grateful for addressing these:
> >>
> >> https://trac.macports.org/ticket/50448
> >
> > Way too late to do anything about that in base. The plan is as described
> > in comment 16.
>
> I didn't realize that was the plan we had settled on, but I haven't been 
> following MacPorts developments that closely this year.
>
> I saw the commits from you to base, changing the default stdlib to libc++ on 
> 10.6-10.8. Looks like your proposal is for users to run rev-upgrade after 
> upgrading.
>
> What is the plan for the buildbot and our prebuilt archives? Obviously we 
> would need to rebuild all of the archives for C++ software on 10.6-10.8. 
> Since you are not planning on changing the archive filenames or their 
> location on the packages server, and since the buildbot uses the presence of 
> the archives on the packages server as an indicator that the ports have 
> already been built, the buildbot will not know that it should rebuild them. I 
> imagine we will have to manually identify all the ports that use C++, remove 
> their archives from the packages server, uninstall them on the 10.6-10.8 
> buildbot workers, and then trigger new builds for them.

Would it be possible to set up at least one builder with 10.6 running
MacPorts master, building all ports with libc++ (apparently default by
now in master), just not uploading the archives to the public site, or
potentially uploading them to a 10.6 subfolder? That is, instead of
putting the file under

http://packages.macports.org/clang-3.4/clang-3.4-3.4.2_12.darwin_10.x86_64.tbz2
we would put it under

http://packages.macports.org/10.6/clang-3.4/clang-3.4-3.4.2_12.darwin_10.x86_64.tbz2
or something else than 10.6 (darwin10.x86_64, 10.6.x86_64, ...).

That way we could at least have all the packages ready by the time
when we do the switch.

A few years back Ryan's biggest opposition to introducing subfolders
with macOS version was the ability to get a quick overview of macOS
versions where the port built successfully. With the new app I believe
this is no longer of any concern.

Independent from the stdlibc++ vs. libc++ question I still believe
that it would be really nice to be able to easily include/exclude the
set of macOS versions. Say that we organize the meeting with very poor
internet connectivity (which incidentally seems to be the case this
October). It comes really handy if we can bring a mirror of all files,
but excluding the platforms we are sure we won't be needing. Sure
that's also possible to do by filtering out certain filenames, but
being able to just skip some folders is much easier.

Mojca

Re: Preparing for 2.6.0 beta

[Mojca Miklavec]

On Sat, 24 Aug 2019 at 05:45, Joshua Root  wrote:
>
> I think we're pretty close to being ready to make a new stable branch
> and tag a beta. Clemens is going to make one more change related to
> Xcode checking; are there any other changes that really need to go in
> before the beta?

I would be grateful for addressing these:

https://trac.macports.org/ticket/50448
https://trac.macports.org/ticket/56042
https://trac.macports.org/ticket/55471

Mojca

Re: New MacPorts ports database site

[Mojca Miklavec]

On Mon, 19 Aug 2019 at 06:17, Joshua Root wrote:
>
> MacPorts' new ports database is live at .

I would like to ask for an opinion.

Please compare
https://ports.macports.org/maintainer/github/ryandesign/
and
https://ports.macports.org/ports/variant/universal

In the first URL subports are grouped. Which one do you like better,
or do you have any ideas for further improvements?
I initially asked for grouping of subports, but I cannot decide if it
actually looks better or not.

I would prefer to have consistent output for all the queries rather
than use a different view for the maintainer.

You can either answer here or "misuse" the following PR
   https://github.com/macports/macports-webapp/pull/101

Thank you,
Mojca