Chocolatey-coreteampackages: (libreoffice*) Packages are outdated

[ptandler]

Both libreoffice-fresh and libreoffice-still are some versions behind:

https://www.libreoffice.org/download/download/
fresh: 6.3.1 (here: 6.2.5)
still: 6.2.7 (here: 6.0.7)

I guess there is a reason for this ...?
Do you have a timeline for updating the packages in chocolatery?

[majkinetor]

This is automatic package so there is no timeline. If its not up to date its probable that there are upstream changes or inconsistencies that will need to get integrated into update.ps1 script.

[ptandler]

Hm, alright. I haven't worked with creating or maintaining packages so far.
Is there a way I can help figuring out why the package is not updated?

[majkinetor]

OK, so I forgot about this, but update is disabled for this package in this commit:

https://github.com/chocolatey-community/chocolatey-coreteampackages/commit/0761a64f9b664c07f1ae5d9afe28c087a9d9721b

@wget mentioned its about upstream request...

Now, I don't even know what that shit means, so unless @wget provides explanation here I will re-enable it.

Anyway, some observations:

• When anybody disables the package he should provide more detailed log comment about the reasons
• We shouldn't accept those kind of requests. Its not normal to me that upstream continues to publish new version of tools in its download sections while at the same time preventing random other repositories for doing automated package update. So we should deny all such requests IMO (/cc @AdmiringWorm), after all, we just do what users can already do on official site, we don't imagine new versions here. There is no reason EVER to disable updates, there might be reasons to unlist the existing package if there was fabric recall.

[AdmiringWorm]

@majkinetor it was disabled as requested by upstream (the developers of libreoffice) while @wget is working together with the developers by providing a better package for the software.

This have been mentioned several times already on the disqus forums for both libreoffice-fresh and libreoffice-still

There is no reason EVER to disable updates

That is your opinion, but sometimes there actually are reasons to disable the updater, this is one of the times.

[majkinetor]

This is the comment by @wget:

We know this package is broken. We have been working with upstream to fix the automation completely without annoying them.

We have received hundreds of messages wrt. this package. Since you cannot read previous messages properly, each time I receive an email to my personal address asking me to fix this package, the fix will get delayed from one day.

This is still moot point

You failed to see alternative options. If the user can install it by clickily click, then it can be automated. The failure of upstream silent installer options or whatever is just current method of silent installation the package uses. Somebody might get tired of waiting and provide another, sucha as AHK script.

While that is the option, it may or may not deserve the implmentation depending on multiple factors.

[TheCakeIsNaOH]

We have received hundreds of messages wrt. this package. Since you cannot read previous messages properly, each time I receive an email to my personal address asking me to fix this package, the fix will get delayed from one day.

The way I read the above Discus message by @wget posted on the LibreOffice package page and quoted above by @majkinetor is that for each of the hundreds of messages he has received, he will delay the release of the fixed package by one day. So take hundreds of messages and the one day delay for each message, that would mean that fixed(and updated) LibreOffice packages are not released by @wget till sometime in the middle of 2020 at the earliest.

@wget If I am reading your comment incorrectly, could you please clarify your intentions?

@majkinetor

The failure of upstream silent installer options or whatever is just current method of silent installation the package uses. Somebody might get tired of waiting and provide another, sucha as AHK script.

I believe the problem lies not with the actual package install, but with downloading the package. The download link changes when a new version comes out. Unfortunately, the approximately 280mb LibreOffice installer is too big for chocolatey.org's 200mb package limit, so the installer needs to be downloaded during install.
I am not sure why the download link changing and therefore breaking old versions is a reason to halt updates, rather than continuing to allow it to update and then also concurrently working on a fix to be added when it is ready. There might be some reason, but I have not seen it or understood it.

[wget]

@TheCakeIsNaOH My intention is not to delay this package obviously but rather that users stop sending me emails to my personal email address each day.

I'm taking care of this today until finish even if this implies working pretty late. And please don't reenable auto update.

[wget]

• Auto update now working based on the libreoffice update check service from TDF.
• This avoids to parse the website which was a fragile solution (we are still parsing mirrorbrain output to determine CDN though).
• When the install packages are moved away from the CDN, the links are now still working.
• Update process working on a standard AppVeyor instance.
• No more gap when fresh becomes still

Currently working on Posh 2.0 compatibility in order to make the helper functions shared between the update.ps1 and the choclateyInstall.ps1 scriptlets.

[wget]

Update: Posh 2.0 nearly finished.

During my tests I realized the SHA-256 digest was missing for some releases on the TDF servers, leading to errors when building packages, I reported the issues and the TDF sysadmins are gonna fix it during the night or tomorrow end of day :)

Their fix will allow me to parse and compute the digest is a much more solid manner and be independent of the mirror load balancer they use (currently still MirrorBrain, but MirrorBits in the very near future).

