It looks like LuLu now releases DMG files instead of ZIPs:
https://github.com/objective-see/LuLu/releases/download/v2.2.0/LuLu_2.2.0.dmg

Error in com.github.apettinen.download.MSTeams: Processor: URLDownloader: Error: Curl failure: LibreSSL SSL_read: SSL_ERROR_SYSCALL, errno 54 (exit code 56)

MSTeamsURLProvider
{'Input': {}}
MSTeamsURLProvider: MSTeams URL found: https://statics.teams.microsoft.com/production-osx/1.1.00.5851/Teams_osx.dmg
{'Output': {'url': 'https://statics.teams.microsoft.com/production-osx/1.1.00.5851/Teams_osx.dmg'}}
URLDownloader
{'Input': {'url': 'https://statics.teams.microsoft.com/production-osx/1.1.00.5851/Teams_osx.dmg'}}
URLDownloader: No value supplied for CHECK_FILESIZE_ONLY, setting default value of: False
URLDownloader: No value supplied for CURL_PATH, setting default value of: /usr/bin/curl
Curl failure: LibreSSL SSL_read: SSL_ERROR_SYSCALL, errno 54 (exit code 56)
Failed.

macOS High Sierra 10.13.3
AutoPkg 1.0.4

The MS Teams folks have switched from providing a .dmg with the app inside to now providing an installer package. Latest link from the download page is this:

https://statics.teams.microsoft.com/production-osx/1.1.00.17551/Teams_osx.pkg

May the Teams recipes please be updated to now handle the downloaded installer package?

Currently the git-lfs.pkg recipe seems to just put the entire unzipped archive into /usr/local/bin:

$ pkgutil --payload-files git-lfs-amd64-3.2.0.pkg 
.
./usr
./usr/local
./usr/local/bin
./usr/local/bin/git-lfs
./usr/local/bin/git-lfs/git-lfs
./usr/local/bin/git-lfs/man
<snip>
./usr/local/bin/git-lfs/README.md

I'd expect the git-lfs binary at

./usr/local/bin/git-lfs

and the then the contents of the man/man1 and man/man5 directories installed under

./usr/local/man/man1
./usr/local/man/man5

etc.
As it is currently, git-lfs doesn't actually work post-install because it's installed to /usr/local/bin/git-lfs/git-lfs. And the man pages don't work, either.

As of v2.12.0 of git-lfs the packaging/release format for git-lfs has changed (See: https://github.com/git-lfs/git-lfs/releases/tag/v2.12.0) and this is causing the AutoPkg recipes to silently fail.

Specifically, the git-lfs maintainers have stopped packaging macOS releases as compressed .tar.gz archives and, instead, are now packaging them as .zip files. The reason for this change is due to Apple not allowing tarballs to be signed/notarized (but .zip files are) and more info about this change can be seen in the inciting PR here => git-lfs/git-lfs#4143

As you can see below, the most recent release that the AutoPkg recipe is picking up is the final release of git-lfs which was packaged as a tarball (and newer, more recent releases are being ignored):

$ autopkg run git-lfs.munki
Processing git-lfs.munki...

The following new items were downloaded:
    Download Path
    -------------
    /Users/Shared/autopkg/Cache/local.munki.git-lfs/downloads/git-lfs-amd64-2.11.0.tar.gz

The following packages were built:
    Identifier          Version  Pkg Path
    ----------          -------  --------
    com.github.git-lfs  2.11.0   /Users/Shared/autopkg/Cache/local.munki.git-lfs/git-lfs-amd64-2.11.0.pkg

Hi,

I receive this error when I run the hugo.munki recipe after creating an override in Autopkgr

No JSON object can be decoded.

Any thoughts as other munki recipes work fine.

A download link for Microsoft Teams has been posted to http://macadmins.software.

I was able to use it to build a new MicrosoftTeams.download AutoPkg recipe which uses that link:

https://github.com/autopkg/rtrouton-recipes/blob/master/MicrosoftTeams/MicrosoftTeams.download.recipe

https://updates.bravesoftware.com/sparkle/Brave-Browser/stable/appcast.xml

I have noted errors lately from AutoPkgr with messages like "Processor: GitHubReleasesInfoProvider: Error: No release assets were found that satisfy the criteria." While I did not got back in versions history of Brave, I do note that at least for v75.0.65.121 on a Mac test box, that it does have an SUFeedURL key in its Info.plist file pointing to the URL at the top of this message.

If I have a chance later today I will see if I can't submit a pull request. However, I am posting this here if anyone else wants to get on that more quickly.

How is it possible to verify that "bravesoftware.com" is actually an official domain associated with "brave.com"? The official download appear to all come from "brave.com".

Hey,

Is you recipe for Brave Apple Silicon ready ?
I means, is there a way to tell it to download arm dmg with detection of Apple Silicon hardware ?

Thanks :)

