Before I log a support ticket. Is anyone experiencing LibreOffice crashing when you try re-open a previously saved document (i.e. odt, ods, docx, xlsx, …)?
I can create a new document and save it; then quit LibreOffice.
However, if I return later and try to re-open it, it immediately crashes and displays a “crash” window.
however, if I try to re-open the same document again…
Same here. Booting into 6 week older revision of Haiku (March) and LibreOffice works great. Looking at the difference in packages, LibreOffice itself hasnt been updated, so its another package causing the problem.
UPDATE: After additional checks, it seems to affect the documents of newer file types. The .doc, .sxw, .xls, and .rtf files open correctly with LibreOffice. Hmmm…I’m guessing here that libxml2 is not required to open the older file types. I will create a support ticket for this related issue.
It’s not even sure atm this “is” related, but when I saw the missing symbol I thought about the removed functions in libxml2, mostly we take care of packages requiring libraries, in cases SONAME changes are involved, in this case the SONAME wasn’t an isssue, just that libxml2 removed the “FTP” functions without proper advertising causing the breakage. I’ve revbumped LO and build is running on the buildmaster (should take a while) which atleast should resolve the missing symbol (not sure if it fixes the crash).
Also we need to see that for merging library packages the SONAME is correctly filled in in the recipe (which was the problem for libsndfile before).
What is needed at a minimum is some testing, either automated or manual, preferable both, in order to ensure that updated packages do not break anything.
I don’t think there is some form of automatic testing here, mostly I check it manually here. I guess the easiest fix for this was to build libxml2 with --with-ftp to restore the missing funtions, but as that wasn’t done, the SONAME didn’t break dependency (so it doesn’t pick up the missing symbol until you launch the app).
Checked on 64bit and also get the crash, but I didn’t see the missing symbol there, so maybe it’s not related to libxml2 even.
EDIT Just checked 32bit which still seems to be fine.
Manual testing would have caught the error, and so would automated.
By manual testing I am referring to a testing release (nightly → testing → stable) so users that use the testing release have an amount of time to spot and report errors.
By automated I am referring to tools that can spot missing symbols (and other errors).
One thought I’ve had is to automatically detect which symbols (if that is the correct term) each package requires and produces and any information about its api/abi version. If that is possible, packages could state which symbols they need instead of which package. Reservation for me using the wrong terminology since I don’t know them. What I mean is that packages should define what functions they need, not which packages. By knowing the functions the needed packages can be selected. Is this possible?
Listing all symbols in the package metadata would add several megabytes of data to the files overall, when the info is already available in the files packaged inside, it doesn’t seem that great a solution.
We are already doing dependencies at the executable or library level rather than at the package level, whiuch, indeed, doesn’t help at all in this case.
One possible improvement would be to run abi-compliance-checker on each update to see when functions are removed from a library and then we can make sure to test some of the dependant packages before shipping the change.
And, yes, we really need to not have a single branch at haikuports and have some kind of stable repository. Even if no one will use it because all apps in it will be out of date
I’ve read those and found out through readelf that indeed the functions are missing, did a local rebuild for libxml2 with --with-ftp and the functions get restored then, but as upstream mentions (iirc) they were of no use.
Why re-enable them then? do we need them for something? it seems to me the better approach is just to rebuild the packages that depend on libxml2 ?, this is just a suggestion though not a complaint, after all you’re the one doing all the work.
Has there been any discussions and/or any decisions taken on future improvements regarding testing and improved tools to minimise breakage? Even if nobody has the time to work on it now, it would be good to have a plan documented and tickets created.
