Re: Subsurface on Apple Silicone

[Linus Torvalds via subsurface]

On Mon, Oct 25, 2021 at 2:11 PM Thiago Macieira via subsurface
 wrote:
>
> Is this enough for Subsurface needs?

No. If anything, it's exactly the opposite of what Subsurface needs,
now that subsurface no longer does the GPS location tracking (because
of all the permission problems that involved).

Subsurface really wants that "show the map" thing from QtLocation, not
the "get location information" from QtPositioning (and then we have
that "google maps plugin" to show google satellite data, since no
other source tends to be available and really good enough for dive
site information).

So subsurface isn't actually interested in QtPositioning at all,
except indirectly (ie  QtLocation ends up using QtPositioning, I
think).

   Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface on Apple Silicone

[Thiago Macieira via subsurface]

On Sunday, 24 October 2021 18:35:14 PDT Thiago Macieira via subsurface wrote:
> > Any pointers, Thiago?
> 
> There was some discussion about only QtPositioning being available... not
> sure. I didn't pay attention. I did a quick check to see if the qtlocation
> repository was tagged with 6.2 but didn't check *what* it installs. I don't
> keep a full build of Qt in my laptop, that's what workstations wit lots of
> cores are for :)
> 
> Can you try QT += positioning to see if that helps and replacing the
> #includes?

Yep, the module is only QtPositioning:

$ ls -ld include/Qt{Positioning,Location}
ls: cannot access 'include/QtLocation': No such file or directory
drwxr-xr-x 3 tjmaciei tjmaciei 4096 Sep 30 00:50 include/QtPositioning
$ ls mkspecs/modules/qt_lib_{positioning,location}.pri
ls: cannot access 'mkspecs/modules/qt_lib_location.pri': No such file or 
directory
mkspecs/modules/qt_lib_positioning.pri

Here are the classes it contains:
$ ls -1 include/QtPositioning
6.3.0
QGeoAddress
qgeoaddress.h
QGeoAreaMonitorInfo
qgeoareamonitorinfo.h
QGeoAreaMonitorSource
qgeoareamonitorsource.h
QGeoCircle
qgeocircle.h
QGeoCoordinate
qgeocoordinate.h
QGeoLocation
qgeolocation.h
QGeoPath
qgeopath.h
QGeoPolygon
qgeopolygon.h
QGeoPositionInfo
qgeopositioninfo.h
QGeoPositionInfoSource
QGeoPositionInfoSourceFactory
qgeopositioninfosourcefactory.h
qgeopositioninfosource.h
QGeoRectangle
qgeorectangle.h
QGeoSatelliteInfo
qgeosatelliteinfo.h
QGeoSatelliteInfoSource
qgeosatelliteinfosource.h
QGeoShape
qgeoshape.h
QNmeaPositionInfoSource
qnmeapositioninfosource.h
QNmeaSatelliteInfoSource
qnmeasatelliteinfosource.h
qpositioningglobal.h
QtPositioning
qtpositioning-config.h
QtPositioningDepends
QtPositioningVersion
qtpositioningversion.h

Is this enough for Subsurface needs?
-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DPG Cloud Engineering



___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface on Apple Silicone

[Thiago Macieira via subsurface]

On Sunday, 24 October 2021 17:12:04 PDT Dirk Hohndel wrote:
> [hohndel@fedora build]$ qmake6 ../googlemaps.pro
> Project ERROR: Unknown module(s) in QT: location
> 
> So at least qmake6 doesn't appear to know how to build against Qt Location.

Hmm... the "qt_lib_location.pri" file must be missing. I'll take a look 
tomorrow.

> Interestingly, when I go to https://doc.qt.io/qt-6/qtmodules.html
>  - it doesn't list Qt Location... So
> maybe it's only "sort of" there? Or maybe I'm supposed to use it
> differently?


> Oh, and then using
>   dnf repoquery -l qt6-qtlocation-devel
> shows that this package does, indeed, only contain QtPositioning, but not
> QtLocation
> 
> Trying to find anything on this topic via Google has been not very
> successful.
> 
> Any pointers, Thiago?

There was some discussion about only QtPositioning being available... not 
sure. I didn't pay attention. I did a quick check to see if the qtlocation 
repository was tagged with 6.2 but didn't check *what* it installs. I don't 
keep a full build of Qt in my laptop, that's what workstations wit lots of 
cores are for :)

Can you try QT += positioning to see if that helps and replacing the 
#includes?

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DPG Cloud Engineering



___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface on Apple Silicone

