Opened 3 years ago

Last modified 18 months ago

#26249 new task

port Sage to FreeBSD 12

Reported by: dimpase Owned by:
Priority: major Milestone: sage-pending
Component: porting: BSD Keywords:
Cc: mkoeppe Merged in:
Authors: Dima Pasechnik, Li-Wen Hsu Reviewers:
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: #26253, #27764 Stopgaps:

Status badges

Description (last modified by dimpase)

In FreeBSD 12 the long-standing incompleteness of its libm has been helped. This simplifies a lot, compared to #22679.

We will not try to work around the toolchain problem related to gfortran/libgcc_s. Instead, we just add a line at the end of /etc/libmap.conf as follows:

libgcc_s.so.1 /usr/local/lib/gcc7/libgcc_s.so.1

Also, we create the following symbolic links:

$ ls -l ~/bin
total 0
lrwxr-xr-x  1 dima  dima  20 Apr 27 12:49 make -> /usr/local/bin/gmake
lrwxr-xr-x  1 dima  dima  21 Apr 27 13:46 patch -> /usr/local/bin/gpatch

and use the standard shell, /bin/sh. In ~/.profile we put

export LDFLAGS="-L/usr/local/lib"
export CFLAGS="-I/usr/local/include"
export CXXFLAGS=$CFLAGS
export CPPFLAGS=$CFLAGS
export FCFLAGS=$CFLAGS
export FFLAGS=$CFLAGS

to account for clang not looking into /usr/local by default.

