The download recipe of CrashPlan fails, because the code signature changed. Instead of

Developer ID Installer: Code 42 Software

it is now

Developer ID Installer: Code 42 Software (9YV9435DHD)

Hi @jessepeterson. I'm getting the same error that a few others are getting with com.github.keeleysam.recipes.GoogleTalkPlugin/MunkiPkginfoReceiptsEditor - autopkg/keeleysam-recipes#148.

Looks like this processor is now part of the autopkg core processor. Would you mind adjusting the recipe at

See #3 for previous issue. Getting an odd reply to the update query:

curl 'https://update.virtualbox.org/query.php?platform=DARWIN_64BITS_GENERIC&version=4.3.16_95972&count=97&branch=stable'

Returns:

5.0.0_BETA4 http://download.virtualbox.org/virtualbox/4.3.28/VirtualBox-4.3.28-100309-OSX.dmg

I think usually the update string (first spare-separated result from the query) should match the DMG. But in this case it clearly doesn't. Not sure what to do about this. Waiting it out for now. Perhaps need to (finally) implement supplying a user agent to the query.

Hi!

ClamXav is now distributed as a pkg file, not a zip. This means that the ClamXav.download.recipe Unarchiver phase will fail trying to open the zip archive since it, well, isn't one.

Noticed recently that the PDFPenPro recipe wasn't pulling down new versions. It still shows v13.1, even though PDFPenPro is now at v13.2.1. Looking in the download recipe, I see it references the Sparkle feed at

https://updates.smilesoftware.com/com.smileonmymac.PDFpenPro.xml

which indeed still shows v13.1.

It seems SmileSoftware sold PDFPen to Nitro last year based on these posts:

• https://pdfpen.com/blog/nitro-pdfpen-extending-pdf-productivity-to-mac-ipad-and-iphone
• https://www.gonitro.com/blog/nitro-pdfpen-pdf-productivity-for-mac-ipad-iphone

This makes me wonder if newer versions maybe are referencing a different feed URL now.

Anyway, thought I should report this.

Hi there,

I have just run
autopkg run -v VMwareTools.munki MakeCatalogs.munki

Everything downloads fine. At install time though on a fresh vm client, I get the following error:

ERROR: Hash value integrity check for VMwareTools-9.9.2.iso failed.
WARNING: Can't install VMwareTools because the integrity check failed.

I think I read somewhere if the iso/dmg is read/write format, the hash changes every time it is mounted? Have you ran into this error?

I did make an override file, but only to change the repo path attribute - I don't think that should impact anything relevant...

Thanks to digitalcraftsman (on MacAdmins slack) for helping track down the issue of repeating installs in Munki caused by the installcheck_script finding out of date plugins after the UTC install. Workaround is to just rename that key in the pkginfo and instead rely on the installs key for Munki. Either need to make an exception in the script or have UTC fix their crap.

Can't make autopkg override.
Fresh install of OSX 10.12 with munki and autopkg.

autopkg make-override UniversalTypeClient6.munki

Result:

Traceback (most recent call last):
File "/usr/local/bin/autopkg", line 2435, in
sys.exit(main(sys.argv))
File "/usr/local/bin/autopkg", line 2429, in main
exit(subcommands[verb]'function')
File "/usr/local/bin/autopkg", line 1787, in make_override
FoundationPlist.writePlist(override_plist, override_file)
File "/Library/AutoPkg/FoundationPlist/FoundationPlist.py", line 131, in writePlist
plistData = _plistToData(plistObject)
File "/Library/AutoPkg/FoundationPlist/FoundationPlist.py", line 106, in _plistToData
raise NSPropertyListSerializationException(error)
FoundationPlist.FoundationPlist.NSPropertyListSerializationException: Error Domain=NSCocoaErrorDomain Code=3851 "Property list invalid for format: 100 (property lists cannot contain objects of type 'CFNull')" UserInfo={NSDebugDescription=Property list invalid for format: 100 (property lists cannot contain objects of type 'CFNull')}

At some point Smile's PDFpen apps switched to a DMG instead of a zip.