Keep you posted.

[wget]

Good news again. The SHA-256 feature has been corrected upstream at TDF. Thanks dear sysadmins :)

I have however issues enabling my Posh 2.0 session on Windows 10 1903. While the later seems to work fine, all object instanciations are returning the same error, example:

$request = [System.Net.WebRequest]::Create("$url.sha256")
Create : Exception calling "Create" with "1" argument(s): "Configuration system failed to initialize"
At line:1 char:43
+ $request = [System.Net.WebRequest]::Create <<<< ("$url.sha256")
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : DotNetMethodException

It seems like as if the AppDomain that has been created to launch the Posh 2.0 session wasn't loading the .NET assemblies properly. Any idea how to fix this? It seems like this problem has arisen since MS deprecated Posh 2.0 on Windows 10.

[ghost]

I will risk saying something dumb, because I am thankful for the package and want to show it.
I beleive it wants to initialize it's System.Configuration context , finds a corresponding .config file and fails to read it at the 43th charachter in the first line. To me it looks like some newer System.Configuration wants its values in another syntax.

Could be You just need to open and close an appSettings section , see : https://stackoverflow.com/questions/6436157/configuration-system-failed-to-initialize#comment20987936_6436157

[wget]

Ok I found the culprit. Since Microsoft removed official support for Posh 2.0, I was on my own. Since I'm initially a C/C++ guy, I had the idea to surround my call statement with a catch statement in order to avoid the exception from escalating to the posh process and thus being able to display the exact message sent by the exception.

PS C:\Windows\system32> $url = "https://downloadarchive.documentfoundation.org/libreoffice/old/5.4.7.2/win/x86_64/LibreOffice_5.4.7.2_Win_x64.msi"
PS C:\Windows\system32> try { $request = [System.Net.WebRequest]::Create("$url.sha256") } catch { write-host $_.Exception.ToString() }
System.Management.Automation.MethodInvocationException: Exception calling "Create" with "1" argument(s): "Configuration system failed to initialize" ---> System.Configuration.ConfigurationErrorsException: Configuration system failed to initialize ---> System.Configuration.ConfigurationErrorsException: Unrecognized configuration section uri. (C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe.Config line 2)
   at System.Configuration.ConfigurationSchemaErrors.ThrowIfErrors(Boolean ignoreLocal)
   at System.Configuration.BaseConfigurationRecord.ThrowIfInitErrors()
   at System.Configuration.ClientConfigurationSystem.EnsureInit(String configKey)
   --- End of inner exception stack trace ---
   at System.Configuration.ClientConfigurationSystem.EnsureInit(String configKey)
   at System.Configuration.ClientConfigurationSystem.PrepareClientConfigSystem(String sectionName)
   at System.Configuration.ClientConfigurationSystem.System.Configuration.Internal.IInternalConfigSystem.GetSection(String sectionName)
   at System.Configuration.ConfigurationManager.GetSection(String sectionName)
   at System.Configuration.PrivilegedConfigurationManager.GetSection(String sectionName)
   at System.Diagnostics.DiagnosticsConfiguration.Initialize()
   at System.Diagnostics.DiagnosticsConfiguration.get_Sources()
   at System.Diagnostics.TraceSource.Initialize()
   at System.Net.Logging.InitializeLogging()
   at System.Net.Logging.get_On()
   at System.Net.WebRequest.Create(Uri requestUri, Boolean useUriBase)
   at Create(Object , Object[] )
   at System.Management.Automation.DotNetAdapter.AuxiliaryMethodInvoke(Object target, Object[] arguments, MethodInformation methodInformation, Object[] originalArguments)
   --- End of inner exception stack trace ---
   at System.Management.Automation.DotNetAdapter.AuxiliaryMethodInvoke(Object target, Object[] arguments, MethodInformation methodInformation, Object[] originalArguments)
   at System.Management.Automation.DotNetAdapter.MethodInvokeDotNet(String methodName, Object target, MethodInformation[] methodInformation, Object[] arguments)
   at System.Management.Automation.Adapter.BaseMethodInvoke(PSMethod method, Object[] arguments)
   at System.Management.Automation.ParserOps.CallMethod(Token token, Object target, String methodName, Object[] paramArray, Boolean callStatic, Object valueToSet)
   at System.Management.Automation.MethodCallNode.InvokeMethod(Object target, Object[] arguments, Object value)
   at System.Management.Automation.MethodCallNode.Execute(Array input, Pipe outputPipe, ExecutionContext context)
   at System.Management.Automation.AssignmentStatementNode.Execute(Array input, Pipe outputPipe, ExecutionContext context)
   at System.Management.Automation.StatementListNode.ExecuteStatement(ParseTreeNode statement, Array input, Pipe outputPipe, ArrayList& resultList, ExecutionContext context)

