New release for mac?

[doc...@gmail.com]

No hurry apparently, as the single mac bug is in the binary I'm currently running but when might it be available?

thanks for all you guys do.

Mike

[Bob Campbell]

I don’t know, but I’m trying to build Hugin from the ground up for the mac.  

Is anyone the designated builder for this now?  

I’ve gotten through building the ExternalPrograms under the mac directory, and have some suggestions and updates for the scripts. Notably, how SetEnv.sh finds paths and versions for Xcode, but also how Apple’s clang(++) can be made to use libomp.  I’m not 100% sure I’ve got everything perfect, but I’m on the way.  Unfortunately, the documentation is way out of date as there is no xcode project file anymore, and the mac docs don’t tell you what you need for cmake options & vars. So I feel like I’m at a bit of a dead-end.  If anyone’s working on it, I’ll try to help, but right now I’m stuck.

Thanks,

Bob Campbell

--
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/f88ca778-8da6-40fd-a872-2096536c4200n%40googlegroups.com.

[T. Modes]

Bob Campbell schrieb am Mittwoch, 3. Februar 2021 um 07:13:03 UTC+1:

and the mac docs don’t tell you what you need for cmake options & vars. So I feel like I’m at a bit of a dead-end.  If anyone’s working on it, I’ll try to help, but right now I’m stuck.

I don't have access to a Mac. But have a look at the script mac/configure-bundle.sh. There are an example for the CMake invokation on a mac.

Another advice is to use a CMake GUI: there are all switches listed in the GUI and you can so easily inspect and change the parameters.

[Bob Campbell]

Thanks!  Didn’t know about cmake gui’s.  I’ll try that.

I did see the cmake in configure-bundle.sh, but it seemed sparse?  At least considering the complexity of the build scripts under ExternalPrograms, but I’ll see if that just works.

--
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/f4d2c0f2-9c2a-4924-948d-3257d56d821fn%40googlegroups.com.

[nik...@mischkulnig.de]

I have built the mac binaries for the last few releases. I can try to do one over the next couple of days. 

I added some instructions back when I moved the mac build system from XCode to cmake: http://hg.code.sf.net/p/hugin/hugin/file/tip/mac/configure-bundle.sh

Niklas

[Niklas Mischkulnig]

I've updated some external programs either because some links were dead or because the old version isn't compatible with the macOS 11.0 SDK.

(I also had to bump the minimum version to macOS 10.10 because of wxWidgets 3.1.4). There's now also more apparent `mac/README.md` file.