I was able to test a fix and will submit a PR shortly.

Getting the following when running ProjectLibre.munki (overridden):

Processing ProjectLibre.munki.recipe...

The following recipes failed:
ProjectLibre.munki.recipe
Error in local.munki.ProjectLibre: Processor: com.github.jessepeterson.munki.GrandPerspective/SourceForgeURLProvider: Error: Could not retrieve RSS feed http://sourceforge.net/api/file/index/project-id/715892/rss

Nothing downloaded, packaged or imported.

I think this is because you're using urllib2 and sourceforge have changed to redirect the original url somewhere else. You could possibly shell out to curl and use -L/--location but I did not want to be presumptuous!

Ben

I just cloned and used your VirtualBox.munki recipe and was surprised when it pulled in version 4.3.30. when 5.0.2 is marked as the latest on virtualbox.org. It appears Oracle is either faking us into using non-stable releases or haven't updated their update check url mechanism.

Using the URLs you use in the URLProvider I found they differ in version output:
ROOT_URL/LATEST_URL
http://download.virtualbox.org/virtualbox/LATEST.TXT = 5.0.2
UPDATE_CHECK_URL
https://update.virtualbox.org/query.php?platform=DARWIN_64BITS_GENERIC&version=4.3.16_95972&count=97&branch=stable = 4.3.30

I'm afraid I've not had time to do any debugging on this, but the error is below:

Processing AnyConnect.munki...
Use of undefined key in variable substitution: u'PKG'
Error processing path '%PKG%' with glob.
Failed.

Hi!

My organisation has the following AutoPkg recipe repo added to our Munki setup:

https://github.com/autopkg/jessepeterson-recipes.git

Through this, we've installed ImageJ:

$ autopkg run -v ImageJ.munki

The ImageJ recipe has then been enabled as a watched recipe in AutoPkgr, with AutoPkgr set to run once a day.

Each AutoPkgr notification informs us of the following:

The following software is now available for testing:

ImageJ: 1.49

However, no new version of ImageJ is present in our Testing catalog. The current version available in our Standard catalog is ImageJ 1.49p. We've now unchecked the recipe in AutoPkgr and no further notifications have been received. Any advice?

Thanks,

Andrew

The following recipes failed:
PDFpenPro.munki.recipe
Error in com.github.jessepeterson.PDFpenPro.munki: Processor: DmgCreator: Error: creation of /Users/Shared/Jenkins/Library/AutoPkg/Cache/com.github.jessepeterson.PDFpenPro.munki/PDFpenPro.dmg failed: hdiutil: create failed - error -5341

Actual size is 123 MB, so adding a dmg_megabytes -> 128 seems to fix it. That leaves about 5 MB free on the dmg.

@jessepeterson
DockUtil has been updated recently i.e. 3 days ago and it appears this has upset your recipe.

I get from AutoPkgr the following error -

extraction of /Users/munkiadmin/Library/AutoPkg/Cache/local.munki.dockutil/unpack/payload with aa failed

As you can see from the release changes, the author of DockUtil has Migrate to a SwiftPM package to support homebrew requirements which logically would be related to the issue.

Do you have any plans to create a recipe for Universal Type Client 7? If not, have you started using a different Mac Font Management app, or are you sticking to v6?

I cant seem to figure out if this is a problem with Autopkg, the archive, or the recipe.
The recipe returns the error "ditto failed: ditto: Couldn't read PKZip signature"

I manually downloaded the archive from bin.extensis.com/UTC-4-2-3-M.zip
And manually unzipped it using "ditto --noqtn -x -k UTC-4-2-3-M.zip" which I believe is what autopkg uses, and it unzips properly.

I grabbed the archive from my cache folder and attempted to unzip it using the same command and it fails with "ditto: Couldn't read PKZip signature" again.

Before I look to duplicate this, I don't suppose you want to separate the parts: download, pkg, munki, into individual recipes with child/parent relationship, for use beyond Munki?

Error in local.munki.Seashore: Processor: com.github.jessepeterson.munki.GrandPerspective/SourceForgeURLProvider: Error: No matched files