Things to fix:

  • #26250 (fixes to rubiks)
  • #27764 (a fix to flint)
  • #26253 (update of psutils)
  • yasm check is broken on FreeBSD (it's always YES!)
  • #26602 (cephes removed)
  • #26287 (update to gc, to the FreeBSD's version)
  • #26288 (update to matplotlib, fixes compilation errors)
  • #26190 (update to latte_int---which is an optional package)
  • #26733 (update to openblas)
  • #26315 (update to giac, to be able to use clang 6.0.1)
  • #27262 (needed to link sagelib to libs from /usr/local/lib)

There is some hope that the libgcc_s.so.1 problem will finally be [fixed in FreeBSD https://lists.freebsd.org/pipermail/freebsd-ports/2019-April/115972.html]

The strategy which would pay off to make Sage an "easy" FreeBSD port is to add/enhance as many needed by Sage external libraries as separate ports into FreeBSD, so that Sage does not need to vendor this. To this end, #27330 is very relevant ticket.

A first foray into this is enhancing FreeBSD's port of flint2 to be linkable with NTL (something that is a requirement for flint2 in Sage), see here. The necessary work on the flint2 side has been done in the meantime, see https://github.com/wbhart/flint2/pull/543 - so now it's only the FreeBSD part that needs to be done.

Few obvious other candidates for a port in FreeBSD are gf2x and ecm.

Change History (65)

comment:1 Changed 3 years ago by dimpase

  • Description modified (diff)

comment:2 Changed 3 years ago by dimpase

  • Description modified (diff)

comment:3 Changed 3 years ago by dimpase

  • Description modified (diff)

comment:4 Changed 3 years ago by dimpase

  • Description modified (diff)

comment:5 Changed 3 years ago by dimpase

  • Description modified (diff)

comment:6 Changed 3 years ago by gh-lwhsu

  • Authors set to Dima Pasechnik, Li-Wen Hsu

comment:7 Changed 3 years ago by dimpase

  • Description modified (diff)

comment:8 Changed 3 years ago by dimpase

  • Description modified (diff)

comment:9 Changed 3 years ago by dimpase

  • Description modified (diff)

comment:10 Changed 3 years ago by dimpase

  • Description modified (diff)
  • Milestone changed from sage-8.4 to sage-8.5

comment:11 Changed 3 years ago by dimpase

This scipy problem is still there. (while this works with the system's python2) It's a matter of comparing the patches used there with what we do in Sage. Perhaps they disable multithreading...

comment:12 follow-up: Changed 3 years ago by embray

I'm currently overextended as always and don't have any deep personal motivation to work on FreeBSD support, but I would definitely like to have it if we can so if there's anything I can help with here I'll make a FreeBSD 12 VM so I can have it to play around on.

comment:13 in reply to: ↑ 12 Changed 3 years ago by dimpase

Replying to embray:

I'm currently overextended as always and don't have any deep personal motivation to work on FreeBSD support, but I would definitely like to have it if we can so if there's anything. I can help with here I'll make a FreeBSD 12 VM so I can have it to play around on.

I can give you access to the FreeBSD 12.0 VM I am running on GCE, this would be easier, I guess. (12.0 is still in beta/RC cycle, so installation is not straightforward, you basically need to build it from source).

comment:14 Changed 3 years ago by gh-dimpase

currently testing what we have here (with Sage 8.6) on the released FreeBSD 12.0

Last edited 3 years ago by gh-dimpase (previous) (diff)

comment:15 follow-up: Changed 3 years ago by dimpase

the next issue we hit is Python3 on Sage 8.7.beta3: https://bugs.python.org/issue6299 (pyexpat module does not build)

comment:16 in reply to: ↑ 15 Changed 3 years ago by dimpase

  • Dependencies set to #27254

Replying to dimpase:

the next issue we hit is Python3 on Sage 8.7.beta3: https://bugs.python.org/issue6299 (pyexpat module does not build)

for the time being, working around this by not installing setuptools and pip for py3

Last edited 3 years ago by dimpase (previous) (diff)

comment:17 Changed 3 years ago by dimpase

  • Dependencies changed from #27254 to #27254, #/26253

comment:18 Changed 3 years ago by dimpase

  • Dependencies changed from #27254, #/26253 to #27254, #26253, #27262
  • Description modified (diff)

comment:19 Changed 3 years ago by dimpase

  • Description modified (diff)

comment:20 Changed 3 years ago by dimpase

  • Dependencies changed from #27254, #26253, #27262 to #27254, #26253, #27262, #27764
  • Description modified (diff)
  • Milestone changed from sage-8.5 to sage-8.8

comment:21 Changed 2 years ago by embray

  • Milestone sage-8.8 deleted

As the Sage-8.8 release milestone is pending, we should delete the sage-8.8 milestone for tickets that are not actively being worked on or that still require significant work to move forward. If you feel that this ticket should be included in the next Sage release at the soonest please set its milestone to the next release milestone (sage-8.9).

comment:22 Changed 2 years ago by dimpase

  • Description modified (diff)
  • Milestone set to sage-pending

to use flang (which is a possibility on FreeBSD at least), one needs

  • build/pkgs/numpy/spkg-install

    a b export FFLAGS="$FFLAGS -fPIC" 
    1818export FCFLAGS="$FCFLAGS -fPIC"
    1919
    2020export NUMPY_FCONFIG="config_fc --noopt --noarch"
    21 
     21export LDFLAGS="$LDFLAGS -lexecinfo" # needed for flang
    2222################################################
    2323
    2424sage-python23 setup.py \

due to it being somewhat underlinked.

comment:23 Changed 2 years ago by dimpase

As I have to abandon the FreeBSD VM I've been using, I've pushed the current WIP branch to https://github.com/lwhsu/sagemath/commits/wip31082019

TBC on another FreeBSD machine.

comment:24 Changed 21 months ago by gh-thierry-FreeBSD

A work-in-progress has been submitted to the FreeBSD Phabricator:

https://reviews.freebsd.org/D24195

Its aim is to upgrade the existing port to 9.0.

Do not hesitate to comment or modify!

comment:25 Changed 21 months ago by dimpase

I think it'd be much better to use the work done on #27330 - you don't even need to build a special Python version, but use one on the system! (And, of course, use autoconf, don't mess around with generated ./configure)

comment:26 Changed 21 months ago by gh-thierry-FreeBSD

I used the external packages when this is possible with the released Sage 9.0. This version still builds the bundled Python. I guess that the progress done with #27330 will be available in the next release?

Thanks for your comment, I'll try to use autoconf.

comment:27 Changed 21 months ago by dimpase

A large part of #27330 is already in 9.0. But yes, I think it's much better to wait for 9.1, or actually start using 9.1.betas (we're near the first release candidate).

IIRC FreeBSD has quite a few packages available, although they aren't always built with pre-reqs needed for Sage, e.g. Flint is not built with NTL support.

comment:28 Changed 21 months ago by gh-thierry-FreeBSD

Great! I'll try to work on 9.1 ASAP.

You are right about Flint: the ports used Cmake, and the NTL option is not available in CMakeLists.txt (and it is not even enabled by default with configure).

But we can change that, and I just sent a PR to fix it:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245085

comment:29 Changed 21 months ago by gh-thierry-FreeBSD

And I just added a port for Cliquer, from your autotoolized version:

https://www.freshports.org/math/cliquer/

comment:30 Changed 21 months ago by dimpase

Thanks. I suggest that every Sage library/package mentioned in #27330 be made a FreeBSD port (some of them are), this should be enough to finish this task.

We have plans to turn Sage into a "normal" pip-installable Python library, but this probably won't happen before the end of the year.

comment:31 Changed 21 months ago by gh-thierry-FreeBSD

I recently also added eclib, m4ri, gf2x, gp2c and the Pari packages (elldata, galdata, galpol, nftables and seadata).

And still going on!

comment:32 Changed 20 months ago by gh-thierry-FreeBSD

Some news: I have just updated the WIP-port to 9.1.beta9: it is available at https://reviews.freebsd.org/D24195

Every possible packages listed in #27330 are used as external packages, thanks for that!

Unfortunately, there remain some problems, mostly caused by staging (DESTDIR): a lot of libraries are referring to the directory where they have been built: e.g.

Error: 'lib/python3.7/site-packages/PIL/_imagingft.so' is referring to /usr/ports/math/sage/work/stage Error: 'lib/libldl.so.2.2.6' is referring to /usr/ports/math/sage/work/stage

Is there some possibility to let them refer to relative directories? How would you set SAGE_LOCAL?

comment:33 Changed 20 months ago by gh-thierry-FreeBSD

To be more precise: I have played with SAGE_LOCAL and SAGE_DESTDIR.

The logical choice seemed to set SAGE_LOCAL=$PREFIX and SAGE_DESTDIR=$STAGEDIR, but this is not the case.

comment:34 Changed 20 months ago by gh-thierry-FreeBSD

Actually, to be more positive, it mostly works!

Looking for the root of the problem, only 29 libraries are not fully staged - but of course, thereafter the other binaries using one of this library become affected.

ATM (with 9.1.beta9), my list of affected libraries is:

libamd.so.2 => /usr/ports/math/sage/work/stage/usr/local/lib/libamd.so.2

libbraiding.so.0 => /usr/ports/math/sage/work/stage/usr/local/lib/libbraiding.so.0

libbrial_groebner.so.3 => /usr/ports/math/sage/work/stage/usr/local/lib/libbrial_groebner.so.3

libbrial.so.3 => /usr/ports/math/sage/work/stage/usr/local/lib/libbrial.so.3

libbtf.so.1 => /usr/ports/math/sage/work/stage/usr/local/lib/libbtf.so.1

libcamd.so.2 => /usr/ports/math/sage/work/stage/usr/local/lib/libcamd.so.2

libccolamd.so.2 => /usr/ports/math/sage/work/stage/usr/local/lib/libccolamd.so.2

libcddgmp.so.0 => /usr/ports/math/sage/work/stage/usr/local/lib/libcddgmp.so.0

libcholmod.so.3 => /usr/ports/math/sage/work/stage/usr/local/lib/libcholmod.so.3

libcolamd.so.2 => /usr/ports/math/sage/work/stage/usr/local/lib/libcolamd.so.2

libecl.so.16.1 => /usr/ports/math/sage/work/stage/usr/local/lib/libecl.so.16.1

libfactory-4.1.1.so => /usr/ports/math/sage/work/stage/usr/local/lib/libfactory-4.1.1.so

libfflas.so.1 => /usr/ports/math/sage/work/stage/usr/local/lib/libfflas.so.1

libffpack.so.1 => /usr/ports/math/sage/work/stage/usr/local/lib/libffpack.so.1

libgap.so.0 => /usr/ports/math/sage/work/stage/usr/local/lib/libgap.so.0

libgc.so.1 => /usr/ports/math/sage/work/stage/usr/local/lib/libgc.so.1

libhomfly.so.0 => /usr/ports/math/sage/work/stage/usr/local/lib/libhomfly.so.0

libiml.so.1 => /usr/ports/math/sage/work/stage/usr/local/lib/libiml.so.1

liblinbox.so.0 => /usr/ports/math/sage/work/stage/usr/local/lib/liblinbox.so.0

liblrcalc.so.1 => /usr/ports/math/sage/work/stage/usr/local/lib/liblrcalc.so.1

libomalloc-0.9.6.so => /usr/ports/math/sage/work/stage/usr/local/lib/libomalloc-0.9.6.so

libpolys-4.1.1.so => /usr/ports/math/sage/work/stage/usr/local/lib/libpolys-4.1.1.so

libppl.so.14 => /usr/ports/math/sage/work/stage/usr/local/lib/libppl.so.14

libpynac.so.18 => /usr/ports/math/sage/work/stage/usr/local/lib/libpynac.so.18

libsingular_resources-4.1.1.so => /usr/ports/math/sage/work/stage/usr/local/lib/libsingular_resources-4.1.1.so

libSingular-4.1.1.so => /usr/ports/math/sage/work/stage/usr/local/lib/libSingular-4.1.1.so

libsuitesparseconfig.so.5 => /usr/ports/math/sage/work/stage/usr/local/lib/libsuitesparseconfig.so.5

libumfpack.so.5 => /usr/ports/math/sage/work/stage/usr/local/lib/libumfpack.so.5

libzn_poly-0.9.so => /usr/ports/math/sage/work/stage/usr/local/lib/libzn_poly-0.9.so

Some of them like libgc, brial, or fflas-ffpack should be fixed RSN (thanks to #27330 ).

I guess that the most problematic case is libsuitesparseconfig.so, which is widely used.

comment:35 Changed 20 months ago by dimpase

  • Cc mkoeppe added

I cc Matthias, who has been doing a lot of work on improving Sage's installation. He'd be able to understand the issue better than me, hopefully.

comment:36 Changed 20 months ago by gh-thierry-FreeBSD

The problem is documented in build/pkgs/suitesparse/patches/03-buildflags.patch:

"Note that -L$(INSTALL_LIB) cannot be removed from LDFLAGS unless the package is broken into components. It is necessary as the components are progressively installed in INSTALL_LIB one after the other."

It has been reported in #28832 and fixed for OS X with -install_name, but this does not fix it for FreeBSD. I'll have to try other patches - unless suiteparse could be used from a system package? It is not yet listed in #27330 but would be awesome!

comment:37 Changed 20 months ago by dimpase

Now we have #29502 for suitesparse - not done yet.

comment:38 Changed 20 months ago by gh-thierry-FreeBSD

Some news: after #29502 for suitesparse and #29024 for singular, only 13 libraries (+ of course the modules built around them!) cause problems with staging: libbraiding libbrial_groebner libbrial libecl libfflas libffpack libgap libgc libhomfly liblinbox libppl libpynac libzn_poly-0.

Among them, all are listed in #27330 (with or without a ticket), but libpynac. We do not even have pynac in the FreeBSD ports tree (but we have math/GiNaC) => it will be my next target.

comment:39 follow-up: Changed 20 months ago by gh-thierry-FreeBSD

After giac (#29541) and pynac (#29542), I tried to use a system package for ECL (lang/ecl) and Maxima (math/maxima), but without success for the moment: see #29617. To be tried again when ECL will be upgraded (#22191)!

Meanwhile, our ports must be patched:

  • lang/ecl: add a symbolic link for $PREFIX/lib/ecl
  • math/maxima: this one is more tricky, because now ECL is not even supported and must be added, and to get a useful package we need to replace the default from SBCL to ECL (or create a slave port?)

They are not submitted yet, but if someone want to work on #29617 the patches are available at

comment:40 in reply to: ↑ 39 Changed 19 months ago by dimpase

Replying to gh-thierry-FreeBSD:

After giac (#29541) and pynac (#29542), I tried to use a system package for ECL (lang/ecl) and Maxima (math/maxima), but without success for the moment: see #29617. To be tried again when ECL will be upgraded (#22191)!

Meanwhile, our ports must be patched:

  • lang/ecl: add a symbolic link for $PREFIX/lib/ecl
  • math/maxima: this one is more tricky, because now ECL is not even supported and must be added, and to get a useful package we need to replace the default from SBCL to ECL (or create a slave port?)

there are many free Common Lisp implementations, I suppose there can be lang/cl as a "main" package with a number of slaves, perhaps SBCL as a standard one.

comment:41 Changed 19 months ago by mkoeppe

I'd recommend to add system package information for FreeBSD. See https://trac.sagemath.org/ticket/29354 where this is done for Slackware (except for the bits that use docker)

Last edited 19 months ago by mkoeppe (previous) (diff)

comment:42 follow-up: Changed 19 months ago by gh-thierry-FreeBSD

Well, every package listed in #27330 have a corresponding package from the FreeBSD ports tree and a spkg-configure.m4 to use it!

Next step: try to solve the problem with bad staging (non-respect of $DESTDIR) for the libraries built by Sage.

comment:43 in reply to: ↑ 42 Changed 19 months ago by mkoeppe

Replying to gh-thierry-FreeBSD:

Well, every package listed in #27330 have a corresponding package from the FreeBSD ports tree and a spkg-configure.m4 to use it!

Yes, and the trick is to put the names of these packages in a freebsd.txt file to record the correspondence of spkg to FreeBSD port.

Last edited 19 months ago by mkoeppe (previous) (diff)

comment:44 follow-up: Changed 19 months ago by gh-thierry-FreeBSD

OK, I'll do it!

comment:45 in reply to: ↑ 44 Changed 19 months ago by gh-thierry-FreeBSD

Replying to gh-thierry-FreeBSD:

OK, I'll do it!

Done in #29653.

comment:46 follow-up: Changed 19 months ago by mkoeppe

Next, if you're serious about FreeBSD support, I would recommend setting up testing infrastructure with our tox.ini and virtualbox (https://www.freebsd.org/doc/handbook/virtualization-guest-virtualbox.html) or a similar solution so that Sage developers and our CI infrastructure have a chance of testing on that platform.

Last edited 19 months ago by mkoeppe (previous) (diff)

comment:47 in reply to: ↑ 46 Changed 19 months ago by gh-thierry-FreeBSD

Replying to mkoeppe:

I would recommend setting up testing infrastructure with our tox.ini and virtualbox (https://www.freebsd.org/doc/handbook/virtualization-guest-virtualbox.html) or a similar solution so that Sage developers and our CI infrastructure have a chance of testing on that platform.

Thanks, this is interesting - but at this point a bit premature: there is no compilation error, but Sage is not yet ready for FreeBSD, even if we are making progress.

comment:48 Changed 18 months ago by gh-thierry-FreeBSD

Well, we are almost done!

It is not yet committable in the FreeBSD ports tree, because there are some pre-requisites (isl to be upgraded, and two possible forks for ECL and Maxima if no better solution is found).

See https://reviews.freebsd.org/D24195 for details.

comment:49 Changed 18 months ago by dimpase

for ecl I suggest to use a not yet merged https://trac.sagemath.org/ticket/22191

which looks good on Linux and OpenBSD.

also a new release of Flint is coming.

comment:50 Changed 18 months ago by gh-thierry-FreeBSD

Thanks! I'm just in discussion with the maintainers of these two ports (ECL and Maxima). Let's check this version.

comment:51 Changed 18 months ago by dimpase

ecl obviously must be upgraded to the latest release (maxima currently packaged with Sage works well with it, too).

which bugs of maxima one prefers, is another question. :-)

our experience with updating maxima is that each new release has serious regressions.

Last edited 18 months ago by dimpase (previous) (diff)

comment:52 Changed 18 months ago by dimpase

here is Flint update ticket https://trac.sagemath.org/ticket/29719

it is awaiting upstream putting in finishing touches here: https://github.com/wbhart/flint2/issues/753

comment:53 Changed 18 months ago by gh-thierry-FreeBSD

I guess that it is safer to get Sage 9.1 into our ports tree with the current dependencies.

We'll look to upgrade these afterwards!

comment:54 follow-ups: Changed 18 months ago by gh-thierry-FreeBSD

We are done, 9.1 is in the tree: https://www.freshports.org/math/sage/

and we are working on the upgrade of ECL to 20.4.24: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247283

comment:55 in reply to: ↑ 54 Changed 18 months ago by dimpase

Replying to gh-thierry-FreeBSD:

We are done, 9.1 is in the tree: https://www.freshports.org/math/sage/

This is great!

I guess we should make the Sagemath source FreeBSD-friendly, so that one can build Sage from source using the standard ./configure + make route, right? This would need

  • adding data for the needed packages, that is, there should be build/pkgs/*/distros/freebsd.txt files added with package names.
  • adding pre-reqs data: build/pkgs/freebsd.txt and build/pkgs/freebsd-bootstrap.txt
  • import patches you added in FreeBSD to Sage (if any)

comment:56 Changed 18 months ago by dimpase

  • Dependencies changed from #27254, #26253, #27262, #27764 to #26253, #27764

comment:57 Changed 18 months ago by gh-thierry-FreeBSD

The most important patch concerns configure.ac: without it, you cannot even run configure!

I submitted it with the system package information in #29653, but it has been rejected.

The other patches are mostly specific and related to the ports system, caused by differences in directories, but shouldn't be necessary for those trying to build Sage by themselves with the bundled packages.

mkoeppe asked me to set up a testing infrastructure. I'm not familiar at all with that, but I'll try to do it (any pointers appreciated!).

comment:58 Changed 18 months ago by dimpase

I will look at #29653 - it needs a rebase over the latest 9.2.beta1

regarding testing - is docker ported to FreeBSD?

Anyway, one can set a patchbot, for this one just needs a FreeBSD host that will pull branches and build/test them.

comment:59 Changed 18 months ago by gh-thierry-FreeBSD

There exists a port of docker: https://www.freshports.org/sysutils/docker (but I never used it!).

comment:60 Changed 18 months ago by gh-lwhsu

I don't think docker port is production ready at the moment. I suggest the faster way would be having a github mirror and use hosted CI service: https://wiki.freebsd.org/HostedCI

comment:61 in reply to: ↑ 54 ; follow-up: Changed 18 months ago by dimpase

Replying to gh-thierry-FreeBSD:

We are done, 9.1 is in the tree: https://www.freshports.org/math/sage/

I've revived a VM with FreeBSD, it's running 12.1-RELEASE-p6

How do I get the new port in there? Do I need a system update (if yes, to what?)? Or it's easier? I've run portsnap, and still see old stuff for sage in /usr/ports/math/sage.

comment:62 follow-up: Changed 18 months ago by gh-thierry-FreeBSD

You did the right thing!

  • 12.1-RELEASE-p6 is OK
  • `portsnap fetch update' is a well supported method - but I do not know how long it takes to be refreshed. I guess that if you try again is 1h or 2 it should be fine.

comment:63 in reply to: ↑ 61 Changed 18 months ago by gh-lwhsu

Replying to dimpase:

Replying to gh-thierry-FreeBSD:

We are done, 9.1 is in the tree: https://www.freshports.org/math/sage/

I've revived a VM with FreeBSD, it's running 12.1-RELEASE-p6

How do I get the new port in there? Do I need a system update (if yes, to what?)? Or it's easier? I've run portsnap, and still see old stuff for sage in /usr/ports/math/sage.

I guess there are two possibilities, one is portsnap is not updated yet (unlikely, IIRC it updates hourly), the other is it's tracking quarterly branch, and 9.1 is only in latest branch now. I haven't used portsnap for a while so I might also be wrong.

To get the latest ports tree in real-time, you can try to use svn to checkout from:

https://svn.freebsd.org/ports/head

or git from

https://github.com/freebsd/freebsd-ports

comment:64 in reply to: ↑ 62 ; follow-up: Changed 18 months ago by dimpase

Replying to gh-thierry-FreeBSD:

You did the right thing!

  • 12.1-RELEASE-p6 is OK
  • `portsnap fetch update' is a well supported method - but I do not know how long it takes to be refreshed. I guess that if you try again is 1h or 2 it should be fine.

OK, thanks, seems to be in progress now, after I did portsnap fetch update (my first try was portsnap fetch` - probably they are not the same thing)

lwhsu - did you see my email about CI? (just checking)

comment:65 in reply to: ↑ 64 Changed 18 months ago by gh-lwhsu

Replying to dimpase:

Replying to gh-thierry-FreeBSD:

You did the right thing!

  • 12.1-RELEASE-p6 is OK
  • `portsnap fetch update' is a well supported method - but I do not know how long it takes to be refreshed. I guess that if you try again is 1h or 2 it should be fine.

OK, thanks, seems to be in progress now, after I did portsnap fetch update (my first try was portsnap fetch` - probably they are not the same thing)

Yes there are two steps. One if for fetching the content and the other one is for actually updating the ports tree. See portsnap(8)

lwhsu - did you see my email about CI? (just checking)

Yes, please forgive me for needing longer to response.

Note: See TracTickets for help on using tickets.