Created attachment 84246 [details] screenshot of standard sparkle options Current behavior: existing update check is confusing and does not allow direct download let alone easy install. Expected behavior: LibreOffice should use Sparkle on OS X with three appcasts files. The channels could be analogue to Firefox Stable / beta / nightly. If you want to see sparkle in action it is integrated into tons of software on OS X and free to use: https://github.com/andymatuschak/Sparkle E.g. in Transmission. Allow users how often to check for updates and which release channel they want to be on. Operating System: Mac OS X Version: 3.3 all versions
Looks a valid enhancement request to me.
OH, I want this so badly!
Since users running outdated versions of LO and this would be a great solution to the problem (at least for OS X) I raise importance to "high".
There is additional discussion on the Sparkle project. https://github.com/sparkle-project/Sparkle/issues/380 Some Sparkle developers and hackers want to help make this happen. Are there some experts here that can help explain build details for Mac?
kendy made a very smart suggestion: why not look into using the Mozilla MPL licensed Software Update mechanism? https://wiki.mozilla.org/Software_Update Major benefit would be, that it is (hopefully) cross-platform and thus would improve the update UX on all OS.
Also, note that there is an implementation of Sparkle for Windows: http://winsparkle.org/
(In reply to comment #5) > kendy made a very smart suggestion: why not look into using the Mozilla MPL > licensed Software Update mechanism? > > https://wiki.mozilla.org/Software_Update > > Major benefit would be, that it is (hopefully) cross-platform and thus would > improve the update UX on all OS. Sparkle on OSX just WORKS. Mozillas Software Update _still_ has problems on OSX to update Firefox as a non-admin user.
*** Bug 83406 has been marked as a duplicate of this bug. ***
*** Bug 86985 has been marked as a duplicate of this bug. ***
Hi All, I would like to start working on this bug. I went through the associated bugs and comments. According to them (stating the obvious), we need to re-use mozilla's update system's code and provide auto-update. Kindly point me to the direction where I can start. Thanks a lot!
brij: If the answer is that the Mozilla's approach is the best, first we need to collect the code pointers to their implementation; so can you please find out the code that: 1) asks for updates in Firefox, and downloads the new stuff? 2) the code in Firefox that applies the update? 3) the code that builds a suitable update pack, and 4) the code for the server part that distributes the info that there is a new update When you have this, we need to plug that into the LibreOffice infrastructure accordingly. For the 1) and 2), that would be have to be plugged into extensions/source/update/* , for 3), that would be something to plug into our release process, and 4) would be for the infra team. Can you please add the code pointers here? If you struggle with that, please let me know, I'll help searching :-) Thanks in advance!
I am interested in working on this bug in advance of GSoC. I've found the code for the updater via Mozilla IRC, but I did not have time to look it through. https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/updater
Nathan: You might want to start by looking into nsIUpdateService.idl . This is the UI file and gives you an idea of the flow.
I haven't looked into the OS X part yet but according to Mozilla wiki, on Windows it pretty much boils down to: 1. Download update in the background 2. Start a maintenance service which avoids UAC prompt (I think this works because you install the service as privileged, something along those lines) 3. Close Firefox, patch it with service, bring it back, close service (through some hackery) As I see it, all that really needs to be done is to change downloads to be done in the background and move the patching code into a service. I'm not sure any special framework or major changes are needed, just a separation of the patching process. Any thoughts on that?
One thing that needs double checking is whether the process correctly picks up the installed LO locale(s) and maintains that. It has a nasty habit of switching back to English. Also the current procedure is that you download the default installer with ALL locales. This is not efficient, esp on bad bandwidth, so (though it could be a developmental feature for 1.1) is to only pull the patch for the locales required.
enhancement proposal checking new LibreOffice version and installed Extensions seem to be coupled Dealing with libreoffice update, these 2 actions should be separated and an other enhancement would be specifying the checking/update policy per extension but as first step let only separate libreoffice update notification and Extensions as a whole
enhancement proposal (well for version 1.2 or so ^^) for windows: checking for offline help and update to newest version. ;-)
Please let's not pollute this bug with enhancement requests; if you want to file any, create separate bugs for that, and make this one depend on them :-) Thank you!
This is not an enhancement. It is a prerequisite. How do you think the millions of non-English LO will feel if we implement an automatic update which resets them to English by accident or design? Making sure the new update does NOT mess up the locale is a showstopper. Thank you.
Pls ignore my last comment, I misread. :$
I have sponsored this issue https://freedomsponsors.org/issue/716/provide-better-update-mechanism-was-use-sparkle-update-with-stable-beta-nightly-channels-to-keep-users-on-the-latest-releases-on-os-x#
I have started looking for code pointers relevant to this bug. Here is what I have currently found: The files that we are interested in are primarily nsUpdateService.js, nsIUpdateService.idl, and possibly nsUpdateServiceStub.idl. How updates are created: - select best update from a list of updates: IDL: nsIUpdate selectUpdate([array, size_is(updateCount)] in nsIUpdate updates, in unsigned long updateCount) JS: /** * Determine the update from the specified updates that should be offered. * If both valid major and minor updates are available the minor update will * be offered. * @param updates * An array of available nsIUpdate items * @return The nsIUpdate to offer. */ selectUpdate: function AUS_selectUpdate(updates) {...} - download the update: IDL: AString downloadUpdate(in nsIUpdate update, in boolean background) JS: /** * Download and stage the given update. * @param update * A nsIUpdate object to download a patch for. Cannot be null. */ downloadUpdate: function Downloader_downloadUpdate(update) {...} - lines 4232-4252 in nsUpdateService.js are significant - apply the update: IDL: void applyOsUpdate(in nsIUpdate update) For more info on the update service check nsIUpdateService.idl (lines 350-456). The functions appear to rely on an nsIUpdate object. It's interface is in nsIUpdateService.idl as 'nsIUpdate'. Infra needed: - general information about updates: https://wiki.mozilla.org/Software_Update - information about Windows Silent Update Service: https://wiki.mozilla.org/Windows_Service_Silent_Update - XML format for determining updates: https://wiki.mozilla.org/Software_Update:updates.xml_Format We will need to look further into this later. Misc: - code performing check: In the Checker prototype, getUpdateURL(force) gets the URL to the XML update details file on a server, checkForUpdates(listener, force) checks for updates. - code triggering update install is detailed in the "How updates are created" section
Current information regarding this issue can be found here: https://wiki.documentfoundation.org/Development/Online_Update
Nathan Yee committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b59955bf2124b558147033782bf067a3723e4730 online update tdf#68274: fix --enable-online-update=mar on Windows It will be available in 5.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 39028 has been marked as a duplicate of this bug. ***
*** Bug 99951 has been marked as a duplicate of this bug. ***
clearing the Whiteboard target entry, that was Nathan Yee's preliminary work setting up Mozilla's Mozilla ARchive, or "mar", incremental binary updating--still lots to be done. Clearly has moved beyond an OS X only issue. And not clear why this would not simply be closed duplicate of bug 54242 -- or better close that to this. =-ref-= status here https://wiki.documentfoundation.org/Development/Online_Update https://wiki.mozilla.org/Software_Update https://gerrit.libreoffice.org/#/c/17053/
Stuart: this bug was OS X only, since the OP (me) suggested to use Sparkle to deal with updates. The sparkle framework is OS X only. If TDF / LO core devs decide to instead work on the mozilla update mechanism that is fine and then of course it is OS agnostic (iirc). Sparkle: https://github.com/sparkle-project/Sparkle
ups. sorry, OP not me, but I am sure I filed a dupe a long time ago ;)
@Steve, looks like it went cross platform from comment 5 onward...
(In reply to steve -_- from comment #28) > The sparkle framework is OS X only. Sparkle OS X: Sparkle https://sparkle-project.org/ https://github.com/sparkle-project/Sparkle Sparkle Windows: WinSparkle https://winsparkle.org/ https://github.com/vslavik/winsparkle
*** Bug 92835 has been marked as a duplicate of this bug. ***
Does the work on MAR-based LO updater for Windows account for the case when LO for Windows is initially installed using MSI (the prevalent majority case, mandatory for enterprise deployment)? I ask because the updater should not break mandatory MSI functionality, such as: 1. Add/remove components of installed software. This could be broken if we simply replace some files in installation directory: 1.1. If we simply replace a file 1-to-1, then removing a feature with that file and then adding it again will restore old file from MSI kept in Windows\Installer directory, which is undesirable at least, and can prevent from working because of incompatibilities of different versions of different files trying to work together. Also, installer may detect different version of a file, and work improperly; 1.2. If an update wants to add new files or remove existing, this is another sort of problems for installer trying to add/remove features. 2. Uninstall the software: if the updater had added new files to installation, then uninstaller must not have those files (that it knows nothing about) left in Program Files after uninstall (or it will be bad UX). 3. Repair/reinstall: I suppose it's obvious what problems may be encountered here, least of those is unexpected reverting to an older version.
(In reply to Mike Kaganski from comment #34) > Does the work on MAR-based LO updater for Windows account for the case when > LO for Windows is initially installed using MSI (the prevalent majority > case, mandatory for enterprise deployment)? > > I ask because the updater should not break mandatory MSI functionality, such > as: > > 1. Add/remove components of installed software. This could be broken if we > simply replace some files in installation directory: > 1.1. If we simply replace a file 1-to-1, then removing a feature with that > file and then adding it again will restore old file from MSI kept in > Windows\Installer directory, which is undesirable at least, and can prevent > from working because of incompatibilities of different versions of different > files trying to work together. Also, installer may detect different version > of a file, and work improperly; > 1.2. If an update wants to add new files or remove existing, this is another > sort of problems for installer trying to add/remove features. > > 2. Uninstall the software: if the updater had added new files to > installation, then uninstaller must not have those files (that it knows > nothing about) left in Program Files after uninstall (or it will be bad UX). > > 3. Repair/reinstall: I suppose it's obvious what problems may be encountered > here, least of those is unexpected reverting to an older version. I do not know if the work I did on the updater accounts for these changes. It has been a while since I have worked on the updater, and in hindsight I believe that it would have been a better idea to use an existing software updating framework instead of porting Mozilla's updater. From what I remember seeing, their implementation was tightly coupled to Firefox and thus I think it would have been much cleaner and safer to use a different approach for an LO update mechanism. I would personally recommend scrapping the existing work on the updater and looking into an alternative framework such as Sparkle.
Unfortunately Sparkle was not cross-platform :-(
(In reply to Jan Holesovsky from comment #36) > Unfortunately Sparkle was not cross-platform :-( Sparkle for macOS: Sparkle https://sparkle-project.org/ https://github.com/sparkle-project/Sparkle Sparkle for Windows: WinSparkle https://winsparkle.org/ https://github.com/vslavik/winsparkle Linux: Updates via distribution's package management anyway One user of Sparkle (at least on the macOS platform) for its cross platform software: * Java Plugin/JRE from Oracle Other cross platform software projects, which also are using Sparkle for updating itself (at least on the macOS platform): * Transmission * VLC Media Player […] How did all these projects achieve that in doing so and in doing so well and in doing so cross platform? What have they done to achieve that, what LibreOffice can't do and achieve either?
(In reply to Sierk Bornemann from comment #37) > (In reply to Jan Holesovsky from comment #36) > > Unfortunately Sparkle was not cross-platform :-( > > Sparkle for macOS: Sparkle > https://sparkle-project.org/ > https://github.com/sparkle-project/Sparkle > > Sparkle for Windows: WinSparkle > https://winsparkle.org/ > https://github.com/vslavik/winsparkle Two different products, not a single cross-platform one. Markus M. will work on getting the current updater in shape. Let's not get carried away. There's plenty of LibreOffice work we can direct our energy to while waiting.
(In reply to Buovjaga from comment #38) > Markus M. will work on getting the current updater in shape. Let's not get > carried away. There's plenty of LibreOffice work we can direct our energy to > while waiting. Quick update: Markus just pushed the updater to a feature branch: https://cgit.freedesktop.org/libreoffice/core/log/?h=feature/mar-updater
(In reply to Nathan Yee from comment #35) > I would personally recommend scrapping the existing work on the updater and > looking into an alternative framework such as Sparkle. That’s what I’ve been saying since before this project started. It’s sad that nobody seems to listen.
I strongly support sparkle usage. The counter argument atm from devs is, that sparkle is not cross platform. And then again, snap-builds (whatever that is) on Linux is dealt with and that's not cross from what I can tell. Obviously work is happening since moggi pushed the mar updater for windows to a feature branch. That branch also has recent action. So work is being done at this time. Downside for macOS: moggi is not interested to work on any updater stuff regarding macOS. That's his preferences and I respect that. But I wonder, how updates on macOS then can be moved forward into some constructive direction. Adolfo are you in touch with QA / Dev department? We all agree this is an important problem in LO I guess. Figuring out options to move this forward would be great.
(In reply to Adolfo Jayme from comment #40) > (In reply to Nathan Yee from comment #35) > > I would personally recommend scrapping the existing work on the updater and > > looking into an alternative framework such as Sparkle. > > That’s what I’ve been saying since before this project started. It’s sad > that nobody seems to listen. The mar based updater code is actually quite good. I'm not sure why people recommend to use something else without having had a look into the code. The only problems with the mar based updater are infra problems. Otherwise the code solves many problems that big and complex projects like LibreOffice or Firefox have. Additionally the Mozilla security team did a quite good analysis of the problem space and raised many security issues that are fixed. Does anyone here volunteer to do the same security audit for any other system? I'm happy to hand over the work on an automated updater if someone wants to deal with all these boring low level platform details.
(In reply to steve -_- from comment #41) > I strongly support sparkle usage. The counter argument atm from devs is, > that sparkle is not cross platform. And then again, snap-builds (whatever > that is) on Linux is dealt with and that's not cross from what I can tell. How are they related? There is a huge difference between some release format (they are already all platform dependent) and introducing 3 platform dependent update mechanisms. This means 3 times the code and 3 times the attack surface. > > Obviously work is happening since moggi pushed the mar updater for windows > to a feature branch. That branch also has recent action. So work is being > done at this time. > > Downside for macOS: moggi is not interested to work on any updater stuff > regarding macOS. That's his preferences and I respect that. But I wonder, > how updates on macOS then can be moved forward into some constructive > direction. Yes, I will not do the work necessary to enable the feature on OSX. However the code is there and you just need to find a developer to spend a bit of time enabling the feature. It is not that it would not work, just that I will not spend my free time debugging platform problems and dealing with OSX. Mozilla's updater code works on OSX and all the platform bits are already in our repo. > > Adolfo are you in touch with QA / Dev department? We all agree this is an > important problem in LO I guess. Figuring out options to move this forward > would be great. Did anyone here who says that the mar based updater is a bad idea and sparkle is such a good idea have ever looked into the code. Especially all the security stuff related to installing automated updates. Do you really want to audit 3 different frameworks? Do you really suppose that you will find developers willing to maintain 3 different update frameworks. I suppose I have better chances convincing all other developers to just drop OSX support.
And to make sure it is not only a rant but also shows some of the things that any alternative would need to provide: * cross-platform, at least Windows and Linux, OSX is a plus * simple signing of the update files * silent updater for limited user accounts on windows (https://bugzilla.mozilla.org/show_bug.cgi?id=711475) * verification of updater, updater service, and update file signature (e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=709173, https://bugzilla.mozilla.org/show_bug.cgi?id=704285, https://bugzilla.mozilla.org/show_bug.cgi?id=708854) * a way to have the silent update service optional * version checks for the update files (on the client side, needs to happen in the updater)(https://bugzilla.mozilla.org/show_bug.cgi?id=708688) * update service should drop all unnecessary permissions (might execute untrusted stuff) * a decent security review (e.g. at least the points raised by the Mozilla security team need to be handled) (especially the silent update service is a high risk piece of code) * handling of staged updates on windows (work around for the nasty file is still in use problem on windows) Now most of the stuff is already implemented in our updater branch. I even managed to get the update service building and have most of the security stuff adapted to our code. To show that an alternative is better you need to cross at least these points from the list and show that it is less work to integrate it correctly than it is to finish the current code.
Hi there, I'm one of the Mozilla engineers who works a lot on our update system (mostly the server side). If there's any questions are confusion about the way our updates work feel free to get in touch (email, irc - whatever) - I'm happy to help if you're having issues. I also wanted to point you at https://wiki.mozilla.org/ReleaseEngineering/Funsize - which is the system we use to generate partial MARs these days.
(In reply to Ben Hearsum from comment #45) > Hi there, I'm one of the Mozilla engineers who works a lot on our update > system (mostly the server side). If there's any questions are confusion > about the way our updates work feel free to get in touch (email, irc - > whatever) - I'm happy to help if you're having issues. > > I also wanted to point you at > https://wiki.mozilla.org/ReleaseEngineering/Funsize - which is the system we > use to generate partial MARs these days. Hey Ben, thanks for the offer. I have by now implemented at least some parts of the mar based updater for Linux daily builds. We have some unique challenges that are different to Mozilla that we need to solve (e.g. we distribute MSI on windows and will need to generate MSP that we wrap in the MAR files). Funsize looks like something I need to evaluate. We are still hoping to be able get basic automatic updates based on the Mozilla updater code working in 6.0
*** Bug 125625 has been marked as a duplicate of this bug. ***
Changing priority to 'high' since the number of duplicates is higher than 5 or the number of people in CC higher than 20
*** Bug 130146 has been marked as a duplicate of this bug. ***
(In reply to Ben Hearsum from comment #45) > I also wanted to point you at > https://wiki.mozilla.org/ReleaseEngineering/Funsize - which is the system we > use to generate partial MARs these days. The funsize Github repo is archived and apparently funsize now lives in https://hg.mozilla.org/mozilla-central/file/tip/taskcluster/docker/funsize-update-generator/scripts/funsize.py
What is the current state of this? Having auto updates on Windows is pretty important imho to ensure a nice user experience.
Proposal for a better UI at bug 80110
*** Bug 147758 has been marked as a duplicate of this bug. ***
Work is ongoing to make this available as (for now) an experimental feature for Windows in LibreOffice 24.2.0, see <https://wiki.documentfoundation.org/index.php?title=Development/Online_Update&oldid=720758> ("updated to current status") for details. A list of relevant commits on the libreoffice-24-2 branch so far: > 7f49fa220225d2afbefac756a03586212d8ce1c6 "Make --enable-online-update=mar at least compile again, on Linux" > 8686b480ba1d79463f33fe931a454d9d92c3d739 "Fix apparent copy/paste typo" > cc3fb303db41492eccf845f34581b462c6ee24ec "Fix apparent typo in make create-update-info" > d4370db8ceb74950d3ef381d4a0c1aca033f0294 "mkdir_p still needed by make create-partial-info" > b17d051ad56ab706d15a3b696266be1ac1df2e5d "Make --enable-online-update and --enable-online-update=mar orthogonal" > 5d2c5b09c9e7940b2285180b42e6e574063b693e "GUI to en-/disable the --enable-online-update-mar feature at runtime" > caea33a11a212fc1c0426c90715c06376dbb9f06 "Turn on MAR-based updater for Win64" > 13595f6220095d120e13ccb6fbfac1de4c803fe7 "Fix --enable-online-update-mar on Windows" > bce717bcc3b647fa43e403c459500ed5ed79def4 "Fix Linux --enable-online-update-mar build" > 5af8759dc7bd9219f0cfc01aaa0d83b323a581ae "Split --with-update-config=... into many --with-online-update-mar-...=..." > acf00a90166bd17198e5b3c9fb2417dd0bd45deb "Fix number of actual arguments" > 084b1f6d0c43a90bb15c58e7e8d7b4f6d2e53de4 "Fix backward vs. forward slashes on Windows" > e34e4640823dd729bb9d530cbe1d187d991f8532 "Turn onlineupdate into external/onlineupdate" > dec2ee4f9d1e01757c76362f2f94600fe6c25066 "-Werror,-Wunused-result" > 92b7f110a9a4b61c01a921bfa65b3951a8386b62 "Fix placement for --enable-online-update-mar UI" > 62a50239e06ac2f94f4a1cfbef5a8689bd42b875 "Avoid "Desktop disposed before terminating it" assert" > 9800a7106223bd7759aa851574ef720d15a146cd "Hide --enable-online-updaet-mar GUI behind ExperimentalMode for now" > d125fc2a2178b100253ea089b7ad30acafccfb57 "Improve --enable-online-update-mar Windows MOZ_MAINTENANCE_SERVICE feature" > 1913ad7cfbf8d101f7e7bc8832b57bdded7ab389 "Set --with-online-update-mar-channel for distro-configs/LibreOfficeWin64.conf" > a4ad9b249eb002137dbab9f6df89280bc5ca3ef8 "Revert "updater: check every 12 hours for updates for now"" > 1c069c14a130010ec6cf53bd1b7d84a9df589f36 "Update --enable-online-update-mar server URL" > 04b18e28d3b44e2175331e78183e3b0fe6d81187 "Windows MSI custom action for --enable-online-update-mar" > b66c2c243b4877475341011d851196a201610321 Fix Windows MSI custom action for --enable-online-update-mar > 8aff3034ed3dec8c579d169bbe1e3094b49a8b72 Fix Windows path separator > 953ffde0ec80581c56c17bfec71e1b2817a3592d Hard-code --with-online-update-mar-channel=LOOnlineUpdater > 57092e6eadecec93e85c2d81d0e8601f6ec1106e Re-enable MOZ_VERIFY_MAR_SIGNATURE feature > 7b47ee0b6ca78ed51544b8177b810cd353814068 Actually drop --with-online-update-mar-channel > 37fb56a1ce031f929067b37c2959b970ff39efd2 Don't mess with UserInstallation setting of --with-package-format=archive > f28e0f30a47b3c8706d0247e1ee4f3e4084546cd Also copy updater.ini (so that updater progress UI will actually shown up) > b235e5e2f0933a013c6177f7e31ae82b45e9e048 Fix make create-update-info (for Windows, at least) > aa93c77c360f1b1e60baa3af556976f697147005 Introduce external/onlineupdate/monitor-sources.sh > 958089803917f46c81ca818b791c846c072f6fca Fix make create-update-info also for non-Windows > 873443e40fdfaa992edc4bc05b01c71e61ab2e94 Workaround for --disable-windows-build-signing --enable-dbgutil test builds
(In reply to Stephan Bergmann from comment #54) Today i was presented with something i was waiting for a long time (years, now...). That's the Libreoffice automatic update (thank you so much for it @Stephan Bergmann). It says "Please wait while we update your installation." Soon after libreoffice loads but there is no new version installed. i tried to run as administrator and i got the same result. is this expectable?
(In reply to Maverick from comment #55) > (In reply to Stephan Bergmann from comment #54) > > Today i was presented with something i was waiting for a long time (years, > now...). That's the Libreoffice automatic update (thank you so much for it > @Stephan Bergmann). > > It says "Please wait while we update your installation." > > Soon after libreoffice loads but there is no new version installed. > > i tried to run as administrator and i got the same result. > > is this expectable? From the ESC log: * Release Engineering update (Cloph) + 7.6: 7.6.6 RC2 next week + 24.2.2 RC2 next week + MAR update + enabled now for 24.0.0 -> 24.1.1, seems to work + RC<N> -> final will be enabled; otherwise just final -> next final + thanks a lot (Stephan) + does this mean end-users can already use this? (Xisco) + it's experimental for 24.2, but yes (Cloph) + need to opt in via tools -> options + on master, no longer experimental, but still need to opt in (Stephan) + for now, hardcoded to check once a week Did you activate that option?
(In reply to Maverick from comment #55) > It says "Please wait while we update your installation." > > Soon after libreoffice loads but there is no new version installed. This means that it downloaded an update and at least tried to apply it. I don't have a Windows machine around today to check the details, but in your user installation (.../LibreOffice/4/), next to the user/ sub-dir, there should now be a sub-dir named update/ (or something similar) with a sub-dir named 0/. Inside that should be a "status" file (what does it contain?) and one or more *.log files. If you could attach those here, that would be helpful. Also, is there a *.mar file in that directory?
(In reply to Dennis Roczek from comment #56) > Did you activate that option? If you mean Tools > Options > On-line Update > Enable Automatic Update, then yest it's enabled!
(In reply to Stephan Bergmann from comment #57) > Inside that should be a "status" file (what does it contain?) Just the text "pending-service" > and one or more *.log files. If you could attach those here, that would be helpful. Will attach 2 .log files > Also, is there a *.mar file in that directory? Yes it is, an update.mar (size: 15.0mb)
Created attachment 193127 [details] 2 log files the requested log files
(In reply to Maverick from comment #60) > the requested log files The relevant part is in update-elevated.log: > 2024-03-14 16:18:10+0000: EXECUTE PATCH share/wizards/resources_ug.properties > 2024-03-14 16:18:10+0000: LoadSourceFile: destination file size 80585 does not match expected size 78930 > 2024-03-14 16:18:10+0000: LoadSourceFile failed > 2024-03-14 16:18:10+0000: ### execution failed Are you aware that you ever manually modified the file share/wizards/resources_ug.properties in the LO installation? Alternatively, it might be the case that some operation does change that file, which we'd need to track down. Can you please open a Windows command shell and do a `dir` of that LO installation's share/wizards directory, and paste the output here? If that output includes file time stamps, it might give a first clue whether your resources_ug.properties has indeed been modified post installation.
(In reply to Stephan Bergmann from comment #61) > Are you aware that you ever manually modified the file > share/wizards/resources_ug.properties in the LO installation? I am sure i never manually modified the file share/wizards/resources_ug.properties in the LO installation!!! Now, the weird thing is that this is happening in all our Windows machines (plus a personal laptop i have at home...) I'm not on a windows machine ATM. As soon as i can (in about 1h-3h) i'll fire up the CLI and report back here.
(In reply to Stephan Bergmann from comment #61) > Can you please open a Windows command > shell and do a `dir` of that LO installation's share/wizards directory, and > paste the output here? If that output includes file time stamps, it might > give a first clue whether your resources_ug.properties has indeed been > modified post installation. Does not seem to have been modified post instalation... but, here's the output (i have a PT installation, btw): 01-02-2024 12:04 <DIR> . 01-02-2024 12:04 <DIR> .. 28-01-2024 19:44 25.263 resources_af.properties 28-01-2024 19:44 56.065 resources_am.properties 28-01-2024 19:44 68.266 resources_ar.properties 28-01-2024 19:44 75.870 resources_as.properties 28-01-2024 19:44 27.764 resources_ast.properties 28-01-2024 19:44 81.069 resources_be.properties 28-01-2024 19:44 88.474 resources_bg.properties 28-01-2024 19:44 70.192 resources_bn.properties 28-01-2024 19:44 76.578 resources_bn_IN.properties 28-01-2024 19:44 82.443 resources_bo.properties 28-01-2024 19:44 28.342 resources_br.properties 28-01-2024 19:44 71.862 resources_brx.properties 28-01-2024 19:44 26.446 resources_bs.properties 28-01-2024 19:44 27.904 resources_ca.properties 28-01-2024 19:44 27.809 resources_ca_valencia.properties 28-01-2024 19:44 29.134 resources_ckb.properties 28-01-2024 19:44 31.069 resources_cs.properties 28-01-2024 19:44 24.684 resources_cy.properties 28-01-2024 19:44 26.096 resources_da.properties 28-01-2024 19:44 28.789 resources_de.properties 28-01-2024 19:44 61.875 resources_dgo.properties 28-01-2024 19:44 32.292 resources_dsb.properties 28-01-2024 19:44 90.198 resources_dz.properties 28-01-2024 19:44 94.777 resources_el.properties 28-01-2024 19:44 24.519 resources_en_GB.properties 29-06-2023 22:13 23.957 resources_en_US.properties 28-01-2024 19:44 24.520 resources_en_ZA.properties 28-01-2024 19:44 26.025 resources_eo.properties 28-01-2024 19:44 28.142 resources_es.properties 28-01-2024 19:44 26.362 resources_et.properties 28-01-2024 19:44 25.559 resources_eu.properties 28-01-2024 19:44 50.737 resources_fa.properties 28-01-2024 19:44 27.043 resources_fi.properties 28-01-2024 19:44 30.391 resources_fr.properties 28-01-2024 19:44 24.523 resources_fur.properties 28-01-2024 19:44 26.481 resources_fy.properties 28-01-2024 19:44 31.447 resources_ga.properties 28-01-2024 19:44 30.996 resources_gd.properties 28-01-2024 19:44 28.183 resources_gl.properties 28-01-2024 19:44 71.763 resources_gu.properties 28-01-2024 19:44 25.503 resources_gug.properties 28-01-2024 19:44 63.588 resources_he.properties 28-01-2024 19:44 72.113 resources_hi.properties 28-01-2024 19:44 26.843 resources_hr.properties 28-01-2024 19:44 30.186 resources_hsb.properties 28-01-2024 19:44 33.764 resources_hu.properties 28-01-2024 19:44 90.643 resources_hy.properties 28-01-2024 19:44 24.378 resources_id.properties 28-01-2024 19:44 31.710 resources_is.properties 28-01-2024 19:44 26.932 resources_it.properties 28-01-2024 19:44 50.229 resources_ja.properties 28-01-2024 19:44 72.485 resources_ka.properties 28-01-2024 19:44 26.818 resources_kab.properties 28-01-2024 19:44 83.739 resources_kk.properties 28-01-2024 19:44 86.620 resources_km.properties 28-01-2024 19:44 29.422 resources_kmr_Latn.properties 28-01-2024 19:44 86.351 resources_kn.properties 28-01-2024 19:44 40.943 resources_ko.properties 28-01-2024 19:44 68.582 resources_kok.properties 28-01-2024 19:44 61.753 resources_ks.properties 28-01-2024 19:44 24.730 resources_lb.properties 28-01-2024 19:44 65.155 resources_lo.properties 28-01-2024 19:44 29.016 resources_lt.properties 28-01-2024 19:44 30.094 resources_lv.properties 28-01-2024 19:44 65.914 resources_mai.properties 28-01-2024 19:44 75.895 resources_mk.properties 28-01-2024 19:44 86.016 resources_ml.properties 28-01-2024 19:44 85.242 resources_mn.properties 28-01-2024 19:44 70.092 resources_mni.properties 28-01-2024 19:44 73.768 resources_mr.properties 28-01-2024 19:44 91.894 resources_my.properties 28-01-2024 19:44 25.770 resources_nb.properties 28-01-2024 19:44 78.178 resources_ne.properties 28-01-2024 19:44 26.275 resources_nl.properties 28-01-2024 19:44 25.665 resources_nn.properties 28-01-2024 19:44 25.955 resources_nr.properties 28-01-2024 19:44 28.902 resources_nso.properties 28-01-2024 19:44 28.692 resources_oc.properties 28-01-2024 19:44 25.382 resources_om.properties 28-01-2024 19:44 78.021 resources_or.properties 28-01-2024 19:44 67.816 resources_pa_IN.properties 28-01-2024 19:44 28.434 resources_pl.properties 28-01-2024 19:44 28.915 resources_pt.properties 28-01-2024 19:44 28.842 resources_pt_BR.properties 28-01-2024 19:44 29.893 resources_ro.properties 28-01-2024 19:44 79.441 resources_ru.properties 28-01-2024 19:44 25.795 resources_rw.properties 28-01-2024 19:44 92.425 resources_sat.properties 28-01-2024 19:44 71.474 resources_sa_IN.properties 28-01-2024 19:44 61.962 resources_sd.properties 28-01-2024 19:44 64.734 resources_si.properties 28-01-2024 19:44 24.354 resources_sid.properties 28-01-2024 19:44 30.721 resources_sk.properties 28-01-2024 19:44 26.893 resources_sl.properties 28-01-2024 19:44 27.772 resources_sq.properties 28-01-2024 19:44 25.913 resources_sr.properties 28-01-2024 19:44 24.523 resources_sr_Latn.properties 28-01-2024 19:44 25.672 resources_ss.properties 28-01-2024 19:44 26.783 resources_st.properties 28-01-2024 19:44 27.281 resources_sv.properties 28-01-2024 19:44 24.495 resources_sw_TZ.properties 28-01-2024 19:44 28.333 resources_szl.properties 28-01-2024 19:44 81.256 resources_ta.properties 28-01-2024 19:44 77.605 resources_te.properties 28-01-2024 19:44 71.772 resources_tg.properties 28-01-2024 19:44 84.034 resources_th.properties 28-01-2024 19:44 25.403 resources_tn.properties 28-01-2024 19:44 30.358 resources_tr.properties 28-01-2024 19:44 26.722 resources_ts.properties 28-01-2024 19:44 26.505 resources_tt.properties 28-01-2024 19:44 80.585 resources_ug.properties 28-01-2024 19:44 79.896 resources_uk.properties 28-01-2024 19:44 25.498 resources_uz.properties 28-01-2024 19:44 29.350 resources_ve.properties 28-01-2024 19:44 30.506 resources_vec.properties 28-01-2024 19:44 35.478 resources_vi.properties 28-01-2024 19:44 27.432 resources_xh.properties 28-01-2024 19:44 34.280 resources_zh_CN.properties 28-01-2024 19:44 35.032 resources_zh_TW.properties 28-01-2024 19:44 26.064 resources_zu.properties 120 File(s) 5.527.414 bytes 2 Dir(s) 429.161.762.816 bytes free
@Maverik: What is the exact LO version that you have installed (and which fails to auto-update)? And is it 32-bit x86 or 64-bit x86-64?
(In reply to Stephan Bergmann from comment #64) > @Maverik: What is the exact LO version that you have installed (and which > fails to auto-update)? And is it 32-bit x86 or 64-bit x86-64? Version: 24.2.0.3 (X86_64) / LibreOffice Community. I'm not sure if i downloaded it directly from libreoffice.org/download or from dev-builds.libreoffice.org. If it was the latter, i suppose it was either an RC or final... If you prefer, i can try a different v24.2.0.3 to be sure (in this case, please provide a link to the correct one)
@Bergmann some update: I've uninstalled libreoffice and removed everything i could find regarding it in user/appdata and in programs' folders. Then i downloaded 24.2.0.3 from https://downloadarchive.documentfoundation.org/libreoffice/old/24.2.0.3/win/x86_64/ installed and retried the update but ended up with the same result. It does not update to 24.2.1 (not even if i run it as admin).
Indeed, while a 32-bit LibreOffice_24.2.0.3_Win_x86 installation downloads a 14991064-byte update.mar file that I've seen working fine, a 64-bit LibreOffice_24.2.0.3_Win_x86_64 installation downloads a 15730646-byte update.mar file that is apparently broken: Already for the first to-be-patched file it wants to process (i.e., share/wizards/resources_ug.properties), it complains that "destination file size 80585 does not match expected size 78930" (see comment 61). @cloph: Did anything go wrong generating that mar file?
@Bergmann let me ask two questions: 1. when 24.2.2 get's out, since a new mar file gets generated, will this get "automatically" fixed? 2. when 24.8.0 get's out will the update lead you to 24.2.6, 24.2.7 and so on, or will it go strait from 24.2.5 -> 24.8.0? (really hope the road is 24.2.5 -> 24.8.0. Makes a lot more sense to me.)
Nothing wrong with the update packages themselves, but with the server layout/the mapping of buildIDs to the actual updates, should be fixed now.
(In reply to Christian Lohmaier from comment #69) > Nothing wrong with the update packages themselves, but with the server > layout/the mapping of buildIDs to the actual updates, should be fixed now. yes, thanks, fixed; seen a LibreOffice_24.2.0.3_Win_x86_64 installation automatically upgrade all the way to the latest LO 24.2.2.1 now
(In reply to Maverick from comment #68) > 1. when 24.2.2 get's out, since a new mar file gets generated, will this get > "automatically" fixed? should fix itself automatically now for you, see previous comments > 2. when 24.8.0 get's out will the update lead you to 24.2.6, 24.2.7 and so > on, or will it go strait from 24.2.5 -> 24.8.0? > (really hope the road is 24.2.5 -> 24.8.0. Makes a lot more sense to me.) that depends on what mar files TDF infra provides; but even if there are only individual "single step" updates 24.2.5 -> 24.2.6 -> 24.2.7 -> 24.8.0 available instead of a "big step" 24.2.5 -> 24.8.0, the single step updates would all be downloaded and applied automatically in succession, so that the end result should be the same
(In reply to Stephan Bergmann from comment #70) > (In reply to Christian Lohmaier from comment #69) > > Nothing wrong with the update packages themselves, but with the server > > layout/the mapping of buildIDs to the actual updates, should be fixed now. > > yes, thanks, fixed; seen a LibreOffice_24.2.0.3_Win_x86_64 installation > automatically upgrade all the way to the latest LO 24.2.2.1 now I can confirm that some of the machines around here did perform the upgrade. There are a few different situations (probably are a local problem): a) A laptop performed the upgrade directly from 24.2.0.3 -> 24.2.2.1 (as expected). b) Other desktops (about an hour later) performed the upgrade only from 24.2.0.3 -> 24.2.1.1. They do detect there is 24.2.2.1, but they don't upgrade to it. c) A few of them, however, have not performed any upgrade at all (they do detect the update). Apparently this can be fixed by removing and cleaning the machine from any previous LO install. I installed version 24.2.0.3 and they do upgrade to 24.2.1.1, but not to 24.2.2.1, like in b) Unfortunately i have no time, ATM, to investigate or test this situations more into detail.
(In reply to Stephan Bergmann from comment #71) > should fix itself automatically now for you, see previous comments OK, nice! Thank you. > that depends on what mar files TDF infra provides; but even if there are > only individual "single step" updates 24.2.5 -> 24.2.6 -> 24.2.7 -> 24.8.0 > available instead of a "big step" 24.2.5 -> 24.8.0, the single step updates > would all be downloaded and applied automatically in succession, so that the > end result should be the same OK, i can live with that :)
Created attachment 193325 [details] Update available > (In reply to Stephan Bergmann from comment #70) > > (In reply to Christian Lohmaier from comment #69) > > b) Other desktops (about an hour later) performed the upgrade only from > 24.2.0.3 -> 24.2.1.1. They do detect there is 24.2.2.1, but they don't > upgrade to it. Let me correct this: It upgrades from 24.2.0.3 -> 24.2.1.1 but then it say it has more updates. The update dialog says the newer upgrade to the installed version 24.2.1.1 is 24.2.1 (and not 24.2.2.1 as i mistakenly indicated - sorry about that!) screenshot attached
(In reply to Maverick from comment #74) > It upgrades from 24.2.0.3 -> 24.2.1.1 but then it say it has more updates. > The update dialog says the newer upgrade to the installed version 24.2.1.1 > is 24.2.1 (and not 24.2.2.1 as i mistakenly indicated - sorry about that!) You have both the traditional "Check for updates automatically" notifications and the new MAR-based "Enable automatic update" enabled? Then the former will notify you about potential updates to version X at point Y in time, while the latter will automatically update to (a potentially different) version Z at (a potentially different) point W in time. (Which can be confusing; the overall plan is to get rid of the former once the latter is no longer an experimental-only feature.) To force the automatic MAR-based update to kick in as soon as you start LO, you can start LO with the LIBO_UPDATER_TEST_ENABLE environment variable set.
@Stephan, * So rolled back my daily driver on Win10 following a full uninstall and registry cleanup to 24.2.0.3 via msiexec.exe command line as admin, left out the localHelp installer. Want to place this into Automatic Update via MAR mode and get some experience with it. I've enabled experimental, and checked the boxes on the Tools -> Options -> Online Update (Check for updates automatically:Every day; Download updates automatically; and Send OS version and basic hardware information). On relaunch I get the legacy notice (globe icon top right) of a "LibreOffice update available". Assume from comment 75 we can uncheck the check and the download? But /me confused... How exactly should we proceed to change over to MAR updates? Did I miss a panel option somewhere? Experimental features enabled but can't locate "Enable automatic update" in UI. Is it an Expert Configuration stanza?
(In reply to V Stuart Foote from comment #76) > > But /me confused... How exactly should we proceed to change over to MAR > updates? Did I miss a panel option somewhere? Experimental features enabled > but can't locate "Enable automatic update" in UI. Is it an Expert > Configuration stanza? Never mind it was simple, just had to think about it: C:\Program Files\LibreOffice\program>.\soffice.exe -env:LIBO_UPDATER_TEST_ENABLE=1 Got a clean sequential MAR update 24.2.0.3 --> 24.2.2.1
(In reply to Stephan Bergmann from comment #75) > You have both the traditional "Check for updates automatically" > notifications and the new MAR-based "Enable automatic update" enabled? Yes, actually it was. Can one disable the "Check for updates automatically", and LO will still continue to get MAR updates (as long as the Enable Automatic Updates is checked)? or to get the mar updates with the "Check for updates automatically" disabled one has to always set the environment variable you mentioned?
(In reply to V Stuart Foote from comment #77) and to make it stick across soffice.exe launches, issued this from admin level command prompt. setx LIBO_UPDATER_TEST_ENABLE "1" /M to set the environment variable for the system. Drop to /M to make it per-user
Created attachment 193329 [details] Expert config Office.Update stanzas Hmm, still confused: With Experimental features enabled and "LIBO_UPDATER_TEST_ENABLE" set 1, opened Expert configuration to the Office.Update stanzas (attached). Found the Update --> 'Enabled' Boolean set False Edited it to True, but would not expect to need to. Although this was run from a non-privileged user account. Waiting for the 24.2.2.2 rc2 MAR to post and apply.
@Stephan, cloph See that 24.2.2.2 has built (2024-03-24) and MSI is available in pre-release, but not being offered that as MAR incremental on launch of a 24.2.2.1 with Office.Update 'Enabled' and the "LIBO_UPDATER_TEST_ENABLE" env variable set. Was there something that needs to get triggered to build the MAR diff, or am I misconfigured somehow?
(In reply to V Stuart Foote from comment #81) > @Stephan, cloph > > See that 24.2.2.2 has built (2024-03-24) and MSI is available in > pre-release, but not being offered that as MAR incremental on launch of a > 24.2.2.1 with Office.Update 'Enabled' and the "LIBO_UPDATER_TEST_ENABLE" env > variable set. > > Was there something that needs to get triggered to build the MAR diff, or am > I misconfigured somehow? Never got a MAR update of 24.2.0.3 past initial 24.2.2.1 Cleaned off my MAR updated 24.2.0.3 install. Then installed clean from the 24.2.1.2 MSI package. Completed install and immediately ran from program directory .\soffice.exe -env:LIBO_UPDATER_TEST_ENABLE=1 as admin. Received a MAR update of the new install, but again only to 24.2.2.1 (bf759d8). The 24.2.2.2 final (d56cc15) as MAR is not being received. At this point, with check for updates now offering the 24.2.2.2 download as available, kind of seems the MAR diff build is not being generated?