Hey Jesse!

I'm not sure why, but the VMware Tools recipe isn't downloading the latest version. I'm probably doing something wrong, but I tried setting DEFAULT_VERSION_SERIES to 10.0.0, but had no luck. Now that I'm writing this, I've realized it's probably not something I can specify in the recipe override.

The latest version of the tools can be found here:

https://softwareupdate.vmware.com/cds/vmw-desktop/fusion/10.0.1/6754183/packages/com.vmware.fusion.tools.darwin.zip.tar

I ran my override like this, and it imported the new pkg OK:

autopkg run -v local.munki.VMwareTools -p /path/to/com.vmware.fusion.tools.darwin.zip.tar

Mike

Reported to me in direct email that VirtualBox recipe is broken. I haven't had time to take a look but recording here for I have time.

Hi there

We are trying to import UTC6 into our repo using your recipe in AutoPkgr. The download is working but the recipe "com.github.jessepeterson.munki.UniversalTypeClient6" does not seem to run. If I try and run it manually I get the attached screenshot.

We have UTC5 successfully working using your recipe so are puzzled.

CUDADriver is not MunkiImporting for me in autopkg. MunkiImporter Processor claims it's already in the repo (as an older version). I believe this is due to the fact that because there is no installs key MunkiImporter falls through to comparing the versions of the receipts key items and for CUDADriver apparently they don't change (they seem to all be "1.0" or "1" back through the oldest versions I have).

Before the CUDADriver recipe used to unpack the package and generate a Munki installs key. But that was changed in #1 (and again adjusted in 96167dd).

