Created attachment 186940 [details] error I cannot open attached file in bibisect repo. Not sure if it's about that repo or LO.
Created attachment 186941 [details] reproducer From this commit: commit 26bf26272bf525b59b4a4ce18b3ce14c1febfd7b [log] author Miklos Vajna <vmiklos@collabora.com> Mon Apr 24 14:27:47 2023 +0200 committer Miklos Vajna <vmiklos@collabora.com> Tue Apr 25 08:05:16 2023 +0200 Update libxmlsec to 1.3.0
I can't reproduce it in Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 52acefd6024ec79f8333ba40eef83816eda3046f CPU threads: 8; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: es-ES (es_ES.UTF-8); UI: en-US Calc: threaded Win only ? Info about LibreOffice is missing...
I wrote "bibisect repo", it's Linux.
(In reply to Timur from comment #3) > I wrote "bibisect repo", it's Linux. There are bibisect repos for Win and Mac as well. About LibreOffice info still missing though...
Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 52acefd6024ec79f8333ba40eef83816eda3046f CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded I can start LO, but not with that file, I think also some others.
Seems like problem is: Ubuntu 18.04 with 1.2.25 1.2.25 cannot work with libxmlsec 1.3.0.
Reading the commit, there's an ABI incompatibility. Perhaps you should upgrade Ubuntu to have a more recent lib. Now, I wonder those who package LO for Ubuntu 18.04 didn't see this dependency. Perhaps Ubuntu's bug? Miklos: any thoughts here?
Gabor has a tip here: https://gerrit.libreoffice.org/c/core/+/150647/5#message-8392aeb0294a7d90ae8bdc99ac58d18631622ce1 does that work for you? Given that xmlsec upstream has no interest in supporting such an old NSS and our documented Linux baseline (RHEL7) has newer NSS, I would suggest you stick with internal NSS for your builds instead of doing something here at a source code level. Thanks.
Upgrade Ubuntu is not a solution here. I'm not sure if I would do it, as I'm not sure that bibisect repos, especially olders ones, would still work. And it's not only about me. https://www.libreoffice.org/get-help/system-requirements/ says just this: * Linux kernel version 3.10 or higher * glibc2 version 2.17 or higher * Gnome 3.18 or higher, with the at-spi2 1.32 package So with this change, what would be requirements? Only the newest OS? Bad. Gabor wrote: "Guess we stick to the --without-system-nss or upgrade the distro". Where upgrade excluded, does it mean that LO should be built --without-system-nss or in 2 builds, what about bibisect repos?
(In reply to Timur from comment #9) > Upgrade Ubuntu is not a solution here. I'm not sure if I would do it, as I'm > not sure that bibisect repos, especially olders ones, would still work. I don't see the interest to stick to something which is 5 years ago when the upgrade (at least the OS) is free. => uncc myself.
Unfortunately there was no reason given for upgrading libxml. If there is no compelling reason, then it probably makes sense to delay it at least until the next version of LO - it is rather late in the development cycle to break usage on a platform for no reason.
I explained already, LO was known to support old OS, it's very important, and is not the same as 'free upgrade' in terms of money, which may or may not work and be free in terms of usability. NSS version in Ubuntu 18.04 seems to be 3.35. What would be required? Agree with Justin, can you please revert this until: 1. LO 8.0 is released 2. bibisect repos are made sure to work with this old OS?
Repro with linux-64-7.6 bibisect repo: Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: a8493ee3d7dac611286a75516f24dd6e451f9718 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded More serious than originally thought: same with ODP and ODG files, and can't create a new document with Draw or Impress whatsoever. Error message: loading component library <file:///home/t/linux-64-7.6/instdir/program/../program/libsdlo.so> failed at /home/tdf/lode/bibisect/core76/cppuhelper/source/shlib.cxx:312 I am on Ubuntu 20.04, which is only 3 years old and should be supported by Canonical until 2030, but I guess that's not relevant and the issue actually lies in how the linux-64-7.6 bibisect repo is built. Xisco?
Sorry, it seems whenever I update xmlsec, somebody is upset. (In reply to Justin L from comment #11) > Unfortunately there was no reason given for upgrading libxml. Quoting <https://gerrit.libreoffice.org/c/core/+/141865/5#message-6d4d308e1ec85c5ba31fa9c9a4fd9a7658687042>: > You mean you also have NSS which is older than the Linux baseline (RHEL7), documented in README.md? > > I think it's reasonable to depend on NSS >= 3.79, since it's in the Linux baseline. > > At the same time, I just did this update as usual maintenance, I don't need this update urgently or anything; so if it's annoying and somebody wants to revert it: go for it, no hard feelings. I hope that helps.
So to be clear, the issue is only related to building, right? I'm OK with upping the requirement for developers, or having them use an extra flag, as long as all Ubuntu users will not be forced to upgrade to Ubuntu 22.10 to use the latest LO (first libnss3 version above 3.79: https://packages.ubuntu.com/kinetic/libnss3 )
(In reply to Stéphane Guillou (stragu) from comment #15) > So to be clear, the issue is only related to building, right? No. It is also related to testing and bibisect, where we don't have control over the environment it is run in. (comment 12)
Discussed in the ESC call, because we touched baselines anyway: https://lists.freedesktop.org/archives/libreoffice/2023-April/090317.html Bottom line is that this really just worked by accident previously, so technically no need to revert. If somebody wants to do it, go ahead, but I myself currently have no such plans. Thanks.
(In reply to Timur from comment #9) > Upgrade Ubuntu is not a solution here. I'm not sure if I would do it, as I'm > not sure that bibisect repos, especially olders ones, would still work. Slightly off-topic, but I can confirm the bibisect repos can be made to work on Ubuntu 22.04. (some manual hacks may be needed, it's documented in the wiki)
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/1770d3ba3313f2166153d39be6ae1212c00da6d8 tdf#155034 Revert "Update libxmlsec to 1.3.0" It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Xisco, is there a way to rebuild bibisect repo for the meantime not to have libxmlsec 1.3.0?
(In reply to Timur from comment #20) > Xisco, is there a way to rebuild bibisect repo for the meantime not to have > libxmlsec 1.3.0? What do you mean? the patch was reverted so the bisect repository will change back to xmlsec1-1.2.37 when compiling as well
I guess Timur means re-building the past few broken builds without the patch, so we don't have one of those annoying unbisectable ranges. Not sure if it's been done in the past / if it's worth the effort.
Yes.
(In reply to Xisco Faulí from comment #21) > What do you mean? the patch was reverted so the bisect repository will > change back to xmlsec1-1.2.37 when compiling as well This will come back to haunt us again soon enough. So the question is, can we do anything proactively about it. Do we need to change the bibisect builders to use --without-system-nss? (I expect that just shifts the problem to needing a libc or whatever that a newer nss requires...)
(In reply to Timur from comment #20) > Xisco, is there a way to rebuild bibisect repo for the meantime not to have > libxmlsec 1.3.0? The range is fairly small. It isn't that hard to read through three days worth of changes to guess at the commit that caused a regression. Plus if you really need an exact bibisect you could run it on a newer machine.
(In reply to Justin L from comment #25) > (In reply to Timur from comment #20) > > Xisco, is there a way to rebuild bibisect repo for the meantime not to have > > libxmlsec 1.3.0? > The range is fairly small. It isn't that hard to read through three days > worth of changes to guess at the commit that caused a regression. Plus if > you really need an exact bibisect you could run it on a newer machine. Nevermind, I've already done it. I'll let you know when is updated
(In reply to Justin L from comment #24) > (In reply to Xisco Faulí from comment #21) > > What do you mean? the patch was reverted so the bisect repository will > > change back to xmlsec1-1.2.37 when compiling as well > This will come back to haunt us again soon enough. So the question is, can > we do anything proactively about it. > > Do we need to change the bibisect builders to use --without-system-nss? (I > expect that just shifts the problem to needing a libc or whatever that a > newer nss requires...) Yes, I can add --without-system-nss to the bisect repositories but I don't see it being used anywhere in distro-configs/ other than CPLinux-LOKit.conf
Thanks. It's important especially for automated bibisects, that repo will be used for years. If we had to use skip script before, now we really do not need to. This seems to have raised 2 questions: 1. Will "Update libxmlsec to 1.3.0" for newer LO leave as supported just newer OS like Ubuntu 22.04, ditching all older OSes, which has not been LO strategy so far, resembling so MS? That's an important question that must be discussed and published before committing. 2. Should bibisect repos in that case be built with --without-system-nss? I how it would work, probably some wiki update is needed.
IMHO, bisect repositories should be as similar a release ones ( not counting languages, help, etc for size reasons ) so if LibreOfficeLinux.conf doesn't have --without-system-nss, Linux_bisect shouldn't either
(In reply to Timur from comment #28) > 1. Will "Update libxmlsec to 1.3.0" for newer LO leave as supported just > newer OS like Ubuntu 22.04, ditching all older OSes Yes - for generic builds. No - for targeted builds the --without-system-nss could be added by Ubuntu/Debian package maintainers when they create new packages for 20.04 etc.
@Timur, the repo has been rebuilt and updated. Please pull it and test it.
Fine now, thanks.
I've set up a centos7 build environment, also an Ubuntu 18.04 environment where I can test the build result. https://gerrit.libreoffice.org/c/core/+/152747 is my next attempt to get libreoffice to move away from the old xmlsec-1.2, hopefully this time it won't break your use-case, Timur. Feedback is welcome. Thanks.
Thanks for that, Miklos. Master bibi repo is 9 days old, I will see this when updated.
7.6 is not updated for 3 weeks, but regardless, I can use 24.2 in Ubuntu 18.04, I guess that means all is OK, thanks Miklos.