The issue came from the file C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe.config. Since this file is read by Posh 5.1, the latter was containing statements not understood by Posh 2.0.

I simply removed that file after having taken ownership of it (it belongs to the TrustedInstaller group by default) and it did the trick. :)

PS C:\Users\user> cd C:\Windows\System32\WindowsPowerShell\v1.0
PS C:\Windows\System32\WindowsPowerShell\v1.0> takeown.exe /f .\powershell.exe.config

Continuing to test the script in Posh 2.0 mode before doing a PR. :) Will let you know of the progress being made :)

[wget]

Posh 2.0 seems ok. Final checks will be performed as soon I'm home and we are nearly ready to go. 💪 Hope to publish my PR for review later today :)
https://github.com/wget/chocolatey-coreteampackages/tree/fix-libreoffice-website-link

[wget]

After discussion led today on gitter, I'm currently implementing a bug fix and I would like to remove a warning generated by AU when packages are being updated. Won't likely be implemented today, but tomorrow :)

[wget]

1. The warning from AU being displayed on stdout is just warning the version has been reset to 0.0 and doesn't cause any harm. The exception being trigerred in AU is because I do have letters in AU streams used to distinguish the branch we are talking about. Since letters are not valid semver chars, AUVersion complains and 0.0 is printed as warning. So this is basically unfixable, except if we modify AU (which I won't do).

2. The bug I have been talking about in my previous message was a regex replacement issue.

   $linesToPatch["(?i)(^\ssilentArgs\s=\s)('.')"] = "$1'/qn /passive /norestart /l*v"{0}\install.log"' -f"$Env:TEMP\chocolatey\$Env:ChocolateyPackageName`$Env:ChocolateyPackageVersion`""

   each time a package is build, that line is being appended rather than replacing the existing. The regex is at fault here. I'm currently debugging.

3. The last test performed by AppVeyor has failed but shouldn't. Sometimes when the package is being downloaded from the archive servers from TDF, the link connection is so slow that it takes more time than 600s (the limit of the AppVeyor container run time). Asked the other core team packagers to see if this can cause an issue for the future.

[majkinetor]

Regarding letters in version, there is nothing to fix in AU. Produce correct version in au_GetLatest. by converting letters to numbers via some method (it is also nice to show real version somewhere in the nuspec or README.md)

[wget]

Ok. The versions are taken care in the package object anyway, so I can recover the exact version (and build) via another method if needed. So everything is fine. Gonna merge since everything is working locally (except the tests are failing on the appveyor instance since there is a 600s timeout).

[wget]

Okay. Having the logs form the core team package repo will be interesting to have. Because while working locally, TDF servers are refusing the connection from the coreteampackage VM :/

[wget]

The error I get from the AppVeyor instance is Unable to connect to the remote server which means it seems the issue comes from upstream. Maybe sysadmins blocked connection attempts from Google Cloud (last time I checked AppVeyor used that cloud provider).

[wget]

I have sent a message to the sysadmin team at TDF in order for them to confirm and investigate the issue. I keep you posted.

[wget]

Received a response from the TDF sysadmins. They are not applying blacklisting nor rate limit.
AppVeyor seems now to be hosted at Liquid Web, L.L.C. The connection issue may be due to a temporary network disconnection between both datacenters (LiquidWeb and TDF'ones).

Any way, as we can see now, LibreOffice versions have been pushed. Those not visible on the chocolatey repos are due to the fact they haven't passed automated testing yet.

Some LibreOffice versions have been rejected in the past and will be repushed manually. Keep you posted.

In the meantime 6.3.2 is available from the fresh branch :)

[majkinetor]

What about still version ?

https://chocolatey.org/packages/libreoffice-still

6.2.7 vs current 6.2.8

[AdmiringWorm]

@majkinetor wget commented about this on the libreoffice-still package couple of days ago.

http://disq.us/p/252gpfm
Hello everyone. This LibreOffice-Still package has been updated. As it is now relying on the update service provided by The Document Foundation to determine whether there are new updates, there will be about about a 2 weeks delay each time a new version of LibreOffice is released.
The tacit distribution policy of TDF is as follow: distribute LibreOffice immediately via its website, but after some (1-2 weeks) delay, the update service is notified of the new version.
This behavior allows to make sure (1) all mirrors have been synchronized, (2) reduce burden on the infra (we don't want all of our 225 millions users to be notified of the new update at the same time for logic reasons) and (3) play a safeguard role: if, despite our strict test policy, a last minute bug or a hard regression is found, only people who have downloaded LibreOffice manually will be impacted.

and

http://disq.us/p/2540h5x
For the exact same reason described in the exact same message I wrote above. It hasn't been pushed to the TDF Update Service by TDF sysadmins yet.
https://cgit.freedesktop.or...
And as this CHoco package is now using the TDF Update Service to detect updates, so... :)

[majkinetor]

OK, then we can close this.