We can go back to generating an installs key but this means unpacking the DMG and PKG again (I think part of the reason why #1 was proposed in the first place). This would allow MunkiImporter to compare something valid as the receipt versions in the .pkg don't seem to be maintained at all.

Thoughts? Paging @timsutton and @mkuron re: #1.

This seems to be the relevant portion from autopkg run -vv com.github.jessepeterson.munki.VirtualBoxExtPack. I believe this started after the update to macOS 12.3.

MunkiImporter: No value supplied for MUNKI_REPO_PLUGIN, setting default value of: FileRepo
MunkiImporter: No value supplied for MUNKILIB_DIR, setting default value of: /usr/local/munki
MunkiImporter: No value supplied for force_munki_repo_lib, setting default value of: False
MunkiImporter: Using repo lib: AutoPkgLib
MunkiImporter:         plugin: FileRepo
MunkiImporter:           repo: /Volumes/Munki/munki_repo
'str' object has no attribute 'get'
Failed.
Receipt written to /Volumes/Munki/AutoPkg/Cache/com.github.jessepeterson.munki.VirtualBoxExtPack/receipts/com.github.jessepeterson.munki-receipt-20220320-075437.plist

The following recipes failed:

    com.github.jessepeterson.munki.VirtualBoxExtPack
        Error in com.github.jessepeterson.munki.VirtualBoxExtPack: Processor: MunkiImporter: Error: 'str' object has no attribute 'get'

The following new items were downloaded:
    Download Path                                                                                                                             
    -------------                                                                                                                             
    /Volumes/Munki/AutoPkg/Cache/com.github.jessepeterson.munki.VirtualBoxExtPack/downloads/Oracle_VM_VirtualBox_Extension_Pack.vbox-extpack  

Did you planned a new recipe for UniversalTypeClient 7 ?

Microsoft has deprecated its remote desktop client in respect to version 10:

Deprecation of the Remote Desktop 8.0 client for macOS

It would be great if you could update your autopkg recipies. Thanks!

Hi Jesse,
Just thought I would drop a line to advise that the CUDADriver.munki recipe is failing.
The error is a 404 " Page not found" me thinks their is not much you can do to resolve this.

I did some digging in the XML document that recipe looks to and notice that Nvidia offer other CUDA versions for the 10.7 and 10.6 does your current recipe allow for version overrides to set it to download specific version's for different OS versions?
My apologies if it does still learning the ropes with autopkg.

$ codesign --verify --verbose=1 /Applications/Universal\ Type\ Client.app/
/Applications/Universal Type Client.app/: nested code is modified or invalid
file modified: /Applications/Universal Type Client.app/Contents/Frameworks/cpp-core.framework
file modified: /Applications/Universal Type Client.app/Contents/Frameworks/Sparkle.framework
file modified: /Applications/Universal Type Client.app/Contents/Frameworks/HDCrashReporter.framework
file modified: /Applications/Universal Type Client.app/Contents/Frameworks/ExtensisFontManagement.framework

I've opened up a support ticket with them. In the mean time, the recipe breaks if you don't pass -k DISABLE_CODE_SIGNATURE_VERIFICATION=1

CrashPlan seems to have hid their download behind a login. I can't find a published new URL to download, but my CrashPlan for Small Business account shows this url: https://download.crashplan.com/installs/agent/cloud/11.3.1/3/install/CrashPlanSmb_11.3.1_3_Mac.dmg

Please change the DEFAULT_VERSION_SERIES value stored in VMwareToolsURLProvider.py from 7 to 8, now that VMware Fusion 8.0.0 has been released:

https://github.com/autopkg/jessepeterson-recipes/blob/master/VMware/VMwareToolsURLProvider.py#L13

You took out the PackageRequired processor, but the recipe still uses it (https://github.com/autopkg/jessepeterson-recipes/blob/master/Cisco/AnyConnect.munki.recipe#L75-L76)

autopkg run AnyConnect.munki.recipe -k PKG=/Users/grahamgilbert/Downloads/anyconnect-macosx-4.1.04011-web-deploy-k9.dmg -k MUNKI_REPO_SUBDIR=apps/Cisco/AnyConnect
Processing AnyConnect.munki.recipe...
Failed.

The following recipes failed:
    AnyConnect.munki.recipe
        Unknown processor 'PackageRequired'.

Nothing downloaded, packaged or imported.

With the 5.1.20 run, VirtualBoxExtPack.munki.recipe postinstall script seems to hang upon installation.

$VBM extpack install --replace \
	/tmp/Oracle_VM_VirtualBox_Extension_Pack.vbox-extpack

When the above is run manually, it prints a Terms and Conditions agreement prompt (which explains the hang upon installation). Any suggestions for bypassing?

Running the ImageJ.munki recipe is producing the following error:

Error in com.github.jessepeterson.munki.ImageJ: Processor: Copier: Error: Can't copy /Users/*username*/Library/AutoPkg/Cache/com.github.jessepeterson.munki.ImageJ/downloads/ij.jar to /Users/*username*/Library/AutoPkg/Cache/com.github.jessepeterson.munki.ImageJ/pkgroot/Applications/ImageJ/ImageJ64.app/Contents/Resources/Java/ij.jar: [Errno 2] No such file or directory: u'/Users/*username*/Library/AutoPkg/Cache/com.github.jessepeterson.munki.ImageJ/pkgroot/Applications/ImageJ/ImageJ64.app/Contents/Resources/Java/ij.jar'

Unarchiver seems to be working ok:

Unarchiver {'Input': {'archive_path': u'/Users/*username*/Library/AutoPkg/Cache/com.github.jessepeterson.munki.ImageJ/downloads/ImageJ.zip', 'destination_path': u'/Users/*username*/Library/AutoPkg/Cache/com.github.jessepeterson.munki.ImageJ/pkgroot/Applications', 'purge_destination': True}} Unarchiver: Guessed archive format 'zip' from filename ImageJ.zip Unarchiver: Unarchived /Users/*username*/Library/AutoPkg/Cache/com.github.jessepeterson.munki.ImageJ/downloads/ImageJ.zip to /Users/*username*/Library/AutoPkg/Cache/com.github.jessepeterson.munki.ImageJ/pkgroot/Applications

Version of ImageJ downloaded and unarchived by recipe doesn't include ImageJ64.app.

$ ls -l /Users/username/Library/AutoPkg/Cache/com.github.jessepeterson.munki.ImageJ/pkgroot/Applications/ImageJ

*ImageJ.app
*ImageJ32.app
*luts
*macros
*plugins

Issue with app version on NIH webserver, as implemented in #8 ?

The dockutil command installed via the package miss the executable flag.

chmod +x /usr/local/bin/dockutil is needed as postinstall script in the package.

Hi @jessepeterson! I noticed that the VirtualBoxExtPack.munki recipe has this in the installcheck_script:

VBM=/usr/local/bin/VBoxManage

if [ ! -f $VBM ]
then
	echo 'VBoxManage not present'
	exit 0
fi

Which indicates that the extension pack should be installed if the VBoxManage binary is not present. However, the same recipe has a postinstall script that includes this:

if [ ! -f $VBM ]
then
	echo 'VBoxManage not present'
	exit 1
fi

This will exit with an error if the same binary is not present.

Because the extension pack payload does not install the VBoxManage binary, wouldn't this result in looping? I think the answer is to change the installcheck_script to exit 1 instead of exit 0 but before I open a PR I wanted to make sure I'm not missing something.

I got this error. What can I do ?
autopkg make-override UniversalTypeClient6.munki
Traceback (most recent call last):
File "/usr/local/bin/autopkg", line 2453, in
sys.exit(main(sys.argv))
File "/usr/local/bin/autopkg", line 2447, in main
exit(subcommands[verb]'function')
File "/usr/local/bin/autopkg", line 1782, in make_override
recipe, search_dirs=search_dirs)
File "/usr/local/bin/autopkg", line 1389, in get_trust_info
'path': os_path_compressuser(processor_path),
File "/usr/local/bin/autopkg", line 1349, in os_path_compressuser
elif pathname.startswith(home_dir):
AttributeError: 'NoneType' object has no attribute 'startswith'

I think you figured out on Slack that it was because there were changes made to the binary. Perhaps instead of having the download link be https://raw.github.com/kcrawford/dockutil/master/scripts/dockutil just go with the latest link on the releases page?
https://github.com/kcrawford/dockutil/releases

It would be useful to us, and I suspect it would take you less time than me to figure out how to parse the files into the PkgCreator processor.

There are new versions of UTC out and the receipt for UTC6 errors with
"No matching filename found".
Looks like there's no URL to download the UTC6 inside the munki receipt. (I'm not a coder, but it looks like it's missing.)

The UTC5 receipe errors with:
"Code signature verification failed. Note that all verifications can be disabled by setting the variable DISABLE_CODE_SIGNATURE_VERIFICATION to a non-empty value."

There were some changes in the Extensis a3 server, please look at your personal messages in Slack.

When running this comes up. Seems to have broken after they updated there website.
The following errors occurred:

• No match found on URL: https://www.extensis.com/support/product-support/universal-type-server-6/

New URL:
https://www.extensis.com/support/universal-type-server-6/

Hey.

PR submitted for URL changes to UTC 4 and 5 recipes. I'd like to make a suggestion with the recipes for 3 and 4 however.

1. 3 won't work because it's removed from Extensis' site, I'd suggest removing it
2. Could you break out the recipe for 4 into a download recipe, like you've previously done for 5 and 6?

Lemme know if I can help!

When you hit the download page, it sends you a 302 redirect which also has a 302 redirect, but that site has a full listing of the v3 pkgs.

I might have time to PR this early next week, but wanted to at least get it out there for right now.

curl https://www.clamxav.com/downloads/ClamXav_Current.zip
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href="https://cdn.clamxav.com/ClamXAVdownloads/ClamXAV_3.0.4_7302_Installer.pkg">here</a>.</p>
<hr>
<address>Apache/2.4.7 (Ubuntu) Server at www.clamxav.com Port 443</address>
</body></html>

curl https://cdn.clamxav.com/ClamXAVdownloads
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="http://database.clamxav.com/ClamXAVdownloads/">here</a>.</p>
<hr>
<address>Apache/2.4.18 (Ubuntu) Server at database.clamxav.com Port 80</address>
</body></html>

When running this recipe in AutoPKGr, I get this error:

Error in com.github.jessepeterson.munki.AnyConnect: Processor: Copier: Error: Error processing path '%PKG%' with glob.