Latest LibreOffice.download.recipe failing due to version mismatch b/w tested release notes page and download version available

[fseesink]

Updated my Munki repos including the LibreOffice recipes after noticing it wasn't pulling latest.

But new version is failing. Digging into recipe, I see it does a regex on https://www.libreoffice.org/download/release-notes/

That page shows the latest version as 24.2.

So the final URL provided is

https://download.documentfoundation.org/libreoffice/stable/24.2/mac/x86_64/LibreOffice_24.2_MacOS_x86-64.dmg

However, if you visit the actual site, you'll see the latest is actually 24.2.1, and at least on that site, the URL is then

https://www.libreoffice.org/donate/dl/mac-x86_64/24.2.1/en-US/LibreOffice_24.2.1_MacOS_x86-64.dmg

And if I manually adjust the earlier URL to

https://download.documentfoundation.org/libreoffice/stable/24.2.1/mac/x86_64/LibreOffice_24.2.1_MacOS_x86-64.dmg

that does, in fact, work.

So there appears to be an issue where the release notes page isn't being maintained/matching the actual version on the download page of the site, causing the error.

Here is the output from running autopkg run -vv LibreOffice.munki.recipe in case it helps:

autopkg run -vv LibreOffice.munki.recipe                                                                                   ─╯
Processing LibreOffice.munki.recipe...
CreateLibreOfficeAuxArchName
{'Input': {'arch_name': 'x86_64'}}
{'Output': {'aux_arch_name': 'x86-64'}}
URLTextSearcher
{'Input': {'re_pattern': 'LibreOffice (?P<version>\\d+\\.\\d+(\\.\\d+)?) '
                         '\\(\\d{4}-\\d{2}-\\d{2}\\) - Latest Release',
           'url': 'https://www.libreoffice.org/download/release-notes/'}}
URLTextSearcher: No value supplied for result_output_var_name, setting default value of: match
URLTextSearcher: Found matching text (version): 24.2
URLTextSearcher: Found matching text (match): 24.2
{'Output': {'match': '24.2', 'version': '24.2'}}
URLDownloader
{'Input': {'filename': 'LibreOffice-x86_64.dmg',
           'url': 'https://download.documentfoundation.org/libreoffice/stable/24.2/mac/x86_64/LibreOffice_24.2_MacOS_x86-64.dmg'}}
URLDownloader: No value supplied for prefetch_filename, setting default value of: False
URLDownloader: No value supplied for CHECK_FILESIZE_ONLY, setting default value of: False
URLDownloader: ERROR: (22) The requested URL returned error: 404

curl: (22) The requested URL returned error: 404

Failed.
Receipt written to /Users/frank/Library/AutoPkg/Cache/local.munki.LibreOffice/receipts/LibreOffice.munki-receipt-20240302-141649.plist

The following recipes failed:
    LibreOffice.munki.recipe
        Error in local.munki.LibreOffice: Processor: URLDownloader: Error: curl: (22) The requested URL returned error: 404

Nothing downloaded, packaged or imported.

[gregneagle]

There’s not a lot Hannes can do about this. The developer has made it nearly impossible to find/discover the download URL. So the recipe “calculates” a download URL based on the version listed in the current release notes. If those are not accurate…

[gregneagle]

An alternate approach would be to look at the directory listings here:

http://downloadarchive.documentfoundation.org/libreoffice/old/latest/mac/x86_64/ and here: http://downloadarchive.documentfoundation.org/libreoffice/old/latest/mac/aarch64/

But sadly, those are seemingly available only via http and not https.

[gregneagle]

I take that back. There's some weird redirects going on from the download page, but

https://downloadarchive.documentfoundation.org/libreoffice/old/latest/mac/x86_64/ and https://downloadarchive.documentfoundation.org/libreoffice/old/latest/mac/aarch64/

do seem to work. One could then do a regex search looking for .dmg files...

[gregneagle]

This proposed alternate approach really only helps with "latest". I don't see an easy way to get the previous/stable/whatever version from the download archive.

[fseesink]

Aaaand just this morning it looks like they must've updated the release notes page, as 24.2.1 came down. Yeah, always a joy with this.

I realize this is always the challenge. Recipes are to finding the right info on webpages/etc. the way "screen scraping" is done in network automation. You are at the mercy of the site/NOS devs in that you try to RegEx/filter your way around their output. But it could change at any time.

I have often thought (more like wished) how nice it would be if there were some well established, clearly defined way that software sites would all post their release information. Kind of like how websites have robots.txt files, only with some kind of standardized/API like way of providing version info. Possibly JSON or some other structured format that was easily consumable by software.

But it is what it is I guess. I do appreciate you looking into this, though. I'm noticing this happening with some other recipes, too, of late, where the version info either isn't up-to-date, or in some cases (e.g., Python3) where they put out updates to two different trains, but the order they list them on the page isn't what is expected.

[pandemicus]

Yeah, I had to contact the devs to get them to update the page.

They hinted on a "new hompage" soon where they could list this in a better way. They should be aware now about our community and AutoPkg and roughly how AutoPkg works. I hope this is helpful!

Similar issue: https://github.com/autopkg/hjuutilainen-recipes/issues/275

[guille-okt]

The last versions from 7.6 and 24.2 can be seen here https://www.libreoffice.org/download/download-libreoffice/, I will try to create a processor to get the two last version info there