The download from the Terragrunt repository is not set with an executable flag.

I can see the permissions being set on directories within your recipe but this doesn't seem to pass to the file being injected into the package, meaning the resulting file in /usr/local/bin isn't executable.

I'm looking into Jesse Petersons ModeChanger processor to change the permissions on the file, I will submit a PR if I can get it working.

The last week Brave.munki has been giving me these errors:

Processing local.munki.Brave...
URLDownloader
URLDownloader: Item at URL is unchanged.
URLDownloader: Using existing /Users/jonasb/Library/AutoPkg/Cache/local.munki.Brave/downloads/Brave.dmg
EndOfCheckPhase
CodeSignatureVerifier
CodeSignatureVerifier: hdiutil imageinfo error hdiutil: imageinfo failed - image not recognised
 with image /Users/jonasb/Library/AutoPkg/Cache/local.munki.Brave/downloads/Brave.dmg.
/Users/jonasb/Library/AutoPkg/Cache/local.munki.Brave/downloads/Brave.dmg is not mounted
Failed.
Receipt written to /Users/jonasb/Library/AutoPkg/Cache/local.munki.Brave/receipts/local.munki-receipt-20200922-131717.plist

The following recipes failed:
    local.munki.Brave
        Error in local.munki.Brave: Processor: CodeSignatureVerifier: Error: /Users/jonasb/Library/AutoPkg/Cache/local.munki.Brave/downloads/Brave.dmg is not mounted

Nothing downloaded, packaged or imported.

Getting this error during Run Recipe

/Users/user/Library/AutoPkg/Cache/local.munki.MSTeams/downloads/Teams_osx.dmg failed: ERROR: hdiutil error nx_kernel_mount:1359: : checkpoint search: largest xid 5, best xid 5 @ 1
nx_kernel_mount:1359: : checkpoint search: largest xid 5, best xid 5 @ 1
nx_kernel_mount:1359: : checkpoint search: largest xid 5, best xid 5 @ 1
nx_kernel_mount:1359: : checkpoint search: largest xid 5, best xid 5 @ 1
nx_kernel_mount:1359: : checkpoint search: largest xid 5, best xid 5 @ 1
nx_kernel_mount:1359: : checkpoint search: largest xid 5, best xid 5 @ 1
nx_kernel_mount:1359: : checkpoint search: largest xid 5, best xid 5 @ 1
nx_kernel_mount:1359: : checkpoint search: largest xid 5, best xid 5 @ 1
with image /Users/user/Library/AutoPkg/Cache/local.munki.MSTeams/downloads/Teams_osx.dmg.
Could not mount /Users/user/Library/AutoPkg/Cache/local.munki.MSTeams/downloads/Teams_osx.dmg!

Any ideas?

I had a quick look, but the whole installer is now embedded in a .app, so it's going to be tricky to unpick.

There is something wrong with the MSTeams.download recipe. When i try to autopkg run -v MSTeams.download i get the following error:

The following recipes failed: MSTeams.download Error in com.github.apettinen.download.MSTeams: Processor: URLDownloader: Error: Curl failure: LibreSSL SSL_read: SSL_ERROR_SYSCALL, errno 54 (exit code 56)

The 1Password_CLI set of recipes are currently broken somewhat - in that they return an out of date version of the tool. This is because when the recipes were written they were matching for .zip downloads, 1PW have changed this to be .pkg for newer releases.

I have made a PR here:

#25

As Microsoft has launched the new, non-electron based Teams.app, the current MSTeams recipe requires some changes. Most notably, the MSTeamsURLProvider.py likely becomes obsolete for Mac, as Microsoft provides a static download URL on their Teams webpage, see https://www.microsoft.com/en-us/microsoft-teams/download-app -> Download new teams.

However, Windows seemingly does not have a static download link. Therefore, removing the MSTeamsURLProvider might be a breaking change.

Thus we have two options:

1. Make the the current recipe MS Teams Classic (breaking change too) and create a new one
2. Extend the MSTeamsURLProvider so that it will always offer the static download link for macOS. This is fairly simple change to do, plus additionally the code could be updated a bit (to be more Python3, for example).

Any comments on this, anyone?

As discussed in #36 we should make MSTeams.munki recipe to use configurable variable instead of a fixed key value for versioning.

Is there a way to change default language with the Teams recipe ?