[Dirk Hohndel via subsurface]

> On Oct 22, 2021, at 10:19 PM, Thiago Macieira via subsurface 
>  wrote:
> 
> On Friday, 22 October 2021 16:52:06 PDT Dirk Hohndel via subsurface wrote:
>> Some more messing around with Qt 6... we're not only losing QtWebKit -
>> there's also no Qt Location and no Qt Positioning. Which means no map
>> module that we can use.
> 
> Those were missing in 6.0 and 6.1, but qtlocation is back in 6.2.

So here's what I got:

Fedora 34 with Qt 6.2

[hohndel@fedora build]$ sudo dnf install qt6-qtlocation-devel
Last metadata expiration check: 1:54:29 ago on Sun 24 Oct 2021 03:02:30 PM PDT.
Package qt6-qtlocation-devel-6.2.0-1.fc34.x86_64 is already installed.
Dependencies resolved.
Nothing to do.
Complete!
[hohndel@fedora build]$ qmake6 ../googlemaps.pro 
Project ERROR: Unknown module(s) in QT: location

So at least qmake6 doesn't appear to know how to build against Qt Location.

Interestingly, when I go to https://doc.qt.io/qt-6/qtmodules.html 
 - it doesn't list Qt Location...
So maybe it's only "sort of" there? Or maybe I'm supposed to use it differently?

Oh, and then using 
dnf repoquery -l qt6-qtlocation-devel 
shows that this package does, indeed, only contain QtPositioning, but not 
QtLocation

Trying to find anything on this topic via Google has been not very successful.

Any pointers, Thiago?

/D___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface on Apple Silicone

[Thiago Macieira via subsurface]

On Friday, 22 October 2021 16:52:06 PDT Dirk Hohndel via subsurface wrote:
> Some more messing around with Qt 6... we're not only losing QtWebKit -
> there's also no Qt Location and no Qt Positioning. Which means no map
> module that we can use.

Those were missing in 6.0 and 6.1, but qtlocation is back in 6.2.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DPG Cloud Engineering



___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface on Apple Silicone

[Thiago Macieira via subsurface]

On Friday, 22 October 2021 10:34:08 PDT Dirk Hohndel via subsurface wrote:
> I haven't followed this closely enough to see if the Linux distros are
> including these patches in their versions, though.

They are, at least the ones that follow KDE somewhat closely.

https://src.fedoraproject.org/rpms/qt5-qtbase/blob/rawhide/f/sources
https://build.opensuse.org/package/show/openSUSE:Factory/libqt5-qtbase
https://github.com/archlinux/svntogit-packages/blob/packages/qt5-base/trunk/
PKGBUILD#L31-L33
etc.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DPG Cloud Engineering



___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface on Apple Silicone

[Dirk Hohndel via subsurface]

> On Oct 22, 2021, at 1:57 PM, Robert Helling wrote:
> 
> Hi Dirk,
> 
> thanks a lot for your update. 
> 
>> On 15. Oct 2021, at 23:20, Dirk Hohndel > > wrote:
>> 
>> OK, since I had a day off today I didn't only finish 5.0.4, I also decided 
>> to at least poke a toe into this mess.
>> 
>> The summary of what I've learned so far?
>> 
>> UGH.
>> 
>> QtWebKit doesn't work with Qt 6 and it appears that no one is interested in 
>> porting that monster.
>> Frankly, I can't blame them.
>> 
>> Which means that we can't support printing with Qt 6.
>> 
> 
> I am only writing to report I started looking again into getting rid of  
> WebKit. I think even without the option to proceed to Qt 6, this would be a 
> good idea. After all, the only place where we really rely on it is to figure 
> out the page breaks when printing more than one dive. 
> 
> Progress is quite slow though as my time is currently limited (we just 
> started in person teaching again a week ago) but so far I did not get stuck. 
> Which I count as a good sign. 
> 
> Will keep you posted.


Some more messing around with Qt 6... we're not only losing QtWebKit - there's 
also no Qt Location and no Qt Positioning. Which means no map module that we 
can use.

/D

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface on Apple Silicone

[Robert Helling via subsurface]

Hi Dirk,

thanks a lot for your update.

> On 15. Oct 2021, at 23:20, Dirk Hohndel  wrote:
> 
> OK, since I had a day off today I didn't only finish 5.0.4, I also decided to 
> at least poke a toe into this mess.
> 
> The summary of what I've learned so far?
> 
> UGH.
> 
> QtWebKit doesn't work with Qt 6 and it appears that no one is interested in 
> porting that monster.
> Frankly, I can't blame them.
> 
> Which means that we can't support printing with Qt 6.
> 