PTBatcherGUI.app works, but I think the GL Preview is somehow not working because Hugin.app itself freezes while the splash screen is shown (doesn't crash though).

I haven't yet figured out why.

> have some suggestions and updates for the scripts. Notably, how SetEnv.sh finds paths and versions for Xcode, but also how Apple’s clang(++) can be made to use libomp

Go ahead :D

I also changed to SDKVERSION=$(xcrun --show-sdk-version) already, if that's what you had in mind.

Niklas

[Bob Campbell]

Yes, using xcrun for the SDKVERSION was one change.  

Also, I use subfolders under /Applications/.  Notably, I have XCode installed in /Applications/Development/, so I’ve added:

XCODE_PATH=`xcode-select --print-path`

and changed:

MACSDKDIR="${XCODE_PATH}/Platforms/MacOSX.platform/Developer/SDKs/MacOSX${SDKVERSION}.sdk"

I think there’s an xcrun option that will provide the above path w/o having to use the double var concatenation.

And:

PROCESSNUM=$(sysctl hw.ncpu | sed 's/^.*://' | sed 's/[^[:digit:]]//g’);

I have a feeling ‘sysctl’ may be more future-proof than the output of hostinfo. Seems cleaner at least.

Another is for anything using cmake and CMakeModules/FindOpenMP.cmake for libomp, add:

  #Apple clang

  "-Xpreprocessor -fopenmp -lomp”

(-lomp may not be necessary?)

I can use homebrew’s clang instead, but if that was the only reason for not using Apple’s clang, that may be a solution. (I haven’t gotten a working build yet, though, so...)

BTW, the only libiconv that I got to work without error was homebrew’s, so I was thinking they’re building it with particular options.  Are you able to get it to link in and/or compile correctly?  I was getting this error until I installed homebrew’s version:

ld: warning: dylib (/Users/rsc/src/hugin-2020.0.0-2/mac/ExternalPrograms/repository/lib/libiconv.dylib) was built for newer macOS version (10.15) than being linked (10.13)

Undefined symbols for architecture x86_64:

  "_iconv", referenced from:

      Exiv2::

- Completely aside, when I ran into the above error (x86_64), I tried updating the line:

 OPTIMIZE="-march=core2 -mtune=core2 -ftree-vectorize” \

to a more current -march, but couldn't really find anything definitive to use and nothing I tried helped anyway. But that might be something to consider as well - core2 macs were deprecated quite a while ago (I had a white imac that was core2 - I don’t think any of the silver ones are).  So what might be a better -march to optimize for?

Thanks for the updates!  I assume I need to refresh hugin from hg?

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/6f2e6f57-307a-4423-8594-7ae153ebf7cbn%40googlegroups.com.

[Niklas Mischkulnig]

Bob Campbell schrieb am Samstag, 6. Februar 2021 um 02:53:10 UTC+1:

Yes, using xcrun for the SDKVERSION was one change.  

Also, I use subfolders under /Applications/.  Notably, I have XCode installed in /Applications/Development/, so I’ve added:

XCODE_PATH=`xcode-select --print-path`

and changed:

MACSDKDIR="${XCODE_PATH}/Platforms/MacOSX.platform/Developer/SDKs/MacOSX${SDKVERSION}.sdk"

I think there’s an xcrun option that will provide the above path w/o having to use the double var concatenation.

I've changed it to use xcrun --show-sdk-path where possible.

 

And:

PROCESSNUM=$(sysctl hw.ncpu | sed 's/^.*://' | sed 's/[^[:digit:]]//g’);

I have a feeling ‘sysctl’ may be more future-proof than the output of hostinfo. Seems cleaner at least.

Yeah, I had already changed it to sysctl -n hw.physicalcpu.

 

Another is for anything using cmake and CMakeModules/FindOpenMP.cmake for libomp, add:

  #Apple clang

  "-Xpreprocessor -fopenmp -lomp”

(-lomp may not be necessary?)

I can use homebrew’s clang instead, but if that was the only reason for not using Apple’s clang, that may be a solution. (I haven’t gotten a working build yet, though, so...)

I'll look into that. clang++ openmp.cpp -Xclang -fopenmp -lomp -I include -L lib does work in an isolated test.

 

BTW, the only libiconv that I got to work without error was homebrew’s, so I was thinking they’re building it with particular options.  Are you able to get it to link in and/or compile correctly?  I was getting this error until I installed homebrew’s version:

ld: warning: dylib (/Users/rsc/src/hugin-2020.0.0-2/mac/ExternalPrograms/repository/lib/libiconv.dylib) was built for newer macOS version (10.15) than being linked (10.13)

Undefined symbols for architecture x86_64:

  "_iconv", referenced from:

      Exiv2::

No, it works for me (just running build-all.sh). Does that happen when building Hugin or exiv2?

 

- Completely aside, when I ran into the above error (x86_64), I tried updating the line:

 OPTIMIZE="-march=core2 -mtune=core2 -ftree-vectorize” \

to a more current -march, but couldn't really find anything definitive to use and nothing I tried helped anyway. But that might be something to consider as well - core2 macs were deprecated quite a while ago (I had a white imac that was core2 - I don’t think any of the silver ones are).  So what might be a better -march to optimize for?

The oldest Mac supported by 10.8-10.11 is the iMac Mid 2009, using an Intel Core 2 Duo (T7300, T7700)...

 

 I assume I need to refresh hugin from hg?

Yes

Niklas

[Bob Campbell]

When building exiv2.  Maybe because I have the build target set to 10.13?  I’m building exiv2-0.27.2 - haven’t checked if that’s the most recent release.

[Tim Kerby]

How's the build for this going? I'm finding the display issues on hidpi screens on the previous version a challenge and hoping we could have even a mac alpha soon to try

Thanks

Tim

[Niklas Mischkulnig]

timoth...@gmail.com schrieb am Mittwoch, 17. Februar 2021 um 12:43:51 UTC+1:

How's the build for this going? I'm finding the display issues on hidpi screens on the previous version a challenge and hoping we could have even a mac alpha soon to try

I've updated the dependencies and pushed that to the repository so that it can be compiled with the current Xcode version. But I haven't had time to look why the Hugin GL Preview doesn't work.

 

On Monday, 8 February 2021 at 18:12:22 UTC Bob Campbell wrote:

When building exiv2.  Maybe because I have the build target set to 10.13?  I’m building exiv2-0.27.2 - haven’t checked if that’s the most recent release.

repository/lib/libiconv.dylib doesn't exist for me after building the dependencies, it should use the system version. I ran otool -L lib/libexiv2.dylib and it has indeed linked against /usr/lib/libiconv.2.dylib.

Maybe changing the deployment target caused another configuration change when building gettext (which then built libiconv, I'm don't actually know why it doesn't in my case).

If you're not actually intending to build a binary for distribution, you could also simply not set -DMAC_SELF_CONTAINED_BUNDLE=ON in Hugin's cmake and install all dependencies via Homebrew (or MacPorts), so treating it like a "normal" Linux build and following INSTALL_cmake.

Niklas

[jmuc...@gmail.com]

Guys,

Thanks for working on this. I too find the missing previews on retina screens very hard to work around.

Based on the comments on the release-notes page, (namely "Fixes fast preview on HiDPI screens under GTK+3 and MacOS"), it seems like was able to compile it on a Mac, no? 

[Bob Campbell]

On Feb 17, 2021, at 3:20 PM, Niklas Mischkulnig <nik...@mischkulnig.de> wrote:

 

On Monday, 8 February 2021 at 18:12:22 UTC Bob Campbell wrote:

When building exiv2.  Maybe because I have the build target set to 10.13?  I’m building exiv2-0.27.2 - haven’t checked if that’s the most recent release.

repository/lib/libiconv.dylib doesn't exist for me after building the dependencies, it should use the system version. I ran otool -L lib/libexiv2.dylib and it has indeed linked against /usr/lib/libiconv.2.dylib.

Maybe changing the deployment target caused another configuration change when building gettext (which then built libiconv, I'm don't actually know why it doesn't in my case).

If you're not actually intending to build a binary for distribution, you could also simply not set -DMAC_SELF_CONTAINED_BUNDLE=ON in Hugin's cmake and install all dependencies via Homebrew (or MacPorts), so treating it like a "normal" Linux build and following INSTALL_cmake.

I do want to build for distribution, eventually.  Mainly, I was just going by the docs, which are out of date, but mention building zlib and iconv2 manually, to statically link in.  I’m fine with using the system libiconv2 if it works.

My latest block is that I was having trouble getting enblend to compile correctly.  I’m getting this error:

ld: symbol(s) not found for architecture x86_64

clang-11: error: linker command failed with exit code 1 (use -v to see invocation)

which relates to a linking problem:

Undefined symbols for architecture x86_64:

  "___kmpc_barrier", referenced from:

      _.omp_outlined..769 in enblend.cc.o

      _.omp_outlined..773 in enblend.cc.o

      _.omp_outlined..774 in enblend.cc.o

Obviously, libomp issues again, so I tried changing various paths and tried to force it to find repository/lib/libomp.dylib, which is obviously there:

$ ls ./lib/lib*omp*

./lib/libgomp.dylib ./lib/libiomp5.dylib ./lib/libomp.dylib

Until I finally added a -l and discovered:

$ ls -l ./lib/lib*omp*

lrwxr-xr-x  1 rsc  staff  12 Feb 15 21:15 ./lib/libgomp.dylib -> libomp.dylib

lrwxr-xr-x  1 rsc  staff  12 Feb 15 21:15 ./lib/libiomp5.dylib -> libomp.dylib

lrwxr-xr-x  1 rsc  staff  14 Feb 15 21:15 ./lib/libomp.dylib -> libiomp5.dylib

lol.  So obviously something’s up with the installer for libomp.  I just haven’t taken the time to figure out what’s going on with that step.

[Bob Campbell]

I’m also having that problem, and would like to see it addressed.  I’m hopefully helping out by trying to build a distributable package that isn’t tied to other software installed on the system, making it more ‘universal’.  So, while there may have been build that tested the hidpi screen patch, it likely required a particular set of third-party software installed, typically from MacPorts or Homebrew. 

Bob

--
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/d47c913c-6338-4b57-b1b2-0413819f2f89n%40googlegroups.com.

[Bob Campbell]

Well, I was able to get it built, finally, and tested it out on three different macs:

iMac Retina 5K 2019, Catalina 10.15.7, Radeon Pro 570X

Mac Mini Late 2012, Catalina 10.15.7, Intel HD 4000

MacBook Pro Late 2011, High Sierra 10.13.6, Intel HD 3000 (the discreet nvidia chip on this is burned out, so it’s using the onboard Intel gfx chip)

To get it to build and link correctly, though, I had to update openmp to version 11.1.0 (instead of 11.0.1).

All worked, I’m glad to say, including the hidpi GL preview on the iMac!  

Unfortunately, I still have the problem on the iMac where PTBatcherGUI starts the stitching batch job, but nothing happens.  I’ve added Hugin, PTBatcherGUI, and HuginStitchProject to Full Disk Access in the Privacy/Security Prefs, but nothing happens.  Oddly, it works fine on the mac mini with all the same (as far as I can tell) security settings.

PTBatcherGUI on the iMac just opens the stitching window, but nothing happens in the window.

On Feb 19, 2021, at 6:31 PM, jmuc...@gmail.com <jmuc...@gmail.com> wrote:

--
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/d47c913c-6338-4b57-b1b2-0413819f2f89n%40googlegroups.com.

[dgjohnston]

Hi Bob … I have a MacBook Pro (15-inch, Mid 2012) running Catalina 10.15.7, Intel Core i7 16GB memory, Intel HD Graphics 4000 1536 MB.

If you need some additional testing of you build I would be willing to test it for you.

Don Johnston

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/BDB44D64-DDA2-4858-8653-9D52182C234E%40gmail.com.

[Bob Campbell]

Well, I don’t have it all packaged up nicely, but here’s a tarball of the build:

http://you-rebel-scum.com/hugin/hugin_test.tar

Untar’s a hugin_test folder.  You may need to move, remove, or zip up the Hugin folder in your Applications area for it to get the correct binaries, though.

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/2EDA04AE-E2F4-4C2C-913C-6567782E7AD3%40accesscomm.ca.

[jmuc...@gmail.com]

Thanks for doing this. I just downloaded and tried it myself.

PTBatcherGUI hung the first time, but I force-quit and then opened it on its own to get the "are you sure you want to run this" dialog. Then it ran fine.

I do get the same error I did with the last version: 15:51:15: Failed to get the working directory (error 2: No such file or directory)

No details on what directory that is, so I'm at a loss.

The OpenGL preview works now. :-)

[AKS-Gmail-IMAP]

The failed to open error is due to Hugin and PTBatcherGUI not having proper access rights. Fixing that is the business of granting Hugin and PTBatcherGUI Full Disk Access at Security & Privacy at System Preferences. I find doing that is required on this recent build running on OS X 10.17.7.

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/6ac94e4f-0d83-4987-9fe8-fd8e106e126en%40googlegroups.com.

[Bob Campbell]

Yeah, that’s the catch; both my imac and my mac mini (both on 10.15.7) have Hugin, PTBatcherGUI, and HuginStitchProject with Full Disk Access in the Security prefs.  The mini works ok - the stitcher runs the commands just fine; the imac does not; PTBatcherGUI starts the stitching job, opens the stitching window, and then nothing happens.  It also doesn’t respond to any mouse clicks, but the OS doesn’t register it as frozen - but I have to force quit anyway.

The only thing I can think is that PTBatcherGUI is calling command line utilities in the Hugin.app, so maybe each one needs Full Disk Access?  But the mini doesn’t have all those rights granted.  What the mini did have was an older OS with more successive upgrades; the imac is newer and came with Catalina.

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/D87DB4E6-A0F8-494D-8605-B0DC53968576%40gmail.com.

[dgjohnston]

After telling MacOS that everything was okay (and setting Full Disk Access) everything is now working on my MacBook Pro

 15-inch, Mid 2012) running Catalina 10.15.7, Intel Core i7 16GB memory, Intel HD Graphics 4000 1536 MB.

So you can caulk this up as a great success.

Thanks for putting this together for us Mac users!!!!!

Don J.

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/6132ECD6-E376-4B53-9832-CE0C01727EF9%40gmail.com.

[jmuc...@gmail.com]

Bob,

Did you try just launching PTBatcherGUI directly on its own? Then you should get the dialog asking if its ok to run it.

[jmuc...@gmail.com]

Thanks. This worked.

Now how to get PTBatcherGUI to become the active app when it starts running?

[Harry van der Wolf]

Having full disk access is not the only point.

Hugin is not released via the App store and not via a registered developer. That's also why the MacOS Gatekeeper software is blocking it.

You have to right-click every app bundle, click on open and MacOS will test the contents, say something about the risks,  and asks if it can open it.

After that it works OK, also with upgrades. If you completely remove it and then reinstall it, you have to do the same again.

Or follow this link to read about it: https://support.apple.com/en-us/guide/mac-help/mh40620/mac

I do cross-platform open-source development as well and I hate the MacOS policy and am therefore not a registered developer and certainly not release via the App Store, so my app has the same issue. (Users have to accept that or simply not use my app. I support the MacOS users, not Apple).

Harry

Op wo 24 feb. 2021 om 23:38 schreef jmuc...@gmail.com <jmuc...@gmail.com>:

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/097959d4-2ca9-4536-a042-4b5d8114e6c4n%40googlegroups.com.

[jmuc...@gmail.com]

Yeah, I have a bunch of apps that I have to do this for. Not a big deal. What's odd about PTBatcherGUI is that Hugin can launch it, so it looks like all is well, but then it doesn't do anything. You need to directly open it and OK it yourself. Then the Hugin launch will work fine. Most apps don't even launch, so this is a bit deceptive...or so it was for me.

Again, another weird thing about that app is that when it does launch, it does so at the end of the list (e.g., when CMD-tabbing through open apps). I'd have expected it to be the next app that I can quickly CMD-tab to, or even to make itself the frontmost app.

All minor issues. :-)

[yuv]

On Thu, 2021-02-25 at 08:22 +0100, Harry van der Wolf wrote:
> I hate the MacOS
> policy and am therefore not a registered developer and certainly not
> release via the App Store, so my app has the same issue. (Users have
> to accept that or simply not use my app. I support the MacOS users,
> not Apple).

Write to your local anti-trust authority / competition commissioner /
etc. Anyone has my permission to re-use the text below, on the
condition that said anyone does not rely legally on it (I am not
anyone's lawyer, and in most cases I cannot be). I am happy to put
together a more detailed argument/analysis for anyone to use against
Apple and (adapted accordingly) the rest of BigTech.

Apple is "lessening or preventing competition" (the legal keyword) and
has gone way too long under the radar screen. I recently had to set up
an iDevice (school requirement) and it felt worse than being ordered to
stay at home under curfew because of the current pandemic. Apple has
managed to successfully excercise ownership on users, developers, and
government.

Anti-trust authorities have given Microsoft users the choice of browser
at a time when Microsft's conduct was much less detrimental and
offensive to the market than Apple's current conduct is detrimental to
the market, no matter how the market is defined (and definition of the
market is crucial for an anti-trust case).

In your letter, request the following remedies:
* Apple to give user a choice of cloud services to connect their
iDevice to on initialization of the iDevice. Similar to what Microsoft
had to do with the choice of browser. This includes choice of app
store; choice of cloud storage provider; choice of account ID provider.
* Apple to accept in its stores software built with non-Apple
toolchains.
* Apple to give app developers (cloud providers!) access to the same
API independent of Apple's cloud services that it uses to implement
iCloud sync and instant messaging. Right now, Dropbox, Nextcloud, and
other competitors are at hard disadvantage because they cannot achieve
feature-parity with iCloud. Their workaround is to have their app's
sync triggered on GPS-coordinate change, totally inferior, while on
Android they have an opportunity to achieve parity with Google's
services.
* Apple to implement standard Push API in Safari, for the same reason
as above. Currently, Apple requires website operator regi$tration,
licen$e, and use of an Apple service. I call this unlawful
monetization of access to user
* Apple to give user the choice to replace Apple's root encryption keys
with the user's own; and to disable the features that prevents software
unauthorized by the encryption keys owner to run on the iDevice.
* Ultimate control must rest with the user, not with Apple, and
ultimate control is not the same as dumping the iDevice on the
electropile junk.

At the moment, the only reasonable way to describe iDevices is a pre-
paid lease with an unknown term at the discretion of the landlord on
zero-day notice. Unconscionable. Has been unacceptable for centuries
in the Western legal systems, and it is time set the record straight
that it won't be acceptable in the future either.

--
Yuval Levy, JD, MBA, CFA
Ontario-licensed lawyer

[Bob Campbell]

Well, I tried deleting all the Security & Privacy settings for both Hugin and PTBatcherGUI, and re-enabling them, but still got a blank batch window.  Then I opened PTBatcherGUI on it’s own, and clicked “Always save log” and it started working.  Go figure.

Yeah, the new MacOS security settings are a pain, but as a unix sys admin, they’re equal to the selinux security in RedHat & CentOS.

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/CAGARPpurZgasQZ6J1j2PGbE2qo%3DgynC5q0ZAbhK_LR8bH2jvsQ%40mail.gmail.com.

[Harry van der Wolf]

Hi Yuv,

Nice to see you again here.

Thanks for the extensive, clear answer on this. (and I learned something from it as well).

Although I do have some serious complaints about Apple, enough to abandon the platform, I do not see myself picking this up. Especially not from Europe to an US company. Even the EU has issues getting a grip on Facebook, Apple and some of the other "evil" companies.

That also means that this isn't the first time. Isn't there a central committee/foundation that is doing these kind of things?

Best,

Harry

Op do 25 feb. 2021 om 17:26 schreef yuv <goo...@levy.ch>:

--
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/54fd888ebf50778c211ae9e36253dd25a20196ff.camel%40levy.ch.

[yuv]

On Tue, 2021-03-02 at 14:45 +0100, Harry van der Wolf wrote:
> Nice to see you again here.

Thanks. My current mail infrastructure is borken and so I do read
manually these days, mainly with the delete key, until I am comfortable
with my filters again.

> Isn't there a central
> committee/foundation that is doing these kind of things?

anti-trust is typically a government decision and modern countries have
their anti-trust agencies that are influenced by voices on both sides
of the divide. You can support organizations like the EFF that voice
the concerns at the high political levels, but compete with the
lobbying of companies whose yearly revenue is larger than that of a
mid-sized country. And then you can vote with your wallet, but it
becomes increasingly difficult. School forced an iDevice in my
household again. Can't buy a new car without Google or Apple inside
nowadays. Increasingly difficult to bank without a smartphone and
integrated surveillance. And while most modern countries have rules
against tied selling on their books, they are still not able to wrap
their legal heads around the situation where the currency exacted from
the consumer is not money. interesting time we live in.

[Jim Watters]

Yuv,

Nice to see you here putting your talents and expertise to good use. I
read some of most threads but I've not contributed in a long time.

Jim Watters

[jmuc...@gmail.com]

Will this 2020 version make it to the sourceforge download page?

[Bob Campbell]

I briefly looked for a build target for a distributable .dmg file, but didn’t find anything.  I’ll try putting together something, but if anyone knows off-hand, please speak up!

--
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/925d4a20-51d7-4d73-a289-8fe5f7b81a83n%40googlegroups.com.

[Niklas Mischkulnig]

Bob Campbell schrieb am Montag, 15. März 2021 um 06:58:10 UTC+1:

I briefly looked for a build target for a distributable .dmg file, but didn’t find anything.  I’ll try putting together something, but if anyone knows off-hand, please speak up!

As described on http://hg.code.sf.net/p/hugin/hugin/file/tip/mac/README.md,

this will create a dmg like the ones of previous releases:

make package 

Niklas