I am only writing to report I started looking again into getting rid of  
WebKit. I think even without the option to proceed to Qt 6, this would be a 
good idea. After all, the only place where we really rely on it is to figure 
out the page breaks when printing more than one dive.

Progress is quite slow though as my time is currently limited (we just started 
in person teaching again a week ago) but so far I did not get stuck. Which I 
count as a good sign.

Will keep you posted.

Best
Robert


signature.asc
Description: Message signed with OpenPGP
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface on Apple Silicone

[Dirk Hohndel via subsurface]

On Fri, 2021-10-22 at 10:27 +0200, Tomaz Canabrava wrote:
> friendly reminder from an old time lurker
> that the 5.15 Qt is still being updated on the KDE infrastructure with the 
> LTS patches.

Well, yes they do.
But there are no releases. Which means that in order to go down that
path I am now truly in "build everything from source everywhere"-hell.

I haven't followed this closely enough to see if the Linux distros are
including these patches in their versions, though. Similarly, MXE
(which we use for Windows builds) doesn't use the KDE LTS version.

Also - I don't know if KDE will do anything to deal with any future
incompatibilities with Android and iOS changes.

So... I'm not yet sure that this is a reasonable way to go.

/D

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface on Apple Silicone

[Tomaz Canabrava via subsurface]

friendly reminder from an old time lurker
that the 5.15 Qt is still being updated on the KDE infrastructure with the
LTS patches.


On Fri, Oct 15, 2021 at 11:21 PM Dirk Hohndel via subsurface <
subsurface@subsurface-divelog.org> wrote:

> OK, since I had a day off today I didn't only finish 5.0.4, I also decided
> to at least poke a toe into this mess.
>
> The summary of what I've learned so far?
>
> UGH.
>
> QtWebKit doesn't work with Qt 6 and it appears that no one is interested
> in porting that monster.
> Frankly, I can't blame them.
>
> Which means that we can't support printing with Qt 6.
>
> The rest of the changes seemed like they should be doable in a few days of
> just hunting the build errors and warnings down - nothing seems
> catastrophic.
>
> Adding Qt 6 support should give us Apple M1 support, support for
> additional localizations of the base widget (e.g., Dutch). But frankly not
> a lot more that I can identify.
> The amount of work needed to upgrade our build infrastructure to Qt 6 for
> Windows, Mac, AppImage, Android, iOS... I really don't even want to
> contemplate it.
>
> So my current plan continues to be "stay on Qt 5.15 for as long as I
> possibly can". After all, the major Linux distros are mostly still shipping
> Qt 4 :)
>
> /D
>
> On Oct 15, 2021, at 12:05 PM, Dirk Hohndel via subsurface <
> subsurface@subsurface-divelog.org> wrote:
>
>
>
> On Oct 15, 2021, at 9:55 AM, Robert Helling wrote:
>
> Hi,
>
> has anybody managed to build Subsurface on Apple Silicone? Because I
> haven’t.
>
>
> Yeah, I still don't have a Mac with M1 silicon, so no, haven't even
> tried... my understanding is that the x86 version works just fine, though...
>
> Here is a log of my frustrations.
>
> Before leaving for the summer vacation, I received a new MacMini at the
> office featuring the new ARM based Apple hardware that everybody is so
> excited about. It runs Big Sur.
>
> It took several weeks to find the time to properly take care of it,
> install all the software I need for work, get permissions right (it seems
> they changed what admin users can do when the machine is part of an active
> domain or better what they cannot do, for example install software updates
> etc etc). But those things I think I have under control by now.
>
> So I move forward and tried to set up a build environment for Subsurface.
> I encountered halve installed versions of Xcode which on the other hand
> leave behind zombi installations when removed that confuse auto build when
> still around when there is a second version as well (this took me two days
> to understand). But also that is solved. I think.
>
>
> This might be good to document in more detail, especially how to fix it
> (for the next poor person coming around to this)
>
>
> But now I hit a road block: I am able to build the subsurface object
> files. But then I came to the understanding that Qt 5.x does not exist in
> version for Apple’s ARM processors, only for the 86 family (which could be
> used in Rosetta mode and indeed the official Mac binaries from Dirk’s
> server work fine on that machine). But I have not been able to convince the
> Subsurface build system to build 86 family binaries on my ARM machine.
>
>
> No idea how to do that, frankly. I'm sure you've found this page
> https://www.qt.io/blog/qt-on-apple-silicon and if you wanted to
> experiment with Qt6 there's more stuff here
> https://doc.qt.io/qt-6/macos.html
>
> I think eventually we will need to port to Qt 6 - and that should fix the
> core of your problem, right?
>
> So I see three options to move forward: „Cross-build“ Subsurface for the
> old hardware platform. Or wait for ARM built binaries of Qt 5.x (which as I
> understand might never happen at least in the open source world). Or move
> Subsurface forward to work with Qt 6 (which might be in better shape w.r.t.
> ARM but I don’t really understand the current situation in detail).
>
>
> I think you have that right. Allegedly one can build "fairly decent" Qt
> 5.15 binaries for M1. Just takes a while :)
>
> But really, the only logical path is Qt6
>
> /D
>
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
>
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface on Apple Silicone

[Dirk Hohndel via subsurface]

OK, since I had a day off today I didn't only finish 5.0.4, I also decided to 
at least poke a toe into this mess.

The summary of what I've learned so far?

UGH.

QtWebKit doesn't work with Qt 6 and it appears that no one is interested in 
porting that monster.
Frankly, I can't blame them.

Which means that we can't support printing with Qt 6.

The rest of the changes seemed like they should be doable in a few days of just 
hunting the build errors and warnings down - nothing seems catastrophic.

Adding Qt 6 support should give us Apple M1 support, support for additional 
localizations of the base widget (e.g., Dutch). But frankly not a lot more that 
I can identify.
The amount of work needed to upgrade our build infrastructure to Qt 6 for 
Windows, Mac, AppImage, Android, iOS... I really don't even want to contemplate 
it.

So my current plan continues to be "stay on Qt 5.15 for as long as I possibly 
can". After all, the major Linux distros are mostly still shipping Qt 4 :)

/D

> On Oct 15, 2021, at 12:05 PM, Dirk Hohndel via subsurface 
>  wrote:
> 
> 
> 
>> On Oct 15, 2021, at 9:55 AM, Robert Helling wrote:
>> 
>> Hi,
>> 
>> has anybody managed to build Subsurface on Apple Silicone? Because I haven’t.
> 
> Yeah, I still don't have a Mac with M1 silicon, so no, haven't even tried... 
> my understanding is that the x86 version works just fine, though...
> 
>> Here is a log of my frustrations.
>> 
>> Before leaving for the summer vacation, I received a new MacMini at the 
>> office featuring the new ARM based Apple hardware that everybody is so 
>> excited about. It runs Big Sur.
>> 
>> It took several weeks to find the time to properly take care of it, install 
>> all the software I need for work, get permissions right (it seems they 
>> changed what admin users can do when the machine is part of an active domain 
>> or better what they cannot do, for example install software updates etc 
>> etc). But those things I think I have under control by now.
>> 
>> So I move forward and tried to set up a build environment for Subsurface. I 
>> encountered halve installed versions of Xcode which on the other hand leave 
>> behind zombi installations when removed that confuse auto build when still 
>> around when there is a second version as well (this took me two days to 
>> understand). But also that is solved. I think.
> 
> This might be good to document in more detail, especially how to fix it (for 
> the next poor person coming around to this)
> 
> 
>> But now I hit a road block: I am able to build the subsurface object files. 
>> But then I came to the understanding that Qt 5.x does not exist in version 
>> for Apple’s ARM processors, only for the 86 family (which could be used in 
>> Rosetta mode and indeed the official Mac binaries from Dirk’s server work 
>> fine on that machine). But I have not been able to convince the Subsurface 
>> build system to build 86 family binaries on my ARM machine.
> 
> No idea how to do that, frankly. I'm sure you've found this page 
> https://www.qt.io/blog/qt-on-apple-silicon 
> <https://www.qt.io/blog/qt-on-apple-silicon> and if you wanted to experiment 
> with Qt6 there's more stuff here https://doc.qt.io/qt-6/macos.html 
> <https://doc.qt.io/qt-6/macos.html>
> 
> I think eventually we will need to port to Qt 6 - and that should fix the 
> core of your problem, right?
> 
>> So I see three options to move forward: „Cross-build“ Subsurface for the old 
>> hardware platform. Or wait for ARM built binaries of Qt 5.x (which as I 
>> understand might never happen at least in the open source world). Or move 
>> Subsurface forward to work with Qt 6 (which might be in better shape w.r.t. 
>> ARM but I don’t really understand the current situation in detail).
> 
> I think you have that right. Allegedly one can build "fairly decent" Qt 5.15 
> binaries for M1. Just takes a while :)
> 
> But really, the only logical path is Qt6
> 
> /D
> 
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface on Apple Silicone

[Dirk Hohndel via subsurface]

> On Oct 15, 2021, at 9:55 AM, Robert Helling wrote:
> 
> Hi,
> 
> has anybody managed to build Subsurface on Apple Silicone? Because I haven’t.

Yeah, I still don't have a Mac with M1 silicon, so no, haven't even tried... my 
understanding is that the x86 version works just fine, though...

> Here is a log of my frustrations.
> 
> Before leaving for the summer vacation, I received a new MacMini at the 
> office featuring the new ARM based Apple hardware that everybody is so 
> excited about. It runs Big Sur.
> 
> It took several weeks to find the time to properly take care of it, install 
> all the software I need for work, get permissions right (it seems they 
> changed what admin users can do when the machine is part of an active domain 
> or better what they cannot do, for example install software updates etc etc). 
> But those things I think I have under control by now.
> 
> So I move forward and tried to set up a build environment for Subsurface. I 
> encountered halve installed versions of Xcode which on the other hand leave 
> behind zombi installations when removed that confuse auto build when still 
> around when there is a second version as well (this took me two days to 
> understand). But also that is solved. I think.

This might be good to document in more detail, especially how to fix it (for 
the next poor person coming around to this)


> But now I hit a road block: I am able to build the subsurface object files. 
> But then I came to the understanding that Qt 5.x does not exist in version 
> for Apple’s ARM processors, only for the 86 family (which could be used in 
> Rosetta mode and indeed the official Mac binaries from Dirk’s server work 
> fine on that machine). But I have not been able to convince the Subsurface 
> build system to build 86 family binaries on my ARM machine.

No idea how to do that, frankly. I'm sure you've found this page 
https://www.qt.io/blog/qt-on-apple-silicon 
<https://www.qt.io/blog/qt-on-apple-silicon> and if you wanted to experiment 
with Qt6 there's more stuff here https://doc.qt.io/qt-6/macos.html 
<https://doc.qt.io/qt-6/macos.html>

I think eventually we will need to port to Qt 6 - and that should fix the core 
of your problem, right?

> So I see three options to move forward: „Cross-build“ Subsurface for the old 
> hardware platform. Or wait for ARM built binaries of Qt 5.x (which as I 
> understand might never happen at least in the open source world). Or move 
> Subsurface forward to work with Qt 6 (which might be in better shape w.r.t. 
> ARM but I don’t really understand the current situation in detail).

I think you have that right. Allegedly one can build "fairly decent" Qt 5.15 
binaries for M1. Just takes a while :)

But really, the only logical path is Qt6

/D

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Subsurface on Apple Silicone

[Robert Helling via subsurface]

Hi,

has anybody managed to build Subsurface on Apple Silicone? Because I haven’t.

Here is a log of my frustrations.

Before leaving for the summer vacation, I received a new MacMini at the office 
featuring the new ARM based Apple hardware that everybody is so excited about. 
It runs Big Sur.

It took several weeks to find the time to properly take care of it, install all 
the software I need for work, get permissions right (it seems they changed what 
admin users can do when the machine is part of an active domain or better what 
they cannot do, for example install software updates etc etc). But those things 
I think I have under control by now.

So I move forward and tried to set up a build environment for Subsurface. I 
encountered halve installed versions of Xcode which on the other hand leave 
behind zombi installations when removed that confuse auto build when still 
around when there is a second version as well (this took me two days to 
understand). But also that is solved. I think.

But now I hit a road block: I am able to build the subsurface object files. But 
then I came to the understanding that Qt 5.x does not exist in version for 
Apple’s ARM processors, only for the 86 family (which could be used in Rosetta 
mode and indeed the official Mac binaries from Dirk’s server work fine on that 
machine). But I have not been able to convince the Subsurface build system to 
build 86 family binaries on my ARM machine.

So I see three options to move forward: „Cross-build“ Subsurface for the old 
hardware platform. Or wait for ARM built binaries of Qt 5.x (which as I 
understand might never happen at least in the open source world). Or move 
Subsurface forward to work with Qt 6 (which might be in better shape w.r.t. ARM 
but I don’t really understand the current situation in detail).

Or ignore this new machine and only try to build Subsurface on my old Intel Mac 
(which are a bit aged which was the reason in the first place to get the new 
machine).

Any thoughts? Am I missing something?

Best
Robert


signature.asc
Description: Message signed with OpenPGP
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface